Hi,
I think there is a little bug in file tos/chips/cc2420/receive/CC2420ReceiveP.nc on line 369 and 376 when using refference file:
http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc?revision=1.22&content-type=text%2Fplain
Bug is in function dec() which prepares received message for hardware decryption. I think that intended meaning of line 369 is to drop mallformed packets (failed CRC check) and not to waste resources by decrypting such packet. But CRC check on mentioned lines is incorrect.
According to CC2420 datasheet, page 36,37 result of CRC check is stored in most significant bit of last byte of frame in RXFIFO. It is high iff packet passed CRC check, low otherwise. On line 369 is CRC checked by this way:
if(header.length+1 > RXFIFO_SIZE || !(crc << 7))
This condition should flush packets with wrong CRC (or illegal packet length). But in fact it does not check the result of CRC. CRC check condition should be:
(crc>>7) == 1 IFF packet passed CRC check.
Due to this bug there is a very high probability, that packet with invalid CRC is not flushed but passed for decryption (if applicable). What is in my opinion not intended behaviour. Condition (crc <<7)==0 is met only if crc == 0 what is highly unlikely since 1.-7. bit is LQI value of packet (8.bit is result of CRC check). Obviously even if crc is uint8_t, result of crc<<7 is not constrained on 8 bits.
There are another CRC checks in CC2420ReceiveP.nc, but correct ones. For example on lines 641 or 678.
This is only a little bug (probably only a typo), but IMHO it is worth fixing.
Proposed fix: change (crc<<7) to (crc>>7) on lines 369, 376.
