[Tinyos-devel] CRC bug
Roman Lim
rlim at ee.ethz.ch
Tue Jan 8 09:06:45 PST 2008
I did also observe wrong packets in a testbed with tmote sky nodes. the
attached picture shows the network status after a 2.5 week testrun (ctp
with low power mac). The red nodes at the bottom do not exist in the
real network, but somehow their ids reached the visualization app.
I am actually using a modified version of the current cc2420 stack, but
I did not touch the crc check part in the CC2420ReceiveP.
Roman
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.
>
> The S_RX_PAYLOAD is simply there to skip any kind of acknowledgement
> checking.
>
> How many bad packets are you seeing, exactly? 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.
>
> -David
>
>
>
>
> -----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
>>>>>
>>>>>
>>>
>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: network_graph.png
Type: image/png
Size: 58795 bytes
Desc: not available
Url : https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080108/ccdaeb70/network_graph-0001.png
More information about the Tinyos-devel
mailing list