• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 57 subscribers
  • Views 618 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Finding the msdu in MAC_MCPS_DATA_CNF

Xavier Boniface
Intellectual 260 points

Other Parts Discussed in Thread: CC2430, TIMAC

I am using TIMAC-1.3.0 on CC2430.

After having sent some data to a peer, one gets a MAC_MCPS_DATA_CNF event, in which the original data sent is mirrored (pDataReq field in macMcpsDataCnf_t).

I observe that the msdu fields of pDataReq seem to be wrong. They do not seem to match the ones which were set by MAC_McpsDataAlloc(), prior to call MAC_McpsDataReq(), and they seem to be shifted by 21 -- i.e. upon reception of the MAC_MCPS_DATA_CNF event, the following workaround allows to retrieve the correct msdu parameters:

              pData->dataCnf.pDataReq->msdu.len -= 21;
              pData->dataCnf.pDataReq->msdu.p   += 21;

It seems that, internally, when sending the data, len is incremented by 21. At the end, rather than performing len -= 21, this is p which is scrolled back. Can anyone explain how to find the msdu in MAC_MCPS_DATA_CNF?

  • 0
    TI__Prodigy 140 points

    The original “msdu.p” in macMcpsDataReq_t is reused in macBuildHeader() and remapped to the “msdu.p” in macTx_t to include the MAC header. You can also add the MAC header length to get to the original application data. In your case, it happens to be 21. Unfortunately, the MAC header has a variable length so adding 74 bytes (no encryption) to pData->dataCnf.pDataReq might be the easiest way to get back to your application data.

  • 0 in reply to Supertrainmegazord
    Intellectual 260 points

    Hi, and thank you for the quick answer.

    So, OK: I now understand that MAC_McpsDataAlloc() allocates macMcpsDataReq_t followed by a placeholder for the MAC header (see §7.2.1 in the 802.15.4. spec), and a placeholder for the data.

    When MAC_McpsDataAlloc() is called with == MAC_SEC_LEVEL_NONE and == MAC_KEY_ID_MODE_NONE, the data always starts at the offset sizeof(macMcpsDataReq_t) == 50 + MAC_DATA_OFFSET == 24, even if the MAC header may be shorter indeed (21 bytes in my case).

    So, my workaround to restore msdu.p and msdu.len in pData->dataCnf.pDataReq will now look like:

    {

      uint8 *originalMsdup = (uint8 *)pData->dataCnf.pDataReq + sizeof(macMcpsDataReq_t) + MAC_DATA_OFFSET;

      pData->dataCnf.pDataReq->msdu.len -= (uint8)(originalMsdup - pData->dataCnf.pDataReq->msdu.p);

      pData->dataCnf.pDataReq->msdu.p = originalMsdup;

    }

    I also understand that, if MAC_McpsDataAlloc() is ever called with different and parameters, the placeholder for the MAC header will have a different size, due to the addition of the "Auxilliary Security Header" in the MAC header. The additional number of bytes can then probably be computed using MAC_ENC_OFFSET, MAC_MIC_32_LEN, MAC_MIC_64_LEN and MAC_MIC_128_LEN. I'll have a closer look at that if I ever activate encryption.

     

    However, I suggest that, in future releases of the TIMAC, msdu.p and msdu.len be restored to their original values before the macMcpsDataReq_t structre used for MAC_McpsDataReq() is recalled in MAC_MCPS_DATA_CNF.

    This can be very useful if the application wants to retry sending the data if the sending failed, by just calling MAC_McpsDataReq(pData->dataCnf.pDataReq);

     

    Xavier

  • 0 in reply to Xavier Boniface
    TI__Mastermind 19350 points

    Oh the things we'd love to do with more time and testing resources and .... bright graduate students like you! The LPRF Oslo office has internships every summer and the LPRF San Diego office has an engineering open position.