Link Layer Type Request NETANALYZER_NG

[Jan Adam via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Jan Adam <JAdam () hilscher com>
>
> Date: Mon, 22 Mar 2021 14:33:59 +0000
>
> > 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.
>
> The footer is exactly 54 Bytes long.
>
> ______________________________________________________________
> > Are they aligned on natural boundaries?
>
> No, it is not aligned but packet.  We use #pragma pack(1) for the footer structure.
>
> ______________________________________________________________
> > Presumably VarSize is the same thing as PayloadSize?  If so, then presumably incl_len must be equal to VarSize + 
> > {either 53 or 72}.
>
> Yes, VarSize is the same thing as PayloadSize. And also yes the incl_len must be equal to VarSize + 54.
>
> ______________________________________________________________
> > So what do the two time stamps indicate for the various various of Representation?
>
> For the current implementation only the first time stamp is of significance. It is planned to add an on-device 
> aggregation of request and response for IO-Link and we are trying to use the second time stamp to mark the response 
> arrival time.
>
> For frame preemption protocol (FPP) we also plan to mark a reassembled preempted frame with both time stamps in the 
> capture device. Reassembling on the device is not possible without losing the timing information with the current link 
> layer type.
>
> Synchronization is also a scenario where we see a possible use case for the second timestamp.
> It is not jet specified how the above will be implemented so variation may occur.
>
> ______________________________________________________________
> > What do the four fields of the SrcID indicate for the various values of Representation?
>
> For Representation 0x01 to 0x05 their meaning is defined as following:
> tSrcId.ulPart1netANALYZER device number
> tSrcId.ulPart2netANALYZER serial number
> tSrcId.bPart4netANALYZER port number
>
> For Representation 0x02 to 0x05
> tSrcId.bPart3netANALYZER TAP name (as character, e.g. 'A' = 0x41 or 'B')
>
> For Representation 0x01
> tSrcId.bPart3netANALYZER TAP number
>
> ______________________________________________________________
> > What do the values of PayloadState indicate for the various values of Representation?
>
> For Representation 0x02 to 0x05
> #define MSK_VAR_STATE_RX_ERR0x0000000000000001
> #define MSK_VAR_STATE_WRONG_FCS0x0000000000000002
> #define MSK_VAR_STATE_ALIGN_ERR0x0000000000000004
> #define MSK_VAR_STATE_FRAME_SHORT0x0000000000010000
> #define MSK_VAR_STATE_FRAME_TRUNCATED  0x0000000000020000
> #define MSK_VAR_STATE_PREAMBLE_SHORT    0x0000000100000000
> #define MSK_VAR_STATE_PREAMBLE_LONG     0x0000000200000000
> #define MSK_VAR_STATE_NO_SFD            0x0000000400000000
> #define MSK_VAR_STATE_FRAGMENT_CNT_ERR  0x0000001000000000
> #define MSK_VAR_STATE_SMD_SEQ_ERR      0x0000002000000000
>
> For Representation 0x01 PayloadState is defined to be 0x0000000000000001
>
> ______________________________________________________________
> > What other possible values of PayloadType are there?
>
> The PayloadType has the following possible values but they are not usefull for capturing network traffic. So the only 
> value in the context of packet data will be 0x0A which represents DATATYPE_OCTET_STRING.
>
> #define VAR_DATATYPE_BOOLEAN        0x01
> #define VAR_DATATYPE_BIT1           0x30
> #define VAR_DATATYPE_BIT2           0x31
> #define VAR_DATATYPE_BIT3           0x32
> #define VAR_DATATYPE_BIT4           0x33
> #define VAR_DATATYPE_BIT5           0x34
> #define VAR_DATATYPE_BIT6           0x35
> #define VAR_DATATYPE_BIT7           0x36
> #define VAR_DATATYPE_BIT8           0x37
> #define VAR_DATATYPE_INTEGER8       0x02
> #define VAR_DATATYPE_INTEGER16      0x03
> #define VAR_DATATYPE_INTEGER24      0x10
> #define VAR_DATATYPE_INTEGER32      0x04
> #define VAR_DATATYPE_INTEGER40      0x12
> #define VAR_DATATYPE_INTEGER48      0x13
> #define VAR_DATATYPE_INTEGER56      0x14
> #define VAR_DATATYPE_INTEGER64      0x15
> #define VAR_DATATYPE_UNSIGNED8      0x05
> #define VAR_DATATYPE_UNSIGNED16     0x06
> #define VAR_DATATYPE_UNSIGNED24     0x16
> #define VAR_DATATYPE_UNSIGNED32     0x07
> #define VAR_DATATYPE_UNSIGNED40     0x18
> #define VAR_DATATYPE_UNSIGNED48     0x19
> #define VAR_DATATYPE_UNSIGNED56     0x1A
> #define VAR_DATATYPE_UNSIGNED64     0x1B
> #define VAR_DATATYPE_REAL32         0x08
> #define VAR_DATATYPE_REAL64         0x11
> #define VAR_DATATYPE_VISIBLE_STRING 0x09
> #define VAR_DATATYPE_OCTET_STRING   0x0A
> #define VAR_DATATYPE_UNICODE_STRING 0x0B
> #define VAR_DATATYPE_NONE           0xff
>
> ______________________________________________________________
> > > 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.
>
> Both might be possible path to take for slicing. In any case the PayloadSize should also be adjusted when the payload 
> length is changed in my opinion. Is this a Problem?
>
> ______________________________________________________________
>
>
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Guy Harris <gharris () sonic net>
> Gesendet: Freitag, 19. März 2021 01:20
> An: Jan Adam <JAdam () hilscher com>
> Cc: tcpdump-workers () lists tcpdump org
> Betreff: Re: [tcpdump-workers] Link Layer Type Request NETANALYZER_NG
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you 
> recognize the sender and know the content is safe. Never provide your password!
> VORSICHT: Diese E-Mail kommt von einem externen Absender. Bitte keine Links anklicken oder Anlagen öffnen falls Sie den 
> Absender nicht kennen. Niemals Ihr Kennwort eingeben!
>
>
> 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.
>
> Hilscher Gesellschaft für Systemautomation mbH   |  Rheinstrasse 15  |  65795 Hattersheim  |  Germany  |  
> www.hilscher.com<http://www.hilscher.com>
> Sitz der Gesellschaft / place of business: Hattersheim  |  Geschäftsführer / managing director: Sebastian Hilscher, 
> Hans-Jürgen Hilscher
> Handelsregister / commercial register: Frankfurt B 26873  |  Ust. Idnr. / VAT No.: DE113852715
> Registergericht / register court: Amtsgericht Frankfurt/Main
>
> Important Information:
> This e-mail message including its attachments contains confidential and legally protected information solely intended 
> for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and 
> delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are 
> strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.
>
> Wichtiger Hinweis:
> Diese E-Mail einschließlich ihrer Anhänge enthält vertrauliche und rechtlich geschützte Informationen, die nur für den 
> Adressaten bestimmt sind. Sollten Sie nicht der bezeichnete Adressat sein, so teilen Sie dies bitte dem Absender 
> umgehend mit und löschen Sie diese Nachricht und ihre Anhänge. Die unbefugte Weitergabe, das Anfertigen von Kopien und 
> jede Veränderung der E-Mail ist untersagt. Der Absender haftet nicht für Inhalte von veränderten E-Mails.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers