Wireshark-dev: Re: [Wireshark-dev] Option to disable Expert Info for issue with frame length

From: "Maynard, Chris" <Christopher.Maynard@xxxxxxx>
Date: Fri, 21 Jul 2023 14:50:06 +0000

I think it may be best to open an issue for this at https://gitlab.com/wireshark/wireshark/-/issues and choose “FeatureRequest” for the template.

- Chris

 

From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of CheeHow WEE via Wireshark-dev
Sent: Tuesday, July 18, 2023 11:10 PM
To: wireshark-dev@xxxxxxxxxxxxx
Cc: CheeHow WEE <cheehow@xxxxxxxxxxxxxxx>
Subject: [Wireshark-dev] Option to disable Expert Info for issue with frame length

 

Hi there,

 

I would like to follow up on the above request, I've yet to get any response from previous mail.

So, I will try with a new mail, the subsequent content will be the same.

 

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

 

 

 

 

 

 

 

 

 

 

 

CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited.