• State Verified Answer
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 3260 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

    It will take some time for us to be able to sniff the ble traffic to a level that will help. In the meantime I think I have found what is going on and have some further questions. On every connection, if our MTU is not default 23, we send an MTU exchange request. On the first connection the bluez based central sends a MTU exchange response and everyhing is fine. On the second connection we never receive an MTU echange response and 30 seconds later we timeout and disconnect. I do think that bluez is in error here although they wonder why the peripheral is sending an MTU request when we are already bonded/paired. My question is, is there a way to have the software on the peripheral only send an MTU exchange request on the first connection to a central and not again on the subsequent connections to a bonded/paired central?

Reply
  • 0

    It will take some time for us to be able to sniff the ble traffic to a level that will help. In the meantime I think I have found what is going on and have some further questions. On every connection, if our MTU is not default 23, we send an MTU exchange request. On the first connection the bluez based central sends a MTU exchange response and everyhing is fine. On the second connection we never receive an MTU echange response and 30 seconds later we timeout and disconnect. I do think that bluez is in error here although they wonder why the peripheral is sending an MTU request when we are already bonded/paired. My question is, is there a way to have the software on the peripheral only send an MTU exchange request on the first connection to a central and not again on the subsequent connections to a bonded/paired central?

Children
No Data
Related