On Thu, Nov 1, 2012 at 1:28 PM, Marc Petit-Huguenin
<marc@xxxxxxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> I am writing an external program that is reading a pcapng file generated by
> editcap. The spec for pcapng[1] describes the options as a list of TLV ended
> by the opt_endofopt type, so one may think that the minimal option list is the
> empty list 0x00000000. But a file (generated by editcap) containing no option
> in the EnhancedPacket block does not contain even an empty list. There is a
> redundancy here - if the presence of an option list is determined by the size
> of the block, then opt_endofopt is redundant as the end of list can be
> determined from the block size (and in all cases, opt_endofopt still looks
> redundant)
>
> So, is editcap right to not put an empty list after the captured packet? and
> if it is the case, then what is the point of opt_endofopt?
I think editcap is correct. The options are listed as optional. Thus,
in processing the block, if the block-length tells you that there
cannot be any options, then you do not need to even process them.
However, the opt_endofopt option makes it easy when processing
options. Of course it would be possible to keep track of the block
total length and how much you have already processed, so in that sense
it is redundant.
I guess the real question is:
Is it legal to have a pcap-ng file that contains a block with options
that does not contain an opt_endofopt option?
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)