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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 24 Jul 2023 10:49:03 -0700
On Jul 24, 2023, at 1:47 AM, CheeHow WEE <cheehow@xxxxxxxxxxxxxxx> wrote:

> Thanks for explaining a detailed "possible" implementation of the packet alignment in previous mails.
> It's actually performed within the given PCIe based FPGA capture card, hence the packets are stored in the card's memory (presumably a ring buffer) by firmware aligned to a certain boundary for efficiency reasons.
> In our case, it's 32 bits.

Are the packets in the capture card's buffer in the form of pcap Packet Records, with the card putting a pcap Packet Record header in front of each packet's data, so that you can just write data to disk directly from the card's buffer (or have the card's buffer transferred into host memory and then writing to disk directly from host memory)?

And does "aligned to a certain boundary for efficiency reasons. In our case, it's 32 bits." mean that 1) the Packet Records are all padded to 32 bits in the buffer and 2) that the Captured Packet Length field in the Packet Record headers is, rather than the number of captured bytes in the packet, the number of packet bytes in the packet *rounded up to a multiple of 4 bytes*?

If so, does the capture card support "slicing" packets, so that not all bytes in the packet on the network are in the packet in the capture?

> The main concern from our side is actually Wireshark added Commit 8674eea7 and fixed Issue 18312, there're a lot of error frames that are marked as opposed to earlier versions.
> It causes temporal understanding mismatch when a user reads a PCAP generated by our capture system on Wireshark.
> We would like to request a "reverse" of the commit by having an option.

"You have a problem.  You add an option to work around the problem.  You now have two problems." :-)

Is there some reason why an option is preferable to, for example, changing the pcap specification, so that Captured Packet Length > Original Packet Length means that the Packet Record is padded, and the real Captured Packet Length is equal to the Original Packet Length?  The lack of an option means that Wireshark Just Works with both normal pcap files and padded pcap files, with users not having to worry about correctly setting an option?

(And libpcap should be changed as well, for the same reason.)