Re: NDIS Intermediate (passthru) communicates with second driver

Hi Stephan


You actually *can* send IOCTLs to an NDIS miniport driver. The required
mechanism is exactly the one you describe, namely by adding a new
device object to the driver via NdisMRegisterDevice().

It looks like you are already nagging to words (although the above
statement is technically more correct than the one that I made, I
admit). Unfortunately, the rest of the message seems to be wrong.....

IIRC, this is necessary as the driver's default device object is
already occupied by NDIS. The use of NdisMRegisterDevice() is necessary
as NDIS miniports must (should) not use any non-NDIS system functions
(i.e., in this case, IoCreateDevice() etc.).

Now PASSTHRU is an NDIS intermediate (IM) driver, which means it
implements both an NDIS miniport and an NDIS protocol.

Now NDIS protocol and intermediate drivers *are* allowed to call any
system functions, not just NDIS functions. Thus, you can also create a
device object via IoCreateDevice() in the standard way in your IM. This
seems a better approach than using NdisMRegisterDevice(), as the latter
requires you to first initialize at least one miniport instance


In fact, you can create a device object via IoCreateDevice() not only
from NDIS IM, but from miniport driver as well - there is no problem
here. Problems will arise later when you try to access this device via
its regular Dispatch interface.......


It has nothing to do with miniport in itself - this is just the
question of wrapper. Before
you register miniport, you have to initialize a wrapper by calling
NdisMInitializeWrapper(), which is true for both miniports and NDIS IM.
At this point you lose your ability to access devices, created by
miniport driver (unless you have created them via
NdisMRegisterDevice()calls), via the regular Dispatch interface.
Protocols drivers are a totally different story - once they don't
require NDIS wrapper, their devices can be accessed via the regular
Dispatch interface. Therefore, if we look at NDIS IM in this context,
they are just miniport drivers

In other words creating a device with IoCreateDevice() is not going to
help you here, even if you do it before initializing a miniport. Once
you have called NdisMInitializeWrapper(),these devices will become
unaccessible via the regular Dispatch interface

Anton Bassov




Stephan Wolf [MVP] wrote:
You actually *can* send IOCTLs to an NDIS miniport driver. The required
mechanism is exactly the one you describe, namely by adding a new
device object to the driver via NdisMRegisterDevice().

IIRC, this is necessary as the driver's default device object is
already occupied by NDIS. The use of NdisMRegisterDevice() is necessary
as NDIS miniports must (should) not use any non-NDIS system functions
(i.e., in this case, IoCreateDevice() etc.).

Now PASSTHRU is an NDIS intermediate (IM) driver, which means it
implements both an NDIS miniport and an NDIS protocol.

Now NDIS protocol and intermediate drivers *are* allowed to call any
system functions, not just NDIS functions. Thus, you can also create a
device object via IoCreateDevice() in the standard way in your IM. This
seems a better approach than using NdisMRegisterDevice(), as the latter
requires you to first initialize at least one miniport instance.

Stephan
---
soviet_bloke@xxxxxxxxxxx wrote:
Hi mate

You cannot send IOCTLs to miniport drivers. If you want to do something
like that, you need to create a standalone device that is not a part of
a network stack by calling NdisMRegisterDevice(), so that you can send
IOCTLs to it. This device will already delegate the job to the actual
one. Look at NdisMRegisterDevice() documentation for more info

Anton Bassov

.

Relevant Pages

  • Re: NDIS_MINIPORT_CHARACTERISTICS
    ... > this is by being there at the time it registers with NDIS. ... To show that it is possible that a backdoor comms ... >>of calls that NDIS makes to a miniport. ... > driver on the filesystem due to IDS/AV worries. ...
    (microsoft.public.development.device.drivers)
  • Re: Acquiring a mutex in DPC
    ... When you get a device object after NdisMRegisterDevice, ... find your miniport instance and perform necessary functions. ... > that the unplug should reload your driver and reset those pointers. ... >> An app has the handle open. ...
    (microsoft.public.development.device.drivers)
  • Re:NDIS Irda protocol driver
    ... in between miniport driver's indication of packets to NDIS library and NDIS ... library's notification of your driver about incoming packets. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Tcpip.sys bug: FTP Upload. MiniportHalt isnt called untill it has
    ... cancel packets on the miniport driver. ... driver, this bug would have been discovered long, long ago. ... handler and that does return all unsent packets to Ndis. ... hanging the PnP manager with device ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS_MINIPORT_CHARACTERISTICS
    ... I am not sure what you mean by "patching NDIS routine". ... I strongly advise against making any assumption about what miniport block ... Then please write an IM driver. ...
    (microsoft.public.development.device.drivers)
Loading