Re: Link Layer Type Request NETANALYZER_NG

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Wed, 24 Mar 2021 01:48:54 -0700
>
> On Mar 24, 2021, at 12:32 AM, Jan Adam <JAdam () hilscher com> wrote:
>
> > > So, with incl_len equal to {PayloadSize,VarSize} + 54, orig_len would be equal to {original PayloadSize} + 54, so 
> > > the original payload size would be orig_len - 54.
> > >
> > > That would allow the original size and the sliced size of the payload to be calculated, so that should work.
> >
> > Yes it should work.
> >
> > I have the feeling this is more about the design then the implementation.
>
> It's about either 1) saying "slicing is forbidden" or 2) saying "here's how you do slicing".  In either case, there 
> would be implementation changes to tcpdump and Wireshark's editcap tool, as both of them can do packet slicing when 
> reading a file and writing another file from the contents (although I just discovered that tcpdump doesn't appear to 
> correctly set the snapshot length in the header of the output capture file, which I need to fix).
>
> > I will try to explain our design decision of the footer. We have observed that customers using Wireshark don't think 
> > about the header when counting the bytes in the hex dump and expect the frame to start at the first byte and as a 
> > result read out wrong values.
>
> Perhaps that's an indication that Wireshark needs to do a better job of distinguishing between metadata headers and 
> packet data, then.  (I already think so, as 1) counting metadata headers as data means, for example, that you get bogus 
> bytes/second values and 2) separating them may make it more straightforward to implement transformation from, for 
> example, 
>
> > Therefore our idea was to put the additional info at the end in form of a footer.
> >
> > Maybe you can help me understand more of the general concept, how is this slicing handled for a DLT with a header or 
> > footer in general?
> > If you take for example another DLT: https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html it has 16 byte header 
> > size, how does editcap or tcpdump take that into account? Is it possible to slice without taking the header size into 
> > account?
>
> For headers, it currently will do what would be done when doing a live capture and slicing it - the snaplen is the 
> maximum size of the data in the packet record, *including* metadata headers.
>
> Changing that might be considered an incompatible change, but the ability to say "write packets out with no more than N 
> bytes of *on-the-network packet data*" (rather than "no more than N bytes of *total* packet data, including metadata 
> headers"), as a separate option, might be useful.
>
> That would be fairly say to do for *ex post facto* slicing of an existing capture file.  It would involve code that 
> knows the size of the metadata header for all link-layer types, so that would be a bit of an architectural change to 
> the code, but not a painful one.
>
> It's trickier for live captures, but, if the slicing is done by a BPF program, where the return value of the BPF filter 
> indicates the number of bytes of total packet data to write, that could be done even if the metadata header is 
> variable-length.  That's the case for *BSD/macOS, Linux, Solaris, AIX, and, as far as I know, Windows with Npcap.
>
> I'm not sure there *are* any currently cases where a given LINKTYPE_ value specifies a metadata trailer.  There are 
> some network devices that append metadata trailers to Ethernet packets and route them to a host for capturing, with 
> Wireshark having heuristics for trying to guess whether there's a metadata trailer on the frame or not and which type 
> of metadata trailer it is; slicing, whether done at capture time or *ex post facto*, will just slice the metadata 
> trailer in two or slice it off completely.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers