Comment # 8
on bug 11452
from Guy Harris
(In reply to Hadriel Kaplan from comment #7)
> Sorry I should have re-opened this bug; there are actually several bugs
> logged in my head that need to be opened and resolved for pcapng.
Well, this *particular* bug is fixed; presumably you're speaking of creating
*new* bugs for other issues.
> But right
> now I'm working on generating test pcapng files for the various scenarios,
> so I can add them to the test suite with the bug fix deliveries.
>
> Some other bugs logged in my head that I will eventually open bugzilla bugs
> for:
> 1) mergecap also assumes all files have at least one IDB. (but see #8 below)
> 2) for mergecap/capinfos: pcapng's file reading code doesn't get *all* the
> IDBs in a file until it reads through the whole file, so mergecap/capinfo's
> have an incorrect view of what all the IDBs and linktypes/encaps are in the
> file.
Yes, the way we handle IDBs should be redone. The IDBs read at the beginning
are best thought of as hints, so that you can preemptively reject some attempts
to read a file and write another file (when merging, editing with editcap, or
filtering with TShark) when you know up front that the output file format can't
handle it. In one-pass programs, you won't be able to preemptively reject
*all* attempts, so some might fail in the middle of processing if, for example,
you discover an IDB with a link-layer header type that the output format
doesn't support (the output format isn't necessarily pcap or pcapng, so it
doesn't necessarily support all formats that have LINKTYPE_ values).
We also should probably generate interface information from the appropriate
block type in Microsoft Network Monitor files and from per-packet information
in file formats such as iptrace. I.e.:
> 8) I've been thinking that all wiretap file readers should actually create
> an IDB - make that the way it works, by having wtap do it for them if they
> don't do it themselves (i.e., just as it currently does it on behalf of
> legacy pcap files). But this doesn't mean an IDB will always exist - a truly
> empty pcapng file won't have one, for example. But the point is to make wtap
> be more like a pcapng file format internally.
some file formats *should* do it themselves.
There should also be a way for the sequential reading routines to indicate
"hey, some more interfaces showed up".
You are receiving this mail because:
- You are watching all bug changes.