[Winpcap-users] Retireving MAC Address

[Gianluca Varenni]

----- Original Message ----- 
From: "Guy Harris" <guy at alum.mit.edu>
To: <winpcap-users at winpcap.org>
Sent: Saturday, January 07, 2006 5:29 PM
Subject: Re: [Winpcap-users] Retireving MAC Address


> 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).

This would probably mean adding a replacement for pcap_open() or 
pcap_open_live(), in order to specify the adapter name *and* the DLT we want 
to use in that adapter, in case the adapter supports multiple DLTs. Unless 
we somewhat embed the DLT in the adapter name passed to pcap_open(). Doesn't 
this make things unnecessary complicated?

>
> 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.

Yes, probably.

>
> 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).

I didn't understand what you meant. In any case, supposing that we want to 
have this concept of interface type vs. supported DLTs, where a particular 
physical adapter has *one* interface type and possibly *multiple* supported 
DLTs, when you save the captured packets to pcap-ng, it makes sense to save 
*both* the interface type *and* the DLT. Is this what you meant? Which 
brings again my previous question: do we really need all this complexity?

>
>> 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.

:-))

GV

>
>> 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.)
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>