Hi!
Is it possible at all for a LWF to query the underlying USB miniport to
glean more information about a device the LWF is attached to? In this case,
the underlying miniport would be the generic RNDIS USB miniport.
Information that I would like to glean (besides vid, which I know I can
resolve through plumbing OID_GEB_VENDOR_ID from my LWF) would be pid,
manufacturer string, product string, and serial number.
I’m looking for a solution for Windows 7 and newer.
Thanks!
NDIS doesn’t handle that much detail from the USB bus, and RNDIS won’t give that much detail to NDIS anyway. (When you query OID_GEN_VENDOR_ID, you’re seeing a hardware-reported value which apparently happens to coincide with the USB VID, but it’s not guaranteed to.)
You really want to find the underlying devnode and issue IOCTL_USB_GET_NODE_INFORMATION. This is easier from usermode, if you have that luxury.
Finding the underlying devnode can get complicated, in the general case where an IM driver sits between you and the actual physical miniport. You can walk the ifStackTable to get through the built-in IM drivers (although I don’t think that vmSwitch populated ifStackTable back on Windows Server 2008 R2). The easiest strategy is to just say you don’t support configurations like that :).
I don’t know an elegant way to find the underlying devnode. Here’s a non-elegant way to do it:
Given the complexity of the above, I can’t really claim it as a great piece of engineering… I hope you can come across a better way to do it.
Thanks, Jeffery!
This is at least a good start. I’ll update the group with the methods I used
for the USB query.
“Jeffrey Tippet” wrote in message news:xxxxx@ntdev…
NDIS doesn’t handle that much detail from the USB bus, and RNDIS won’t give
that much detail to NDIS anyway. (When you query OID_GEN_VENDOR_ID, you’re
seeing a hardware-reported value which apparently happens to coincide with
the USB VID, but it’s not guaranteed to.)
You really want to find the underlying devnode and issue
IOCTL_USB_GET_NODE_INFORMATION. This is easier from usermode, if you have
that luxury.
Finding the underlying devnode can get complicated, in the general case
where an IM driver sits between you and the actual physical miniport. You
can walk the ifStackTable to get through the built-in IM drivers (although I
don’t think that vmSwitch populated ifStackTable back on Windows Server 2008
R2). The easiest strategy is to just say you don’t support configurations
like that :).
I don’t know an elegant way to find the underlying devnode. Here’s a
non-elegant way to do it:
Given the complexity of the above, I can’t really claim it as a great piece
of engineering… I hope you can come across a better way to do it.
> 6. Open the device registry key IoOpenDeviceRegistryKey(PLUGPLAY_REGKEY_DRIVER.
This requires the pdo, not the top of stack. After getting the top of stack, you need to send a query device relations / target device and use the resulting pdo in the API call. Remember to ObDeref the PDO from the QDR.
d
Bent from my phone
From: Jeffrey Tippetmailto:xxxxx
Sent: ?12/?19/?2013 6:25 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] Can A LWF Driver Query An Underlying USB Device?
NDIS doesn’t handle that much detail from the USB bus, and RNDIS won’t give that much detail to NDIS anyway. (When you query OID_GEN_VENDOR_ID, you’re seeing a hardware-reported value which apparently happens to coincide with the USB VID, but it’s not guaranteed to.)
You really want to find the underlying devnode and issue IOCTL_USB_GET_NODE_INFORMATION. This is easier from usermode, if you have that luxury.
Finding the underlying devnode can get complicated, in the general case where an IM driver sits between you and the actual physical miniport. You can walk the ifStackTable to get through the built-in IM drivers (although I don’t think that vmSwitch populated ifStackTable back on Windows Server 2008 R2). The easiest strategy is to just say you don’t support configurations like that :).
I don’t know an elegant way to find the underlying devnode. Here’s a non-elegant way to do it:
1. NDIS_FILTER_ATTACH_PARAMETERS::NetLuid ->GetIfTable2Ex
2. Read MIB_IF_ROW2::InterfaceGuid
3. Find all network devices with IoRegisterPlugPlayNotification(GUID_DEVINTERFACE_NET)
4. For each network device, that you’re notified of, open a handle ZwOpenFile
5. Get the device object with ObReferenceObjectByHandle, FILE_OBJECT::DeviceObject
6. Open the device registry key IoOpenDeviceRegistryKey(PLUGPLAY_REGKEY_DRIVER)
7. Read the “NetCfgInstanceId” value and compare it to the InterfaceGuid you read in step #2
8. If the NetCfgInstanceId value matches, this is the right miniport. Issue the IOCTL to the device.
Given the complexity of the above, I can’t really claim it as a great piece of engineering… I hope you can come across a better way to do it.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
Starting with NDIS 6.2, can?t I use the MiniportPhysicalDeviceObject member of the NDIS_FILTER_ATTACH_PARAMETERS struct for the PDO?
“Doron Holan” wrote in message news:xxxxx@ntdev…
> 6. Open the device registry key IoOpenDeviceRegistryKey(PLUGPLAY_REGKEY_DRIVER.
This requires the pdo, not the top of stack. After getting the top of stack, you need to send a query device relations / target device and use the resulting pdo in the API call. Remember to ObDeref the PDO from the QDR.
d
Bent from my phone
--------------------------------------------------------------------------------
From: Jeffrey Tippet
Sent: ?12/?19/?2013 6:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Can A LWF Driver Query An Underlying USB Device?
NDIS doesn’t handle that much detail from the USB bus, and RNDIS won’t give that much detail to NDIS anyway. (When you query OID_GEN_VENDOR_ID, you’re seeing a hardware-reported value which apparently happens to coincide with the USB VID, but it’s not guaranteed to.)
You really want to find the underlying devnode and issue IOCTL_USB_GET_NODE_INFORMATION. This is easier from usermode, if you have that luxury.
Finding the underlying devnode can get complicated, in the general case where an IM driver sits between you and the actual physical miniport. You can walk the ifStackTable to get through the built-in IM drivers (although I don’t think that vmSwitch populated ifStackTable back on Windows Server 2008 R2). The easiest strategy is to just say you don’t support configurations like that :).
I don’t know an elegant way to find the underlying devnode. Here’s a non-elegant way to do it:
1. NDIS_FILTER_ATTACH_PARAMETERS::NetLuid ->GetIfTable2Ex
2. Read MIB_IF_ROW2::InterfaceGuid
3. Find all network devices with IoRegisterPlugPlayNotification(GUID_DEVINTERFACE_NET)
4. For each network device, that you’re notified of, open a handle ZwOpenFile
5. Get the device object with ObReferenceObjectByHandle, FILE_OBJECT::DeviceObject
6. Open the device registry key IoOpenDeviceRegistryKey(PLUGPLAY_REGKEY_DRIVER)
7. Read the “NetCfgInstanceId” value and compare it to the InterfaceGuid you read in step #2
8. If the NetCfgInstanceId value matches, this is the right miniport. Issue the IOCTL to the device.
Given the complexity of the above, I can’t really claim it as a great piece of engineering… I hope you can come across a better way to do it.
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
Who put that there? I didn’t know we exposed that 
Yes, you can use that. It should simplify this quite a bit.