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: Thu, 18 Mar 2021 17:19:43 -0700
>
> On Mar 15, 2021, at 9:04 AM, Jan Adam <JAdam () 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