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.