> There is a Debian bug report (#82868) about this as well and I have to
> say I have not idea what's going on here. From the report:
>
> | tcpdump: listening on eth1
> | tcpdump: WARNING: compensating for unaligned libpcap packets
>
> I can't reproduce this here and I did not yet check the source.
> Perhaps this is really simple? Can somebody enlighten me?
Tcpdump's IP dissector casts a pointer into the raw packet buffer, at
the offset of the IP header, to a "const struct ip *", and uses that to
refer to fields in the IP header.
This requires that, on processors that require {2,4}-byte alignment of
{2,4}-byte integral quantities, that the address of the IP header be
aligned on a 4-byte boundary; however, there's no guarantee that this
will be the case on a random packet read from a capture file.
It may also not necessarily be the case on a packet supplied by the
packet capture device. I think the BPF devices in BSD arrange that this
be the case, by, for example, putting two extra padding bytes at the
beginning of an Ethernet header, so that if the first padding byte is
aligned on a 4-byte boundary, the IP header will also be so aligned.
On Linux, given that only one packet is read at a time from the capture
device (i.e., from the socket), "handle->offset" could be used to do
this alignment - the offset would, for example be 2 on Ethernet and 3 on
FDDI. You'd probably want to allocate a buffer of size
"handle->bufsize + handle->offset", rather than just "handle->bufsize".
To reproduce this problem, you will have to run on a
processor+compiler+OS that doesn't allow unaligned accesses - i.e.,
doing it on an x86-based machine such as a PC won't work unless the
processor is a 486 or greater *and* the OS kernel sets the flag to
disable unaligned accesses; I don't know of any OSes that do that.
(Note that the person who submitted the bug report is running on a
SPARC-based machine.)
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe