--- Begin Message ---
On Mar 24, 2021, at 12:32 AM, Jan Adam <ja...@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
