Hi Eric, Thanks for your prompt reply. Please see my comments inline.
On Wed, Oct 10, 2012 at 9:12 PM, Eric Decker <[email protected]> wrote: > Welcome to the real world. > > A production/robust stack should handle these issues. I haven't spent > enough time with the current cc2420 stack to know how far it was taken. > > I will one of these days visit this issue because I need a production > quality radio stack for the CC2520 radio. So will dig into it at that > time. > > In the meantime ... > > On Wed, Oct 10, 2012 at 4:05 PM, Xiaohui Liu <[email protected]> wrote: > >> Hello everyone, >> >> Normally, if a packet is corrupted, the CRC is supposed to detect and >> discard it, at least with very high probability. However, if the corruption >> happens on the length field, are these issues handled by the radio stack? >> > > This issue is partially handled by the existence of a special sequence of > symbols called the SFD (Start Frame Delimiter). > > Also if the length is corrupted the CRC will cause the packet to abort. > There is a defined maximum length for a packet which will also cause the > packet to abort prior to doing a CRC calculation. So if the packet is too > long but below the max length, the CRC will be computed and should cause > the packet to abort. Seeing the start of another frame should also cause > the packet to abort. > > By aborting a packet, you mean the CC2420 h/w terminates its reception and the packet will not be placed at RXFIFO, or the packet is placed into RXFIFO but flushed by the CC2420 driver later? > >> 1) the corrupted length is larger than the actual bytes buffered in >> RXFIFO, and RXFIFO.beginRead() or RXFIFO.continueRead() is called to >> read rxFrameLength bytes from it. What could happen in this case? Underflow? > > > There should be special signalling between the CC2420 h/w and the CC2420 > driver. This signalling should tell the driver that we have an abnormal > packet. Either we have received another SFD prior to the current packet > finishing or that we have an underflow (we the h/w stopped seeing symbols > prior to its idea of when the packet should be finished). > > Both of those conditions must be handled in a robust driver. I don't know > how far the implementers of the current CC2420 driver took things. In the > little bit of looking I've done, I haven't seen evidence that these > conditions are handled. The CC2420 driver was based (from the looks of > things) on some sample TI/Chipcon code that talks to the chip using some > default setup. And special handling of exception processing has to be > programmed into the chip special. It is actually quite capable chip. > But it has to be because it is an off-load processor. (I used to design > this kind of stuff (inter cpu communications, multi-processors, etc. when > things were much much larger). > > >> >> 2) the CRC is read at the wrong offset ((buf[rxFrameLength] >> 7)). And >> it can happen to be 1, causing the corrupted packet to be signaled to upper >> layers as a correct packet even though it is not. >> > > I don't understand what you are saying is the behaviour. If the CRC is > at the wrong offset, how can it be correct? I think one should get an > indication that the packet is bad. > > AFAIK, there is no special signalling you mentioned above between the CC2420 h/w and the current CC2420 driver. This can happen when the h/w passes a packet with corrupted length filed to the driver. For instance, if the correct rxFameLength is 21, but it is corrupted and now becomes 20. So instead of CRC failure as (buf[21] >> 7) indicates, CRC passes since (buf[20] >> 7) is mistaken for CRC, which happens to be 1. Of course, if there is special signalling, this should not happen. Note, we should also be instrumenting the behaviour of the device and there > isn't any that I've found. It should also be instrumentation in the cc2420 > that one can get. Stuff like how many bad packets are we seeing and or > what reasons. Otherwise how does one debug what is going on. But it is > difficult doing this in a severly resource constrained system. > > >> 3) this has a cascade effect if there are additional packets buffered in >> RXFIFO after this corrupted one. Their lengths can also be mistaken because >> the previous packet uses a wrong boundary, identified by the wrong length >> field. >> > > Shouldn't happen. Because a new SFD should cause the current packet to > be closed out. It should be flagged as bogus. I don't know the details > of how this works given the FIFO design of the CC2420. > Do you know where I may find more information regarding the inner working of CC2420 FIFOs, namely, TXFIFO and RXFIFO? I haven't found much on the datasheet. I want to understand many details such as the layout of multiple frames in the RXFIFO. > If the driver/h/w got it wrong then it is indeed a problem. If the > interface between the driver and the cc2420 isn't correct, then one > probably has to flush the queue and start over. Because you really don't > have any other choice. For the reasons you've stated. > > >> >> This seems a severe issue but I haven't found any measure to cope with it >> in the stack. Can anyone please give me a hint? Thanks sincerely in advance. >> > > I concur and why I beleive it hasn't been handled. It is a corner case > which production code and deployment want to deal with but typically don't > get dealt with in academic environments. > > I don't beleive it has been dealt with but am willing to be wrong. The > above is my current cursory (I've haven't picked the code apart to analyzie > it for correct operation as well as a corner case analysis) observations > about the state of the CC2420 driver. > > I will be doing a full analysis of the cc2420 stack when I implement the > cc2520 driver. It will start being a clone but will have to change > because we are using the 2591 range extender which will change what pins > are used for what function. I will probably also have to change the > driver/radio interface in other ways to handle corner cases that haven't > been changed. > > I probably won't back-port the changes to the cc2420. But we'll see. > > > >> >> -- TelosB >> -Xiaohui Liu >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > > -- -Xiaohui Liu
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
