L2CAP Packet length mismatch in HCI_ACL packet causing packet loss

Hi Lakshmikanth

How did you generate this sniffer log?

Could you also generate a sniffer log from on-air sniffer using the nRF Sniffer for Bluetooth LE?

Regards,
Sigurd Hellesvik

Hi Sigurd,

Unfortunately we don't have the required hardware for nRF sniffer. It takes a while for us to procure.

Meanwhile, could you please share your thoughts on what could be going wrong here? 

I can share hci_snoop log generated at the central device for your reference if that is helpful. 

Best

Lakshmi

Please Find. 

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

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

user106736 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

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

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

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

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

Hi Sigurd, 

Thanks for looking into it. 

I am trying to generate the nRF sniffer log to know what is happening on air. 

Best

Lakshmi