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.
> - 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
Section 5 "Packet Record" of the current version of the pcap specification:
https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcap.html#name-packet-record
says:
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.
Packet Data:
the data coming from the network, including link-layer headers. The actual length of this field is Captured Packet Length. The format of the link-layer headers depends on the LinkType field specified in the file header (see Figure 1) and it is specified in [I-D.ietf-opsawg-pcaplinktype].
If you want to have a mechanism to use to pad pcap packet records to a multiple of 4 bytes, then:
1) that's going to require some changes to code that reads pcap files (libpcap, Wireshark's libwiretap, etc.);
2) that's going to require a change to the pcap specification.
Some possible changes to the pcap specification:
1) The specification can be changed to indicate that Captured Packet Length > Original Packet Length means that:
the full packet data has been captured and written to the file;
the Original Packet Length field indicates the amount of packet data;
{Captured Packet Length} - {Original Packet Length} is the amount of padding added after the packet data;
or
2) we introduce new magic numbers for "padded pcap" files, which means we could, for example, state that in "padded pcap" files, all Packet Records are padded to a multiple of 4 bytes.