[pcap-ng-format] Separate options for "user" and "vendor" descriptions of an interface?

Anders Broman anders.broman at ericsson.com
Mon Jan 26 22:52:18 UTC 2015


On ethernet interfaces perhaps the mac adress could be used?

Skickat från min Sony Xperia™-smartphone

---- Guy Harris skrev ----


On Jan 26, 2015, at 1:42 PM, Jasper Bongertz <jasper at packet-foo.com> wrote:

> Another issue with interfaces is that it would be nice to have an
> identifier that stays the same across different capture jobs. Windows
> captures currently have this with the GUID in the interface name, but
> as far as I know all others don't.

No OS other than Windows provides, as far as I know, any form of either per-machine or global interface identifiers that are persistent and guaranteed to be unique over time.

> I'm not sure though on how to create and keep those indentifiers
> persistent  across  multiple  runs of dumpcap. On Windows its
> something the OS does (as far as I can tell) and dumpcap uses.

Dumpcap just uses the name provided by libpcap/WinPcap and, on NT 5 and later, WinPcap has to look up interfaces by GUID, and the OS provides such a GUID, so that's what's used in the interface name.

Without something in the OS code that manages interfaces supplying an interface identifier of the type described, I don't think libpcap or anything using libpcap could provide one itself - if it can't determine whether "eth0" at time T and "eth0" at time T+deltaT are the same interface, it can't know whether to give them the same ID or different IDs.

The code providing them would probably have to store them in some form of persistent storage so that they survive a reboot.

A quick look at the I/O Kit registry on my Mac doesn't show an obvious property assigned to, for example, en0 that would allow some form of global interface persistent and unique ID or even a per-host persistent and unique ID.  I don't know whether Linux distributions provide it, either via the kernel (I suspect not, especially given the "persistent" requirement) or via udev or whatever's the new hotness these days, or whether *BSD, Solaris, HP-UX, or AIX provide anything of that sort.

So, whilst it'd be nice, step 1 wouldn't be a pcap-ng step, it'd be an "underlying OS" step.
_______________________________________________
pcap-ng-format mailing list
pcap-ng-format at winpcap.org
https://www.winpcap.org/mailman/listinfo/pcap-ng-format


More information about the pcap-ng-format mailing list