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.
