Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3096] Ability to annotate packet captures

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3096

--- Comment #66 from Guy Harris <guy@xxxxxxxxxxxx> 2012-02-20 18:02:11 PST ---
(In reply to comment #55)
> Created attachment 7856 [details]
> Read and write multiple IDB:s
> 
> This should make it possible to read and write multiple IDB:s
> could some one check it in please(if OK) as I have problems with
> RapidSVN and cygwin currently. IDB options are still lost as there
> is no code to write them.
> Regards
> Anders

Note that the comment

        /* Loop ower all IDB:s */

should be changed to

        /* Loop ower all IDB:s that appear before any packets */

because

    http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb

says

    In order to properly associate the captured data to the corresponding
interface, the Interface Description Block must be defined before any other
block that uses it; therefore, this block is usually placed immediately after
the Section Header Block.

but "usually" isn't "always".  Consider, for example, a capture on the "any"
device; a capturing program could, instead of writing out a single IDB for the
"any" device, write out IDBs for actual adapters as soon as a packet arrives
for a not-already-known interface.  That way, the capture records which
particular interface a packet was received or sent on (there's either a bug in
the libpcap or tcpdump bug databases, or a message to tcpdump-workers, where
somebody wanted tcpdump to be able to print the interface name in an "any"
capture, so there are people who want that), and it can handle interfaces that
appear after the capture is started (the "any" device works by not bothering to
bind the PF_PACKET socket to a particular device, so *all* packets are directed
to that socket, even ones from devices that didn't exist at the time the
capture started).

Unfortunately, that makes the logic more complicated; for a multi-pass program,
you can just accumulate the interface information as you read the file, but for
a single-pass program, you'd have to copy interface information as it shows up
while reading.

One way would be to have a read routine that can return more than just packet
information, so it can say "and *this* is a new interface".

Another way would be to have the program reading the packets check whether the
packet came in on an interface it knows about and, if not, query Wiretap again
for the list of interfaces.

Note, BTW, that pcap-NG isn't the only file format that stores interface
information; or example, Network Monitor stores it as well.  It puts it into
fake packets with link-layer header type values of 0xFFFD or 0xFFFB (the record
header includes a link-layer header type).  The fake packet contains a count of
adapters (up to 65535), a "Computer Name" (probably the NetBIOS-ish name, even
with NetBIOS dying off over time) and, per adapter:

    the "friendly name" of the adapter (this would be something
not-too-technical such as "Local Area Connection" - I don't know what it'd be
for some server with 8 Ethernet ports, say);

    a "Description", which looks like the vendor description from the driver
(such as "AMD PCNet Family PCI Ethernet Adapter - Packet Scheduler Miniport");

    an optional "Layer Name";

    the "miniport GUID" (which is probably the GUID string from the adapter
name);

    a MediaType (probably the link-layer header type);

    the MTU (which is 0 on the adapter in question);

    the link speed (64-bit bits-per-second value - 3Gbps for the adapter, go
figure, although it's *really* a large chunk of software from VMware, not an
*actual* AMD adapter);

    the MAC address;

    counted lists of various address properties - IPv4 addresses, IPv6
addresses, gateway addresses (IPv4 addresses of routers, presumably), DHCP
server addresses, and DNS server(?) addresses.

In the capture I have, it's the second "packet" in the capture, after another
fake "capture filter" packet (which also gives the software that did the
capture - as a couple of hex version numbers and the pathname of NetMon's
executable!), so it appears before all packets.  The UI isn't particularly
sophisticated - it just shows the information as a packet in the capture - so,
in theory, we could perhaps have multiple such fake packets in the capture, for
the "any"-device case, without breaking much.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.