Problem in framer_sink

GNU Radio
1

Hey all,

I finally figured out the problem where my receivers would stop
receiving packets. It had nothing to do with hardware gain, thanks to
Tom R. for pointing me off of that path.

So the gr_framer_sink_1 is a little screwed up. (As a reminder,) The
packet format is:

[ ACCESS_CODE(<=64 bits) | LEN(16) | LEN(16) | DATA ]

where the length field is in bytes. It works as follows:

After detecting access code, if the two length fields are identical, try
and create a packet. I was sending packets of size 128, (length
0b0000000010000000), and every once in a while both 1s would get flipped
and it would try and create a packet of size 0; due to a bug in the code
this entered an unrecoverable state in the state machine. (I’m sending a
patch to patch-gnuradio.)

Now, I see two problems in this code - no whitening and no integrity
check. Thoughts on whether we should add one or both of these? Neither
is a guaranteed fix, but given my particular problem, it appears that
whitening might be a good idea. Especially noting that most MTU sizes
are less than ~2300 bytes, meaning that it’s very likely that the upper
5 bits of each length field will be 0.

-Dan

2

Johnathan C. wrote:

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.

-Dan

3

On Sun, Mar 11, 2007 at 05:52:37PM -0700, Dan H. wrote:

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

4

Johnathan C. wrote:

The CRC check on the payload is of course dependent on the correct
length. If the length value gets corrupted but both copies are
identical, the packet will still get rejected at the CRC check stage.

Except in your case, where the state machine hangs up with a payload
length of zero. Good catch. The length field in the received packet
should always be at least four bytes, as that is the length of the CRC
field in use, so the check will get added to the code for payload_len < 4.
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.

-Dan

5

On Sun, Mar 11, 2007 at 01:20:20PM -0700, Dan H. wrote:

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.

-Dan

Dan,

r4739 implements a new fix for the fr_framer_sink_1 problem.
Can you please build it and test?

Thanks,
Eric

6

Dan H. 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.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com