Guy Harris
changed
bug 8997
| What |
Removed |
Added |
| Hardware |
x86-64
|
All
|
| Summary |
"Linux Cooked Capture" header has incorrect padding
|
Heuristics for recognizing VSS Monitoring trailers are too weak
|
| OS |
Ubuntu
|
All
|
Comment # 1
on bug 8997
from Guy Harris
The Official Description of the Linux cooked capture header is at
http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html
and there's no padding there.
In fact, the "Padding" reported by Wireshark is in a *trailer*. Presumably the
reason why the trailer is there is that this packet was an Ethernet packet
padded to the 60-bytes-if-you-don't-count-the-CRC minimum, with the 14-byte
link-layer header stripped off because the capture was on a
PF_PACKET/SOCK_DGRAM socket rather than a PF_PACKET/SOCK_RAW packet (that's
what happens when capturing in "cooked" mode), and with libpcap synthesizing a
16-byte cooked header, so that the packet is 2 bytes longer than it "really"
was on the wire - which is why it's 62 bytes.
Presumably the "Padding" is reported for Linux cooked packets because they
might have been Ethernet packets with padding.
As for the "VSS-monitoring" part of the trailer, my guess is that some devices
from VSS Monitoring:
http://www.vssmonitoring.com
receive Ethernet packets and either unconditionally, or once they've determined
that the packet is of a type where you can add extra trailer information and
have the receiver blindly discard it (any packet with an explicit length field,
such as a packet with an 802.2 LLC header, so that there's a length field in
that header, or a packet length within some other protocol header, such as are
in IPv4 and IPv6 packets, is probably such a packet; I'm not sure about
Spanning Tree Protocol BPDUs, however), append a trailer containing information
such as time stamps and (switch?) port numbers.
If said Ethernet packet happens to be handed to something capturing with a
PF_PACKET/SOCK_DGRAM socket - for example, a process capturing on the "any"
device - the packet trailer will probably be the same as it would have been had
that process been capturing with a PF_PACKET/SOCK_RAW packet, so checking for a
VSS trailer makes sense.
The VSS trailer dissector is implemented as a "heuristic" trailer dissector, so
that every Ethernet packet with a trailer has the trailer handed to the VSS
trailer dissector, which tries to figure out whether the trailer really *is* a
VSS trailer or not. Linux cooked packets are handed to it because they might
be Ethernet packets.
The problem here is that the heuristic is getting a "false positive"; I suspect
the same false positive would have occurred had that packet been captured on
eth0 or eth1 or whatever real Ethernet interface on which it had arrived and
delivered to libpcap with an Ethernet header.
Wireshark 1.6.7 might not have shown the VSS trailer because it might not have
had the VSS monitoring dissector.
It might be possible to strengthen the heuristics.
You are receiving this mail because:
- You are watching all bug changes.
