Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] pcapng / interface names / OPT_IDB_NAME

From: Harald Welte <laforge@xxxxxxxxxxxx>
Date: Sat, 17 Oct 2020 16:25:47 +0200
Dear wireshark developers,

I'm currently facing a problem where I need to create pcap files of about
26 network devices in parallel.  24 of those are hdlcX devices (by Linux
kernel hdlc_fr), while two are Ethernet devices.  So there are
different link types, but I doubt this matters for the remainder of the
discussion.

The resulting capture file should of course indicate on which particular interface
a given packet was sent or received.

I discovered that pcap-ng has the if_name field as part of the Interface Description Block,
so that during the capture process, one can store the InterfaceID to interface name
mapping, and then every packet refers to the InterfaceID.

Looking at the wireshark source, wiretap seems to translate that to OPT_IDB_NAME
and looking further at the code it appears that this might be displayed some way.

However, I don't seem to be able to find any code for actually ever
writing this file when generating capture files.

Furthermore, when starting a cooked Linux capture on the Linux 'any' device,
it also appears wireshark is not displaying the information about which netdevice
the message was captured.

As far as I know, on AF_PACKET sockets one can do recvmsg() and will then get
a sockaddr_ll structure alongside the actual packet, which contains the ifindex
of the underlying network deivce.  Together with the usual sockopt or netlink
based method that can be trnaslated to a device name.

Am I missing something?  Is there a specific reason why this information is not
obtained/displayed or written when writing an output file, even in pcap-ng mode?
Maybe there are some preferences I'm missing, or I'm looking at the
wrong code?

Any related help is appreciated.

Regards,
	Harald
-- 
- Harald Welte <laforge@xxxxxxxxxxxx>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)