On Oct 17, 2020, at 7:25 AM, Harald Welte <laforge@xxxxxxxxxxxx> wrote:
> I'm currently facing a problem where I need to create pcap files
Or, at least, *some* form of capture file....
> 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.
Yes, those were some of the goals of pcapng:
supporting captures from multiple interfaces, with different link-layer header types;
providing, for each interface, information about the interface, including a name and, if available, a description;
identifying, for each packet, the interface on which the packet was captured.
> 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.
Yes, the "Frame" section of the packet details will indicate the interface ID and, if available, the interface name and description.
> However, I don't seem to be able to find any code for actually ever
> writing this file when generating capture files.
There is currently no code in libpcap to support writing pcapng files (and the code it has to *read* them uses the current libpcap API, meaning it can't read all libpcap files, and doesn't make the additional information in pcapng files available).
We (the libpcap developers) would like to provide APIs to:
get additional information when capturing, to put into pcapng files;
get additional information when reading pcapng files;
support writing pcapng files.
(For the third of those, Michael Richardson has been talking about other changes to support faster writing of capture files, including support for asynchronous I/O.)
Wireshark doesn't use libpcap to read or write capture files; instead, it has two libraries:
libwiretap, which is a general library for reading and writing many capture file formats, including pcap, pcapng, and *other* formats;
libwritecap, which is a much smaller and simpler library, used by dumpcap, to write pcap and pcapng files.
That's how dumpcap can write pcapng files when capturing.
> 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.
Yes. Fixing that would be part of the "get additional information when capturing, to put into pcapng files" item above.
Currently, dumpcap doesn't work around the absence of support for that in libpcap; it probably *could* do so.
(This is, by the way, one of the reasons why the pcapng spec does *not* require that all Interface Description Blocks appear at the beginning of the file - if you capture on the "any" device, new devices may appear while the capture is in progress, and, at some point before the first packet on the new interface is written to a pcapng file, an IDB for that interface would have to be written, if we're writing separate IDBs for each interface rather than just writing a single IDB for the "any" interface.)
> 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.
It can, although you can also do memory-mapped capture, which is what current versions of libpcap do. The information in question is provided by memory-mapped captures as well.
> 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?
Yes. The reason is "nobody's written the code to do so yet". :-)
