Attachments (3) Download All
Nordic Case Info
  • Case ID: 346492
Options

Ble pairing with linux - zero distribution flags

kat829

Hi!

We are having problems pairing a nRF52840 against linux (ubuntu 25.04). Pairing fails instantly, before any passkey is shown on the host, returning with code 9.

Short log is here:



AI back and forths suggest that the host PC cancels pairing because it receives the zero distribution flags in
```
<dbg> bt_smp: smp_pairing_req: rsp: io_capability 0x02, oob_flag 0x00, auth_req 0x0D, max_key_size 0x10, init_key_dist 0x00, resp_key_dist 0x00
```

Detailed logs (attaching file here doesn't work, so linking externally):
- zephyr with hci_core and smp logging: http://ktweb.cz/upload/logs2/right.log
- the same, but filtered: http://ktweb.cz/upload/logs2/right_filtered.log
- btmon log: http://ktweb.cz/upload/logs2/btmon.log

Any ideas what the problem might be and where to look further?

EDIT: here is wireshark log (paired from gui this time):

- fails on gatt instead http://ktweb.cz/upload/logs2/wireshark_linux_pairing.pcapng (This is probably our problem, since gatt is handled by an external service.)
- this one actually contains pairing attempt similar to the key distribution problem: http://ktweb.cz/upload/logs2/wireshark_linux_pairing2.pcapng

EDIT2 my updated conclusions and hypotheses:
- I think that the distribution flags are correct and (on of the) troubles is that zephyr doesn't reply with its own keys within the next 400ms or so.
- Looks like key generation takes too long on zephyr side. Before it is finished, the connection gets terminated.
- Reason for termination seems to be related to gatt and the ll buffers. Right before the connection is determined as disconnected, I see this check to fail in conn.c. Increasing the number doesn't fix the issue, but results in increased number of calls to bt_conn_tx_processor before failure (which is where the disconnect is determined):


- my guess is that the bt_conn_tx_processor is triggered by receiving the gatt requests
- successful pairing against android http://ktweb.cz/upload/logs2/wireshark_android_pairing.pcapng
- there is a minor difference between linux and android flow. I think it is not important, but it should be noted that we are trying to achieve security level 4:


- failed pairing with the number from above excerpt increased 3 to 12 and buffer count: http://ktweb.cz/upload/logs2/wireshark_linux_pairing3.pcapng (flood of gatt packets from central to peripheral)
- This makes me think that either linux simply overwhelms zephyr with gatt requests, or there is some problem with our gatt provider (which is implemented by a custom implementation from c2usb). Still will be grateful for any thoughts on the subject.

Parents
  • 0

    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?

  • 0 in reply to kat829
    kat829 said:

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

    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

  • 0 in reply to kat829

    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:

    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

  • 0 in reply to Edvin

    > 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:

     wireshark_linux_pairing4_with_clock_control.pcapng

  • 0 in reply to kat829
    kat829 said:
    > 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

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

    kat829 said:
    To be precise, it drops the connection. 

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

    Best regards,

    Edvin

  • 0 in reply to Edvin

    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:



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

  • 0 in reply to kat829

    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.)

Reply
  • 0 in reply to kat829

    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.)

Children
  • 0 in reply to kat829
    kat829 said:

    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. 

    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

Terms of service