• State Not Answered
  • Replies 12 replies
  • Subscribers 70 subscribers
  • Views 2530 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 281058
Options

L2CAP Packet length mismatch in HCI_ACL packet causing packet loss

Lakshmikanth Satyavolu

Hi Community,

I am using ble_hrs_heart_rate_measurement_send API to send notifications to my central device which is a android mobile. 

Recently I have observed packet loss at central device due to L2CAP packet length is differ from ACL packet length. 

In the HCI_ACL packet, total length is 27. But in the ACL payload which is L2CAP packet length is showing as only 2. Total payload is present in L2CAP. 

Hence my application running on mobile is unable to fetch the packet from L2CAP since it is dropped at HCI. 

Attached is wireshark screen shot for reference. Highlighted packet was dropped at HCI. 

Where could be the issue ? Any pointers would be really helpful. 

Best

Lakshmikanth

Parents Reply Children
  • 0 in reply to Lakshmikanth Satyavolu

    Hi

    In the HCI_ACL packet, total length is 27. But in the ACL payload which is L2CAP packet length is showing as only 2

    Is the payload length=2 you mention is from the following?

    If so, I think this indicates the length of the "Data Total Length":

    As highlighted in this image after I click the Data Total Length, the two bytes are 1b 00, where 0x1b = 27.

    I am not able to find what the error is from this trace though.

    Recently I have observed packet loss at central device

    How do you experience the packet loss?

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi Sigrud,

    Thanks for response.

    Sorry for sending wrong file. Please find attached log(10-12-diff7.log) and screen shot of the problem.

    Check the packet number 3479 from snoop log. Which has total ACL Packet length is 27 (1b 00) circled in BLUE.

    But in L2CAP payload, length of L2CAP packet is shown as 02 00 (which was highlighted in RED circle). But total length of packet is 27 which matches ACL length. How could this happen? 

    Please compare this packet with other packets around it to see the difference. 

    Because the length of L2CAP was not populated properly, it is not getting recognized as a L2CAP data packet at the central device. Hence the packet is lost. 

    snooplog:- 

    10-12-diff7.log

    Sigurd Hellesvik said:
    How do you experience the packet loss?

    I am sending sequential data to the central and analyze the data by checking difference between each packet. 

    Hope this information is useful. 

    Please let me know if you need more information. 

    Best

    Lakshmi

  • 0 in reply to Lakshmikanth Satyavolu

    Hi Lakshmi,

    Unfortunately, I am not able to figure out anything else on the issue from this log.

    To get enough information on this, I would require the on-air sniffer log, as mentioned.

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik

    Hi Sigurd, 

    Sure. I will have to purchase the hardware and get back. 

    Meanwhile, could you please let me know what exact information are you looking for? I will try to extract it from snoop log and send. I'm curious to know what more information that nRF sniffer can provide other than this.

    I believe this log has everything what nRF sniffer might be having as all layers of BLE stack were captured at packet level. 

    Please let me know. 

    Best

    Lakshmi

  • 0 in reply to Lakshmikanth Satyavolu

    Hi

    I looked some more into the trace you sent and when I were able to decode it, I find the L2PCAP length is indeed incorrect.

    This is likely due to the Bluetooth stack of the phone having decoded the length field incorrectly.
    In this case, we are not able to help you with the issue, as it is in with the Bluetooth stack of the phone, rather than an error with our device.

    To be certain that the nRF52 is sending the correct message, an on-air sniffer log would confirm how the messages look in transit, and which end is having the issue.

    Regards,
    Sigurd Hellesvik

Related