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

[Sam Roberts <vieuxtech () gmail com>]

On Tue, Mar 15, 2011 at 8:59 PM, Guy Harris <guy () alum mit edu> wrote:
> On Mar 15, 2011, at 8:27 PM, Sam Roberts wrote:
>
> > Why would anyone want to deduce this? In wireshark, both dlt values
> > will map to the same dissector,
>
> They *shouldn't* map to the same dissector.  They should map to *different* dissector routines, which call a common 
> routine, passing an "FCS present" flag; if the flag indicates that the FCS is present, they'll look for it and show 
> it, otherwise they'll just leave the FCS out of the dissection.

They will map to the same dissector, thats what I'm trying to say,
WITHOUT heuristics.

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

so the dissector just walks the data from the pcap, dissecting until
hitting snaplen. If snaplen was 1, it would just read the control. If
snaplen is 6, the control and (probably) src/dst address fields. etc.
Same code. Stop when there is no more data.

If the FCS was the first byte in the packet, then it would be a
different format. Or if there was no length field in the header, so
you didn't know when the data ended, but thats not the case.

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.

> Note, by the way, that there are actually *three* LINKTYPE_/DLT_ values for 802.15.4.  The third one is 
> LINKTYPE_IEEE802_15_4_NONASK_PHY/DLT_IEEE802_15_4_NONASK_PHY; the description is

Yes, that is actually a totally different packet format, thats why I
didn't mention it. Its a representation of the packet on the air. Its
the equivalent of an ethernet frame on the wire which has the 7 octet
preamble, start of frame delimiter, and then the DLT_EN10 ethernet
header with dstmac, srcmac, etc...

> (as outgoing packets won't have the FCS).  Unfortunately, I *wasn't* asked, so we had to crap up the Ethernet 
> dissector in Wireshark with code > to cope with that as best it can.  I *REALLY* do not want to have to do that 
> again, or even be asked to do that again (that's one of the reasons > why I wanted pcap-ng to have per-packet 
> attributes to indicate whether the FCS is present - and, given that in, for example, PPP, the FCS
> length can be negotiated, to indicate the length of the FCS.)

I totally sympathize, its awful, but this isn't the same. Heuristics
not required.

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.

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, and use the existing DLT. So, they asked you for a DLT
value, and you'd rather have too many than repeat some of the mistakes
of the past, so you issued one, and there is now a second DLT value.

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

Cheers,
Sam
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.