--- Begin Message ---
On Mar 15, 2021, at 9:04 AM, Jan Adam <ja...@hilscher.com> wrote:
>> Can the variable be anything *other* than a packet of some sort?
>
> There are only the mentioned 5 representations planned for pcap files since
> this is what our capture device may capture into a pcap file. The
> representation gives at least the ability to extend in the future. Do you
> have anything specific in mind?
No.
>> It also appears that the boundary between the payload and the trailer would
>> be determined by fetching the VarSize field at the end of the trailer. The
>> first VarSize bytes of the data would be the payload, and the remaining
>> sizeof(footer) bytes would be the trailer. Is that the case?
>
> This is also correct. The remaining bytes of incl_len - VarSize is the footer
> size.
If the fields of the footer are aligned on natural boundaries, the footer will
be 72 bytes long; if they are *not* aligned, the footer will be 53 bytes long.
Are they aligned on natural boundaries?
Presumably VarSize is the same thing as PayloadSize? If so, then presumably
incl_len must be equal to VarSize + {either 53 or 72}.
> Some fields of the footer (like the ID) may seem to be redundant and not of
> much purpose in the wireshark or tcpdump context but we use the footer
> structure everywhere in our software stack. This way we eliminated converting
> structures between different parts of our software when dealing with captured
> data.
So what do the two time stamps indicate for the various various of
Representation?
What do the four fields of the SrcID indicate for the various values of
Representation?
What do the values of PayloadState indicate for the various values of
Representation?
What other possible values of PayloadType are there?
>> This also means that NETANALYZER_NG data must *not* be cut off at the end by
>> any "slicing" process, such as capturing with a "slice length"/"snapshot
>> length". Is it possible that the frame in the payload is "sliced" in that
>> fashion?
>
> Slicing a captured packet is not supported by our capturing device.
But some software can slice packets afterwards. Either that would have to be
forbidden (meaning editcap and, I think, tcpdump would have to check for
LINKTYPE_NETANALYZER_NG/DLT_NETANALYZR_NG and refuse to do slicing), or they
would have to 1) ensure that the slice size is >= the footer size and 2) do the
slicing specially, removing bytes *before* the footer, so that if incl_len <
VarSize + footer_size, (VarSize + footer_size) - incl_len bytes have been
sliced off.
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
