Re: Request for new Link-layer header type

[<HPfrommer () hilscher com>]

> > > > 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;

Our device does not use the snapshot length feature. So I think this
would only be a theoretical problem. If a frame is longer than the
buffer it can be stored in, bit 3 (Frame too long) will be set in the
uiErrorCode field.

>       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;

Regarding the Wireshark dissector we would have the problem anyway
because we had to cut of the FCS. We have seen that some dissectors do
not work correctly if the FCS is present in the capture data. We would
introduce a bool preference to let the user enable/disable the handoff
of the FCS. Default would be disabled.
As I don't know tcpdump dissectors I'm not sure if this applies there
too.

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

If you're having headaches with putting the "header" on the end we also
can put it on the beginning. No problem for us. As I said, we just
thought it would result in a "nicer" hex-display for the frame data, but
this is just a cosmetic issue.

So, do we agree? The header will be located at the beginning of the data
field:
pcaprec_hdr_t:
    ts_sec
    ts_usec
    incl_len
    orig_len
packet_data:
  NETANA_HEADER_T
    dst_mac
    src_mac
    len_type
    data
    fcs
.... next packet

Handing off the FCS to the next dissector is configurable, default will
be disabled.



> > > > 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.-

I thought that a file using the new link-layer type *must* always
include a NETANA_HEADER_T as this would be an elementary part of the
link-layer encapsulation? If we put the header at the beginning of the
data field it cannot be cut-off by the snapshot length.
The length information in NETANA_HEADER_T wouldn't be parsed by the
dissector as the dissector only uses caplen and len in the pcap record.


This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Hilscher Gesellschaft für Systemautomation mbH
Rheinstr. 15, 65795 Hattersheim
Sitz der Gesellschaft: Hattersheim
Geschäftsführer: Hans-Jürgen Hilscher
Registergericht: Amtsgericht Frankfurt/Main
Handelsregister: Frankfurt B 26873
www.hilscher.com

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.