[Tinyos-devel] CRC bug
Omprakash Gnawali
gnawali at usc.edu
Wed Jan 9 03:10:32 PST 2008
I have also seen a "few" bad node id's with CTP and default cc2420
stack in the past but no such incident in the recent experiments.
Sometimes, I also see corrupt packets (for example, pkts larger than
they should be). Are you sure what you are seeing is due to the radio
stack and not the serial stack? And not CTP or other pieces of
software that might be stomping on the pkt?
- om_p
On Jan 8, 2008 9:06 AM, Roman Lim <rlim at ee.ethz.ch> wrote:
> 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
>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
More information about the Tinyos-devel
mailing list