Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 12508] Wireshark writes Enhanced Packet Blocks without Opt

Date: Fri, 10 Jun 2016 22:58:14 +0000

changed bug 12508


What Removed Added
Status UNCONFIRMED RESOLVED
Resolution --- NOTABUG

Comment # 1 on bug 12508 from
(In reply to Paul Offord from comment #0)
> Wireshark writes PCAP-NG files using Enhanced Packet Blocks (EPBs).  At the
> end of the EPB, just before the trailing Block Total Length, is an Options
> block.

At the end of an EPB, or any other type of block, there *MAY BE* an options
block; to quote the pcapng specification:

    3.5. Options

    All the block bodies MAY embed optional fields. ...

Emphasis on "MAY".

> If there are no options, the Option Block should have a single entry
> referred to as opt_endofeopt.

Nope, the pcapng specification doesn't say that.  If the lengths of the Block
Type, Block Total Length, non-option part of the Block Body, and second Block
Total Length field add up to the value of the Block Total Length field, the
block has no options.

> Wireshark does not add the opt_endofopt bytes to the EPB.

And, if there are no options, it shouldn't.

> If another program writes EPBs with the opt_endofopt Option entry, Wireshark
> misreads the blocks causing unpredictable errors.

If so, that's a *separate* bug, and you should file it as a separate bug, with
a capture file, as written by the other program, attached, demonstrating the
problem.

The file attached to *this* bug reads fine in a reasonably recent Wireshark
master branch version of Wireshark, a reasonably recent Wireshark 2.0.x branch
version of Wireshark, and a reasonably recent master branch version of tcpdump
with a reasonably recent master branch version of libpcap, so there doesn't
seem to be anything wrong with it; both EPBs have lengths that are exactly
large enough to include the Block Type, Block Total Length, fixed-length part
of the EPB, packet data (as per the captured length), 2 bytes of padding (to a
multiple of 4 bytes) in the second EPB, and the trailing Block Total Length, so
they have no options and no option parsing is done on them.


You are receiving this mail because:
  • You are watching all bug changes.