On Mar 15, 2011, at 4:51 PM, Sam Roberts wrote: > On Sun, Mar 13, 2011 at 2:41 PM, Guy Harris <[email protected]> wrote: >> http://www.tcpdump.org/linktypes.html >> >> contains a description of all the existing link-layer header types for which >> there is either > > Not sure why there is two link types for IEEE 802.15.4.
Because this has to work with pcap as well as with pcap-ng, and pcap, unlike pcap-ng, has no way to indicate whether a packet has an FCS. > The "no FCS at the end" case doesn't need a link type, if the snaplen > is 2 bytes shorter than the packet should be, then there is no FCS at > the end. That's a heuristic; heuristics are what you use when you have to work around the lack of information. That particular heuristic assumes that packets are as big as they "should be", which isn't necessarily guaranteed. > Since every decoder needs to know how to deal with a snaplen less than > the original packet length (don't they?), Yes. They typically report that as a packet that's been cut short by the user having used "-s" or set it in the GUI, and say "sorry, this packet was cut short, so I can't fully decode it", which is exactly what they should do. (Actually, in Wireshark, that happens automatically as a result of an exception being thrown when the dissector tries to pull data out of the packet when the data wasn't captured; in tcpdump, it happens as a result of in-line TCHECK/TCHECK2 or TTEST/TTEST2 calls in the decoder.) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
