Re: PCAP-NG Block Formats

[Guy Harris <guy () alum mit edu>]

On Jun 10, 2016, at 8:43 AM, Paul Offord <Paul.Offord () advance7 com> wrote:

> OK – let’s hope it’s the doc.  The thing is, if there could be an optional Options block at the end of the EPB we 
> will have to have the 4 byte endofopt otherwise a reader could interpret the trailing Total Block Length as an option 
> block.  I suppose the standard could require that the reader keep track of the block size and then figure out if 
> Options are included but that is pretty messy.

Note that the reader has to keep track of the block size *anyway*, so it doesn't just run past the end of the block if 
the block doesn't happen to include an endofopt (readers must not assume all writers have followed the spec).

So the end-of-option option doesn't make correct option-parsing code any simpler (it makes *unsafe* option-parsing code 
simpler, but there shouldn't *be* any unsafe option-parsing code), and should probably not have been in the spec.  
Perhaps a future version of the spec should allow it to be omitted, and specify that either 1) not having enough space 
left in the block for a full option (i.e., fewer than 4 bytes left in the packet) or 2) seeing an endofopt terminates 
the processing of options (in case a writer puts out an endofopt and some amount of extra junk after it).
 
> I’ll raise as a Wireshark bug and let’s see who screams.

Give an indication of which version of Wireshark wrote the file with only a two-byte endofopt, and of the procedure 
used to produce it, and attach a capture; I just looked at the 2.0.x code that writes EPBs and it appears to write 4 
bytes of zeroes.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe