Re: Request for new Link-layer header type

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

On Sep 2, 2011, at 12:53 AM, <HPfrommer () hilscher com> <HPfrommer () hilscher com> wrote:

> > > Unfortunately there is no document online, but the structure is quite
> > simple, it's just a 32-bit value containing some bit fields:
> >
> > So a packet has a 32-bit value, followed by the Ethernet header,
> starting >with the destination MAC address?
>
> In order to have a nice Hex-Display, starting with the destination MAC
> address, we would like to put it *after* the Ethernet packet data.

That would have some problems:

        1) if incl_len (caplen) is less than orig_len (len) due to a snapshot length, the first thing to be lost is the 
NETANA_HEADER_T, so you won't be able to support a snapshot length very well;

        2) dissection is more of a pain - a Wireshark dissector would have to wrap the packet data in a subset tvbuff 
and hand it to to Ethernet dissector, a tcpdump dissector would have to cut the length short before calling the 
Ethernet dissector rather than {printing,ignoring} the NETANA_HEADER_T and handing the rest to the Ethernet dissector, 
and so on;

        3) you have to read to the end of a detailed dissection to see the header.

> > > uiLength:
> > > real frame length in bytes
> >
> > How does that differ from the pcap length field?
>
> It's there for historical reasons and provides the length of the
> captured data, it would be the same as the pcap length field.

If "the captured data" doesn't include the NETANA_HEADER_T, then it *wouldn't* be the same as the pcap length field; 
both caplen and len in the pcap record header (and the pcap-ng equivalents) include all the data in the record, 
including pseudo-headers such as the NETANA_HEADER_T.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.