I stand by my reply. There is no way that you can assure that your driver is
the only one managing an adapter.
Now to clear up your idea about DeviceIoControl.
Just take a look at the DDK miniport driver samples. Take a hard look, and
you will see that there are no IOCTL handlers. What this means is that
although you can open the symbolic link, there is nothing that you can do
with it! 802.11 adapters are the same way (with some proprietary
exceptions...).
When handle is opened using the IOCTL_NDIS_QUERY_GLOBAL_STATISTICS approach,
you are not actually opening a handle to the adapter miniport. In reality,
NDIS is a wrapper around the miniport drivers and actually creates these
symbolic links on behalf of the miniport. So, your query goes through NDIS.
And NDIS uses OIDs to fetch the information - just like a NDIS protocol
driver would do.
Going further, IOCTL_NDIS_QUERY_GLOBAL _STATISTICS is one of the few NDIS
IOCTLs that is publicly documented. There isn't a big family of publicly
available IOCTL_NDIS_SET_INFORMATION (I just made that up...) or others for
you to use. If there are any, then Microsoft has not made them public. If
they were public, then anyone could use them - not just you. So, there isn't
any advantage there.
Now some miniport developers just may add a _private_ IOCTL interface to
their miniport. They would use this to do extra things that only the
miniport writer knows about. So, if this sort of IOCTL interface exists for
some miniports, then it is only of use to you if you are friends with the
miniport driver writer.
Good luck,
Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com
Post by NYAThanks everyone for the reply.
I do not want to use WMI to access the driver.
Actually I do not want to ensure that only my software is able to
access the miniport driver and the rest cant. All I want to ensure is
that whenever my application makes a DeviceIOControl call I want to
ensure that the call is handled through my protocol driver(compiled
from the ndisprot example) and not through the system supplied ndisuio
driver. Because of compatibility issues as mentioned in various
websites.
The problem here is that the handle which I use to make my
DeviceIOControl call with is not created by me, so i dont know how the
handle is created and i dont know if and which(if any) a protocol
driver is being used. I searched up Net and found out that there are 2
ways by which a handle to the network adapter can be created.
The first one (mentioned in my previous posts) uses a protocol driver,
so there is NO confusion about whether a protocol driver is being used
or not.
In the second method we use the device name (of the miniport) to create
the handle and use this handle to make DeviceIOControl calls to access
information about the adapter using different OIDs. The confusion which
I have over here is that whether a protocol driver will ever be used in
handling various call which use/create this handle or is the miniport
over here being accessed directly an no protocol driver is being used?
If a protocol driver is being used then I need to provide my protocol
driver (compiled from ndisprot example) so that all the calls take
place through my protocol driver and not the system supplied ndisuio
protocol driver (to take care of compatibility issues). Now even if I
compile and install my protocol driver (with the method given on
ndis.com) how can I know or ensure that my protocol driver is veing
used to handle the requests made by my application?
My hunch is that the handle is being provided to me by the second
method, now I am confused whether to compile and use a protocol driver
from ndisprot or not?
Thanks
Nishchal
Post by Thomas F. Divine [DDK MVP]If you are looking for a way to guarantee that your software is the only
There is no way to guarantee that your software is the only software
controlling an 802.11 adapter.
That is the answer. There is no other answer. You can ask as many times as
you like, but there are no techniques that can provide this guarantee.
The problem is so bad that some folks have built NDIS IM filter drivers that
"hide" the 802.11 capabilities from the OS (Gianluca mentioned this
approach...). That way WZC and many (but not all) third-party Wi-Fi
management tools will not even know the 802.11 adapter actually has 802.11
capabilities.
HOWEVER, even that approach provides no guarantee. Yet-another-vendor may
elect to use the same approach. Your hiding IM driver would battle with
other hiding IM drivers and who knows whether your hiding IM driver would
win over another.
Good luck,
Thomas F. Divine, Windows DDK MVP
http://www.rawether.net
Post by NYAI am making an application which accesses information from the wlan
card. So basically from the application i am making DeviceIOControl
calls and accessing various information by specifying various OIDs.
While accessing the wlan card through DeviceIOControl calls it is
advised that we should use a clone of the ndisprot protocol driver and
not the OS supplied ndisuio driver. That is why i am asking that how do
i make sure that my protocol driver is used instead of the ndisuio
driver.
Also by the second method am I opening a handle to the miniport driver
object directly? So I am not using a protocol driver?
Thanks
Nishchal
Post by Steve DispensaThere are other, documented ways to read information from network adapters.
WMI is designed for this purpose, for example.
You can certainly do what ndisprot does, but it is far better to not write a
driver if you can avoid it. Regardless, you certainly should NOT directly
send IOCTLs to a miniport driver (unless you register a management device
with NdisMRegisterDevice).
What information do you need about the NIC? Can you get it from usermode?
-sd
On 7/21/06 10:12 AM, in article
Post by NYAI want to access the network adapter by simple DeviceIOControl calls
with the help of standard OIDs. Also as advised by various persons I
also do not want to use the default OS supplied ndisuio protocol
driver, instead have compiled a protocol driver from the ndisprot
example in the Win2k3 Server DDK (after changing NT and DOS device
names) and want to make sure that my DeviceIOControl requests are
handled through my protocol driver and not the XP supplied ndisuio
driver.
I found out that the handle to the network adapter can be opened in 2
ways. In the first it is clear that we can specify which protocol
driver we want to use. But in the second (which i found out from the
DDK help in the entry of IOCTL_NDIS_QUERY_GLOBAL_STATS, bottom of the
page) it is not clear that which protocol driver (if any) will be used
to handle the DeviceIOControl requests. Other than that i do not want
to make any direct calls to the driver object in the 2nd method, but I
want to make sure my protocol driver is used, if one is ever being
used.
Thanks for the reply.
Nishchal
Post by Steve DispensaWhat are you trying to accomplish here?
You really aren't supposed to be directly opening the device
objects
created
for network adapters. They're NDIS-owned device objects, and even the
protocols themselves don't directly open those device objects -
they
use
NDIS APIs so that NDIS can stay in the middle. Different miniport drivers
have different capabilities, and you can't know by doing a direct device
open what capabilities a given miniport driver has without poking around in
undocumented NDIS internals. Also, miniport drivers register a set of
callbacks once in their DriverEntry for use in miniport operations, and
again, you can't get that list without doing undocumented things.
Furthermore, if you were to try to open miniport driver device objects
directly, you would almost certainly screw up some state somewhere.
If
you
made direct calls to entry points, for example, you might make them
at
wrong
IRQL (hard to do right if you don't know if the miniport is
serialized
or
not), or you might overlap calls that the miniport depends on being
serialized (impossible to protect against, unless you're NDIS).
So, again, what are you trying to accomplish here?
-sd
On 7/20/06 8:56 PM, in article
Post by NYAHello
There are 2 ways of opening a handle to the network card.
[1] By first opening a stream to the ndisuio/clone of ndisprot protocol
driver and then binding it to the underlying mac--
handle=CreateFile("\\\\.\\\\ndisprot",......);
DeviceIoControl(handle, IOCTL_NDISUIO_BIND_WAIT.....);
//After enumerating and selecting a device, a
DeviceIoControl(Handle, IOCTL_NDISPROT_OPEN_DEVICE,
(LPVOID)&wNdisDeviceName[0]......);
[2] But if we already know the device name we can use the name to open
a handle to thre adapter.
createfile("\\\\.\\{2AA42F55-F......
What is the difference between the two methods? Will a protocol driver
be used internally or for further deviceiocontrol request if the handle
is opened by the second method?
If yes, then supposing if i have an ndisprot cloned protocol driver
(from win2k3 server ddk) installed. then which protocol driver
will
be
used internally the ndisuio (default xp installed) or the ndisprot
clone(installed by user)? This is beacuse both of the drivers
could
be
used. How can i make sure that in this case my calls are passed through
ndisproto clone?
If no then will any protocol driver be used for further OID Requests
from deviceiocontrol
Thanks
Nishchal