I see the same problem in Wireshark 2.0.4. I've created Bug 12508 and attached a three packet file captured with Wireshark 2.0.4 that shows the problem.
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: 10 June 2016 19:17
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] PCAP-NG Block Formats
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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
______________________________________________________________________
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.
Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
