• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 343 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2L: L2CAP fragmented packets crashes stack

Bhavesh Kumar
Prodigy 30 points
Part Number: CC2640R2L

Hi,

We are running into the issue where either stack crashes or application does not receive the L2CAP fragmented PDU. Our project is based on simple_np using the simplelink sdk v1.50.

We are planning to migrate to latest sdk. However, we are already live in the market therefore we are assessing the risk, and decision would be based on whether this is improved/fixed in the latest sdk version.

We would like to get the clarification on the following ?


1. On simple link sdk v.150, we are experiencing that any L2cap fragmented data is not received on application layer.  Is this also the case with latest sdk?

2. There is this thread (https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1125984/cc2640r2f-getting-the-hw_fail_inadequate_pkt_len-error-while-running-a-data-transfer-test-with-the-simple_peripheral-example-project) where we see the similar issue. However it seems that stack gracefully handles this and reports HW_FAIL_INADEQUATE_PKT_LEN?  Would it happen for each L2cap fragmented PDU or only for PDUs with specific length?

  • +1
    TI__Guru** 101450 points

    Hi,

    Thank you for reaching out.

    1- A ticket (BLESTACK-4040) related to L2CAP fragmentation has been fixed on SDK 2.30 - see https://software-dl.ti.com/simplelink/esd/simplelink_cc2640r2_sdk/2.30.00.28_new/exports/docs/blestack/release_notes_ble3stack_3_02_01_28.html

    2- Based on the information I have, the issue described in the E2E thread you have pointed (link) occurs when an L2CAP B-frame carrying 40 bytes of information payload (for a total of 44 bytes when considering the 4-byte header) is fragmented into two parts of 3 bytes and 41 bytes, respectively. That is, the first fragment does not contain the full, 4-byte header that the stack expects and it throws the "inadequate packet length" error. 

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Prodigy 30 points

    Thanks for Answers. Can you please let us know when one should expect the fix for 2?
    Meanwhile is there any workaround we can do to fix/recover from it?

  • 0 in reply to Bhavesh Kumar
    TI__Guru** 101450 points

    Hi,

    Wrt issue #2 - The test-results I have show that only few Android devices would actually allow to reproduce the issue. So far we only have the Samsung Galaxy S21 5G with Android 11 reproducing the issue. The same phone (Galaxy S21) with newer Android versions does not seem to reproduce the issue.

    As mentioned before, the issue is caused by the number of bytes in each fragmented L2CAP packet. This means

    1) As the traffic generated can be considered as pseudo random, even phones susceptible to reproduce the issue may not reproduce it at each connection. This means you could consider basically re-establishing the connection and retry the same when experiencing the issue.

    2) As the packet fragmentation depends among others on the PDU size used, when the error occurs you could consider re-establishing the connection with a different PDU size.

    I do not have details on the timeline to fix this issue on the CC2640R2L device.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Prodigy 30 points

    We are using tx PDU size of 251 bytes with mtu-size of of 247 byes. Even though we don't expect fragmentation since our payload on application layer is always less than the PDU size. However, we still see that few phones (at least pixel 3A) fragment data. Do you have any recommendation on combination  of PDU and mtu to avoid the issue#2 ?

  • 0 in reply to Bhavesh Kumar
    TI__Guru** 101450 points

    Hi,

    I am afraid in a non-controlled environment, you cannot guarantee the absence of fragmentation. I mean L2CAP packets have various sizes so the host may decide to fragment the packets in a way or an other (e.g. in order to fit multiple L2CAP packets in the same PDU).

    One element you could consider trying, is to reduce the connection interval. This way, I expect the number of packets available at the time to the host being smaller, and reduce the risk for packet fragmentation.

    Best regards,