Problem with zcip's packing of ARP packets?

[David Daney]

David Daney wrote:
> OK, so I didn't fully read your message.  You did say which versions of 
> things you are using.
> 
> This does not really seem like a uClibc problem as you are using glibc.
> 
> It seems more likely to be a problem with the net/if_arp.h and/or tool 
> chain you are using. If you look at the arp header of your dump, you 
> will see that it is all screwed up (fields in the wrong order).
> 

With all due respect to Jason Schoon, I don't think the problem is in 
the arp structure definition.

Look at the dump.  The ether type (offset 0xc) is 81 00

#define ETH_P_8021Q	0x8100          /* 802.1Q VLAN Extended Header  */

This packet is not being assembled by the zcip program.

>>> In Hex, that's:
>>>
>>> 0000   ff ff ff ff ff ff 52 54 00 12 34 56 81 00 00 01  ......RT..4V....
>>> 0010   08 06 00 01 08 00 06 04 00 01 52 54 00 12 34 56  ..........RT..4V
>>> 0020   a9 fe 02 af 52 54 00 12 34 56 9a bf a9 fe 02 af  ....RT..4V......
>>> 0030   00 00 00 00 00 00 00 00 00 00 00 00              ............
>>>
>>> The source and target IP address are both supposed to be 
>>> 169.254.2.175 (a9 fe 02 af), but the target IP address is getting 
>>> shifted by two bytes.  You can still see the (a9 fe 02 af) pattern 
>>> after the (9a bf) pattern.  Note:  the arp_packet struct starts at 
>>> 0x0012 in the above capture.  So the target IP address looks like 
>>> it's getting written to the start of a 4-byte boundary at 0x002C.  
>>> However, the source IP address doesn't start at a multiple of 4 bytes 
>>> from the start of the ARP packet, so I'm not sure it's even a packing 
>>> problem.
>>>