[pcap-ng-format] TODO in pcap-ng specifications

[Guy Harris]

On Jul 25, 2012, at 2:48 PM, Jasper Bongertz wrote:

> On 25.07.2012 03:50, Richard Sharpe wrote:
> 
>> Unfortunately, we have to allow the existing implementations to 
>> continue to work, so we might have to say that for 1.0, an 
>> implementation is free to ignore all but the first or last instance
>> of an option that has multiple instances in an options list. I
>> THINK THIS ISSUE REQUIRES MORE DISCUSSION.
> 
> I'd go for the first, but right now I doubt there are many
> implementations that use multiple instances anyway. pcap-ng is pretty
> fresh and AFAIK no tool except now Wireshark (and the Hone project)
> even used it so far.

There's "use" as in read and "use" as in write; Wireshark may be the only major project that writes pcap-ng, but libpcap reads it as of 1.1.0, so any program that uses libpcap can, if it's using libpcap 1.1.0 or later, can read pcap-ng files (as long as all IDBs in the file have the same link-layer header type and snapshot length).

> I see the problem. We have a Block Total Length value that is read
> before the Byte-Order magic is. I'm not sure how much trouble it is to
> require a read of the Byte-Order magic first before interpreting the
> Block Total Length. My implementation basically puts a record
> structure over the Block, so I can easily read the Byte-Order magic
> before interpreting Block Total Length. I'd like the specs to stay
> consistent as much as possible, so in this case I lean towards having
> people read the Byte-Order magic first indeed.

Wireshark currently looks at the block total length first, but it just checks there to see whether it's too small to be a valid SHB - if it's byte-swapped, unless it's a *very* large SHB, a byte-swapped total length will be *larger*, so that code is probably "safe".  It should, however, be fixed; I'll do that.

libpcap doesn't do that for the first SHB - it *reads* the total length before it reads the byte-order magic, but doesn't look at the total length until it's looked at the byte-order magic.  For subsequent SHBs, it doesn't, but it should.