Re: Printing PPI packets

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

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.