6 months ago
No Indication when Exchange MTU Response not received
Posted byrparkinson20 points 7 repliesIn our BLE peripheral using DA14581, upon connection the peripheral sends an Exchange MTU Request and typically receives an Exchange MTU Response. We have run across iOS devices which following the DA14581 sending the Exchange MTU Request, the iOS device sends an Exchange MTU Request and the DA14581 sends an Exchange MTU Response. At this point the iOS device sends a Write Request to a DA14581 characteristic. The DA14581 sends a Write Response and would typically then send an Indication. In the case where the exchange MTU sequence occurs as described no indication is ever sent even though the two sides have successfully negotiated the MTU.
Is the lack of receiving the Exchange MTU Response in this instance keeping the DA14581 in a state where it does not perform indications?
Thanks for your help.
6 months ago
当然,我将附上文件嗅探器. This has only been observed with iOS. We have used Android extensively and have never seen this issue.
Per the sniffer file, this problematic MTU exchange occurs at frames 1169250, 169448 & 169460. The first Write Request arrives to the DA14581 at frame 169758 and there is a Write Response. Our System would always then send an Indication, however in this case it does not.
| Attachment | Size |
|---|---|
| Sniffer | 2 MB |
6 months ago
Hi rparkinson,
Thanks for sharing the sniffer log – I’ll go thought it. Can you please also in date the SDK version? Is it SDK5.0.4?
Thanks, PM_Dialog
6 months ago
Hi rparkinson,
Thanks for the indication. I have escalated this internally, so I’ll get back to you as soon as I have feedback from the Team.
Thanks, PM_Dialog
6 months ago
Hi rparkinson,
According to the Bluetooth LE 4.0 spec, DA14580 has sent a MTU_exchange request and waiting for an MTU exchange response. If this response is not coming from the iPhone (the client) then sending a security request is not a good approach.
We suppose that your need is to decouple MTU exchange request and the security request calling mechanism so that MTU exchange takes place first and then security request will be sent from DA14580.
When a Response to an MTU Exchange Request is pending the device cannot send Indications or Notifications. Obviously, the iOS stack erroneously dropped the Request due to probable conflict with the security process under way. In order not to confuse the iOS stack it is recommended that the Exchange MTU request is decoupled from the Security Request by issuing the MTU request is first and then upon completion the Security Request.
Thanks, PM_Dialog
4 months ago
Hi, we have updated our peripheral device which uses the Dialog 14581 to behave as you recommended, decouple MTU exchange request and the security request calling mechanism so that MTU exchange takes place first and then security request will be sent from DA14580." Unfortunately this change had no impact on the issue we are running into when connecting to certain iOS devices. My specific question is this: in this problematic iOS case after Dialog sends the Exchange MTU Request, iOS sends the Exchange MTU Request and Dialog sends the Exchange MTU Response. While this isn't a sequence covered by the spec, the MTU has been successfully negotiated and that should be adequate to allow Dialog to begin sending Indications. Would such a design update within Dialog be possible to handle this situation?
Thanks and I appreciate your consideration.
6 months ago
Hi rparkinson,
Thanks for your question online. Would it be possible to share a sniffer log, so that I can go through it and understand what is happening over the air? Does this behavior occur only with iOS?
Thanks, PM_Dialog