Re: Request for a new DLT for MTP2 with FCS (repost)

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

Florent.Drouin () alcatel-lucent fr wrote:

> As requested few days before, I would like to use a new DLT to distinguish
> between MTP2 without FCS (the current DLT_MTP2) and MTP2 with FCS.

Or perhaps the link type value in the file header should be interpreted 
as having bitfields, with the lower 16 bits being the link layer type, 
and an indication of whether there's an FCS present being somewhere in 
the upper 16 bits.

NetBSD already uses the upper 16 bits for its own purpose - if the upper 
16 bits are 0x0224, the lower 16 bits are a NetBSD address family value. 
 (Given that AF_INET6, for example, has at least 3 different values on 
various BSD-flavored OSes, 0x0224 should be treated as NetBSD-specific, 
with other values used for other OSes.)

We could, for example, use the uppermost nibble as an FCS length 
indication, with the bit below it being an indication of whether the FCS 
length is known or not.  That doesn't touch any of the bits in 0x0224.

For all current DLT_ values, the bit would be clear, so the FCS length 
isn't known; that's the case for Ethernet, as not only is it not known 
whether any given DLT_EN10MB capture has FCSes in the packets or not 
(some do, some don't), it's not even known which *packets* in a capture 
that does have FCSes (packets sent by the machine doing the capture 
don't, but there's not a per-packet way of indicating that).

I think it would be possible to make this work with pcap-NG as well.

This has the advantage that "what is the link-layer header?" and "do 
frames have FCSes?" are separate questions, answered in separate 
bitfields of the link type value.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.