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. > > 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. 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. 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
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
