The wrong protocol type offset was used on Linux cooked captures
(DLT_LINUX_SLL) in the code to generate protocol type checks.
This didn't cause a problem with live captures, because the generated
code is modified for use in the kernel filtering code, and the
modification is that references to that field are changed to use the
special magic offset value needed to refer to it in the kernel - and the
code that checks for it was using the same wrong offset, so it
incorrectly recognized the incorrect references to that field and turned
them into references using the magic offset, which *do* correctly get
the contents of that field.
I.e., something like
tcpdump -i any arp
for example will see ARP packets and only ARP packets.
It does, however, mean that if you're reading a capture file that came
from "tcpdump -i any", and specify a filter on the command line, it
won't find the packets you want it to find, so
tcpdump -i any -w /tmp/any.pcap
tcpdump -r /tmp/any.pcap arp
for example *won't* see ARP packets.
I checked a fix into the main branch (along with changes to support
"stp" as a filter that matches 802.1d Spanning Tree Protocol packets),
and checked a fix into the libpcap_0_6 branch as well (which just fixes
the bug, without adding the "stp" filter).
We may want to make a libpcap 0.6.2 release; it would fix that bug, and
would also fix the bug on the tcpdump.org Web site where it says
TCPDUMP version 3.6 was released on January 10, 2001. The
current version is 3.6.1 (0.6.2 for libpcap).
even though the current version is 0.6.1, not 0.6.2, for libpcap. :-)
-
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
