Bug 2663

Summary: Posible mishandling of packet size in LrWpanMac for ACK
Product: ns-3 Reporter: Guillermo <willyx>
Component: lr-wpanAssignee: Tom Henderson <tomh>
Status: NEEDINFO ---    
Severity: normal CC: ns-bugs, tommaso.pecorella
Priority: P3    
Version: ns-3.26   
Hardware: PC   
OS: Linux   

Description Guillermo 2017-03-01 01:33:33 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
Comment 1 Tommaso Pecorella 2017-03-01 15:28:38 EST
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.
Comment 2 Guillermo 2017-03-02 11:37:01 EST
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?