• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 5 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 147 次查看
  • 用户 0 名在线用户
选项
选项
相关

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 碎片数据包崩溃堆栈

admin
Guru**** 1812430 points
Other Parts Discussed in Thread: CC2640R2L
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1327208/cc2640r2l-l2cap-fragmented-packets-crashes-stack

器件型号：CC2640R2L

您好！

我们正面临堆栈崩溃或应用程序无法接收 L2CAP 碎片化 PDU 的问题。 我们的项目基于 simple_np、使用 simplelink SDK v1.50。

我们计划迁移到最新的 SDK。 但是、我们已经处在市场上、因此我们要评估风险、具体决策将取决于这在最新 SDK 版本中是改进还是修复的。

我们希望得到以下方面的澄清？


1.在 Simple link SDK v.150中，我们会遇到在应用层上不接收任何 L2CAP 碎片化数据的情况。  最新的 SDK 也是如此吗？

2.出现此主题(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)， 我们会看到类似的问题。 但是、堆栈似乎能从容地处理此问题并报告 HW_FAIL_UNABLE_PKT_LEN？  对于每个 L2CAP 碎片化 PDU，还是仅对于具有特定长度的 PDU，是否会发生这种情况？

  • 0
    TI__Guru**** 1812430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    感谢您与我们联系。

    1-与 L2CAP 碎片相关的票证(BLESTACK-4040)已在 SDK 2.30上修复-请参阅 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-根据我掌握的信息，当 L2CAP B 帧承载40字节的信息有效载荷(考虑4字节标头时总共有44字节)时，就会发生您指出的 E2E 线程(链接)中描述的问题 被分别分为3字节和41字节的两部分。 也就是说、第一个片段不包含栈所期望的完整4字节标头、并且会抛出"不充分的数据包长度"错误。  

    我希望这将有所帮助、

    此致、

  • 0
    TI__Guru**** 1812430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    感谢您的回答。 您能告诉我们什么时候应该对2进行修复吗？
    同时、我们是否可以采取任何权变措施来修复/恢复它？

  • 0
    TI__Guru**** 1812430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    WRT 问题#2 -我的测试结果表明,只有很少的 Android 设备实际上允许重现问题。 到目前为止,我们只有三星 Galaxy S21 5G 与 Android 11重现问题. 相同的手机(Galaxy S21)与较新的 Android 版本似乎不重现问题。

    如前所述、该问题是由每个分段 L2CAP 数据包中的字节数导致的。 这意味着

    1)由于生成的流量可以被视为伪随机,即使有可能重现问题的电话也不能在每次连接中重现。 这意味着您基本上可以考虑重新建立连接、然后在遇到问题时重试。

    2)由于数据包碎片取决于所使用的 PDU 大小，因此当发生错误时，您可以考虑使用不同的 PDU 大小重新建立连接。

    我对解决 CC2640R2L 器件上此问题的时间表没有详细说明。

    我希望这将有所帮助、

    此致、

  • 0
    TI__Guru**** 1812430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我们使用的 TX PDU 大小为251字节、MTU 大小为247字节。 尽管我们不希望出现碎片，因为我们在应用层上的负载总是小于 PDU 大小。 然而,我们仍然看到很少的手机(至少像素3A)碎片数据。 您是否对 PDU 和 MTU 的组合有任何建议以避免此问题#2？

  • 0
    TI__Guru**** 1812430 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    我怕在一个没有控制的环境中,你不能保证没有碎片。 我的意思是 L2CAP 数据包大小不同、因此主机可以决定以某种方式或其他方式对数据包进行分段(例如、为了在同一 PDU 中容纳多个 L2CAP 数据包)。

    您可以考虑尝试的一个元素是缩短连接间隔。 这样、我预计传输到主机的可用数据包数量会更小、从而降低数据包碎片化的风险。

    此致、