On Jun 10, 2016, at 5:19 AM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:
>
> In the documentation in https://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html section 3.3 the diagram shows that a variable length Options block can exist at the end of an Enhanced Packet Block. I have assumed that if I don’t want to specify options I have to add an Option Code opt_endofopt and Option Length of zero at the point, which comes to four bytes 0x00000000.
No, you don't.
As the spec says:
3.5. Options
All the block bodies MAY embed optional fields. ...
Emphasis on "MAY".
The spec should discuss that more, including emphasizing that a reader must pay attention to the block total length when processing options - or deciding whether there are any options to process. I'll look at doing that.
> However, I’ve noticed that Wireshark generated traces don’t seem to do this. All the examples I have looked at have two bytes of zeros, but this happens to align the end of the packet data on a 32-bit boundary and so I’m not sure if that’s the reason for the two bytes.
Yes, it is. As the section on the EPB says:
* Captured Packet Length: 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 10). The value of this field does not include the padding octets added at the end of the Packet Data field to align the Packet Data field to a 32-bit boundary.
...
* Packet Data: the data coming from the network, including link-layer headers. The actual length of this field is Captured Packet Length plus the padding to a 32-bit boundary.
> · If I don’t want to add options to a packet, what should I add just prior to the trailing Block Total Length value?
Nothing.
> · Is this a Wireshark bug (writing incorrect format PCAP-NG files)?
No.
