Yet another bluetooth thread

I’ve read the article, and seems like I’ve already tried most the advices or they are just not applicable due to absence of the options in interface. (I’ve looked into developer options as well)

Also, as soon as btmon log says
Result: Connection refused - security block (0x0003) Status: No further information available (0x0000)
and Reason: Authentication Failure (0x05) it is more likely to be related to some handshake fail during establishing connection or pairing, rather than any power management timeouts. (if it was power management - it should work for some time and then loose connection, but it is disconnect is immediate)

I am no bluetooth expert, but for anology - I had to troubleshoot enough of SSL issues, that usually are result of mismatch between client and server capabilites/ciphers/auth methods.
My guess at the moment is that phone requires some auth mechanism that is not available on mod duo x, some mode is not supported or something like that.

Anyway, probably my main way out is to get more and more verbose logs until some messages will lead to the usefull infromation or solution to be googled.

I’ve also recorded bluetooth snoop (trace) , where it is better visibility on destination and source for the traffic packets in Wireshark. As far as I can see, phone is requesting connection and mod duox is rejecting it:

I’ve uploaded this trace to google drive trace - Google Drive just in case. (forum does not allow to attach anything but pictures)

At this point I am trying to understand how bluetoothd is launched on the device, to configure it to get some logs from this service as well.

It could help if you could point me into parts of the mod duo bluetooth stack where I can retrieve more information.

2 Likes

Fair enough. As I said I didn’t really dig deep into the article and just took an overview.

Thanks a lot for all the info. As we already had a couple of reports of this happening, particularly with the MOD DuoX, I guess that maybe an investigation is worthed. I will ping the developers for that.

1 Like

Okay, looks like I found a solution for my 4.0 dongle at least.
I will share my findings, but if somebody except for MOD devs is going to follow my steps - be warned, I have no idea on the side effects, not an expert on the mod devices and bluetooth, I am just a nerd with access to google, and you can break something on your mod device by applying such changes. I am doing this on Mod Duo X to fix my particular issue with a particular dongle.
Also, sadly it did not fix anything for my 5.0 dongle.

With disclaimers done, here is my yet another dirty hack solution, now for the CSR8510 A10 0a12:0001 4.0 dongle.

Preflight check:

You can -probably- more or less safely check if it is a solution in your case by enabling Simple Paring mode just on the fly. It is enabled by running /usr/bin/hciconfig hci0 sspmode 1 when your dongle is plugged in. After running this command, you can try to re-pair your phone to the Mod Duo X , it should not ask for pin code during pairing.

This simple pairing mode will be washed away by replugging the dongle or device reboot/powerycle, and new pairings will fail. Existing pairing information might be preserved though (not sure, i was too concentrated on the permament fix to test it properly, but my foggy memories tell me that I still was able to connect to the mod device with the already properly paired phone even after reboot. Not sure, actually, it was 4am when I was doing this.)

If it does not work, you might also try remove your dongle’s MAC folder in /data/bluetooth by rm /data/bluetooth/YOUR_DONGLES_MAC_ADDRESS_IN_UPPERCASE and powercycle the device and try setting Simple pairing mode again.

Permanent fix

All these actions below are to ensure that Simple Paring mode is enabled on the hci bluetooth device automatically when dongle is being inserted or device is starting. The instruction below is going to modify the system to apply this change permanently for all future pairings and dongles. Therefore it is a potentially dangerous change.

I expect these changes to be washed away with a firmware update though.

  • First of all, I am creating a script /data/fixbt.sh that waits a couple of seconds (allowing bnep service to start up) and enables Simple pairing on the dongle. Waiting is implemented as a ping, lol, because there was no sleep command out the box. Code below uses echo to create this script per line:
echo  "#!/bin/bash"                                    > /data/fixbt.sh
echo  "ping localhost -w 2"                            >> /data/fixbt.sh
echo  "/usr/bin/hciconfig hci0 sspmode 1"    >> /data/fixbt.sh
chmod ugo+x  /data/fixbt.sh
cat /data/fixbt.sh
  • Second, we are going to modify UDEV rules to invoke this script after dongle is connected.
mount / -o remount,rw     # remount filesystem to write mode
cp /etc/udev/rules.d/96-bnep.rules  /data/96-bnep.rules.bkp  #make backup copy of the file we are going to modify.
nano /etc/udev/rules.d/96-bnep.rules     #edit udev rule. Hope you know how to work with nano editor.

We should add the following text to the end of the first line:

, RUN+="/bin/bash /data/fixbt.sh"
Pay attention to the comma , that divides multiple RUNs for the single “add” acion.

This modification forces UDEV to invoke our fix script when dongle is connected.

  • Also I am always cleaning all 00:… folders in /data/bluetooth/ folder between bluetooth experiments.
    These folders are named after mac addreses of your bluetooth dongles, and contain some information on the dongles and other bluetooth devices mod duo is communicating with. My guess is that cleaning these folder forces mod duo x to forget all the faulty pairings I’ve done before
    I am not sure if it matters, actually, or will you even have MACs starting with 00: as well as me.
    Probably you should see folder content by ls /data/bluetooth to make your own opinion on that.

image

Anyway, I clean them with rm /data/bluetooth/00* -r

  • Now let’s reboot the box (maybe I am wrong, but seems like chances are that nothing will be saved on the filesystem if you will just cut the power using power switch. Also it might be not good for the filesystem, i guess.

reboot

  • NOW we can do the powercycle by toggling the power switch back and forth.

  • Actually that’s all. Now, as result, my phone pairs with ModDuoX easilly, it even does not ask for pin. Browser access works via 192.168.50.1 just fine. (slow, but that’s bluetooth)

P.S.

Also, you can check if my fix script is actually doing what it is supposed to do by starting
watch /usr/bin/hciconfig hci0 sspmode

image

  1. unplug bluetooth dongle,
  2. start watching,
  3. plug bluetooth dongle.
  4. watched hciconfig output will appear and write that Simple Paring mode: Disabled
  5. after a couple of seconds it will start showing Simple Pairing mode: Enabled.

If behaviour is as above, my script does what I expect from it and is called by UDEV rule properly.


@jon I guess this proves that issue can be potentionaly fixed on the mod device side. Might it be possible to have this simple pairing mode added to system->bluetooth menu as an option to enable?

4 Likes

Thank you a lot for all the research and sharing this with us @ignis32! :slight_smile:
I will pass it to the dev team since maybe this may help solving certain issues permanently (if it does not break anything else).

Certainly! Also that the issue may be on the MOD device side (what we were not expecting before).

I will save the request…but I guess yes :slight_smile:

2 Likes

I’m wondering if there is an update. I just bought a bluetooth adapter (BT 5, since I thought anything 3 and above would work) and it’s listed as unsupported. It came with directions on how to download the firmware and everything above in this thread is well above my skill set, so I’m not sure what I would do with the firmware. What’s the easiest way to find a BT dongle that will work? Other options (Wifi looks kind of complicated). Here’s the link to the device: https://avantree.com/dg45-usb-bluetooth-dongle-for-pc

Thanks!

1 Like

Bluetooth 5.0 dongles are indeed lagging and require some more testing on our side.

We have a few forum post on that and also a wiki para that is outdated:

2 Likes

I replaced it with a BT 4 dongle and it connected easily to the last generation of intel iPad Pro without issue, but it was deadly slow in terms of being able to load effects and adjust things.

3 Likes

That is expected - at least that it’s slower than USB

1 Like

I’ve managed to get my hands on the recommended bluetooth dongle for the ModDwarf. MY device recognizes it, and allows me to turn on discorverability – HOWEVER, it seems like the signal isn’t actually being broadcast at all. The bluetooth device “Mod Dwarf” isn’t listed on my Mac, iOS devices, my Windows PC nor my PopOS/Ubuntu PC.

Is the trick then to just to use 4.0? I have tried 5.1, 5.0 and yet to tri 4.1 or 4.0.

2 Likes

On MacOs things are broken on the Apple side since the latest update.
On others, it should work. What is the IP that you are trying to reach? 192.168.50.1?

3 Likes

gotcha – I’m unable to even try for an IP address yet, as I haven’t been able to complete a successful Bluetooth handshake (as in, select “Mod Dwarf” from discoverable Bluetooth devices list, on Windows, Linux (or iOS and Macbook, which is currently broken as you’ve just metioned)

1 Like

I should mention that I’ve only just found out about this:
https://wiki.moddevices.com/wiki/WiFi

Which seems awesome – and preferred for me tbh.

Will try this and report back.

3 Likes

Do you mean that when you try to pair the devices the connection doesn’t hold on?
I’m asking because just yesterday we were investigating this. Basically the behaviour is/was that you flick the switch on the host device for the connection to happen, it seems that happens, but after 1 or 2 seconds it switches back. Is this what is happening with you?

Regarding the wi-fi, please note that that is still an experimental feature.

1 Like

Sounds similar to my problem that I’d fixed by /usr/bin/hciconfig hci0 sspmode 1

2 Likes

Sitting here poking the Web ui on my android tablet screen with no lag, I just wanted to say thanks for this solution :+1: the router works great straight out of the box and gives the modx a reprieve from the reverb walk of shame due to it having been such a pain in the a** to edit (I hate dragging the laptop out just to make a quick edit). This one gets a huge recommendation from me! :beers:

6 Likes

STILL NO LUCK. I’m really starting to hate this thing.

What Bluetooth dongle are you using @robjac?
As far as I know, the 1.13 OS that just got into the release candidate stage will bring some improvements to the supported Bluetooth dongles.
If we know which one are you using we can try to check if it’s covered and/or replicate your issue. That will help to solve it.

3 Likes

Updating all devices now! ; but I have the one listed in the wiki recommendations. I also have an EVGA 5.1 lying around.

Web UI was intermittently failing to connect over USB for me too. just would timeout continuously. of course everything works better when using at my home studio. LOL

2 Likes

The 1.13 was not yet released for all units. It’s still in a release candidate which means that users can manually install it, but bugs can still be found and need to be fixed for the official release.

1 Like

Heya!
Dropping by this thread to check.
I ordered a 5.1 Bluetooth dongle before I saw this…
I’m not sure if I should wait for the improved firmware update OR just buy this dongle: Amazon.nl

Any suggestions/feedback?

Thanks!