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

Wireshark-dev: Re: [Wireshark-dev] interfaces support

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 13 Oct 2011 19:23:24 -0700
On Oct 13, 2011, at 6:40 PM, Andrew Kampjes wrote:

> What support does wireshark currently have for multiple interfaces?

"Currently" as in 1.6.x, or "currently" as in the SVN trunk?  And are you referring to support when capturing or support when reading a capture file?  It sounds as if you're referring to the latter.

> The pcap-ng format supports them but they don't seem to be shown anywhere

Currently - as in "the SVN trunk", so it also means in earlier releases - we don't have anywhere in the GUI that can show you a list of the interfaces.

> and I can't find any points in the code to add interfaces to the GUI.
> 
> I would like to add the interface as a column for ERF. I can already do that manually but right clicking on the field and adding selecting apply as column.

We should probably look at restructuring Wiretap a bit, to be a more pcap-ng-oriented API, which might also allow us to improve the handling of some other capture file formats.  I.e., a read should, instead of returning a packet, return a data item, which could be a packet or an interface description or....

For pcap-ng, an Interface Description Block would be reported as an interface description.

For file formats that don't have records for interfaces, interface description reports would be synthesized as appropriate, e.g. for pcap one would be supplied before the first packet.

For ERF, the ERF-reading code would presumably report interfaces A through D with synthesized interface either before reporting the first packet record or before reporting the first packet record with the specified interface, and report the multi-channel interfaces before reporting the first packet record with the specified channel.

An interface index would be supplied in the Wiretap header provided for all packet records - yes, that would be redundant in ERF files, but that would allow the GUI code not to have to know or care.