[Tinyos-devel] CRC bug
Razvan Musaloiu-E.
razvanm at cs.jhu.edu
Wed Jan 2 13:51:25 PST 2008
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