• State Verified Answer
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 3264 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 127320
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

I am having a problem on the second connect after bonding to a bluez 5.43 central

jlarsen

I can connect/pair/bond to the nrfConnect app and disconnect then reconnect just fine. When I try to do the same to a central running on arm bluez 5.43, the second and subsequent connections timeout after about 30 seconds and the peripheral gets a BLE_GATTC_EVT_TIMEOUT and disconnects.

I have wireshark cptures of the nrf Connect connections and the failing connection to my central.

1st and 2nd connections working as expected rfconnect.pcapng

1st connection mycentral.pcapng

2nd connection (disconnected by peripheral after 30 seconds) mycentral2.pcapng

Parents
  • 0

    Hi Larsen,

    It's not clear in mycentral2.pcapng what exactly cause the disconnection. The connection timeout was set to 52.5 seconds, but the connection was terminated much earlier than that.

    A BLE_GATTC_EVT_TIMEOUT meaning there was a write request sent but never get a response. Do you do any write request from the nRF5 side ?

    Since the sniffer file the encrypted packets was not decrypted correctly I can't tell what could be wrong here. I suspect the LTK keys was not stored correctly.

    You may want try sniffing again and try to sniff with one take that cover both the first connection (when they bond) and the second connection, all in one sniffer trace.

    If you test with something like the ble_app_proximity and test bonding and reconnect, do you have the same problem ?

    Which chip and softdevice were you using ? nRF51 and S132 don't go together.

Reply
  • 0

    Hi Larsen,

    It's not clear in mycentral2.pcapng what exactly cause the disconnection. The connection timeout was set to 52.5 seconds, but the connection was terminated much earlier than that.

    A BLE_GATTC_EVT_TIMEOUT meaning there was a write request sent but never get a response. Do you do any write request from the nRF5 side ?

    Since the sniffer file the encrypted packets was not decrypted correctly I can't tell what could be wrong here. I suspect the LTK keys was not stored correctly.

    You may want try sniffing again and try to sniff with one take that cover both the first connection (when they bond) and the second connection, all in one sniffer trace.

    If you test with something like the ble_app_proximity and test bonding and reconnect, do you have the same problem ?

    Which chip and softdevice were you using ? nRF51 and S132 don't go together.

Children
No Data
Related