-current on BeableBone successful

[George Neville-Neil]

On Sep 10, 2012, at 02:45 , John-Mark Gurney <jmg at funkthat.com> wrote:

> Tim Kientzle wrote this message on Sun, Sep 09, 2012 at 20:16 -0700:
>>> Third is that I get this error:
>>> ip length 328 disagrees with bytes received 330.
>>> accepting packet with data after udp payload.
>>> 
>>> This appeard to be from sbin/dhclient/packet.c...  Not sure exactly why
>>> we are returning a large packet to userland?
>> 
>> I haven't seen this one.
> 
> Looks like this is a BeagleBone issue.  I haven't tracked it down, but
> I did a tcpdump on the server (my other arm board), and the packet has
> the correct length of 342 bytes to match the 328 ip length (plus 14
> bytes of ethernet header)...  tcpdump on the BeagleBone receives a
> 344 byte frame with a couple of stray bytes at the end of the frame...
> 
> Could this be an miscalculation when we are copying around the frame
> to deal the fact our IP stack can't deal w/ misaligned headers?  Just
> a thought..
> 
> Hmm...  Just ran some experiments... 
> 
> ping -s		sent	received
> 1		0x2b	0x3e
> 10		0x34	0x3e
> 18		0x3c	0x3e
> 19		0x3d	0x3f
> 20		0x3e	0x40
> 21		0x3f	0x41
> 99		0x8d	0x8f
> 100		0x8e	0x90
> 101		0x8f	0x91
> 999		0x411	0x413
> 1000		0x412	0x414
> 1001		0x413	0x415
> 
> and 0x3e is 62, which is two short of the min frame length of 64...
> 
> Hope this helps.

My take is the following.  The minimum packet is 60, not including
the preamble or the CRC, so with a CRC it's 64.  It might be that
there is some alignment issue as well.

The difference between all the sent/received is 2 bytes and that's consistent
so either something isn't being stripped or there is an alignment issue
all the way round.

Best,
George