[CheeHow WEE <cheehow@xxxxxxxxxxxxxxx>]

Hi there,

I would like to follow up on the forwarded topic.

Can we (ComWorth) request for an option that is able to ignore error on `frame.len_lt_caplen`?

Such as setting it via Edit -> Preferences?

There's a "padding" added for a 4-bytes aligned PCAP writing API.

- I understood that the latest Wireshark app dev logic such that length should not be lesser than captured length.

- In highspeed performance (scale of > 100 million packets per second) PCAP writing, it's necessary to form a bulk hence the 4-bytes aligned packet size was formulated.

- For offset padding, a junk trailer bytes are added to a packet to the full packet size.

- Example.:
Frame length: 194 bytes (not multiple of 4)

Capture length: 196 bytes (size of a written packet)

Trailer length: 2 bytes

I can't argue that in this case the capture length is the universal truth, but at least it's mitigated to avoid actual malformed packet.

Consider following scenario also:

Frame length: 193 bytes (not multiple of 4) <-- Actual captured packet

Capture length: 196 bytes (size of a written packet)

Trailer length: 2 bytes

There's 1 byte missing, and in this case it's a real malformed packet from the perspective of a captured device.

Above are 2 cases of `frame.len_lt_caplen`, but with 1 valid and 1 invalid packet actually.

It will be even better if `frame.len_lt_caplen` can be programatically provide, such as in our case factoring the given "trailer length" to make a valid "capture length" so the error not showing after knowing its background.

We hope you understand the scenario, and hopefully it's a good contribution when there's such a use case.

Regards,

Cheehow

Forwarded Conversation
Subject: Option to disable Expert Info for issue with frame length
------------------------

From: Duy Khanh Pham <khanh@xxxxxxxxxxxxxxx>
Date: Thu, Mar 23, 2023 at 3:40 AM
To: <wireshark-dev@xxxxxxxxxxxxx>
Cc: 居内寛貴 <iuchi@xxxxxxxxxxxxxx>

Hi,

My case for this request is when doing network data capturing with a capture card. The capture card always sets the capture length to a multiple of 4 due to performance requirement.

 

As a result, the real length will always be less than or equal to the set captured length. 

After WireShark added  Commit 8674eea7 and fixed Issue 18312, it became very troublesome everytime I used WireShark to open a captured PCAP file since a lot of frames have the issue with captured length and the real length.

So, as the title says, I would like to have an option to hide/disable the Expert Info warning if the real length of the capture is less than the captured length.

Hope to hear from you soon.

Best Regards,

Khanh.

Comworth Solutions Pte Ltd

----------
From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, Mar 23, 2023 at 11:35 AM
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Cc: Duy Khanh Pham <khanh@xxxxxxxxxxxxxxx>

On Mar 22, 2023, at 11:40 AM, Duy Khanh Pham via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

> My case for this request is when doing network data capturing with a capture card. The capture card always sets the capture length to a multiple of 4 due to performance requirement.
> 
> As a result, the real length will always be less than or equal to the set captured length.

What do you mean here by "capture length"?

In the record header of packet records in pcap files:

        https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcap.html#name-packet-record

the two length fields are defined as follows:

        Captured Packet Length (32 bits):
                an unsigned value that indicates the number of octets captured from the packet (i.e. the length of the Packet Data field). It will be the minimum value among the Original Packet Length and the snapshot length for the interface (SnapLen, defined in Figure 1).

        Original Packet Length (32 bits):
                an unsigned value that indicates the actual length of the packet when it was transmitted on the network. It can be different from the Captured Packet Length if the packet has been truncated by the capture process; it SHOULD NOT be less than the Captured Packet Length.

                A pcap file writer MAY write an Original Packet Length that is less than the Captured Packet Length if both the Captured Packet Length and the Original Packet length came from a file in which a packet had an Original Packet Length less than the Captured Packet Length; otherwise, it MUST write an Original Packet Length that is greater than or equal to the Captured Packet Length.

                A pcap file reader MAY convert an Original Packet Length that is less than the Captured Packet Length to a value that is greater than or equal to the Captured Packet Length.

and, in the block header of Enhanced Packet Blocks in pcapng files:

        https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcapng.html#name-enhanced-packet-block

they are defined as follows:

        * Captured Packet Length (32 bits): an unsigned value that indicates the number of octets captured from the packet (i.e. the length of the Packet Data field). It will be the minimum value among the Original Packet Length and the snapshot length for the interface (SnapLen, defined in Figure 10). The value of this field does not include the padding octets added at the end of the Packet Data field to align the Packet Data field to a 32-bit boundary.

        * Original Packet Length (32 bits): an unsigned value that indicates the actual length of the packet when it was transmitted on the network. It can be different from the Captured Packet Length if the packet has been truncated by the capture process; it SHOULD NOT be less than the Captured Packet Length.

        A pcapng file writer MAY write an Original Packet Length that is less than the Captured Packet Length if both the Captured Packet Length and the Original Packet length came from a file in which a packet had an Original Packet Length less than the Captured Packet Length; otherwise, it MUST write an Original Packet Length that is greater than or equal to the Captured Packet Length.

        A pcapng file reader MAY convert an Original Packet Length that is less than the Captured Packet Length to a value that is greater than or equal to the Captured Packet Length.

Unless the capture card is slicing packets should, both the "captured length" and the "real length" should have the *exact same value*, which should reflect the number of bytes worth of packet data, *not* including any padding added by the capture card.  In addition, the padding should *not* be written to the capture file.

So what does the "capture length" refer to for your capture card?

----------
From: Duy Khanh Pham <khanh@xxxxxxxxxxxxxxx>
Date: Thu, Mar 23, 2023 at 12:43 PM
To: 居内寛貴 <iuchi@xxxxxxxxxxxxxx>

----------
From: Duy Khanh Pham <khanh@xxxxxxxxxxxxxxx>
Date: Thu, Mar 30, 2023 at 2:10 AM
To: Guy Harris <gharris@xxxxxxxxx>
Cc: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

Sorry for my late reply,

From your article, I understand that the Captured Packet Length is the Frame Length/Length on wire/real length and Original Packet Length is the "Capture Length/captured length" in the attached picture.

My issue is that the capture card in our system always writes packets with "Original Packet Length" bigger than or equal to the "Captured Packet Length" (attached example pcap file). In your article, "Original Packet Length" can be greater than "Captured Packet Length", so I don't think that is an error from my capture card.

Since Wireshark marks this issue as a malformed error, I think it also leads to incorrect FCS checking.

Please help me correct my understanding if I'm wrong.

Best regards,

Khanh

 frame_error.pcap

----------
From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, Mar 30, 2023 at 3:23 AM
To: Duy Khanh Pham <khanh@xxxxxxxxxxxxxxx>
Cc: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

On Mar 29, 2023, at 10:10 AM, Duy Khanh Pham <khanh@xxxxxxxxxxxxxxx> wrote:

> From your article, I understand that the Captured Packet Length is the Frame Length/Length on wire/real length and Original Packet Length is the "Capture Length/captured length" in the attached picture.
>
> My issue is that the capture card in our system always writes packets with "Original Packet Length" bigger than or equal to the "Captured Packet Length" (attached example pcap file). In your article, "Original Packet Length" can be greater than "Captured Packet Length", so I don't think that is an error from my capture card.

Did you mean to say "Original Packet Length" when you said "Captured Packet Length" and to say "Captured Packet Length" when you said "Original Packet Length"?

The Internet Draft in question says that the "Original Packet Length" is the frame length/length onwire/real length:

        Original Packet Length (32 bits): an unsigned value that indicates the actual length of the packet when it was transmitted on the network.

and that the "Captured Packet Length" is the number of bytes in the capture:

        Captured Packet Length (32 bits): an unsigned value that indicates the number of octets captured from the packet (i.e. the length of the Packet Data field).

That is the exact *opposite* of

Attachment: Screenshot_14.png
Description: PNG image