Network Bus Enumerator Driver

Hi Group,

I am trying to collect information about network related
drivers installed on the system using the SetupDiXXXX() API’s. While doing
so, I encountered Network bus enumerator devices. Is there a standard way of
gettting to the network bus enumerator devices from the network device.
Broadcom seems to have a custom bus and the driver’s service is named after
this bus name and the network bus devices uses the ‘System Devices’ class
GUID, whereas Nvidia has a custom bus which is a GUID and this GUID is used
as the device class GUID for the bus enumerator devices.

I would like to know if there is a reliable or standard way of getting
the network bus enumerator device’s hardwareid from a given network device’s
hardwareid or is this vendor specific ?. If vendor specific then how to
find the list of ‘Network bus enumerator’ devices on a given system ?

Thanks for any pointers.

Cheers
Check Abdoul

> I am trying to collect information about network related drivers installed on the system using the > SetupDiXXXX() API’s

What kind of info do you need and why do you think you need SetupDiXXXX() API? There is a good chance that you can arrive to the info that you need via

HKLM \SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}

registry key, rather than via SetupDiXXXX() API and bus enumerators

Anton Bassov

The layout of the registry is not documented and you should not traverse it manually. It will most likely change in a new OS release and an application which walks it manually will break. Using the documented APIs will shield you from the internal changes.

Now, on the real problem. No, there is no way to definitively do find all the network bus enumerators. First, there is no class guid for them. Second, they are inheritly custom drivers tied to a particular piece of hardware or motherboard. Usually their job is to split a NIC with value added features (let’s say an iSCSI implementation) into a plain NIC and another stack which exposes the value add. Why do you need to find these busses? Why are the NICs they expose not good enough? By this logic, you would need to traverse back through PCI and USB since they also enumerate NICs.

d

Hi Anton ,

{4D36E972-E325-11CE-BFC1-08002bE10318} is the ‘Network Adapters’ class
GUID and as Doran mentioned instead of traversing the registry, I use
SetupDiGetClassDevsEx( …) and SetupDiEnumDeviceInfo(…) to enumerate the
list of Network adapter devices. Once these devices are found, I collect the
driver information ( like all the driver files associated with the driver )
for these devices. This works fine for the standard network adapter devices
that are attached to PCI or USB bus ( & the OS provides the drivers for
these buses ).

However sometimes the network adapters are enumerated by a custom
bus driver. In this case the only information that I can get from the
network adapter device is the name of its enumerator {
SetupDiGetDeviceRegistryProperty(… SPDRP_ENUMERATOR_NAME,… ); }. I am
trying to find the driver information for this network bus enumerator and
there does not seem to be a standard device class GUID attached to a network
bus enumerator like there is for ‘Network adapter’, ‘SCSIAdapter’ etc. From
my initial testing, it looks like it is vendor specific and right now I know
only of Broadcom and NVIDIA network bus enumerators.

Cheers
Check Abdoul

wrote in message news:xxxxx@ntdev…
>> I am trying to collect information about network related drivers
>> installed on the system using the > SetupDiXXXX() API’s
>
> What kind of info do you need and why do you think you need SetupDiXXXX()
> API? There is a good chance that you can arrive to the info that you need
> via
>
> HKLM
> \SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}
>
> registry key, rather than via SetupDiXXXX() API and bus enumerators
>
> Anton Bassov
>

Hi Doran,

Thanks for the reply.

> The layout of the registry is not documented and you should not traverse
> it manually. It will most likely change in a new OS release and an
> application which walks it manually will break. Using the documented
> APIs will shield you from the internal changes.

I understand that and that is why I use SetupDiGetClassDevsEx( …)
and SetupDiEnumDeviceInfo(…) to enumerate the list of Network adapter
devices. The only information that I can get from the network adapter device
is the name of its enumerator { SetupDiGetDeviceRegistryProperty(…
SPDRP_ENUMERATOR_NAME,… ); }.

> Now, on the real problem. No, there is no way to definitively do find
> all the network bus enumerators.

Thanks for confirming this.

> Why do you need to find these busses? Why are the NICs they expose not
> good enough?

Oh, the NIC’s they expose are good enough. However they are not
visible to the system in a disaster recovery scenario, unless the network
bus enumerator driver is loaded first, and I am trying to save all the
related driver information for the disaster recovery purpose.

> By this logic, you would need to traverse back through PCI and USB
> since they also enumerate NICs.

The bus drivers provided by the operating system takes care of the
PCI and USB buses.

Cheers
Check Abdoul

wrote in message news:xxxxx@ntdev…
> The layout of the registry is not documented and you should not traverse
> it manually. It will most likely change in a new OS release and an
> application which walks it manually will break. Using the documented APIs
> will shield you from the internal changes.
>
> Now, on the real problem. No, there is no way to definitively do find all
> the network bus enumerators. First, there is no class guid for them.
> Second, they are inheritly custom drivers tied to a particular piece of
> hardware or motherboard. Usually their job is to split a NIC with value
> added features (let’s say an iSCSI implementation) into a plain NIC and
> another stack which exposes the value add. Why do you need to find these
> busses? Why are the NICs they expose not good enough? By this logic, you
> would need to traverse back through PCI and USB since they also enumerate
> NICs.
>
> d
>

i don’t know if you will be able to get this to work effectively. typically a driver needs to be aware that it is in a limited boot scenario, or at least tested in such a scenario. also, there may other drivers outside of the stack that the enumerator depends on. one thing you can do is look at the NIC’s enumerator, if it is not a well known enumerator like PCI or USB, then use the CM APIs to walk up to the parent device and get its information. Repeat until you hit the root or a std bus driver.

d

Hi Doran,

> if it is not a well known enumerator like PCI or USB, then use the CM
> APIs to walk up to the parent device and get its information…

Thanks for this tip. I never had to use the CM API’s till now, so
can you tell me which API’s to look at to start with.

Cheers
Check Abdoul

wrote in message news:xxxxx@ntdev…
>i don’t know if you will be able to get this to work effectively.
>typically a driver needs to be aware that it is in a limited boot scenario,
>or at least tested in such a scenario. also, there may other drivers
>outside of the stack that the enumerator depends on. one thing you can do
>is look at the NIC’s enumerator, if it is not a well known enumerator like
>PCI or USB, then use the CM APIs to walk up to the parent device and get
>its information. Repeat until you hit the root or a std bus driver.
>
> d
>

> {4D36E972-E325-11CE-BFC1-08002bE10318} is the ‘Network Adapters’ class GUID…

If you look under this key, you will see ‘InfPath’ value for every adapter, which is the path to adapter’s .inf file, from which you can get driver name and service name. This is why I thought it may be of help…

Anton Bassov

Hi Anton,

Yes, that is right and you can get all this information use
the SetupDiXXX() API’s too. Maybe I am not making myself clear. I am able to
get all the information for the “network adapter devices”. There is no
problem there. It is the “network bus enumerator devices” ( that enumerated
the network adapter device in the first place ) that I am trying to get
information for and there does not seems to be any standard way of getting
this information.

Cheers
Check Abdoul

wrote in message news:xxxxx@ntdev…
>> {4D36E972-E325-11CE-BFC1-08002bE10318} is the ‘Network Adapters’ class
>> GUID…
>
> If you look under this key, you will see ‘InfPath’ value for every
> adapter, which is the path to adapter’s .inf file, from which you can get
> driver name and service name. This is why I thought it may be of help…
>
>
> Anton Bassov
>

> right now I know only of Broadcom and NVIDIA network bus enumerators.

I could add 3 (or more) to that list, the Infiniband IP over IB network
device (which just recently got WHQL certification), the Xsigo virtual NIC,
and I believe the Chelsio 10G TOE adapter NIC. I know Emulex used to have an
IP over fibre channel NIC, which as I remember had some sort of private peer
interface to the Emulex FC storage adapter to talk to the hardware instead
of a visible bus driver (it might have changed since I last looked at it).

Actually, you probably should even add the extremely common Intel NIC when
VLAN’s have been created (this may apply to many nics). The Intel adapter I
know creates a root enumerated NIC for each VLAN, which then communicates to
its base NIC. The VLAN nic and the base nic are NOT in a PnP hierarchy, so
the enumerator for the VLAN nic will be ROOT.

I believe it would be pretty much impossible to automatically figure out the
whole set of drivers/devices that are required to make a specific NIC
operational.

  • Jan

Using bus driver to support VLAN IMO is asking for trouble. I’d be
surprised if INTC does that. I believe Intel is using NDIS IM for VLAN.
I could be wrong though.

The purpose of Broadcom’s bus driver is to enumerate the on-chip TOE
(TCP chimney offload engine), iSCSI HBA(hardware offload initiator), and
RDMA (Remote DMA) engine. It also enumerates kernel proxy driver for WSD
(WinSock Direct) to allow some applications to utilize the TOE engine
for non-TCP chimney capable Windows operating systems.

Personal opinion, not speaking for my employer.

Calvin Guan (expiring DDK MVP)
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything(r)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-282012-
xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Wednesday, March 28, 2007 12:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Network Bus Enumerator Driver

> right now I know only of Broadcom and NVIDIA network bus
enumerators.

I could add 3 (or more) to that list, the Infiniband IP over IB
network
device (which just recently got WHQL certification), the Xsigo virtual
NIC,
and I believe the Chelsio 10G TOE adapter NIC. I know Emulex used to
have
an
IP over fibre channel NIC, which as I remember had some sort of
private
peer
interface to the Emulex FC storage adapter to talk to the hardware
instead
of a visible bus driver (it might have changed since I last looked at
it).

Actually, you probably should even add the extremely common Intel NIC
when
VLAN’s have been created (this may apply to many nics). The Intel
adapter
I
know creates a root enumerated NIC for each VLAN, which then
communicates
to
its base NIC. The VLAN nic and the base nic are NOT in a PnP
hierarchy, so
the enumerator for the VLAN nic will be ROOT.

I believe it would be pretty much impossible to automatically figure
out
the
whole set of drivers/devices that are required to make a specific NIC
operational.

  • Jan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

I think you will find that the Intel VLAN support is simply an IM-MUX
driver. Your comment that the individual (virtual) miniports are ‘root’
enumerated is correct. They don?t appear to be enumerated by a bus driver
(other than the ‘root’ bus driver). The IM architecture allows the IM
driver to participate in the PnP start-up of the virtual miniport via the
NdisIMInitializeDeviceInstanceEx/NdisIMDeinitializeDeviceInstance()
calls. AFAIK, however, the ‘enumeration’ of the virtual miniports occurs
outside of NDIS (which is how NDIS gets told to load the miniport driver in
the first place).

Dave Cattley
Consulting Engineer
Systems Software Development

I should have said “how the miniport driver gets loaded” 'cause of course
NDIS does not load it (PnP does). Heck, this is not Win9x!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Wednesday, March 28, 2007 7:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Network Bus Enumerator Driver

I think you will find that the Intel VLAN support is simply an IM-MUX
driver. Your comment that the individual (virtual) miniports are ‘root’
enumerated is correct. They don?t appear to be enumerated by a bus driver
(other than the ‘root’ bus driver). The IM architecture allows the IM
driver to participate in the PnP start-up of the virtual miniport via the
NdisIMInitializeDeviceInstanceEx/NdisIMDeinitializeDeviceInstance()
calls. AFAIK, however, the ‘enumeration’ of the virtual miniports occurs
outside of NDIS (which is how NDIS gets told to load the miniport driver in
the first place).

Dave Cattley
Consulting Engineer
Systems Software Development


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Thanks Jan.

Cheers
Check Abdoul

“Jan Bottorff” wrote in message news:xxxxx@ntdev…
>> right now I know only of Broadcom and NVIDIA network bus enumerators.
>
> I could add 3 (or more) to that list, the Infiniband IP over IB network
> device (which just recently got WHQL certification), the Xsigo virtual
> NIC,
> and I believe the Chelsio 10G TOE adapter NIC. I know Emulex used to have
> an
> IP over fibre channel NIC, which as I remember had some sort of private
> peer
> interface to the Emulex FC storage adapter to talk to the hardware instead
> of a visible bus driver (it might have changed since I last looked at it).
>
> Actually, you probably should even add the extremely common Intel NIC when
> VLAN’s have been created (this may apply to many nics). The Intel adapter
> I
> know creates a root enumerated NIC for each VLAN, which then communicates
> to
> its base NIC. The VLAN nic and the base nic are NOT in a PnP hierarchy, so
> the enumerator for the VLAN nic will be ROOT.
>
> I believe it would be pretty much impossible to automatically figure out
> the
> whole set of drivers/devices that are required to make a specific NIC
> operational.
>
> - Jan
>
>