[Winpcap-users] Retireving MAC Address

[Loris Degioanni]

Guy,

Guy Harris wrote:
> Alessandro Baldisserri wrote:
> 
>> There is a way to obtain MAC Address with PCAP API other than Packet 
>> API ?
>> Another question:
>>
>> - Is there a method to recognize only ethernet card from device list?
> 
> 
> Not currently.  I want to add to a future libpcap release a 
> pcap_findalldevs_ex() API (or maybe an API with a different name), which 
> returns a list of lists of type/value pairs, with the type values being 
> the ones for the Interface Description Block in pcap-ng.
> 
> That list of type values already has information for the interface name, 
> IPv4 addresses, IPv6 addresses, and descriptive strings, which covers 
> most of what pcap_findalldevs() returns.  It also has information for 
> the MAC address.
> 
> However, it currently doesn't have an entry for interface flags, which 
> pcap_findalldevs() returns, or an entry for the interface type or DLT_ 
> value.

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?

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


> A value for the interface flags should probably be added (and more 
> flags, such as "does IP checksum offloading", "does TCP checksum 
> offloading", and "does UDP checksum offloading", should be added - that, 
> plus the per-packet direction indication, would allow tcpdump/WinDump, 
> Ethereal, etc. to avoid trying to check the checksum of packets sent out 
> on an interface that offloads them).
> 
> We should perhaps also add both interface type (using SNMP ifType values 
> from
> 
>     http://www.iana.org/assignments/ianaiftype-mib
> 
> ) and DLT_ values (which are *somewhat* correlated to interface types, 
> but not completely correlated; an interface with the ifType value 24, 
> for softwareLoopback, might have DLT_NULL on various BSDs and DLT_EN10MB 
> on Linux, for example, and an interface with the DLT_ value DLT_EN10MB 
> might have type 6 for ethernetCsmacd, or type 71 for ieee80211 if the 
> adapter and software always supply fake Ethernet headers - or it might 
> have *more than one* type, e.g. an 802.11 adapter on many BSDs, which 
> can support DLT_EN10MB for backward compatibility, DLT_IEEE80211, and 
> one of the "radio header" values).  (Yes, the DLT_ types are somewhat 
> redundant with the LinkType field; LinkType should be used to determine 
> what type of link-layer headers the packets actually have, while, in a 
> capture file, the list of DLT_ types indicates what it *could* support.)
> 
> Adding that would let you ignore interfaces that don't have the type you 
> want.

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.

Loris


> For now, you'd have to open the interface and get its type - also bear 
> in mind that non-Ethernet interfaces might still have type DLT_EN10MB.
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>