Hello Guy,
I’ve added you to bug 15292, in order to get your view on the matter.
The issue at hand is the relation between the PCAP global header, snap length field and the Packet header, included length field.
I refer to the specification here: https://wiki.wireshark.org/Development/LibpcapFileFormat
The specification of the first says: "the 'snapshot length' for the capture (typically 65535 or even more, but might be limited by the user), see: incl_len vs. orig_len below"
The specification of the second says: "the number of bytes of packet data actually captured and saved in the file. This value should never become larger than orig_len or the snaplen value of the global header.”
One could argue that the included length is never larger than the snap length, but the specification uses ‘should’, so it is not prohibited. I wonder why.
Is it so that for some type of data link metadata is added to the packet, causing it to become larger than the snap length, while the actual captured packet data still matches the snap length. In that case I would expect the original length field to be lower than the included length field. Not sure if there are such cases.
Anyway, back to the bug. Text2pcap writes 64kB in the PCAP global header while processing packets up to WTAP_MAX_PACKET_SIZE_STANDARD, which is significantly larger. Does that indeed require a change?
Thanks,
Jaap