SetupApi to get network adapter properties

Hi all,

I’ve been trying to use the python ctypes library (which talks to Windows DLLs directly) to make calls to SetupAPI and get a network adapter’s CompatibleIDs

(The intention is to figure out consistently whether it is a LAN adapter or a Wireless adapter. (and the code will run on Win XP+))

So, here’s what I’m doing:

  1. (For now manually) get the GUID of my device from the reg key HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCard<networkconnection status>
    2) Call SetupDiGetClassGetDevsW with a GUID object and get back a Device Information Set
    3) Call SetupDiEnumDeviceInterfaces with the returned handle from one, and a pointer to a SP_DEVICE_INTERFACE_DATA object.

    Now, the return value from 2 comes out False, and when I call GetLastError it gives me a 259 (For No More Items I believe)

    Questions:
    1) Can anyone suggest why it can’t find my network card even though I give it the correct GUID?
    2) Is there a simpler or more practical approach for distinguishing between a LAN and Wireless adapter? Win32_NetworkAdapter.AdapterTypeId is not consistent on the wireless cards that I’ll be querying.

    Here’s the code:

    import win32com.client
    import socket
    import winreg
    import ctypes
    from ctypes import *
    from ctypes.wintypes import *
    import sys
    import re

    class GUID(Structure):
    fields = [(“Data1”, c_ulong),
    (“Data2”, c_ushort),
    (“Data3”, c_ushort),
    (“Data4”, c_ubyte * 8)]

    class SP_DEVICE_INTERFACE_DATA(Structure):
    fields = [(‘cbSize’, DWORD),
    (‘InterfaceClassGuid’, GUID),
    (‘Flags’, DWORD),
    (‘Reserved’, POINTER(ULONG))]

    wmi_cl = win32com.client.Dispatch(‘WbemScripting.SWbemLocator’)
    conn = wmi_cl.ConnectServer(socket.gethostname(), ‘root\cimv2’)
    adapters = conn.ExecQuery(‘SELECT * FROM Win32_NetworkAdapter WHERE NetConnectionID LIKE “%LOCAL%”’)
    status = adapters[0].NetConnectionStatus

    # Fetch the GUID from registry
    raw_string = r’Software\Microsoft\Windows NT\CurrentVersion\NetworkCards%s’ % status
    hkey = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE, raw_string)
    guid
    = winreg.EnumValue(hkey, 0)[1]
    guid
    = re.sub(‘-’, ‘’, guid
    [1:-1])
    print guid


    #Convert the GUID string into a proper GUID object
    hex_bytes = [guid_[i:i+2] for i in range(0, len(guid_),2)]
    print hex_bytes
    DEVICE = GUID(eval(‘0x’+‘’.join(hex_bytes[0:4])),
    eval(‘0x’+hex_bytes[4]+hex_bytes[5]),
    eval(‘0x’+hex_bytes[6]+hex_bytes[7]),
    (eval(‘0x’+hex_bytes[8]),
    eval(‘0x’+hex_bytes[9]),
    eval(‘0x’+hex_bytes[10]),
    eval(‘0x’+hex_bytes[11]),
    eval(‘0x’+hex_bytes[12]),
    eval(‘0x’+hex_bytes[13]),
    eval(‘0x’+hex_bytes[14]),
    eval(‘0x’+hex_bytes[15])))

    print hex(DEVICE.Data1)
    print hex(DEVICE.Data2)
    print hex(DEVICE.Data3)
    print hex(DEVICE.Data4[0])
    print hex(DEVICE.Data4[1])
    print hex(DEVICE.Data4[2])
    print hex(DEVICE.Data4[3])
    print hex(DEVICE.Data4[4])
    print hex(DEVICE.Data4[5])
    print hex(DEVICE.Data4[6])
    print hex(DEVICE.Data4[7])

    # Obtain Device Information Set for our device
    hInfo = ctypes.windll.setupapi.SetupDiGetClassDevsW(byref(DEVICE), None, None, None)
    if hInfo == -1:
    print ‘Something went wrong’
    sys.exit(0)
    else:
    # We could get the device information set!
    # Now, get the enumerated device interfaces
    in_info = SP_DEVICE_INTERFACE_DATA()
    in_info.cbSize = sizeof(in_info)
    found_dev = ctypes.windll.setupapi.SetupDiEnumDeviceInterfaces(hInfo, None, byref(DEVICE), 0, byref(in_info))
    if not found_dev:
    # We coudn’t get them :(!
    print ‘Error %s occurred( If it was 259, we already have no more items. :(’ % ctypes.windll.kernel32.GetLastError()
    else:
    # Figure out how to get our CompatibilityID detail
    # by calling SetupDiGetDeviceInterfaceDetailW and then SetupDiOpenDevRegKey
    print ‘We got a device! Now code the rest!’
    pass

xxxxx@gmail.com wrote:

I’ve been trying to use the python ctypes library (which talks to Windows DLLs directly) to make calls to SetupAPI and get a network adapter’s CompatibleIDs

There’s a built-in Python module to convert a GUID string to binary:

import uuid
x = uuid.UUID(‘{00010203-0405-0607-0809-0a0b0c0d0e0f}’)
print x.bytes

  1. (For now manually) get the GUID of my device from the reg key HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCard<networkconnection status>
    >

    Where did you get this code? You fetch the NetConnectionStatus, and
    look that up in the NetworkCards registry key. That’s just garbage –
    there’s no relationship between those two values. My network adapter
    returns a NetConnectionStatus of 2 (“connected”), but there’s no subkey
    “2” under NetworkCard. The only two things under NetworkCard on my
    machine are the two 1394 network adapters (11 and 17).

    > 2) Is there a simpler or more practical approach for distinguishing between a LAN and Wireless adapter? Win32_NetworkAdapter.AdapterTypeId is not consistent on the wireless cards that I’ll be querying.
    >

    In that case, I think your task is hopeless. The card or driver is
    lying to Windows, and everything else is going to lie to you as well.

    > 2) Call SetupDiGetClassGetDevsW with a GUID object and get back a Device Information Set
    > 3) Call SetupDiEnumDeviceInterfaces with the returned handle from one, and a pointer to a SP_DEVICE_INTERFACE_DATA object.
    >
    > Now, the return value from 2 comes out False, and when I call GetLastError it gives me a 259 (For No More Items I believe)
    >
    > Questions:
    > 1) Can anyone suggest why it can’t find my network card even though I give it the correct GUID?
    >

    Because the GUID that you’re fetching is not a Device Interface GUID.
    It’s just the name of the registry Services key for that device. Where
    did you get the idea that this would work?


    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

Hi Tim,

And thanks a lot for the speedy reply! Replies inline…

On Mon, Dec 21, 2009 at 7:11 PM, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> > I’ve been trying to use the python ctypes library (which talks to Windows
> DLLs directly) to make calls to SetupAPI and get a network adapter’s
> CompatibleIDs
> >
>
> There’s a built-in Python module to convert a GUID string to binary:
>
> import uuid
> x = uuid.UUID(‘{00010203-0405-0607-0809-0a0b0c0d0e0f}’)
> print x.bytes
>
>
Neat. I did see this - but will I be able to just pass this object to the
Windows functions?

> > 1) (For now manually) get the GUID of my device from the reg key
> HKLM\Software\Microsoft\Windows
> NT\CurrentVersion\NetworkCard<networkconnection status>
> >
>
> Where did you get this code? You fetch the NetConnectionStatus, and
> look that up in the NetworkCards registry key. That’s just garbage –
> there’s no relationship between those two values. My network adapter
> returns a NetConnectionStatus of 2 (“connected”), but there’s no subkey
> “2” under NetworkCard. The only two things under NetworkCard on my
> machine are the two 1394 network adapters (11 and 17).
>
>
Ouch. Ok, this just happened to be exactly the same on a couple of my
machines. I’d still have preferred a better way of being able to get the
ClassGUID. Unfortnately, again, Win32_NetworkAdapter doesn’t have the GUID
property in XP. :frowning: What’s the right way to get it?

> > 2) Is there a simpler or more practical approach for distinguishing
> between a LAN and Wireless adapter? Win32_NetworkAdapter.AdapterTypeId is
> not consistent on the wireless cards that I’ll be querying.
> >
>
> In that case, I think your task is hopeless. The card or driver is
> lying to Windows, and everything else is going to lie to you as well.
>
>
Yes, that is unfortunate indeed. If this were working, I’d not have to worry
about the SetupApi at all.

> > 2) Call SetupDiGetClassGetDevsW with a GUID object and get back a Device
> Information Set
> > 3) Call SetupDiEnumDeviceInterfaces with the returned handle from one,
> and a pointer to a SP_DEVICE_INTERFACE_DATA object.
> >
> > Now, the return value from 2 comes out False, and when I call
> GetLastError it gives me a 259 (For No More Items I believe)
> >
> > Questions:
> > 1) Can anyone suggest why it can’t find my network card even though I
> give it the correct GUID?
> >
>
> Because the GUID that you’re fetching is not a Device Interface GUID.
> It’s just the name of the registry Services key for that device. Where
> did you get the idea that this would work?
>
>
Alright, that makes sense. Looks like I got carried aware here again. Again,
what’s the right way to get the GUID?

Thanks and regards,
Avanish

> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

On Mon, Dec 21, 2009 at 7:38 PM, Avanish Raju wrote:

> Hi Tim,
>
> And thanks a lot for the speedy reply! Replies inline…
>
> On Mon, Dec 21, 2009 at 7:11 PM, Tim Roberts wrote:
>
>> xxxxx@gmail.com wrote:
>> > I’ve been trying to use the python ctypes library (which talks to
>> Windows DLLs directly) to make calls to SetupAPI and get a network adapter’s
>> CompatibleIDs
>> >
>>
>> There’s a built-in Python module to convert a GUID string to binary:
>>
>> import uuid
>> x = uuid.UUID(‘{00010203-0405-0607-0809-0a0b0c0d0e0f}’)
>> print x.bytes
>>
>>
> Neat. I did see this - but will I be able to just pass this object to the
> Windows functions?
>
>
>> > 1) (For now manually) get the GUID of my device from the reg key
>> HKLM\Software\Microsoft\Windows
>> NT\CurrentVersion\NetworkCard<networkconnection status>
>> >
>>
>> Where did you get this code? You fetch the NetConnectionStatus, and
>> look that up in the NetworkCards registry key. That’s just garbage –
>> there’s no relationship between those two values. My network adapter
>> returns a NetConnectionStatus of 2 (“connected”), but there’s no subkey
>> “2” under NetworkCard. The only two things under NetworkCard on my
>> machine are the two 1394 network adapters (11 and 17).
>>
>>
> Ouch. Ok, this just happened to be exactly the same on a couple of my
> machines. I’d still have preferred a better way of being able to get the
> ClassGUID. Unfortnately, again, Win32_NetworkAdapter doesn’t have the GUID
> property in XP. :frowning: What’s the right way to get it?
>
>
Oops - I think I just figured this one ought - I’ll try using
SetupDiClassGuidsFromName with Win32_NetworkAdapter as an argument and see
where that leads me. Thanks a lot! I wouldn’t have realized how much on the
wrong path I was on if you hadn’t replied. :slight_smile:

>
>> > 2) Is there a simpler or more practical approach for distinguishing
>> between a LAN and Wireless adapter? Win32_NetworkAdapter.AdapterTypeId is
>> not consistent on the wireless cards that I’ll be querying.
>> >
>>
>> In that case, I think your task is hopeless. The card or driver is
>> lying to Windows, and everything else is going to lie to you as well.
>>
>>
> Yes, that is unfortunate indeed. If this were working, I’d not have to
> worry about the SetupApi at all.
>
>
>> > 2) Call SetupDiGetClassGetDevsW with a GUID object and get back a
>> Device Information Set
>> > 3) Call SetupDiEnumDeviceInterfaces with the returned handle from one,
>> and a pointer to a SP_DEVICE_INTERFACE_DATA object.
>> >
>> > Now, the return value from 2 comes out False, and when I call
>> GetLastError it gives me a 259 (For No More Items I believe)
>> >
>> > Questions:
>> > 1) Can anyone suggest why it can’t find my network card even though I
>> give it the correct GUID?
>> >
>>
>> Because the GUID that you’re fetching is not a Device Interface GUID.
>> It’s just the name of the registry Services key for that device. Where
>> did you get the idea that this would work?
>>
>>
> Alright, that makes sense. Looks like I got carried aware here again.
> Again, what’s the right way to get the GUID?
>
> Thanks and regards,
> Avanish
>
>
>
>
>> –
>>
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> “Life is what you make of it”
> Y. Avanish Raju,
> Google India Pvt. Ltd.
>
> BTech, Computer Science and Engineering & Biotechnology,
> ICFAI University, Dehradun
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
> !V
> PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
> ------END GEEK CODE BLOCK------
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

Avanish Raju wrote:

Ouch. Ok, this just happened to be exactly the same on a couple of
my machines. I’d still have preferred a better way of being able
to get the ClassGUID. Unfortnately, again, Win32_NetworkAdapter
doesn’t have the GUID property in XP. :frowning: What’s the right way to
get it?

Oops - I think I just figured this one ought - I’ll try using
SetupDiClassGuidsFromName with Win32_NetworkAdapter as an argument
and see where that leads me. Thanks a lot! I wouldn’t have realized
how much on the wrong path I was on if you hadn’t replied. :slight_smile:

Where do you think this is going to lead you? Wired and wireless
network adapters both end up in the same setup class. They’re all filed
under “Network Adapters”.

I’m not sure you really grasped what I said before. If the WMI
AdapterTypeID is lying to you, then it is likely that no entity in the
system (other than the driver) knows the truth. The device might have a
private API to tell that, but that doesn’t help.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

On Mon, Dec 21, 2009 at 7:52 PM, Tim Roberts wrote:

> Avanish Raju wrote:
> >
> >
> > Ouch. Ok, this just happened to be exactly the same on a couple of
> > my machines. I’d still have preferred a better way of being able
> > to get the ClassGUID. Unfortnately, again, Win32_NetworkAdapter
> > doesn’t have the GUID property in XP. :frowning: What’s the right way to
> > get it?
> >
> >
> > Oops - I think I just figured this one ought - I’ll try using
> > SetupDiClassGuidsFromName with Win32_NetworkAdapter as an argument
> > and see where that leads me. Thanks a lot! I wouldn’t have realized
> > how much on the wrong path I was on if you hadn’t replied. :slight_smile:
>
> Where do you think this is going to lead you? Wired and wireless
> network adapters both end up in the same setup class. They’re all filed
> under “Network Adapters”.
>
> I’m not sure you really grasped what I said before. If the WMI
> AdapterTypeID is lying to you, then it is likely that no entity in the
> system (other than the driver) knows the truth. The device might have a
> private API to tell that, but that doesn’t help.
>
>
I see. What about, if I try to get the GUIID of the adapters (instead of
Class GUID) , and get their CompatibleID property? I see that LAN adapters
always have PCI\CC_020000 listed in their compatible ID list, but Wireless
adapters have PCI\CC_028000. Is this a fair way of differentiating, or am I
still over-generalizing my observation? After all, this is also how the
Windows Device Driver wizard ensures that we don’t use a LAN adapter driver
for a Wireless card, or vice versa, right?

Regards,
Avanish

> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

Have you considered using WMI and the Win32_NetworkAdapter class?

AFAIK WMI queries and operations from Python are pretty easy. Well, at
least compared to trudging through SetupAPI. It will also work on a 64-bit
platforms if you care.

Incidentally, OID_GEN_PHYSICAL_MEDIUM can be pretty handy in determining if
an adapter is Wireless or Wired Ethernet. I don’t recall if it is exposed
via WMI anywhere or not; I don’t see a mapping in Win32_NetworkAdapter.

Good Luck,
Dave Cattley

If you can get the device GUID you may be able to use IOCTL_NDIS_QUERY_GLOBAL_STATS to fetch OID_GEN_PHYSICAL_MEDIUM that David suggested.

See the topic “Making NDIS Queries from User Mode” on the page http://ndis.com/ndis-general/default.htm for some guidance.

Good luck,

Thomas F. Divine

On Mon, Dec 21, 2009 at 8:31 PM, David R. Cattley wrote:

> Have you considered using WMI and the Win32_NetworkAdapter class?
>
>
Thanks David. Indeed I have, yes. That’s the first thing that occurred to
me. However, sadly, as I mentioned earlier in the thread, the properties
that are supposed to be indicate adapter type, namely, AdapterType and
AdapterTypeId, are 0 on both the LAN card and Wireless LAN card for the set
of machines I need to deal with. :frowning:

AFAIK WMI queries and operations from Python are pretty easy. Well, at
> least compared to trudging through SetupAPI. It will also work on a 64-bit
> platforms if you care.
>
> Incidentally, OID_GEN_PHYSICAL_MEDIUM can be pretty handy in determining if
> an adapter is Wireless or Wired Ethernet. I don’t recall if it is exposed
> via WMI anywhere or not; I don’t see a mapping in Win32_NetworkAdapter.
>
>
Thanks indeed for this advice. I’ll search around a little more.

Good Luck,
> Dave Cattley
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

On Mon, Dec 21, 2009 at 8:39 PM, wrote:

> If you can get the device GUID you may be able to use
> IOCTL_NDIS_QUERY_GLOBAL_STATS to fetch OID_GEN_PHYSICAL_MEDIUM that David
> suggested.
>
> See the topic “Making NDIS Queries from User Mode” on the page
> http://ndis.com/ndis-general/default.htm for some guidance.
>
>
Awesome link! What scares me a little is - the page indicates that Microsoft
might deprecate the use of IOCTLS to query information. However, if it’s
consistent from XP to 7, and I won’t have to worry about an MS patch
changing this behaviour, that should serve my purpose.

I’ll take a deeper dig at that. Thanks indeed!!!

> Good luck,
>
> Thomas F. Divine
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

I just checked the code for MACADDR2, and it seems the types it queries are
precisely what I’d get in Win32_NetworkAdapter (
http://msdn.microsoft.com/en-us/library/aa394216(VS.85).aspx).
Do the WMI calls to Win32_NetworkAdapter finally terminate on the API to
NDIS again? If that’s the case, then I’m bound to get the same result,
precisely as Tim suggested to begin with. :frowning:

What about the way I suggested, of trying to check Compatible IDs, and see
if the queried adapter has PCI\CC_028000 or PCI\CC_020000 in its list?
Could you please chime in on the practicality/consistency of such an
approach?

Regards,
Avanish

On Mon, Dec 21, 2009 at 9:33 PM, Avanish Raju wrote:

>
>
> On Mon, Dec 21, 2009 at 8:39 PM, wrote:
>
>> If you can get the device GUID you may be able to use
>> IOCTL_NDIS_QUERY_GLOBAL_STATS to fetch OID_GEN_PHYSICAL_MEDIUM that David
>> suggested.
>>
>> See the topic “Making NDIS Queries from User Mode” on the page
>> http://ndis.com/ndis-general/default.htm for some guidance.
>>
>>
> Awesome link! What scares me a little is - the page indicates that
> Microsoft might deprecate the use of IOCTLS to query information. However,
> if it’s consistent from XP to 7, and I won’t have to worry about an MS patch
> changing this behaviour, that should serve my purpose.
>
> I’ll take a deeper dig at that. Thanks indeed!!!
>
>
>> Good luck,
>>
>> Thomas F. Divine
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
> “Life is what you make of it”
> Y. Avanish Raju,
> Google India Pvt. Ltd.
>
> BTech, Computer Science and Engineering & Biotechnology,
> ICFAI University, Dehradun
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
> !V
> PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
> ------END GEEK CODE BLOCK------
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

> 1) Can anyone suggest why it can’t find my network card even though I give it the correct GUID?

This is not the correct GUID.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Well, I know that you can use SetupDiGetClassDevs to enumerate all devices of class GUID_NDIS_LAN_CLASS. One of the fields (a string of some sort…) that you can fetch can then be used to open a handle to be used with IOCTL_NDIS_QUERY_GLOBAL_STATS to make the query for OID_GEN_PHYSICAL_MEDIUM that you (apparently) need to identify WLAN adapters.

The INetCfgComponent::GetId method can be used in co-installers to get the ID of a NIC. I have used this in NDIS Notify Objects to selectively bind a protocol-edge to specific USB or PCI devices.

I think you can get the information you need. We’re just not going to give it to you on a silver platter.

Good luck,

Thomas F. Divine

From: Avanish Raju
Sent: Monday, December 21, 2009 9:44 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] SetupApi to get network adapter properties

I just checked the code for MACADDR2, and it seems the types it queries are precisely what I’d get in Win32_NetworkAdapter (http://msdn.microsoft.com/en-us/library/aa394216(VS.85).aspx).
Do the WMI calls to Win32_NetworkAdapter finally terminate on the API to NDIS again? If that’s the case, then I’m bound to get the same result, precisely as Tim suggested to begin with. :frowning:

What about the way I suggested, of trying to check Compatible IDs, and see if the queried adapter has PCI\CC_028000 or PCI\CC_020000 in its list? Could you please chime in on the practicality/consistency of such an approach?

Regards,
Avanish

On Mon, Dec 21, 2009 at 9:33 PM, Avanish Raju wrote:

On Mon, Dec 21, 2009 at 8:39 PM, wrote:

If you can get the device GUID you may be able to use IOCTL_NDIS_QUERY_GLOBAL_STATS to fetch OID_GEN_PHYSICAL_MEDIUM that David suggested.

See the topic “Making NDIS Queries from User Mode” on the page http://ndis.com/ndis-general/default.htm for some guidance.

Awesome link! What scares me a little is - the page indicates that Microsoft might deprecate the use of IOCTLS to query information. However, if it’s consistent from XP to 7, and I won’t have to worry about an MS patch changing this behaviour, that should serve my purpose.

I’ll take a deeper dig at that. Thanks indeed!!!

Good luck,

Thomas F. Divine


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M !V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M !V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Have you considered using WMI and the Win32_NetworkAdapter class?
>
> AFAIK WMI queries and operations from Python are pretty easy. Well, at
> least compared to trudging through SetupAPI. It will also work on a
> 64-bit
> platforms if you care.
>
> Incidentally, OID_GEN_PHYSICAL_MEDIUM can be pretty handy in determining
> if
> an adapter is Wireless or Wired Ethernet. I don’t recall if it is exposed
> via WMI anywhere or not; I don’t see a mapping in Win32_NetworkAdapter.
>
> Good Luck,
> Dave Cattley

The WMI object for OID_GEN_PHYSICAL_MEDIUM is NdisPhysicalMediumType;
The InstanceName member is name of the adapter.

class MSNdis_PhysicalMediumType : MSNdis
{
[key, read] string InstanceName;
[read] boolean Active;
[read, WmiDataId(1)] uint32 NdisPhysicalMediumType;
};

@OP: Using WMI, you can query just wi-fi adapters, using wi-fi specific
classes
not dependent of connection/association state, such as
MSNdis_80211_NetworkTypeInUse or MSNdis_80211_NumberOfAntennas.
This query gets all wi-fi adapters in your machine, because each one creates
exactly one instance of that class.

To get all adapters, use Msndis_EnumerateAdapter.
The DeviceName member is PnP device id of the adapter.
The InstanceName member, again, is name of the adapter.

Regards,
–pa

On Mon, Dec 21, 2009 at 10:45 PM, Thomas F. Divine wrote:

> Well, I know that you can use SetupDiGetClassDevs to enumerate all
> devices of class GUID_NDIS_LAN_CLASS. One of the fields (a string of some
> sort…) that you can fetch can then be used to open a handle to be used
> with IOCTL_NDIS_QUERY_GLOBAL_STATS to make the query for
> OID_GEN_PHYSICAL_MEDIUM that you (apparently) need to identify WLAN
> adapters.
>
> The INetCfgComponent::GetId method can be used in co-installers to get the
> ID of a NIC. I have used this in NDIS Notify Objects to selectively bind a
> protocol-edge to specific USB or PCI devices.
>
> I think you can get the information you need. We’re just not going to give
> it to you on a silver platter.
>

Thank you very much, Thomas for the very useful pointers! Totally agreed
about not giving it straight - then it shouldn’t be me doing the coding. :slight_smile:
I sincerely appreciate all the help I’m getting on the thread.

Regards,
Avanish

>
> Good luck,
>
> Thomas F. Divine
>
>
> From: Avanish Raju
> Sent: Monday, December 21, 2009 9:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] SetupApi to get network adapter properties
>
> I just checked the code for MACADDR2, and it seems the types it queries are
> precisely what I’d get in Win32_NetworkAdapter (
> http://msdn.microsoft.com/en-us/library/aa394216(VS.85).aspx).
> Do the WMI calls to Win32_NetworkAdapter finally terminate on the API to
> NDIS again? If that’s the case, then I’m bound to get the same result,
> precisely as Tim suggested to begin with. :frowning:
>
> What about the way I suggested, of trying to check Compatible IDs, and see
> if the queried adapter has PCI\CC_028000 or PCI\CC_020000 in its list?
> Could you please chime in on the practicality/consistency of such an
> approach?
>
> Regards,
> Avanish
>
> On Mon, Dec 21, 2009 at 9:33 PM, Avanish Raju wrote:
>
>>
>>
>> On Mon, Dec 21, 2009 at 8:39 PM, wrote:
>>
>>> If you can get the device GUID you may be able to use
>>> IOCTL_NDIS_QUERY_GLOBAL_STATS to fetch OID_GEN_PHYSICAL_MEDIUM that David
>>> suggested.
>>>
>>> See the topic “Making NDIS Queries from User Mode” on the page
>>> http://ndis.com/ndis-general/default.htm for some guidance.
>>>
>>>
>> Awesome link! What scares me a little is - the page indicates that
>> Microsoft might deprecate the use of IOCTLS to query information. However,
>> if it’s consistent from XP to 7, and I won’t have to worry about an MS patch
>> changing this behaviour, that should serve my purpose.
>>
>> I’ll take a deeper dig at that. Thanks indeed!!!
>>
>>
>>> Good luck,
>>>
>>> Thomas F. Divine
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>>
>>
>> –
>> “Life is what you make of it”
>> Y. Avanish Raju,
>> Google India Pvt. Ltd.
>>
>> BTech, Computer Science and Engineering & Biotechnology,
>> ICFAI University, Dehradun
>>
>> -----BEGIN GEEK CODE BLOCK-----
>> Version: 3.12
>> GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
>> !V
>> PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
>> ------END GEEK CODE BLOCK------
>>
>
>
>
> –
> “Life is what you make of it”
> Y. Avanish Raju,
> Google India Pvt. Ltd.
>
> BTech, Computer Science and Engineering & Biotechnology,
> ICFAI University, Dehradun
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
> !V
> PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
> ------END GEEK CODE BLOCK------
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

Hi Pavel!

On Mon, Dec 21, 2009 at 10:50 PM, Pavel A. wrote:

> “David R. Cattley” wrote in message news:xxxxx@ntdev.
> …
>
>> Have you considered using WMI and the Win32_NetworkAdapter class?
>>
>> AFAIK WMI queries and operations from Python are pretty easy. Well, at
>> least compared to trudging through SetupAPI. It will also work on a
>> 64-bit
>> platforms if you care.
>>
>> Incidentally, OID_GEN_PHYSICAL_MEDIUM can be pretty handy in determining
>> if
>> an adapter is Wireless or Wired Ethernet. I don’t recall if it is exposed
>> via WMI anywhere or not; I don’t see a mapping in Win32_NetworkAdapter.
>>
>> Good Luck,
>> Dave Cattley
>>
>
> The WMI object for OID_GEN_PHYSICAL_MEDIUM is NdisPhysicalMediumType;
> The InstanceName member is name of the adapter.
>
>
Thank you immensely for this information. I can see at least that on Win 7,
this clearly gives me the correct PhysicalMediumType, even though
Win32_NetworkAdapter is still deceiving (it still shows both my LAN and
Wireless adapters as 0)

However, on Win XP, NdisPhysicalMediumType continues to show the adapters
both as 0. I don’t expect I’ll be able to get valid data on these adapters
even on digging deeper. But I think I have enough information by now to move
forward with my purpose.

Finally, also, a big thank you to all of you on this thread that took the
time and patiently replied with all of your experience. I think, in a day,
I’ve moved much closer to my solution that I imagined I would in weeks.

Regards,
Avanish

> class MSNdis_PhysicalMediumType : MSNdis
> {
> [key, read] string InstanceName;
> [read] boolean Active;
> [read, WmiDataId(1)] uint32 NdisPhysicalMediumType;
> };
>
>
> @OP: Using WMI, you can query just wi-fi adapters, using wi-fi specific
> classes
> not dependent of connection/association state, such as
> MSNdis_80211_NetworkTypeInUse or MSNdis_80211_NumberOfAntennas.
> This query gets all wi-fi adapters in your machine, because each one
> creates exactly one instance of that class.
>
> To get all adapters, use Msndis_EnumerateAdapter.
> The DeviceName member is PnP device id of the adapter.
> The InstanceName member, again, is name of the adapter.
>
> Regards,
> --pa
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


“Life is what you make of it”
Y. Avanish Raju,
Google India Pvt. Ltd.

BTech, Computer Science and Engineering & Biotechnology,
ICFAI University, Dehradun

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/S/MU d- s:- a-- C++++ UL+++ P+ L+++>++++ E–> W++ N o? K- w+>w++ !O !M
!V
PS++@ PE++ Y+@ PGP- t 5? X+ R tv b+++ DI+@ D+ G e>++ h* r-- y
------END GEEK CODE BLOCK------

>The INetCfgComponent::GetId method can be used in co-installers to get the ID of a NIC.

Do you know how you can match this against the PnP IDs from SetupDi/CM_xxx?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

What’s wrong with WlanEnumInterfaces?

I have an INI file that specifies the bus and VID, as illustrated below. The
bus/VID string is compared to the string returned from GetId.

Thomas

; This section specifies the Ethernet adapter
; that the filter is allowed to bind to.
;
; Adapters are identified by the bus and vendor ID.
;
[Adapters]
; LinkSys USB
BindToVendorID=usb\vid_0bda

; D-Link USB
; BindToVendorID=usb\vid_2001

; Intel PCI
; BindToVendorID=pci\ven_8086


From: “Maxim S. Shatskih”
Sent: Tuesday, December 22, 2009 12:46 AM
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Subject: Re:[ntdev] SetupApi to get network adapter properties

>>The INetCfgComponent::GetId method can be used in co-installers to get the
>>ID of a NIC.
>
> Do you know how you can match this against the PnP IDs from
> SetupDi/CM_xxx?
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

Pavel,

Thanks for reminding me to look in the root\WMI namespace as well as
root\CIMv2 :slight_smile:

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Monday, December 21, 2009 10:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] SetupApi to get network adapter properties

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Have you considered using WMI and the Win32_NetworkAdapter class?
>
> AFAIK WMI queries and operations from Python are pretty easy. Well, at
> least compared to trudging through SetupAPI. It will also work on a
> 64-bit
> platforms if you care.
>
> Incidentally, OID_GEN_PHYSICAL_MEDIUM can be pretty handy in determining
> if
> an adapter is Wireless or Wired Ethernet. I don’t recall if it is exposed
> via WMI anywhere or not; I don’t see a mapping in Win32_NetworkAdapter.
>
> Good Luck,
> Dave Cattley

The WMI object for OID_GEN_PHYSICAL_MEDIUM is NdisPhysicalMediumType;
The InstanceName member is name of the adapter.

class MSNdis_PhysicalMediumType : MSNdis
{
[key, read] string InstanceName;
[read] boolean Active;
[read, WmiDataId(1)] uint32 NdisPhysicalMediumType;
};

@OP: Using WMI, you can query just wi-fi adapters, using wi-fi specific
classes
not dependent of connection/association state, such as
MSNdis_80211_NetworkTypeInUse or MSNdis_80211_NumberOfAntennas.
This query gets all wi-fi adapters in your machine, because each one creates

exactly one instance of that class.

To get all adapters, use Msndis_EnumerateAdapter.
The DeviceName member is PnP device id of the adapter.
The InstanceName member, again, is name of the adapter.

Regards,
–pa


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer