Bugzilla – Bug 2663
Posible mishandling of packet size in LrWpanMac for ACK
Last modified: 2017-03-02 11:37:01 EST
Problem occurs when McpsDataRequest is called with a package size close to the Package limit (e.g 116) on: LrWpanMac::McpsDataRequest (McpsDataRequestParams params, Ptr<Packet> p) Packet get tested for size with: if (p->GetSize () > LrWpanPhy::aMaxPhyPacketSize - aMinMPDUOverhead) If the package meets the size requiremets it gets transmitted. However, later in this function it gets extra payload added with: p->AddHeader (macHdr); p->AddTrailer (macTrailer); increasing packet size. The package is later addressed in: LrWpanMac::PlmeSetTRXStateConfirm (LrWpanPhyEnumeration status) as m_txPkt. it is used inside that function in: m_phy->PdDataRequest (m_txPkt->GetSize (), m_txPkt); and in the function: LrWpanPhy::PdDataRequest (const uint32_t psduLength, Ptr<Packet> p) is tested again with: if (psduLength > aMaxPhyPacketSize) which now results in IEEE_802_15_4_FRAME_TOO_LONG status return
I don't think it's really a problem in the code. The problem is that the header size is variable, but the max packet size is fixed. As consequence, you know for real if a packet can be transmitted or not only at the final stage (when the header is built). In LrWpanMac::McpsDataRequest there is only a rough test, while the real one is done later on.
Thanks for the response. Main concern was that I was expecting to use a package of size less than (LrWpanPhy::aMaxPhyPacketSize - aMinMPDUOverhead) and it took some time to realize is less than that (13 bytes less). I see status is on NEEDINFO. Can I help you with something?