On Jun 10, 2016, at 8:43 AM, Paul Offord <[email protected]> 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 <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
