[Winpcap-users] Retireving MAC Address

Guy Harris guy at alum.mit.edu
Sun Jan 8 01:29:48 GMT 2006


Loris Degioanni wrote:

> Interface type or DLT_ value: the Interface Description Block has a 
> LinkType field, which is still marked as "todo" in the specs, but that 
> is actually meant to contain the DLT of the interface. As far as I know, 
> in fact, ntar is using DLTs for the linktype. Gianluca, do you confirm?

In a capture file, an interface will presumably be supplying packets 
with a particular link-layer type (even with the "any" device on Linux), 
so LinkType is sufficient.

In a list of interfaces, however, a given interface might support more 
than one link-layer type (e.g., an 802.11 interface on various BSDs 
would offer DLT_EN10MB for the benefit of applications that don't know 
about 802.11 or radio headers, DLT_IEEE802_11 for apps that do know 
about 802.11 headers, and DLT_IEEE802_11_RADIO for apps that care about 
the radio information).

If we have a pcap_findalldevs() replacement, I'd have it supply an 
attribute-value list for interfaces, as that would mean we could add new 
attributes without changing the API or ABI, and would mean that if some 
attribute is unavailable for an interface, we indicate that by omitting 
it from the attribute-value list).

For that, we should probably use the same values to identify attributes 
in that list as we use in the pcap-ng Interface Description Block.

Given that, we should probably define one for DLT_ values, even if we 
don't bother putting it into all pcap-ng files (although if we get the 
atributes for the Interface Description Block from a pcap_findalldevs() 
replacement, or from a "get the attributes for a particular interface" 
API, we'd get the list of DLT_ values, and we might as well just include 
them, even if they aren't useful).

> Flags: we can definitely make this addition to the specification and to 
> ntar.

The flags I'd include would be

	PCAP_IF_LOOPBACK (because we already have it)

	PCAP_IF_IPCSUMOFFLOAD (or something such as that, to indicate that it 
does IPv4 checksum offloading)

	PCAP_IF_TCPCSUMOFFLOAD (or something such as that, to indicate that it 
does TCP checksum offloading)

	PCAP_IF_UDPCSUMOFFLOAD (or something such as that, to indicate that it 
does UDP checksum offloading)

The names are negotiable for the checksum offloading flags, because 
those names are both a bit long and a bit ugly.

> With the additional problem that in Windows in some cases there's the 
> ambiguity between real link layer and "fake ethernet link layer" 
> introduced by the OS or the NIC driver. Sometimes it's quite difficult 
> to tell what was originally ethernet and what wasn't.

If there's no way to *reliably* determine, on some particular version of 
Windows, the SNMP interface type for an adapter in Windows, WinPcap 
probably shouldn't supply it.  (There *are* SNMP agents on Windows, but 
I don't know if they reliably supply that information, or if they use 
undocumented or otherwise unsupported interfaces to get it.)


More information about the Winpcap-users mailing list