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.
