Hi,
I’m developing NDIS protocol driver which should enumerate the drivers which will send the data to it via IOCTLS.Is it possible to use NDIS protocol driver as a bus driver .
Awaiting your reply.Thanks.
Regards
Alex.
NDIS is pretty much a world on its own, so that classical WDM concepts such as bus driver, PDO, FDO, etc don’t apply to it. Furthermore, although protocol drivers expose a “regular” dispatch interface on the upper edge ( they deal with NDIS only on their lower edge), they are just “legacy” drivers as far as their dispatch interface is concerned - they don’t have AddDevice() routine, and they don’t receive IRP_MJ_PNP requests either (they receive PnP notifications from NDIS, and deal with them in handlers that they have registered with NdisRegisterProtocol()). Furthermore, protocol drivers don’t enumerate adapters that they are bound to. Instead, if you install a protocol
driver via INetCfg, it gets bound to the target adapter right upon installation via the registry settings, so that its PtBindAdapter() handler gets invoked by NDIS, and PtBindAdapter() calls NdisOpenAdapter() - parameters that it uses in this call are provided to by NDIS as arguments to PtBindAdapter().
Certainly, you can install a protocol driver without INetCfg - in such case, you can, indeed,
“enumerate” underlying adapters by reading the registry, and bind to them right in DriverEntry()
(although MSDN claims that it cannot be done by drivers of NDIS version above 3, in actuality,
it can be done by drivers any NDIS version below 6, and it will work on all OSes, including even Vista). However, this is not a very good idea to do things in NDIS 3 style in the year 2007 - these days any good protocol driver is supposed to be PnP-compliant…
Anton Bassov
Being an NDIS protocol imposes no requirements on the driver except its
lower egde. So, it surely can be a WDM/PnP driver for pseudo-device, and can
even be a bus driver and enumerate a PDO for each NIC it is bound to.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> NDIS is pretty much a world on its own, so that classical WDM concepts such
as bus driver, PDO, FDO, etc don’t apply to it. Furthermore, although protocol
drivers expose a “regular” dispatch interface on the upper edge ( they deal
with NDIS only on their lower edge), they are just “legacy” drivers as far as
their dispatch interface is concerned - they don’t have AddDevice() routine,
and they don’t receive IRP_MJ_PNP requests either (they receive PnP
notifications from NDIS, and deal with them in handlers that they have
registered with NdisRegisterProtocol()). Furthermore, protocol drivers don’t
enumerate adapters that they are bound to. Instead, if you install a protocol
> driver via INetCfg, it gets bound to the target adapter right upon
installation via the registry settings, so that its PtBindAdapter() handler
gets invoked by NDIS, and PtBindAdapter() calls NdisOpenAdapter() - parameters
that it uses in this call are provided to by NDIS as arguments to
PtBindAdapter().
>
> Certainly, you can install a protocol driver without INetCfg - in such
case, you can, indeed,
> “enumerate” underlying adapters by reading the registry, and bind to them
right in DriverEntry()
> (although MSDN claims that it cannot be done by drivers of NDIS version above
3, in actuality,
> it can be done by drivers any NDIS version below 6, and it will work on all
OSes, including even Vista). However, this is not a very good idea to do things
in NDIS 3 style in the year 2007 - these days any good protocol driver is
supposed to be PnP-compliant…
>
> Anton Bassov
>
Maxim,
Being an NDIS protocol imposes no requirements on the driver except its
lower egde. So, it surely can be a WDM/PnP driver for pseudo-device, and can
even be a bus driver and enumerate a PDO for each NIC it is bound to.
I think that lack of any *officialy documented* restrictions for protocol drivers is due solely to the fact that normally it just would not get into one’s head to make protocol driver enumerate the hardware devices or attach its devices to some totally unrelated PnP stack …
To begin with, if you do things this way, your driver is going to be bound by 2 absolutely unrelated
contracts. You would need 2 INF files for your driver - one of them has to be installed via the Device Manager as PnP-compliant WDM driver, and another one by INetCfg as NDIS protocol driver.
I am not 100% sure that installation will go absolutely smoothly. Furthermore, I am not 100% sure that dealing with PnP on both edges is completely trouble-free.
Certainly, it would be an interesting idea to try it - just in order to see what happens…
Anton Bassov
Perhaps then, we should encourage the OP to actually give it a try.
As Maxim has noted, the protocol lower-edge requirements can be met by just
about any type of kernel driver. The INF / install issues are not that
terrible - keep in mind that a protocol (Class=NetTrans) is a ‘logical’
entity as far as the binding engine (in INetCfg) is concerned. Filling out
the NDI data to get it bound to adapters is driven for sure by a NetTrans
style INF but nothing there says it has to install a legacy driver (service)
or *any* driver service. Moreover, a PnP INF for a root enumerated device
that happens to be a bus driver could install the very same NT (Driver)
Service. What could possibly be wrong with that? There are other well
known examples of PnP (device) installs installing a service that happens to
be shared with a Protocol install (think IM driver for one).
So yes, one might need two INFs (and maybe one might not!) but this hardly
seems a huge hurdle. As for ‘smoothly’, well, again, that is a question
best answered instead of ‘predicted’. I could imagine a Class=Net device
that is not *really* an adapter but is a bus-driver and which indicates to
NetCfg via NDI dependencies that it would appreciate having another
component installed, namely the ‘protocol’. This install would proceed
quite smoothly and not require anything more than DevCon like processing to
request the (root enumerated) psuedo-adapter-is-really-bus-enumerator device
to be installed.
So in my estimation, this is pretty straight forward (but perhaps not
ordinary):
-
INF to install a Net (adapter) ‘device’ which will actually be the bus
enumerator. It will not actually be a NIC and preventing it from being
‘bound’ can be done through careful use of the binding parameters in the NDI
key. -
INF to install a NetTrans (protcol) or perhaps a NetService. The name
of this NetTrans service could be specified in the (adapter) enumertor’s NDI
parameters as a RequiredAll entry and would cause the protcol to be
installed silently.
But this is probably just one of a dozen ways to accomplish the same thing
and should not be construed as any sort of an answer but more as
encouragement to go do it!
As for the “… Lack of any *offically documented* restictions …”, this is
perfectly correct. There are no restrictions. How much more clearly can
that be documented through omission? Do we need the NDIS team to issue an
official statement of non-restriction on what sort of driver can implement a
protocol lower edge? It has always been *any* driver since NDIS protocols
play no roll in determining the semantics of the ‘host’ driver’s interaction
with the OS (aka, I/O Manager, PnP, etc.)
Good luck with this one. I can tell you from *experience* you are not far
from success.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, August 18, 2007 3:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Enumerating Child Device from NDIS
Maxim,
Being an NDIS protocol imposes no requirements on the driver except
its lower egde. So, it surely can be a WDM/PnP driver for
pseudo-device, and can even be a bus driver and enumerate a PDO for each
NIC it is bound to.
I think that lack of any *officialy documented* restrictions for protocol
drivers is due solely to the fact that normally it just would not get into
one’s head to make protocol driver enumerate the hardware devices or attach
its devices to some totally unrelated PnP stack …
To begin with, if you do things this way, your driver is going to be bound
by 2 absolutely unrelated contracts. You would need 2 INF files for your
driver - one of them has to be installed via the Device Manager as
PnP-compliant WDM driver, and another one by INetCfg as NDIS protocol
driver.
I am not 100% sure that installation will go absolutely smoothly.
Furthermore, I am not 100% sure that dealing with PnP on both edges is
completely trouble-free.
Certainly, it would be an interesting idea to try it - just in order to see
what happens…
Anton Bassov
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
I’ve faced a similar task a number of years ago and ended up adding the NDIS 4 protocol to the WDM bus driver of mine but not installing that protocol via a network INF file. It opens all the network adapters manually by enumerating the Registry, just as Anton has recommended. All NDIS protocol callbacks are called normally with the exception of the adapter binding notifications. It was acceptable as some house keeping was being down at low priority every minute anyway, and a minute worth of delay in discovering a new network device was fine by the customer. That same customer would have been not really amused if the bus driver of a well known setup class has morphed into a network protocol all of a sudden.
That driver is running well in this respect on hundreds of thousands of machines. Has passed with flying colors quite a few WHQL tests over the years. This is by no means perfect but may be an option for you too.
Just $.02,
Ilya Faenson
BTW, what about just writing 2 separate drivers, and making them communicate via some proprietary interface? Is not it easier to do things this way???
Anton Bassov
Hi,
I would like to thank all of you for the valuable ideas and suggestions.Thanks a lot.