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.

[参考译文] CC2530:zclProcessInWriteCmd 中的内存分配问题

Guru**** 2548020 points


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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1019558/cc2530-memory-allocation-issue-in-zclprocessinwritecmd

器件型号:CC2530

HAL_ASSERT 函数在该字段中经常发生故障、起初似乎是随机的、但我设法确定了至少一个真正原因。

在`zclProcessInWriteCmd`中、我们有  

    // We need to send a response back - allocate space for it
    writeRspCmd = (zclWriteRspCmd_t *)zcl_mem_alloc( sizeof( zclWriteRspCmd_t )
            + sizeof( zclWriteRspStatus_t ) * writeCmd->numAttr );

当 numAttr 为0时、它仅分配一个字节。

之后在同一函数中、当 numAttr 为0时写入第二个字节、从而导致缓冲区溢出。

  if ( sendRsp )
  {
    writeRspCmd->numAttr = j;
    if ( writeRspCmd->numAttr == 0 )
    {
      // Since all records were written successful, include a single status record
      // in the resonse command with the status field set to SUCCESS and the
      // attribute ID field omitted.
      writeRspCmd->attrList[0].status = ZCL_STATUS_SUCCESS;
      writeRspCmd->numAttr = 1;
    }

我用我修改的`OSAL_Memory.c`实现将缓冲区溢出固定在一起、该实现在存储器被释放时检测溢出。

这发生在一个 apparenty empty Write Attributes 请求之后:

Frame 15893: 48 bytes on wire (384 bits), 48 bytes captured (384 bits)
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jul 18, 2021 00:56:19.056292000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1626562579.056292000 seconds
    [Time delta from previous captured frame: 0.004722000 seconds]
    [Time delta from previous displayed frame: 0.005223000 seconds]
    [Time since reference or first frame: 45777.277876000 seconds]
    Frame Number: 15893
    Frame Length: 48 bytes (384 bits)
    Capture Length: 48 bytes (384 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zcl]
IEEE 802.15.4 Data, Dst: 0xb80f, Src: 0x72ad
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 242
    Destination PAN: 0x880a
    Destination: 0xb80f
    Source: 0x72ad
    Frame Check Sequence (TI CC24xx format): FCS OK
        RSSI: 12dB
        FCS Valid: True
        LQI Correlation Value: 108
ZigBee Network Layer Data, Dst: 0xb80f, Src: 0x0000
    Frame Control Field: 0x0208, Frame Type: Data, Discover Route: Suppress, Security Data
        .... .... .... ..00 = Frame Type: Data (0x0)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 00.. .... = Discover Route: Suppress (0x0)
        .... ...0 .... .... = Multicast: False
        .... ..1. .... .... = Security: True
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0xb80f
    Source: 0x0000
    Radius: 29
    Sequence Number: 45
    ZigBee Security Header
        Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
            ...0 1... = Key Id: Network Key (0x1)
            ..1. .... = Extended Nonce: True
        Frame Counter: 1602759
        Extended Source: SiliconL_ff:fe:6d:7f:8a (bc:33:ac:ff:fe:6d:7f:8a)
        Key Sequence Number: 0
        Message Integrity Code: c28ecfcb
        [Key: d232aca2c434309bd0e0dae5c074315c]
        [Key Label: 36]
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .1.. .... = Acknowledgement Request: True
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: Temperature Measurement (0x0402)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 96
ZigBee Cluster Library Frame, Command: Write Attributes, Seq: 164
    Frame Control Field: Profile-wide (0x00)
        .... ..00 = Frame Type: Profile-wide (0x0)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
        ...0 .... = Disable Default Response: False
    Sequence Number: 164
    Command: Write Attributes (0x02)

通过对'zcl.c'的快速回顾、我相信 zclProcessInWriteUndivedCmd 也会受到这种影响。

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

    我应用了一个修复程序、确保在初始消息中提到的函数中保留足够的内存。

    修复后、我无法重现此问题、而以前相同的测试方法很容易进入故障状态。

    因此、我认为通过调整分配请求来解决这个问题。

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

    嗨、Mario、

    感谢您提供详细的分析和后续信息!

    此致、
    Ryan