[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Problem in framer_sink
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Problem in framer_sink |
Date: |
Mon, 12 Mar 2007 12:17:33 -0700 |
User-agent: |
Mutt/1.5.9i |
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