This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

PCAP-NG format, Interface Description Block: Interface ID missing

0

Reading again the PCAP Next Generation Dump File Format specification, i see a defect in the Interface Description Block paragraph: the figure shows no Interface ID inside the block though this field is described underneath.

This was never fixed? Too bad, it would really have been nicer than numerating the interfaces by their order in the list of Interfae Description Blocks.

Or am i missing something?

asked 20 Sep '13, 01:11

ime-braun's gravatar image

ime-braun
1445
accept rate: 0%


One Answer:

2

You're right, it is not in the block, but it doesn't have to be. When reading a PCAPng file the first Interface Description Block is interface 0, the second is interface 1, and so on. It is sort of mentioned in the sentence that says

Interface ID: Tools that write / read the capture file associate a progressive 16-bit number (starting from '0') to each Interface Definition Block.

To add an index to the block is not necessary, but of course this means that when reading and writing PCAPng files you must keep the interfaces in the same order, or, if reordering them, renumber the interface IDs in all frames headers accordingly.

But since I'm going to work on the specifications in the next couple of weeks/months anyway I'll write down a reminder to myself to clarify this in the text.

answered 20 Sep '13, 01:34

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 20 Sep '13, 01:35

You're right, it is not in the block, but it doesn't have to be.

Yes, but I would vote to have it there, as an explicit Interface ID is used in several other block, so why not here?

(20 Sep '13, 04:04) Kurt Knochner ♦

It is necessary in other blocks to reference the interface. In the Interface Description Block it would say "0" for the first block, "1" for the second, and so on. Reading the blocks I can do that in code, incrementing the ID for each block I read, so having it in the block is kind of redundant information.

There is a "reserved" 16 bit block left in the IDB, so unless it is reserved with something else in mind we could use it for an index of up to 65535 interfaces.

(20 Sep '13, 04:13) Jasper ♦♦

incrementing the ID for each block I read, so having it in the block is kind of redundant information.

yes that's true, but it requires an (kind of 'out of band') agreement how to handle/create the Interface ID, which needs to be part of the format/structure definition. Nothing wrong with that approach, but also kind of inconsistent in regards of the ID usage in the rest of the specs, especially as you don't loose much space if you add the ID into the block.

(20 Sep '13, 04:41) Kurt Knochner ♦

well, there is an agreement like that, it's just not as specific as it should be. I'll consider using the free 16 bits for the ID, unless others have a veto. Waiting on Guy for his 2 cents ;-)

(20 Sep '13, 04:53) Jasper ♦♦

Note that, given that pcap-ng files without an interface ID in the IDB already exist, no code can depend on there being an interface ID in the IDB, unless you change the minor version of pcap-ng and have some code (code that requires an interface ID in the IDB) incapable of reading the current version of pcap-ng, which strikes me as not an ideal situation.

Presumably the idea is that this would mean that, when writing pcap-ng 1.1 files, you wouldn't have to "keep the interfaces in the same order, or, if reordering them, renumber the interface IDs in all frames headers accordingly", but you'd still, when reading pcap-ng 1.0 files, have to assign the interface IDs based on the ordinal numbers of the IDBs. However, unless you choose not to support writing pcap-ng 1.0 files, you'd still have to have the code to keep the interfaces in the same order or renumber them.

The "out-of-band agreement how to handle the interface ID" is already in the pcap-ng spec; it's the quoted section of the spec in the answer.

(20 Sep '13, 18:04) Guy Harris ♦♦