On Sep 5, 2011, at 1:37 AM, <[email protected]> <[email protected]>
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.
