On Sun, Mar 11, 2007 at 05:52:37PM -0700, Dan Halperin wrote: > Johnathan Corgan wrote: > > Dan Halperin wrote: > > > >> Is the CRC actually required? In the version of the code I'm using on > >> the lab machines (which is from early January), the framer_sink only > >> uses the length field to form the packet and the CRC is checked later. > >> We actually do the CRC after doing some ECC on the bits themselves. > >> > > > > The CRC only applies to the actual data payload; it gets appended at the > > end. But the len field that gets put (twice) into the header is the > > length of the payload + CRC. > > > > On receive, if the len field is corrupt, the received packet will fail > > CRC, because the last four bytes of the payload will be some arbitrary > > value, not the actual CRC field (and the packet won't have the right > > contents anyway.) So no strong protection is really needed for the len > > field. > > Sorry; what I meant is, should we assume that all packets are protected > by CRCs?
No we shouldn't. > The CRC check is done after the packet is pulled from the > message queue, in what I think I would say is the network layer, or the > MAC "layer". I was positing that the end-to-end argument would imply > that the framer (link layer) should not assume that all packets have a > 4-byte CRC. Agreed. I will fix the bug in the framer sink so that it doesn't this problem. It will return the zero-length packet upwward, where it can be dealt with by higher level code. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
