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

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

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.

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

        IEEE 802.15.4 wireless Personal Area Network, with each packet having the FCS at the end of the frame, and with 
the PHY-level data for non-ASK PHYs (4 octets of 0 as preamble, one octet of SFD, one octet of frame length + reserved 
bit) preceding the MAC-layer data (starting with the frame control field).

and there is, in fact, a Wireshark dissector for that (which shares most of its code with the other 802.15.4 
dissectors).  That link-layer type was requested in a thread that started with

        http://article.gmane.org/gmane.network.tcpdump.devel/3253

and

        http://article.gmane.org/gmane.network.tcpdump.devel/3252

(which appear to be two instances of the same message).

> If a company makes an ethernet tap device, and for some reason, made
> it refuse to return more than the first 60 bytes of ethernet frames
> even with tcpdump -s80 (maybe its "super performance mode"), would you
> allocate me a new DLT type, or just say I wrote broken hardware?

In that case, I'd say the hardware was broken.

However, if a company made an Ethernet adapter, and it didn't supply the FCS, I'd just say "oh, well, you don't get the 
FCS with this" and let it use LINKTYPE_ETHERNET/DLT_EN10MB; I might think it'd be *nice* if it could supply the FCS, 
but I wouldn't consider the adapter to be broken.  And, frankly, if I'd been asked when adapters started allowing you 
to get the FCS and drivers started configuring them to do so, I'd have said that, if those adapters did so, a new 
LINKTYPE_/DLT_ value should be provided - and that there should probably be a 2-byte (2 bytes for the benefit of people 
who want the payload on a 4-byte boundary) metadata header stuck in front of the Ethernet header when the driver 
supplies the packet data to the capture mechanism, containing, among other things, an indication of whether the packet 
is incoming or outgoing (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.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.