We acknowledge and respect the
PCAP Capture File Format documentation.
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.
For our application, unfortunately we do not support the PCAPng format, so we are just based on normal libpcap and nseclibpcap.
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.
And, this could be one of the unconventional scenarios that may cause a change to the specification's Section 5 explanation.
What do you suggest for a resolution that's convenient for all?
On Jul 18, 2023, at 8:10 PM, CheeHow WEE via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:
> 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.
By "In highspeed performance (scale of > 100 million packets per second) PCAP writing, it's necessary to form a bulk" do you mean that, in order to be able to write packets at high speed, you buffer up a large number of pcap Packet Records in memory and then write a buffer out in one write operation, and that aligning the Packet Records on 4-byte boundaries means that when you put a Packet Record into the buffer, you're storing 4-byte values on 4-byte boundaries and copying packet data to a 4-byte boundary, thus not getting any penalties for doing misaligned stores?
If so, note that pcapng blocks are always aligned on 4-byte boundaries, so if you write a pcapng file in this fashion, it doesn't require any hacks to code that reads the file.
> - 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.
If the "actual captured packet" is 193 bytes long, then, in a padded pcap file, there would need to be *3* bytes of trailer. If the packet was *supposed* to be 194 bytes long, but whatever software constructed it left one byte out, then, as code that reads padded pcap files would mark that packet as having a captured length of 193 bytes and an original length of 193 bytes, and the dissector would presumably run out of bytes, as it'd be dissecting something that *should* have been 194 bytes long, and would show an error.