Re: [tcpdump-workers] Link Layer Type Request NETANALYZER_NG
--- Begin Message ---
On Mar 15, 2021, at 9:04 AM, Jan Adam 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
Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG
--- Begin Message ---
On Feb 12, 2021, at 4:49 AM, developer--- via tcpdump-workers
wrote:
> Sorry for the delay in responding, I had to look thru the code to make sure
> all the information is accurate.
>
> I looked into the option to change in particular the msg_type 1 (decoded SIP
> message),
> but for the short term, using export_pdu is not an option because of the
> changes required.
>
> The current implementation for the LINKTYPE_AUERSWALD_LOG uses the following
> format:
>
> Each package starts with a message header followed by the payload and a 0
> byte.
> The message header currently has a fixed width of 150 bytes.
> For the future the length of the header might change based on the msg_type.
> (This will allow for less waste compared to the fix length)
> Whenever the content structure of the message or length of header is changed
> a new msg_type will be used.
>
> /* Literals for displaying level are
> local level_tab = {
> [0] = "Off",
> [1] = "Error",
> [2] = "Warning",
> [3] = "Info",
> [4] = "Debug",
> [5] = "EDebug"
> }
> */
>
> // The Offset in comments is just for convenience for writing wireshark
> dissectors
> struct message_hdr {
>uint16_t msg_type; // Offset 0
>uint32_t level; // Offset 2
>char category[32]; // Offset 6
> union { // New Offsetbase 38
>struct {// if msg_type == 0
> int32_t pid; // Offset 38
> int32_t tgid;// Offset 42
> char procname[16];// Offset 46
> char threadname[16]; // Offset 62
> char class_name[32]; // Offset 78
> char method[32]; // Offset 110
> uint32_t lineno; // Offset 142
> uint32_t seqno; // Offset 146
>};
>struct {// if msg_type == 1
> char src_ip[16]; // Offset 38
> uint16_t src_port;// Offset 54
> char dst_ip[16]; // Offset 56
> uint16_t dst_port;// Offset 72
>};
> };
> } __attribute__((packed));// Total 150
So what are the byte orders of the 2-byte and 4byte integral fields?
What are the values that the msg_type field can have?
Presumably the values that the level field can have are 0-5, with the meanings
indicated.
Presumably category is a string; what does that string signify?
What do the values signify in a message of message type 0? They appear to
indicate a thread within a process; do they also indicate the sending class and
method? Is linen a line of source code in the implememtation of that method,
or something else? What is the tgid? What is the sequence number?
What is the payload following the header?--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
