[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Problem in framer_sink

From: Dan Halperin
Subject: Re: [Discuss-gnuradio] Problem in framer_sink
Date: Sun, 11 Mar 2007 17:52:37 -0700
User-agent: Thunderbird (X11/20070103)

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? 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]