On Jun 7, 2004, at 1:55 AM, Mark Pizzolato wrote:
2) Additionally, The application which uses the dedicated Intel NIC, only
really wants to use Ethernet type devices, so it takes the set of interfaces
returned by pcap_findalldevs, and uses pcap_open_live on each, and then
calls pcap_datalink to validate if the interface type is DLT_EN10MB.
"Is an Ethernet-type device" and "has a DLT_ value of DLT_EN10MB" aren't equivalent.
"Has a DLT_ value of DLT_XXX" means "packets captured on this device have a link-layer header of the type for DLT_XXX" - on Linux, for example, loopback devices have a DLT_ value of DLT_EN10MB, because the Linux loopback device supplies packets with Ethernet-format headers (albeit with what are presumably bogus MAC addresses), and, on at least some of the BSDs, 802.11 interfaces have a default DLT_ value of DLT_EN10MB, either because the device is run by the driver in "fake Ethernet header" mode or for what I presume is backwards compatibility for applications that don't understand DLT_IEEE802_11.
It might be useful to have {libp,WinP}cap supply, in addition to the link-layer header type (the DLT_ value), a network interface type (perhaps an SNMP ifType value).
Oddly, when using winpcap 3.1 beta3, of the two interfaces returned by
pcap_findalldevs (Vertified by Ethereal), the NdisWAN interface passes the
DLT_EN10MB test,
That might be because the Network Monitor driver (which is what WinPcap 3.1 uses to capture on NDISWAN interfaces) puts fake Ethernet headers on packets it delivers to its users.
while the 3Com interface doesn't.
That's a bug, given that you've said it's an Ethernet interface; what DLT_ value does it have?
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
