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

[Jasper Bongertz]

There is an option called "if_MACaddr" in the PCAPng interface block
specifications, but so far I have never seen a file where it is
actually present (same goes for "if_IPv4addr" and "if_IPv6addr").

The MAC address was also what came to mind, with the usual "well, it's
allowing to track a specific machine down to the hardware" privacy
concerns - but then again, the Windows GUID will most likely never be
changed for that reason, so its probably not any better.

I have no idea how easy it is to get the capture card's MAC address
and write it to the file... but it's probably a lot easier than the
step 1 thing Guy mentioned.

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3681 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150127/6b9f3b01/attachment.bin>