Wireshark-dev: [Wireshark-dev] pcapng - packet comment terminator; packet list equiv for debug

From: chuck c <bubbasnmp@xxxxxxxxx>
Date: Thu, 24 Sep 2020 19:41:00 -0500

vmware has a packet capture utility (pktcap-uw) which adds packet comments when writing a capture as pcapng.
Looks like the code that writes the comments is reusing a buffer so that when a smaller comment is written there are leftover characters from the previous comment.
The code is also adding a null terminator to the comment string.
When the capture is reloaded in View->Reload as File Format/Capture, the comments are flagged with "Trailing stray characters".

Question #1. 
The pcapng draft standard states:
"If an option's value is a string, the value is not necessarily zero-terminated. Software that reads these files MUST NOT assume that strings are zero-terminated, and MUST treat a zero-value octet as a string terminator."

but also:
"opt_comment:

The opt_comment option is a UTF-8 string containing human-readable comment text that is associated to the current block. Line separators SHOULD be a carriage-return + linefeed ('\r\n') or just linefeed ('\n'); either form may appear and be considered a line separator. The string is not zero-terminated."

Is Wireshark handling comments with embedded nulls properly?

Question #2.
Viewing the pcapng internals in the Wireshark gui is great but ....

I can view frame.comment in the "Capture" view but not pcapng.options.option.length
In the "File Format" view I can add option attributes as a column but get the values for all the blocks in a single entry.

Has it ever been discussed to turn the Packet List pane into a Block List pane?  

Is #1 worthy of opening a bug/issue? (or alternative, try to open bug with vmware - ugh)
Is #2 worthy of an enhancement request?

thanks
chuckc




Block: Enhanced Packet Block 7
    Block Type: Enhanced Packet Block (0x00000006)
        0... .... .... .... .... .... .... .... = Block Type Vendor: False
        .000 0000 0000 0000 0000 0000 0000 0110 = Block Type Value: Enhanced Packet Block (0x00000006)
    Block Length: 284
    Block Data
        Interface: 0x0000
        Timestamp (High): 372758
        Timestamp (Low): 4002058514
        [Timestamp: Sep 24, 2020 17:43:41.000380882 Central Daylight Time]
        Captured Length: 170
        Packet Length: 170
        Packet Data
        Packet Padding
        Options
            Option: Comment = CAPPT UplinkRcvKernel TSO 0 CSUM 0 CSUMVFD 1 ENCAP 0 SEGS 1 [ 1522 ]
                Code: Comment (1)
                Length: 72
                Comment: CAPPT UplinkRcvKernel TSO 0 CSUM 0 CSUMVFD 1 ENCAP 0 SEGS 1 [ 1522 ]
            Option: End of Options
                Code: End of Options (0)
                Length: 0
    Block Length: 284


Block: Enhanced Packet Block 8
    Block Type: Enhanced Packet Block (0x00000006)
        0... .... .... .... .... .... .... .... = Block Type Vendor: False
        .000 0000 0000 0000 0000 0000 0000 0110 = Block Type Value: Enhanced Packet Block (0x00000006)
    Block Length: 168
    Block Data
        Interface: 0x0000
        Timestamp (High): 372758
        Timestamp (Low): 4002165189
        [Timestamp: Sep 24, 2020 17:43:41.000487557 Central Daylight Time]
        Captured Length: 60
        Packet Length: 60
        Packet Data
        Options
            Option: Comment = CAPPT UplinkRcvKernel TSO 0 CSUM 0 CSUMVFD 0 ENCAP 0 SEGS 1 [ 60 ]
                Code: Comment (1)
                Length: 68
                Comment: CAPPT UplinkRcvKernel TSO 0 CSUM 0 CSUMVFD 0 ENCAP 0 SEGS 1 [ 60 ]
                    [Expert Info (Warning/Undecoded): Trailing stray characters]
                        [Trailing stray characters]
                        [Severity level: Warning]
                        [Group: Undecoded]
            Option: End of Options
                Code: End of Options (0)
                Length: 0
    Block Length: 168



0000   01 00 48 00 43 41 50 50 54 20 55 70 6c 69 6e 6b   ..H.CAPPT Uplink
0010   52 63 76 4b 65 72 6e 65 6c 20 54 53 4f 20 30 20   RcvKernel TSO 0
0020   43 53 55 4d 20 30 20 43 53 55 4d 56 46 44 20 31   CSUM 0 CSUMVFD 1
0030   20 45 4e 43 41 50 20 30 20 53 45 47 53 20 31 20    ENCAP 0 SEGS 1
0040   5b 20 31 35 32 32 20 5d 00 00 00 00               [ 1522 ]....

0000   01 00 44 00 43 41 50 50 54 20 55 70 6c 69 6e 6b   ..D.CAPPT Uplink
0010   52 63 76 4b 65 72 6e 65 6c 20 54 53 4f 20 30 20   RcvKernel TSO 0
0020   43 53 55 4d 20 30 20 43 53 55 4d 56 46 44 20 30   CSUM 0 CSUMVFD 0
0030   20 45 4e 43 41 50 20 30 20 53 45 47 53 20 31 20    ENCAP 0 SEGS 1
0040   5b 20 36 30 20 5d 00 5d                           [ 60 ].]
                            ^^ extra char after null



http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url="">

3.5. Options
------------

Options are a list of Type - Length - Value fields, each one containing a single value:

Option Type (16 bits): an unsigned value that contains the code that specifies the type of the current TLV record. Option types whose Most Significant Bit is equal to one are reserved for local use; therefore, there is no guarantee that the code used is unique among all capture files (generated by other applications), and is most certainly not portable. For cross-platform globally unique vendor-specific extensions, the Custom Option MUST be used instead, as defined in Section 3.5.1).
Option Length (16 bits): an unsigned value that contains the actual length of the following 'Option Value' field without the padding octets.
Option Value (variable length): the value of the given option, padded to a 32-bit boundary. The actual length of this field (i.e. without the padding octets) is specified by the Option Length field.


"If an option's value is a string, the value is not necessarily zero-terminated. Software that reads these files MUST NOT assume that strings are zero-terminated, and MUST treat a zero-value octet as a string terminator."

The following codes can always be present in any optional field:

Common Options
Name          Code Length Multiple allowed?
opt_endofopt    0    0         no
opt_comment     1  variable    yes


opt_comment:

The opt_comment option is a UTF-8 string containing human-readable comment text that is associated to the current block. Line separators SHOULD be a carriage-return + linefeed ('\r\n') or just linefeed ('\n'); either form may appear and be considered a line separator. The string is not zero-terminated.
Examples: "This packet is the beginning of all of our problems", "Packets 17-23 showing a bogus TCP retransmission!\r\n This is reported in bugzilla entry 1486.\nIt will be fixed in the future.".