Problem with zcip's packing of ARP packets?
David Daney
ddaney at avtrex.com
Fri Aug 11 16:16:52 UTC 2006
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.
>>>
More information about the busybox
mailing list