Re: Request for new Link-layer header type

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

On Sep 5, 2011, at 1:37 AM, <HPfrommer () hilscher com> <HPfrommer () hilscher com> wrote:

> Our device does not use the snapshot length feature. So I think this
> would only be a theoretical problem.

Wireshark's editcap program can be used to impose an *ex post facto* snapshot on packets; arguably, tcpdump should do 
so as well, if you do something such as

        tcpdump -r {input file} -w {output file} -s {snapshot length}

and it might do so already.

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

They only do so if the Ethernet dissector leaves the FCS in the capture data.  There are three different versions of 
Ethernet dissector:

        the "this frame has no FCS" dissector, which passes on, for frames with a type field, everything past the 
Ethernet header;

        the "this frame has an FCS" dissector, which strips off the FCS before handing it to subdissectors;

        the "I don't know whether this frame has an FCS" dissector, which passes on, for frams with a type field, 
everything past the Ethernet header, and, if the subdissector subsequently set the tvbuff length (e.g., the IPv4 
dissector does so, as IPv4 has its own length field), attempts to guess whether any of the data not handled by the 
subdissector is an FCS or not.

In your case, you would always call the "this frame has an FCS" dissector, in which case the Ethernet dissector would 
remove the FCS (if not cut off by the snapshot length) before handing the packet to the subdissector.

> We would introduce a bool preference to let the user enable/disable the handoff of the FCS.

No, if your frames always include the FCS, you'd introduce code to call the "has an FCS" version of the dissector, 
obviating the need for the user to enable or disable anything.

> As I don't know tcpdump dissectors I'm not sure if this applies there too.

A tcpdump dissector for your link-layer type would always cut off the FCS before calling the Ethernet dissector.

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

...and one that applies to other link-layer types as well, such as 802.11 + various radio headers such as radiotap.  A 
more general solution might make sense here.

> 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

Sounds good.

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

Again, if those packets always have an FCS, for Wireshark you should just call the "eth_withfcs" dissector from your 
dissector.  That will solve the problem for you.

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

My point here is that both caplen and len must include the length of the NETANA_HEADER_T, i.e. the minimum possible 
value of caplen and len is 4, and if you have, for example, a full-length 1518-byte Ethernet packet (1518 because it 
includes the FCS), len will be 1522, because it includes the NETANA_HEADER_T, and caplen will presumably be the same in 
captures from your device, as it doesn't support a snapshot length.

In that case, presumably the uiLength would be 1518.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.