Hello everybody,
I hope someone can enlighten me on the following issue, since I just can’t a solution…
I need to send OIDs to an NDIS WiFi driver.
The OIDs must be sent via the NDIS framework (NdisOidRequest ?),
since NDIS sends the OIDs serially, and the WiFi driver relies on it.
The problem:
The sender driver is not an NDIS driver. It’s a simple WDF driver.
In addition, I need to make sure that the OIDs go directly to the NDIS
driver, and are not intercepted by filter drivers on the way.
The only solution I found so far is by using the IHV user-mode extensions:
Creating a user mode application that gets the requests from the KMDF driver
(using the reverse-call technique), and then using the function WlanIhvControl(),
which sends OIDs to an NDIS driver.
Is there a better solution?
Am I missing something?
Thanks in advance !
The only way to send an NDIS ‘oid’ request to a miniport that does not pass
through filter drivers along the way is to be a/the filter at the altitude
closest to the actual MAC or to get some other filter already in that
position to do it for you. The IHV-EXT uses the native Wifi filter as that
point. Since the native wifi driver is pretty adamant about not letting
solutions like the one you are trying to create muck up its view of the
NWIFI adapter, your challenge will be to slide in between the native wifi
filter and the native wifi adapter.
But really, what are you trying to do? Because maybe you just think you
need to send OIDs yet the information you wish to gather can be obtained via
other means?
Good Luck,
Dave Cattley
Hi, and thanks for your reply !
My WiFi miniport driver relies on NDIS to serialize incoming requests (it cannot handle
more than one request at a time), so the only way to communicate with it would
be sending OIDs through the NDIS framework.
Of course, I can register my driver as a protocol driver above the MP and send OIDs,
but the problem is that firewalls filter the NIC-speciifc OIDs !.
Is there a way to utilize the IHV framework for sending OIDs from kernel mode?
I’m out of ideas… I find it hard to believe that I’ll have to write a user-mode application
just for the sake of communication between two kernel-mode drivers…
Thanks !
Maybe you should stop trying to solve your driver-2-driver request issue
with NDIS Requests. You still have not really described what you are trying
to accomplish other than to say your chosen solution is hard to implement.
Perhaps another solution then? Like an internal device control request to
an auxiliary device?
Surely you can synchronize requests inside your WiFi driver to retain the
‘one OID at a time’ interleaved with your ‘one external request at a time’.
But frankly I don’t understand the “… but the problem is that firewalls
filter the NIC-specific OIDS!” statement. Are you suggesting that some
LWF driver based firewall is going to know about your custom OID and do
something to it (like block it)? What does this custom OID do? Something
that firewall vendors might wish to legitimately block?
This is all sounding a bit sketchy.
Good Luck,
Dave Cattley
Hi, and again - thanks for the fast (and patient) reply !
Let me start with the bottom line: yes, some firewall vendors block all NIC-specific OIDs.
Wherever this is legitimate or not - it’s not relevant. My solution must work
even if a firewall is installed.
This is a verified statement. My current solution is an NDIS protocol driver,
and OIDs are being blocked.
About serializing the requests internally inside the MP driver - the solution
was overruled by the customer (my driver is not the only one who’s using
the wifi, and he fears that changing the wifi driver will have a wider effect).
If you (or anybody else, of course) can suggest a way of driver-2-driver communication,
which will retain the internal serialization of NDIS requests - I’ll be more than happy…
Currently - I’m lost…
thanks,
Driver to driver requests, and in particular in the world of NDIS, can
generally be:
-
an NDIS Request (OID). You state this does not work for you because of
other third-party components blocking NDIS Requests.
-
I/O requests (IRP). You state this is not acceptable because you [your
customer] cannot permit the modification of the WiFi driver to accommodate
this.
-
WMI requests. Mapping a WMI request to an OID provides a means by which
a driver or UM process can target an NDIS Request to the NIC. A KM client
can initiate these requests directly (see posts to this list a while back by
Mr. Jeffery Tippet on this topic). I cannot say that this will help given
(1) above.
-
Register ‘services’ with the Network Module Registrar (NMR) and consume
those services. For example, the WiFi driver might publish an interface to
be consumed by the protocol driver. Or whatever. But that does not solve
the synchronization with OIDs problem.
But you state that your customer will not permit modification of the WiFi
driver to allow for synchronization and you also state you need this request
to be synchronized with the other NDIS requests (OIDs). I maybe did not
pay close attention to ‘logic’ in school but this to me sounds like you have
been constrained to ‘no solution’. So your problem is not what you are
trying to do but what you have been prevented from doing.
I am more than a bit surprised by your statement that ‘firewall drivers’ are
blocking OIDs - especially vendor specific. Are you sure about that or are
you just discovering that the Windows WiFi LWF driver is blocking OIDs from
your Protocol to the Native WiFi MAC?
And you still have not provided the community with a more ‘functional’
description of what you are trying to accomplish and I am just not inclined
to guess.
Good Luck,
Dave Cattley