Re: [Discuss-gnuradio] Problem in framer_sink

[Achilleas Anastasopoulos]

Regarding protecting the length field,
a rate 1/2 linear block code can always be used.

The way it is now it is a repetition code which
offers little protection.

Achilleas



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 Rondeau 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