[Tinyos Core WG] cc2420 radio stack, and short packets

[David Moss]

David -

 

Take a look at lines 215-217:

 

        if(rxFrameLength <= MAC_PACKET_SIZE) {

          if(rxFrameLength > 0) {

            if(rxFrameLength > SACK_HEADER_LENGTH) {

 

The first byte of a new packet contains the length, and this is the first
check that is performed on that length byte.  There are a few cases this
handles:  packet too big, packet length = 0, packet length not 0 but too
small, and the packet length is just right. 

 

If the packet is too small (length < SACK_HEADER_LENGTH) then the packet
should get dumped and never received.  But . the SACK_HEADER_LENGTH variable
is only 7.   Looks like we need modify the "too small" length check to make
sure we at least have a full header.

 

That's extremely cool that deputy found this issue.

 

-moss

 

 

 

 

  _____  

From: tinyos-2.0wg-bounces at millennium.berkeley.edu
[mailto:tinyos-2.0wg-bounces at millennium.berkeley.edu] On Behalf Of David Gay
Sent: Tuesday, July 08, 2008 9:37 AM
To: TinyOS Core WG
Subject: [Tinyos Core WG] cc2420 radio stack, and short packets

 

I got a deputy failure from a long running base station (on a micaz):
upper bound coercion:
/home/owl/motes/2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc:338:
Assertion failed in CLeq:
  CC2420ReceiveP$m_p_rx_buf->data + (unsigned char )((unsigned int )length -
13U) <= CC2420ReceiveP$m_p_rx_buf->data + 28

As far as I can tell, the logic in that file should prevent too-long packets
ever getting there, so my question is: is it conceivable that "too short"
(less than 14 bytes) packets could show up, and cause underflow in the
subtraction? I don't see anything which would prevent such packets getting
as far as receiveDone_task, which contains the subtraction. 

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20080708/1f98640b/attachment.htm