BLE reconnect loop

[mondalaci]

I seldom test BLE, but I paired my UHK 80 to my Linux PC yesterday, disconnected the BLE connection, and kept using USB. I think I didn't delete the bond. Before going to bed, I put my PC to sleep, and when I woke it up today, my UHK 80 seemingly didn't work and was disconnected according to the OLED display.

I looked into the Zephyr log and saw the following repeating:

W: opcode 0x200a status 0x0d 
Bt connected to unknown (e8:9c:25:57:11:5f)
Bt disconnected from unknown (e8:9c:25:57:11:5f), reason 5
NUS and HID advertising successfully started
USB config changing to Hid_Full
USB config changing to Hid_Full
W: opcode 0x200a status 0x0d 
Bt connected to unknown (e8:9c:25:57:11:5f)
Bt disconnected from unknown (e8:9c:25:57:11:5f), reason 5
NUS and HID advertising successfully started
USB config changing to Hid_Full
USB config changing to Hid_Full
W: opcode 0x200a status 0x0d 
Bt connected to unknown (e8:9c:25:57:11:5f)
Bt disconnected from unknown (e8:9c:25:57:11:5f), reason 5
NUS and HID advertising successfully started
USB config changing to Hid_Full
USB config changing to Hid_Full

I'm unsure about the best solution but feel free to make suggestions. Maybe the firmware should simply stop trying to connect after a certain number of failures within a timeframe per host connection. I'm on master.

[mhantsch]

Oh, that confirms that I'm not alone seeing this. When I tried playing with Bluetooth on my UHK 80 and Linux systems, I often end up in a state where Linux desktop notifications pop up: "UHK 80 connected", "UHK 80 disconnected", "UHK 80 connected", "UHK 80 disconnected" etc. and it never ends until I plug in the UHK via USB, or sometimes I need to "forget" the pairing on the Linux system. I haven't figured out a reproducible sequence, but I have real difficulty pairing the UHK. I need to use commandline and issue a few times a random sequence of these commands:

• bluetoothctl connect <uhk80-mac-address>
• bluetoothctl pair <uhk80-mac-address>
• bluetoothctl trust <uhk80-mac-address>

Sometimes along this process, finally the pop-up appears prompting me to enter the six-digit pairing code. Often this does not pop up and the UHK pairing starts but then fails. It seems very random. Sometimes after having done the "trust" command, it pairs. But then later after turning something off and on again, it enters the connect/disconnect loop with the neverending recurring notification pop-ups.

That's the best description I currently have.

[mondalaci]

Yes, I forgot about the incessant "UHK 80 connected" notifications I've also experienced.

[kareltucek]

GPT says 5 means authentication failure.

UHK acts as a peripheral in this interaction, so it should be the PC that stops obsessively trying to connect when it knows it cannot authenticate, shouldn't it?

(UHK isn't trying anything. It just advertises its features and responds to whoever tries to connect to it.)

The only thing I see that should be done about that is that UHK should not switch from USB HID to BLE HID until a connection is fully formed and secured.

[mondalaci]

The only thing I see that should be done about that is that UHK should not switch from USB HID to BLE HID until a connection is fully formed and secured.

Would this stop the incessant notifications on Linux?

UHK acts as a peripheral in this interaction, so it should be the PC that stops obsessively trying to connect when it knows it cannot authenticate, shouldn't it?

It probably should, but the world is a mess, and the UHK must handle these situations gracefully, even if the root cause is not our fault.

[kareltucek]

Would this stop the incessant notifications on Linux?

Maybe.

---

Also another story is why the authentication fails. Let's wait until the connection manager is merged. It fixes a couple of bluetooth bugs that may easily by the culprit...

[mhantsch]

another story is why the authentication fails

That is indeed the main culprit. It is super hard for me to get the UHK 80 to consistently pair. Once it is really paired, it works. But recent firmware upgrade blew it again, and I ended up in the reconnect loop. I suspect that somehow the keys of UHK and Host don't match anymore, and host is trying to keep connecting to a connection that doesn't match up on the UHK. But I may be wrong.

I had something similar with my ZMK keyboard, but after deleting BLE keys on the keyboard (on ZMK you can just configure a key to delete all BLE keys), they keyboard would pair again. Couldn't get that done on the UHK.

[mondalaci]

I paired my UHK 80 to my Windows 11 laptop. Then, I updated my UHK firmware to 12.3.2 from my Linux PC. Afterward, I saw the following looping on the right half:

Starting advertising, try 0!
NUS and HID advertising continued
Service discovery completed, connection wasn't matched.
Bt disconnected from unknown (a8:41:f4:11:a4:08), reason 19
Starting advertising, try 0!
NUS and HID advertising continued
connected unknown (a8:41:f4:11:a4:08), 0 10
Bt connected to unknown. Starting discovery.
Service discovery completed, connection wasn't matched.
Bt disconnected from unknown (a8:41:f4:11:a4:08), reason 19
Starting advertising, try 0!
NUS and HID advertising continued
connected unknown (a8:41:f4:11:a4:08), 0 10
Bt connected to unknown. Starting discovery.
Starting advertising, try 0!

The messages are somewhat different, but the issue may be the same.

[TPHRyan]

I'm getting this issue with my UHK 80 too (on NixOS, Linux 6.16.0 currently)

I have been using BLE purely to rule out interface issues with some problems I'm experiencing regarding character repeats (or delayed entry), but prefer to use USB as I have no battery.

Device identifies as follows:

[NEW] Device E7:87:A8:E3:E5:40 UHK 80 BLE

Output from bluetoothctl when first connecting (USB connected to power only):

[bluetoothctl]> connect E7:87:A8:E3:E5:40 
Attempting to connect to E7:87:A8:E3:E5:40
[CHG] Device E7:87:A8:E3:E5:40 Connected: yes
Connection successful
...
[CHG] Device E7:87:A8:E3:E5:40 Connected: no
[CHG] Device E7:87:A8:E3:E5:40 Connected: yes
[CHG] Device E7:87:A8:E3:E5:40 Modalias: usb:v37A8p8009d0001
[CHG] Device E7:87:A8:E3:E5:40 ServicesResolved: yes
[CHG] Device E7:87:A8:E3:E5:40 Name: UHK 80 Right NUS
[CHG] Device E7:87:A8:E3:E5:40 Alias: UHK 80 Right NUS

(Is the device name correct, or possibly related to #1110?)

Device disconnects normally when I unplug from power, and then later I plug in into USB. The following occurs:

[CHG] Device E7:87:A8:E3:E5:40 Connected: no
[CHG] Device E7:87:A8:E3:E5:40 Connected: yes
[SIGNAL] org.bluez.Device1.Disconnected org.bluez.Reason.Authentication Connection terminated due to authentication failure
[CHG] Device E7:87:A8:E3:E5:40 Connected: no
[CHG] Device E7:87:A8:E3:E5:40 Connected: yes
[SIGNAL] org.bluez.Device1.Disconnected org.bluez.Reason.Authentication Connection terminated due to authentication failure

(and so on, until I unplug and call disconnect <mac-address> in bluetoothctl)

Apologies, I'm not set up to provide firmware logs or anything.

[mondalaci]

@kareltucek Would firmware logs gathered via Agent be useful for this issue?

[kareltucek]

Not to me at the moment.

[mondalaci]

@kareltucek Please elaborate on the suspected root cause and whether it's c2usb-related.

[kareltucek]

Well, a reconnect loop is only a secondary problem. Primary problem is that pairing with Linux doesn't work.

As to the pairing problem:

• Since GATT negotiation interferes with the pairing, it may be partially c2usb-related as far as I can tell, although I vaguely remember Benedek denying it.
• One problem is that the GATT exchange uses far too long messages (more than 72 bytes), which leads to the messages being split into more than 3 packets, which in turn makes Zephyr drop the connection (without any error message 😡).
  • This is fixed (or rather worked around) by this PR: Fix linux pairing. #1262 , which enables data length extension immediately after connection is established without waiting for the connection to get authenticated (which is current master behavior).
  • I have raised this ticket: https://devzone.nordicsemi.com/f/nordic-q-a/122025/ble-pairing-with-linux---zero-distribution-flags in which however Edvin seems to ignore the provided evidence which makes me doubt whether following his instructions is worthwhile at all.
• In any case, I have dropped the pairing issue due to priorities and due to lack of expertise needed to solve this for the time being. It would be very welcome if Benedek could look into it and solve it.

Regarding the reconnect loop:

• it relates to the way we advertise. We have 4 or so advertising strategies (normal connectable broadcast, true direct connectable advertising, allow-list-restricted connectable broadcast advertising, and scannable non-connectable broadcast advertising). There is a number of problems with this:
  • some of them cause problems, for instance they prevent pairing with some systems, and we don't know which cause problems, or why they cause problems.
• at the end of the day part of the answer will be employing a state machine that employs a non-connectable scannable broadcast advertising somehow. While we do have a working proof-of-concept implementation (WIP: Scannable advertising #1271), we don't know how we want to use it, especially in a way that furthers our other agendas (like pairing that works against all OSes).

There are also other related problems:

• Iirc., there are a couple of tickets on Benedek that ask him to fix the true directed advertising that currently doesn't work.
• Afaik, your stance with respect to a visible NUS advertising is that it is not acceptable, which further complicates all the restrictions on the entire system and, as long as pairing and direct advertising are unresolved, makes it pointless to try to implement any (semi)final solution.
• My experience with Android pairing is that zephyr ble + c2usb stack is unreliable.
• Iirc there might be standing tickets that ask Benedek to refactor c2usb so that it supports multiple ble hids better?
  • (As far as I know, c2usb hooks directly into the bluetooth stack and doesn't communicate with us about which hosts should be served as BLE HID hosts, which complicates working around c2usb limitations.)

[mondalaci]

@benedekkupper Can you weigh in?

[kareltucek]

(My bottom line is that it would be nice if we could fix linux pairing now.)