Re: New page, giving link-layer header type values

[Guy Harris <guy () alum mit edu>]

On Mar 15, 2011, at 5:58 PM, Sam Roberts wrote:

> It sounds like you think there are two variants of 802.15.4, one with
> an FCS, and one without.

No, I don't think that.

Perhaps I need to rename the page, and change the language in it to make this even clearer.  I originally said 
"link-layer types"in some places, but I changed it to consistently say "link-layer *header* types", to emphasize that 
there is *NOT* a one-to-one correspondence between LINKTYPE_/DLT_ values and link-layer types in the sense of 
"link-layer protocols".  However, it doesn't necessarily just cover the header, in the sense of the information at the 
beginning of the packet; it can cover as much of the lowermost protocol as possible, including metadata - for example, 
there are four different LINKTYPE_/DLT_ values for 802.11, one for 802.11 with no radio metadata and three for 
different flavors of metadata that have appeared over time - as well as trailer information such as an FCS.  If there 
are multiple LINKTYPE_/DLT_ values for a given link-layer type, it doesn't necessarily mean there are different 
variants of that link-layer type; it could mean, for example, that different software stacks mangle^Wmodify the 
link-layer headers in different ways (note the two flavors of ARCNET), or that various forms of metadata are prefixed 
to the raw link-layer header (for example, the four flavors of 802.11, or various flavors of Bluetooth).

> Whether or not the radio chips give the FCS to you when you run them
> in sniffer mode depends on the chip. Many just validate the FCS, strip
> it, and pass you the packet minus the FCS, but some give you the whole
> packet, including the FCS. And some don't give you the FCS, they
> replace it with a 2 byte indication of signal strength and quality,
> which is useful,but unfortunately including that in the pcap would
> require a different DLT_ type, because it is no longer a standard
> physical layer frame.

Yes, and it probably *SHOULD* get a different LINKTYPE_/DLT_ value, so that it can be included in captures and 
dissected by programs that do captures and read capture files.  (If it could be moved to the beginning of the packet 
without doing any copying other than of the 2 bytes in question, that would probably be best.)

> Either way, the FCS was there on the data link, we just don't have it.
> Since we only got ("snapped") the packet up to the FCS, we write what
> we got and set the snaplen.

"Snap" in "snaplen" stands for "snapshot".  Many packet capture mechanisms, including several of the ones supported by 
libpcap and the one provided by WinPcap (as well as the ones that come with, for example, various applications for 
Windows) offer the option of taking a "snapshot" of the packet by, for some specified value of N, slicing the packet 
off after the Nth byte if the packet has more than N bytes in it.  This reduces the amount of packet data copied from 
the kernel to the buffer into which the packets are delivered, the amount of buffer memory required for packets, the 
amount of time and disk bandwidth spent writing the packets to disk if that's what's being done, and the amount of disk 
space the capture takes; if, for example, you're trying to analyze the behavior of TCP - which I think was at least 
part of the reason Van, Steve, and company created BPF and tcpdump in the first place - and you're running over 
Ethernet, you probably need only 14 bytes of Ethernet header, 20 bytes of IP header, and 20 bytes of TCP header, for 54 
bytes; the old default for tcpdump was 68 bytes, which may have been done to allow a little room for options.

Therefore, if the captured length of the packet is less than the length of the packet, that means that the user said 
"don't give me any more than N bytes worth of packet data", for some value of N, and programs such as tcpdump and 
Wireshark will note that, as they should, so somebody reading the capture (who might not be the person who made the 
capture) knows that the packets are incomplete and therefore there might be important data missing.  (The fact that 
tcpdump defaulted to a relatively small snapshot length often caused problems when trying to track down problems with 
file servers, because if the customer didn't add "-s 65535" or, in later versions of tcpdump, "-s 0" along with "-w" 
when taking a network trace, the packets would be cut short before any of the data for the file system protocol in 
question, rendering the capture pretty much useless.  It's nice to see the "sorry, this packet was cut short" 
information right in your face - yeah, somebody reading the file *could* perhaps infer that from the packets being 
short, or from looking at the IP length field, blah blah blah, but why should the person looking at the capture have to 
take the extra time to do that?)

> How is it a heuristic to notice that the entire packet is not present
> in the pcap?

It's a heuristic to deduce that this is because the FCS wasn't provided by the capture hardware rather than because the 
user captured with a "-s" flag.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.