OIDScope (from PCAUSA) uses a technique to submit an OID (NdisRequest) using
DeviceIoControl from usermode which results in the request being directly
presented to the target miniport (device object). As such, the OID is not
‘filtered’ by any other NDIS IM drivers that may be bound to the NIC.
On the other hand, a protocol driver (such as TCPIP.SYS, NDISUIO.SYS, and
others) do not use DeviceIoControl but instead issues NdisRequest() calls to
the ‘binding’ between the protocol and the network ‘stack’ of IM drivers and
miniport.
If you had used NDISUIO or the sample NDISPROT from the DDK to submit OID
requests to the ‘stack’, you would have found that they all failed.
Moreover, I think that NDIS itself would probably fail either explicitly or
in subtle ways since the wrapper itself issues OID requests when
initializing a miniport which it expects a rational answer to.
> In TDI drivers or other basic filters I’ve never had to handle powernd
p&p irps. Why do i need to do it in NDIS IM filters?
For one, TDI ‘transport’ device objects are not PnP device objects and so
filtering one you are not likely to encounter too many PnP IRPs. Keep in
mind that an NT ‘filter’ driver attached to a device stack (PnP or legacy)
has absolutely nothing in common with an NDIS IM ‘filter’ driver. NDIS
drivers exchange packets and requests via an entirely different mechanism
(they do not use IRPs and the fact that some NDIS elements are associated
with NT Device Objects is hidden by the NDIS model).
NDIS IM filter drivers participate (generally) in a PnP device ‘stack’ and
thus the NDIS wrapper delegates certain portions of the PnP and power
management to the miniport driver (via OID requests). Under no
circumstances should an IM driver be processing PnP or Power IRPs directly
but only as OID requests or PnP notifications to either the Miniport of
Protocol edges. NDIS deals with the details and asks only some very modest
and trivially implemented support for PnP and Power from the IM driver.
Passthru does this and I again encourage you to follow the example
carefully.
> Also, can you please explain in simple words all this “packets
management” thing?
I recommend that you read through just about everything on www.ndis.com
about NDIS, IM drivers, and NDIS packets. Thomas Divine of PCAUSA does the
community a great service by collecting, editing, and publishing a
significant amount of tutorial and reference materials on the subjects not
found anywhere else. Thomas is a frequent poster to this NG and I suggest
that you search the archives for anything and everything with his name on
it.
I also recommend that you read the Design Guide sections of the DDK
documentation for all NDIS driver types over and over again. Keep in mind
that an IM driver is the combination of a protocol and a miniport (MAC)
driver. It must live with the restrictions of *both* of these models.
The simple (well, not so simple but direct anyway) answer to your question
about packet management is this: NDIS ‘describes’ packets with a
datastructure NDIS_PACKET. This structure contains fields that are reserved
for NDIS, for the Miniport that is involved in processing the packet, and
the Protocol involved in processing the packet. Packet ownership
transitions between a Miniport and Protocol with the help of NDIS. This
relationship is called a ‘binding’ and an NDIS_PACKET in general can only
traverse a single binding. If you want the packet to traverse another
binding, it needs to get ‘re-described’ with a new NDIS_PACKET so that the
next binding can have access to the reserved (Miniport or Protocol) fields
without stomping on some other bindings use of them.
NDIS 5 introduces packet ‘stacks’ to help IM drivers deal with this issue
more effectively but they are not a complete solution. Don’t try to
understand packet stacking until *after* you fully understand how
NDIS_PACKET structures can only traverse a single binding. It is helpful to
understand the reason packet stacks were introduced because they cannot
solve all of the packet handling scenarios an IM driver faces.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
Sent: Monday, February 26, 2007 8:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] A Basic question about NDIS Filter IM drivers
Thanks for your detailed response. I don’t know why the DDK help lacks such
a basic information which i think is so vital for beginners in this field.
This subject is a little confusing for me because after dealing with
“regular” filter drivers, the model here is different (you use callbacks
instead of dispatch functions and no generic implementation of “send to the
lower driver and forget”).
If i understood you right, because all the bindings were transferred to my
virtual NIC, if i don’t implement QueryInformationHandler for example,
queries done on the REAL NIC will never get to it… having said that, how
can you explain the fact that when i DIDN"T implement
QueryInformationHandler, and installed my IM driver, i could still make
queries (from usermode with OID Scope util) on the real NIC and on the
virtual NIC. How did it work ? (also, when i did implement it, i couldn’t
see debug prints in this function when i did queries. but i did see lot of
debug prints from this function of someone else doing queries like
OID_GEN_LINK_SPEED)
Another question:
In TDI drivers or other basic filters I’ve never had to handle powernd p&p
irps. Why do i need to do it in NDIS IM filters?
Also, can you please explain in simple words all this “packets management”
thing?
I expected a single line of code in the NDIS passthrough sample that sends
the packets down,
but instead i saw a lot of code that most of it dealt with changing packets
descriptors which i didn’t understand why is needed at all …
Thanks
