[Tinyos-devel] CRC bug
David Moss
dmm at rincon.com
Fri Jan 4 13:45:05 PST 2008
There are indeed a few edge cases not accounted for in the CC2420 receive
branch. I can certainly see how this is one of them - although I'm not sure
how one CRC check passes while the other fails. Some healthy edge-case unit
testing should be able to help us figure out the correct solution.
The problem is that the single bit that tells us if the CRC passed or not is
actually corrupted due to the bad packet length and previous information
already stored in the message_t's structure.
I'll put this on my list of things to do - there's already a better
implementation of the receive functionality in my CC1100/CC2500 radio stack
we can use for the CC2420 radio.
-David
-----Original Message-----
From: Razvan Musaloiu-E. [mailto:razvanm at cs.jhu.edu]
Sent: Wednesday, January 02, 2008 2:51 PM
To: David Moss
Cc: 'TinyOS Development'
Subject: RE: [Tinyos-devel] CRC bug
Hi!
On Wed, 2 Jan 2008, David Moss wrote:
> The continueRead() when the length shows a bad packet is supposed to read
> out the RX FIFO as if it were a good packet, but the CRC should fail
(65534
> out of 65535 times) when complete.
I though there could be a mismatch between the rxFrameLength and the real
position of the CRC but it shouldn't be because the radio will not be able
to detect the end of a transmission so will dutifully "read" something for
any size.
One question: what happens if a new packet arrives while we are still
reading from RXFIFO the old one? If I understand correctly the FIFO will
remain low even after we read the last byte of the old packet...
> The S_RX_PAYLOAD is simply there to skip any kind of acknowledgement
> checking.
>
> How many bad packets are you seeing, exactly?
I see bad packets randomly (not in bursts). I noticed them in an outdoor
deployment. After I added the filtering code on the basestation I stopped
seeing them.
Something interesting: almost the bad packets have a wrong length. Here is
and example:
destination: 8704 source: 65535 length: 169 group: 1 type: 25 data: [230,
235, 17, 0, 0, 118, 243, 0, 0, 119, 87, 0, 1, 16, 168, 2, 161, 2, 108, 12,
25, 11, 249, 16, 132, 5, 14, 0, 1, 0, 2, 9, 34, 15, 255, 0, 1, 16, 229, 2,
159, 2, 111, 12, 25, 11, 248, 16, 132, 5, 14, 0, 2, 0, 0, 9, 34, 15, 255,
0, 1, 17, 33, 2, 162, 2, 111, 12, 23, 11, 247, 16, 129, 5, 14, 0, 5, 0, 0,
9, 34, 15, 255, 0, 1, 17, 94, 2, 159, 2, 108, 12, 28, 11, 253, 16, 129, 5,
14, 0, 2, 0, 2, 9, 35, 15, 255, 227, 233, 0, 0, 0, 0, 0, 0, 230, 107, 1,
0, 229, 1, 0, 0, 0, 0, 0, 0, 0, 19, 0, 0, 0, 0, 60, 0, 0, 0, 0, 65, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0]
The destination is also wrong. When address recognition is enable the
CC2420 is not signaling the FIFOP so we should never see a packet like
this. Unless we start reading from RXFIFO at a wrong position, right?
> And I wonder if anyone else is having the same problem? When I don't
> have CRC's enabled, I can really tell a difference in the amount and
> types of packets received, especially when my nodes are on the edge of
> communication.
My guess is that the filtering works most of the time but there is a
corner case in which it doesn't.
--
Razvan ME
> -----Original Message-----
> From: Razvan Musaloiu-E. [mailto:razvanm at cs.jhu.edu]
> Sent: Monday, December 31, 2007 4:30 PM
> To: David Moss
> Cc: 'TinyOS Development'
> Subject: RE: [Tinyos-devel] CRC bug
>
> Hi!
>
> I think I might spotted one case in which can a bad packet can hit the
> upper layer. This is also from CC2420ReceiveP:
>
> 209 if(rxFrameLength <= MAC_PACKET_SIZE) {
> 210 if(rxFrameLength > 0) {
> 211 if(rxFrameLength > SACK_HEADER_LENGTH) {
> 212 // This packet has an FCF byte plus at least one
more byte to read
> 213 call RXFIFO.continueRead(buf + 1,
SACK_HEADER_LENGTH);
> 214
> 215 } else {
> 216 // This is really a bad packet, skip FCF and get it
out of here.
> 217 m_state = S_RX_PAYLOAD;
> 218 call RXFIFO.continueRead(buf + 1, rxFrameLength);
> 219 }
> 220
> 221 } else {
> 222 // Length == 0; start reading the next packet
> 223 atomic receivingPacket = FALSE;
> 224 call CSN.set();
> 225 call SpiResource.release();
> 226 waitForNextPacket();
> 227 }
> 228
>
> The transition to S_RX_PAYLOAD from line 217 would allow the control to
> reach the line 290 and potentially get to the signal of receive. Is the
> rx_buf suppose to prevent this?
>
> All the best in the new year to everyone!
> Razvan ME
>
> On Mon, 31 Dec 2007, Razvan Musaloiu-E. wrote:
>
>> Hi!
>>
>> This is surprising. After adding the filtering I mentioned in my previous
>> email I stopped seeing corrupted packets at the application level.
>>
>> --
>> Razvan ME
>>
>> On Mon, 31 Dec 2007, David Moss wrote:
>>
>>> I know it's obscure (HIL level after all), but take a look at
>>> CC2420ReceiveP, line 290:
>>>
>>> // buf[rxFrameLength] >> 7 checks the CRC
>>> if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
>>> uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
>>> signal CC2420Receive.receive( type, m_p_rx_buf );
>>> if ( type == IEEE154_TYPE_DATA ) {
>>> post receiveDone_task();
>>> return;
>>> }
>>> }
>>>
>>> -David
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Razvan Musaloiu-E. [mailto:razvanm at cs.jhu.edu]
>>> Sent: Wednesday, December 26, 2007 5:16 PM
>>> To: David Moss
>>> Cc: Vlado Handziski; Kevin Klues; TinyOS Development
>>> Subject: Re: [Tinyos-devel] CRC bug
>>>
>>> Hi!
>>>
>>> On Fri, 7 Dec 2007, Vlado Handziski wrote:
>>>
>>>> My recollection is that his has been done in HW on the CC2420, but this
is
>>>> before the new stack was introduced.
>>>
>>> The CC2420 chip verifies the CRC but it doesn't do any filtering based
on
>>> this. David, can you please confirm this? :-)
>>>
>>> Below is a patch that does the filtering in CC2420ActiveMessageP.nc.
>>>
>>> diff --git a/tos/chips/cc2420/CC2420ActiveMessageP.nc
b/tos/chips/cc2420/CC2420ActiveMessageP.nc
>>> index 2cd35c8..4e1a452 100644
>>> --- a/tos/chips/cc2420/CC2420ActiveMessageP.nc
>>> +++ b/tos/chips/cc2420/CC2420ActiveMessageP.nc
>>> @@ -164,6 +164,10 @@ implementation {
>>>
>>> /***************** SubReceive Events ****************/
>>> event message_t* SubReceive.receive(message_t* msg, void* payload,
uint8_t len) {
>>> + cc2420_metadata_t* header = call CC2420PacketBody.getMetadata(msg);
>>> + if (header->crc == 0) {
>>> + return msg;
>>> + }
>>> if (call AMPacket.isForMe(msg)) {
>>> return signal Receive.receive[call AMPacket.type(msg)](msg,
payload, len - CC2420_SIZE);
>>> }
>>>
>>> Happy holidays to everyone!
>>> Razvan ME
>>>
>>>> On Dec 7, 2007 10:31 PM, Kevin Klues <klueska at gmail.com> wrote:
>>>>
>>>>> Does anyone know why the crc footer bit is never checked anywhere in
>>>>> the entire tinyos-2.x tree? In tinyos-1.x the radio stack passed the
>>>>> packet up to the AM layer (AMPromiscuous.nc, AMStandard.nc) which
>>>>> checked to see if (footer->crc == 1) before passing the packet up the
>>>>> stack. The AM layer contains no such functionality in T2.
>>>>> Because of this, a disconcerting number of packets (at least on motes
>>>>> that use a cc1000) obtained by the application layer end up bing
>>>>> corrupted.
>>>>>
>>>>> This is obviously a bug, the question is where this filtering should
>>>>> actually be done. As I mentioned before, in tinyos-1.x it was done at
>>>>> the AM layer. Is that where we want to keep it, or should it be
>>>>> pushed down into the radio stacks themselves? In what cases will we
>>>>> ever want to receive a packet if it has a bad crc? I can think of
>>>>> situations where this might be useful (i.e. doing forward error
>>>>> correction or something), but if such functionality were implemented
>>>>> it should exist below the AM layer.
>>>>> I guess my real question then, is where should we put this filtering
>>>>> NOW so taht corrupted packets dont get sent up to the application.
>>>>>
>>>>> --
>>>>> ~Kevin
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
More information about the Tinyos-devel
mailing list