Ble pairing with linux - zero distribution flags

RE: Ble pairing with linux - zero distribution flags

Edvin — Fri, 27 Jun 2025 20:20:57 GMT

[quote user="kat829"]

i don't think it's a hardware issue. if the connection between the halves is stable, it should also be stable between the right half and any other peer. we're using a proven 3rd party wireless module, and the module have been integrated into the uhk 80 according to the datasheet

I would take it with a grain of salt though.

[/quote]

Does that mean that you tested the same connection interval on the same device?

Just in case the issue is also present on your HFXO, can you please try to use the internal RC Oscillator?

USe this in prj.conf:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

Also, you can experiment with all of the sources, and minmizing the accuracy of the LFCLK by setting:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

And see if that changes anything.

Best regards,

Edvin

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 27 Jun 2025 12:53:41 GMT

As for more logs, I have the hci_core and smp logs that I posted in the pack (right.log).

Should I try gather more?

(Generally, capturing logs at debug level is difficult, because there is too many logs and so the logging system keeps dropping messages.)

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 27 Jun 2025 12:51:02 GMT

Sorry, Laszlo Monda from us said it.

> Do you have the logs from the peripheral? Does it also see a disconnection? Or does it see an application reset?

It sees a disconnection.

Furthermore, shortly before the disconnect, the code goes all the way through the true return path in should_stop_tx in `./subsys/bluetooth/host/conn.c`, suggesting that zephyr deliberately drops the connection:

static bool should_stop_tx(struct bt_conn *conn)
    ...
	if (atomic_get(&conn->in_ll) < 3) {
	   ...
	   return false;
	}
    return true;
}

(As noted above, enabling data length extension fixes this mode of failure.)

RE: Ble pairing with linux - zero distribution flags

Edvin — Fri, 27 Jun 2025 12:38:33 GMT

[quote user="kat829"]> i don't think it's a hardware issue. if the connection between the halves is stable, it should also be stable between the right half and any other peer. we're using a proven 3rd party wireless module, and the module have been integrated into the uhk 80 according to the datasheet[/quote]

Is that someone from us who said that? If so, do you have the link to the ticket where this is stated?

[quote user="kat829"]To be precise, it drops the connection. [/quote]

Do you have the logs from the peripheral? Does it also see a disconnection? Or does it see an application reset?

Best regards,

Edvin

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 27 Jun 2025 11:51:07 GMT

> Ok, so it looks like the peripheral application crashes/resets.

To be precise, it drops the connection.

> I also noticed that there are a lot of retransmissions from the central, meaning the peripheral doesn't reply to a lot of the messages. Is this a custom board? Did you have your design through a design review? If not, I recommend that you do that, to make sure that all the clocks are configured correctly.

Yes, it is a custom board.

I have forwarded this question and got:

> i don't think it's a hardware issue. if the connection between the halves is stable, it should also be stable between the right half and any other peer. we're using a proven 3rd party wireless module, and the module have been integrated into the uhk 80 according to the datasheet

I would take it with a grain of salt though.

> I suspect that all of the failed pairing attempts are caused by the devices not being able to maintain the BLE connection:

As noted above, it looks like zephyr intentionally drops the connection in should_stop_tx.

> CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

With this, I am getting slightly different results:

devzone.nordicsemi.com/.../wireshark_5F00_linux_5F00_pairing4_5F00_with_5F00_clock_5F00_control.pcapng

RE: Ble pairing with linux - zero distribution flags

Edvin — Mon, 16 Jun 2025 10:22:40 GMT

Ok, so it looks like the peripheral application crashes/resets. Looking at the sniffer traces, you can see that from some point, all the messages are coming from the central, before the peripheral starts advertising.

I also noticed that there are a lot of retransmissions from the central, meaning the peripheral doesn't reply to a lot of the messages. Is this a custom board? Did you have your design through a design review? If not, I recommend that you do that, to make sure that all the clocks are configured correctly.

I suspect that all of the failed pairing attempts are caused by the devices not being able to maintain the BLE connection:

<inf> Bt: Received passkey pairing inquiry.
<inf> Bt: Type `uhk passkey xxxxxx` to pair, or `uhk passkey -1` to reject
<wrn> bt_conn: conn 0x20010498: not connected[0m
<dbg> bt_smp: bt_smp_disconnected: chan 0x20010b9c cid 0x0006
<dbg> bt_smp: smp_pairing_complete: got status 0x8
<dbg> bt_smp: bt_smp_encrypt_change: chan 0x20010b9c conn 0x20010498 handle 1 encrypt 0x00 hci status 0x1f 
<wrn> Bt: Bt security failed: n/a (n/a, 98:5f:41:d2:92:3a), level 1, err 9, disconnecting
<wrn> Bt: The connection (n/a (n/a, 98:5f:41:d2:92:3a)) isn't even connected! Ignoring.[0m
<wrn> Bt: Pairing of auth conn failed because of 9
<wrn> Bt: Pairing failed: n/a (n/a, 98:5f:41:d2:92:3a), reason 9

For a quick check, can you please try to set your LFCLKSRC to SYNTH (meaning it is derived from the HFXTAL). How to do it depends on what NCS version you are using. If you are using v2.x.x, you can set

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

And see if it is able to maintain the connection.

Best regards,

Edvin

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 13 Jun 2025 12:06:12 GMT

Sure!

devzone.nordicsemi.com/.../1374.logs.zip

RE: Ble pairing with linux - zero distribution flags

Edvin — Fri, 13 Jun 2025 11:48:55 GMT

[quote user="kat829"]What I meant is that we are using the default zephyr host implementation[/quote]

Ok, yes. That is the intended way. You shouldn't change anything in the bluetooth host implementation, so that is good.

I know that DevZone has some hickups some times, but can you please try to upload your attachments again? I am still not able to see them.

Best regards,

Edvin

RE: Ble pairing with linux - zero distribution flags

kat829 — Thu, 12 Jun 2025 10:42:13 GMT

Oops, sorry. We are actually using the SoftDevice controller: i.e., CONFIG_BT_LL_SOFTDEVICE=y.

What I meant is that we are using the default zephyr host implementation (by which I mean that we have not reimplemented or customized the zephyr/subsys/bluetooth functionality). Zephyr 3.7.99 to be specific.

RE: Ble pairing with linux - zero distribution flags

Edvin — Thu, 12 Jun 2025 09:31:25 GMT

Ok, I understand. So it is in fact not an HCI dongle. It is a peripheral application. A BLE keyboard.

(An HCI dongle/device is the typical "bluetooth dongle" that you can buy and plug in your computer to give it Bluetooth capabilities, if your computer doesn't have Bluetooth)

[quote user="kat829"]this device uses zephyr bluetooth stack[/quote]

In that case, I recommend that you look into using the Nordic SoftDevice Controller instead of the Zephyr Bluetooth controller. I believe we (Nordic) were involved in the zephyr bluetooth controller at some point, but I am not sure it is maintained, or who maintains it. At least, we do not support that bluetooth controller.

Check if the issue still persists if you change to the SoftDevice controller.

Best regards,

Edvin

RE: Ble pairing with linux - zero distribution flags

kat829 — Thu, 12 Jun 2025 08:40:55 GMT

I am not sure what you mean by "HCI dongle".

The setup is as follows:

- nRF52840 DevKit with the nrf sniffer - this is the source of wireshark/pcapng sniffs
- ubuntu linux (the central) - this is where btmon log is from
- uhk80 (a bluetooth keyboard; the peripheral) right half, which is a nRF52840-powered board. This acts as a peripheral.
- right.log comes from there (gathered over uart), with CONFIG_BT_SMP=y and CONFIG_BT_HCI_CORE_LOG_LEVEL_DBG=y if I am not mistaken
- this device uses zephyr bluetooth stack, with c2usb to handle USB HID and BLE HID. C2usb also provides the gatt service. It hooks in via udc_mac.

RE: Ble pairing with linux - zero distribution flags

Edvin — Wed, 11 Jun 2025 19:44:07 GMT

[quote user="kat829"]

What exactly is the problem there? Tested multiple times...

[/quote]

It won't open. I guess it is the company firewall.

Are you using the nRF52840 as a HCI dongle? This still isn't clear to me. (I see that hci is mentioned in the log from your initial post, the one pasted into the added text box, but there is HCI logging in normal samples (not just HCI) running on our devices as well. HCI will always be the communication layer between the application and the Bluetooth Controller).

So are the logs from your computer, or from the nRF? And what application is running on your nRF52840?

Best regards,

Edvin

RE: Ble pairing with linux - zero distribution flags

kat829 — Sat, 07 Jun 2025 17:53:50 GMT

Well:

- (Earlier, I tried increasing various buffer counts, including the acl tx, without any success.)
- I have traced the disconnect to an exhaustion of acl buffers.
- After seeing a 69 byte message getting chunked into 3 packets / messages, I have realized that with default LE payload length of 27 bytes, running out of buffers isn't all that surprising.
- I have tried to enable the data length extension right after connection callback kicks in.
- This did the trick.

I am still not sure what a proper solution should be or what part of the stack and of development process is actually to be blamed.

But I wonder, wouldn't it be nice if zephyr logged a warn (or maybe an error!) in situations like these - when it decides to drop a connection because of an unexpected failure?

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 06 Jun 2025 21:07:13 GMT

devzone.nordicsemi.com/.../8666.logs.zip

Works from android.

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 06 Jun 2025 20:55:28 GMT

Actually, this chromium shows an "Upload file(s)" overlay on hover, but doesn't do anything on dropping.

RE: Ble pairing with linux - zero distribution flags

kat829 — Fri, 06 Jun 2025 20:52:05 GMT

Hi Edvin!

> I am not able to download your ktwebs.cz file

What exactly is the problem there? Tested multiple times...

File dropping doesn't work very well for me.

- Neither work laptop with firefox nor chromium on home laptop reacts to dropping files at all.
- Home firefox reacts by showing an error that `The file at /home/me/mnt/www/upload/logs2/btmon.log is not readable.` which is not surprising given sandboxing policies of modern browsers.

Also the reply button doesn't actually open an editor in 9 of 10 tries. (Same problem in firefox 139.0.1 and chromium 137.0.7151.55 which are fairly up-to-date browsers. Finally managed to send this from the chromium, sadly without any files.)

---------

I didn't get a pop-up. Connection is terminated within 420ms of the moment that packet arrives, so the pc doesn't have much time to show it.

The message actually says xxxxxx, but it is literally printed that way by our code. I don't think there is any problem with that part - the procedure works fine with android.

------------

The project is github.com/.../firmware . If you want to take look, points of interest are `device/prj.conf.overlays/*` and `device/src/bt_*`, and also c2usb/c2usb/port/zephyr/bluetooth/hid.cp in github.com/.../c2usb

We have two related issues open:
- macos issue github.com/.../1228
- linux issue github.com/.../999

Notably, while I am testing pairing with linux, macos pairing has broken between two versions where we are not aware of doing any bluetooth-related changes, so as far as we can tell the most likely culprit is switching to deferred logging, which may have to do with cpu time and timing.

RE: Ble pairing with linux - zero distribution flags

Edvin — Fri, 06 Jun 2025 19:58:12 GMT

Hello,

Please add comments instead of adding new information as edits (from this point), because it is difficult to keep track of new information (I don't have any changelog, just your final post, and I am not sure I will read it after replying now 🙂)

I am not able to download your ktwebs.cz files, can you please upload them here instead? Drag and drop, or hit the upload button in the text editor on DevZone (and then hit the gray text saying "upload" to browse to the file you want to upload).

So I am not sure what we are facing right now. The peripheral you are testing, is it one of our samples? If not, can you test with one of our samples to see if the issue is the same there?

[quote user=""]Short log is here:[/quote]

From your log, I see:

<inf> Bt: Type `uhk passkey xxxxxx` to pair, or `uhk passkey -1` to reject

Did you get a popup on the client/central side to enter this 6-digit number? And did your log actually say "xxxxxxxx", or did you replace the numbers with X'es?

Best regards,

Edvin