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.
