On June 07, 2004 at 11:52 AM, Guy Harris wrote:
>
> 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.
I already address the loopback interface issue (which my app will never be
interested in using) by keying off the PCAP_IF_LOOPBACK value returned in
the flags field of the pcap_if_t returned by pcap_findalldevs(),. I also
skip an interface if it is named "any".
> 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?
Well, my original report/analysis was based on a little bit of laziness.
Since I had both Ethereal and my App's display of available interfaces I
tried to infer the inner workings. My analysis was completely wrong.
There is NO issue with the values returned by pcap_datalink(). It returns
DLT_EN10MB as appropriate.
However, there are an issuues with pcap_findalldevs() on ONLY my Win2K
Server SMP system, which happens to have installed the Microsoft supplied
Network Monitor application installed. All of the win-pcap V3.1 beta
versions work find on my WinXP and Win2K Pro desktop systems.
The Win2K Server SMP system gets the following results from pcap_findalldevs
with differing versions of win-pcap:
winpcap V3.0:
\Device\NPF_{054BF786-C6A0-47E1-A532-3B17559575C2} (Intel(R) PRO/100+
Management Adapter)
\Device\NPF_{F582D8E0-3386-4DEE-A88A-68C1B752D3E5} (3Com EtherLink PCI)
winpcap V3.1 beta:
error in pcap_findalldevs: PacketGetAdapterNames: Attempt to release mutex
not owned by caller
winpcap V3.1 beta2:
\Device\NPF_GenericNdisWanAdapter (Generic NdisWan adapter)
winpcap V3.1 beta3:
\Device\NPF_GenericNdisWanAdapter (Generic NdisWan adapter)
My original analysis was lead astray by Ethereal's Capture Options Dialog
box. The Interface field seems to be populated either from a remembered
value or is derived some other way besides using pcap_findalldevs(). The
contents of the list dropdown for the Interface IS the interface set
returned by pcap_findalldevs(). Initially (in my mind) I merged the current
value of the field with the dropdown contents. So in the end, Ethereal and
my App are seeing the same data (Generic Ndis Wan Adapter), and NOT seeing
either of the physical NICs which are installed in the system.
- Mark Pizzolato
==================================================================
This is the WinPcap users list. It is archived at
http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use
mailto: [EMAIL PROTECTED]
==================================================================
