On Jun 10, 2016, at 8:43 AM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> 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.
