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

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

On Mar 15, 2011, at 10:12 PM, Sam Roberts wrote:

> I've got the pdf at work, but from memory, its basically something like:
>
>  ctrl, 1 byte
>  ... optional fields (present if bit set in control, each control bit
> maps to presense or absence of an optional header field)
>  length field (not optional)
>  <length bytes>
>  FCS

I have the IEEE Std 802.15.4-206 PDF in front of me now, and:

        at the PHY layer (the PPDU), you have the preamble, the SFD, one octet with 7 bits of frame size and 1 reserved 
pid, and the PSDU (the PDU handed to the PHY layer);

        at the MAC layer (the MPDU, which is the PDU handed to the PHY layer), you have 2 octets of frame control, 1 
octet of sequence number, 0 or 2 octets of destination PAN identifier, 0, 2, or 8 octets of destination address, 0 or 2 
octets of source PAN identifier, 0, 2, or 8 octets of source address, some number (0, 5, 6, 10, or 14) octets of 
auxiliary security header, the MAC payload, and 2 octets of FCS.

> so the dissector just walks the data from the pcap, dissecting until
> hitting snaplen.

In Wireshark, dissectors are supposed to dissect until they reach the reported length of the packet on the medium, 
regardless of the captured length (the captured length being what you're calling the "snaplen"; the "snaplen", or 
"snapshot length", is actually the N in any "don't give me more than N bytes of packet data" indication given by the 
capture program to libpcap/WinPcap); if they run past the captured length, an attempt to fetch data past the captured 
length will throw an exception, and the packet will be correctly reported as having been cut short by the snapshot 
length.  If I notice a dissector that stops at the end of the captured length, I fix it not to do so.

I don't know whether all dissectors in tcpdump do that, but there's no reason for them not to; they should always use 
TCHECK/TCHECK2 or TTEST/TTEST2 to make sure they don't run past the end of the packet data, and they usually put in a 
"cut short" indication such as [|{protocolname}].  I should review the tcpdump dissectors to make sure nobody's 
treating the captured length as an indication of how big the packet is - and to make sure we do the right thing 
regardless of whether the FCS is present in Ethernet packets or not, *and* do the right thing with 802.11+radiotap 
depending on whether the radiotap header says the FCS is present or not.

> 15.4 is not like ethernet, where the header doesn't have any
> indication of the length, so if you got the FCS at the end, you
> couldn't tell if it was data or not, and you'd have to dig into the
> ethernet payload, and figure out how long the IPv4 thought the packet
> was, and the see that the FCS was at the end.

The length field is only available if you have the PHY layer header.

> As long as the code can deal with truncated packets (which is what the
> second _NO_FCS DLT is, its a truncated form of the first), the code
> will be the same.

There's "truncated because the hardware doesn't supply the FCS to the driver or because the driver doesn't supply the 
FCS to the capture mechanism" and there's "truncated because the user or program said 'don't give me any more than N 
bytes of packet data'", and they are not the same thing and should not be treated the same way.  The former should be 
handled by not trying to dissect or process the FCS; the latter should be handled by noting in the output that the 
packet was cut short in the capture process, as indicated above.

> Otherwise, its no big deal to me, it looks a bit odd, like somebody
> didn't have the FCS, and it didn't occur to them that it was a
> truncated packet and they could just set the snaplen to the length of
> data they had,

They could, but it would be a complete misuse of the "captured length" and "length" fields.  I need to update the 
documentation to indicate that the length field should be "the length of the data that the driver decided to hand to 
the capture mechanism" and the captured length field should be "the amount of that data that the capture mechanism 
passed up to the program doing the capture, based on the maximum-captured-data-length value the capture mechanism was 
told to use by the program".

For Ethernet, Token Ring, FDDI, 802.11, PPP, etc., the length field only includes the FCS if, had the program specifies 
a maximum-length snapshot length, you would have gotten the FCS; it does *NOT* include the FCS if you would never have 
gotten it even with a maximum-length snapshot length (and that has always been the case).  There's no reason why 
802.15.4 should be any different.

> Maybe you can't withdraw a DLT, anyhow, so we're both wasting our time here?

No, we don't withdraw link-layer type values; somebody might already be using them, or might start using them later.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.