On May 5, 2011, at 2:45 PM, Darren Reed wrote:
> Looking through it, the first observation I'd make is that there should not
> have been any 16 bit fields. The one that concerns me most is the IDB which
> has a 16bit link type.
We could add an "enhanced IDB" with a 32-bit LinkType field.
> On Solaris, we're using numbers above 0x80000000 to represent a "private"
> number space for DLPI link types that correspond to internal features. I can
> see that it being desirable to continue to be able to do that, even if only
> for the purposes of experimentation. At present, those DLPI numbers typically
> relate to a more "normal" link type, such as DL_IPV4 (0x80000001) being
> LINKTYPE_IPV4 but others may not.
If a link-layer type is desired for internal experimentation within an
organization, with the organization having no reason to care whether those
captures will be properly interpreted outside the organization, you can use one
of the LINKTYPE_USERn types.
If you want the files to be usable outside the organization - i.e., if you want
a vendor namespace for link-layer types (which means it applies to pcap as well
as pcap-ng) - we'd need to structure the link-layer type values to include an
organization ID. I've already put some work into that to support some
NetBSD-specific link-layer types; it never went any further, but it splits the
link-layer type value into:
the upper 4 bits, for an FCS length field, plus the next bit whose
purpose I'd have to remember, plus the next bit, which indicates whether the
FCS length is present or not;
the next 10 bits, for a "class" value that would be an organization ID;
the next 16 bits, for link-layer type values within that class.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
