Handling IOCTLs in NDIS miniport drivers

NTDEV
1

Hi all,

I’m working on NDIS miniport driver, and I need it to communicate with user mode. I choosed to use ioctls, because I want to share ioctls implementation from another driver I have. However, the another one is kmdf-based driver, and it uses EvtIoDeviceControl dispatch callback to handle ioctls.

From netvmini sample in wdk I could find the call for NdisMRegisterDevice to create an interface for usermode. It gets a dispatch table as an agrument, and the callback for dispatching is WBM’s.

Is it any way to create a WDF interface to usermode from ndis miniport driver?
From http://www.osronline.com/showThread.cfm?link=108185 (message 6 by Anton Bassov) I can’t call for WdfDeviceCreate to create a framework device object. In the other hand, there is an NDIS sample in kmdf source, so I would assume that there is a way to accomplish my needs.

Additional option that I thought about is to create a WDFREQUEST within WDM dispatch routine, but it seems a kind of ugly hack :frowning: Isn’t there any more elegant solution?

Any advise is more then welcome !!!

Thanks,
S.

2

The short answer is no, you cannot create a WDFDEVICE from within a
‘miniport’ driver. More to the point, you cannot create a WDFQUEUE either
or WDFREQUEST or any of the stuff that would make it possible to handle I/O
requests with WDF.

The NDIS/KMDF sample demonstrates the one-and-only capability available to
an NDIS/KMDF driver - I/O targets.

Depending on what you want to do from usermode you have these options:

  1. Create an ‘auxilary’ named device object with NdisMRegisterDevice and
    handle IRPs directly.

  2. Create a KMDF ‘filter’ driver and place it in the stack with your NDIS
    Miniport as an UpperFilter. This allows you to get inline with the IO on
    the actual device stack by why you would want to, I don’t know. The NDIS
    Miniport driver would need to ‘connect’ up with the filter driver. This can
    be accomplished with an IRP_MN_QUERYINTERFACE to the ‘top’ of the device
    stack.

  3. Create a KMDF ‘filter’ driver and place it in the stack with your NDIS
    Miniport as a LowerFilter. Create KMDF control device objects or enumerate
    child devices per NIC depending on what you are trying to accomplish. You
    can send requests from the NDIS miniport to the KMDF filter since the FiDO
    will be in the same device stack as the NDIS Miniport (FDO). You could, for
    instance, export an interface from the FiDO and retrieve it via an
    IRP_MN_QUERYINTERFACE request in the NDIS FDO (or if you are NDIS/KMDF
    WdfIoTargetQueryForInterface()).

Without knowing a lot more about the problem you are trying to solve (not
the tools you are trying to use to solve it) and the nature of the interface
you wish to use in common, it is rather difficult to give good advice. The
points above are just ideas and are not necessarily suitable to anything you
might try to accomplish so don’t expect much.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, November 10, 2008 11:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Handling IOCTLs in NDIS miniport drivers

Hi all,

I’m working on NDIS miniport driver, and I need it to communicate with user
mode. I choosed to use ioctls, because I want to share ioctls implementation
from another driver I have. However, the another one is kmdf-based driver,
and it uses EvtIoDeviceControl dispatch callback to handle ioctls.

From netvmini sample in wdk I could find the call for NdisMRegisterDevice to
create an interface for usermode. It gets a dispatch table as an agrument,
and the callback for dispatching is WBM’s.

Is it any way to create a WDF interface to usermode from ndis miniport
driver?
From http://www.osronline.com/showThread.cfm?link=108185 (message 6 by Anton
Bassov) I can’t call for WdfDeviceCreate to create a framework device
object. In the other hand, there is an NDIS sample in kmdf source, so I
would assume that there is a way to accomplish my needs.

Additional option that I thought about is to create a WDFREQUEST within WDM
dispatch routine, but it seems a kind of ugly hack :frowning: Isn’t there any more
elegant solution?

Any advise is more then welcome !!!

Thanks,
S.

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

3

I was a bit un-fair to say that the only thing available to a KMDF Miniport
driver is I/O targets. I meant that only in the context of processing I/O.
There is a whole lot useful infrastructure in KMDF that works just fine in
Miniport Drivers. What you cannot do is process I/O targeted *at* the
device stack with KMDF. You must use the miniport model approved method.
Moreover, KMDF does not support creating a ‘control device’ in a KMDF
Miniport. You must use the miniport model approved method of doing that (if
one exists). Basically, the port driver (NDIS in this case) and KMDF both
want to take over the driver dispatch table. The port driver must and KMDF
must not in a Miniport.

I was also a bit imprecise and broad-brushed with saying that you cannot
create WDFREQUEST objects in a Miniport driver. Of course you can create
them as requests to be sent to an I/O Target. You cannot create them to
represent IRPs you receive dispatched through the Miniport Driver’s Dispath
Table.

My apologies in advance to the WDF folks.

Finding a way to make KMDF Control Device support work in an NDIS Miniport
is a bit of a pet peeve of mine as it seems like in this one case it ought
to have been possible to let KMDF fill in the ‘auxilary’ dispatch table used
in the call to NdisMRegisterDevice() (but alas, it is not). KMDF I think
makes some other assumptions about how the DeviceObject, DeviceExtension,
etc. relate to the WDFDEVICE and those are not ‘controllable’ for
NdisMRegisterDevice() since it too is make similar assumptions.

This leaves you with the ‘two driver’ approach where the NDIS Miniport and
the KMDF Filter need to split the duties between them.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, November 10, 2008 11:57 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Handling IOCTLs in NDIS miniport drivers

The short answer is no, you cannot create a WDFDEVICE from within a
‘miniport’ driver. More to the point, you cannot create a WDFQUEUE either
or WDFREQUEST or any of the stuff that would make it possible to handle I/O
requests with WDF.

The NDIS/KMDF sample demonstrates the one-and-only capability available to
an NDIS/KMDF driver - I/O targets.

Depending on what you want to do from usermode you have these options:

  1. Create an ‘auxilary’ named device object with NdisMRegisterDevice and
    handle IRPs directly.

  2. Create a KMDF ‘filter’ driver and place it in the stack with your NDIS
    Miniport as an UpperFilter. This allows you to get inline with the IO on
    the actual device stack by why you would want to, I don’t know. The NDIS
    Miniport driver would need to ‘connect’ up with the filter driver. This can
    be accomplished with an IRP_MN_QUERYINTERFACE to the ‘top’ of the device
    stack.

  3. Create a KMDF ‘filter’ driver and place it in the stack with your NDIS
    Miniport as a LowerFilter. Create KMDF control device objects or enumerate
    child devices per NIC depending on what you are trying to accomplish. You
    can send requests from the NDIS miniport to the KMDF filter since the FiDO
    will be in the same device stack as the NDIS Miniport (FDO). You could, for
    instance, export an interface from the FiDO and retrieve it via an
    IRP_MN_QUERYINTERFACE request in the NDIS FDO (or if you are NDIS/KMDF
    WdfIoTargetQueryForInterface()).

Without knowing a lot more about the problem you are trying to solve (not
the tools you are trying to use to solve it) and the nature of the interface
you wish to use in common, it is rather difficult to give good advice. The
points above are just ideas and are not necessarily suitable to anything you
might try to accomplish so don’t expect much.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Monday, November 10, 2008 11:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Handling IOCTLs in NDIS miniport drivers

Hi all,

I’m working on NDIS miniport driver, and I need it to communicate with user
mode. I choosed to use ioctls, because I want to share ioctls implementation
from another driver I have. However, the another one is kmdf-based driver,
and it uses EvtIoDeviceControl dispatch callback to handle ioctls.

From netvmini sample in wdk I could find the call for NdisMRegisterDevice to
create an interface for usermode. It gets a dispatch table as an agrument,
and the callback for dispatching is WBM’s.

Is it any way to create a WDF interface to usermode from ndis miniport
driver?
From http://www.osronline.com/showThread.cfm?link=108185 (message 6 by Anton
Bassov) I can’t call for WdfDeviceCreate to create a framework device
object. In the other hand, there is an NDIS sample in kmdf source, so I
would assume that there is a way to accomplish my needs.

Additional option that I thought about is to create a WDFREQUEST within WDM
dispatch routine, but it seems a kind of ugly hack :frowning: Isn’t there any more
elegant solution?

Any advise is more then welcome !!!

Thanks,
S.

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

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

4

Not to disagree with Dave at all but personally, I always stay away from the idea of creating an aux devobj in a production miniport ndis driver, not because I don’t know how to do it - it just creates more problems than it’s supposed to solve, like what computers do, IMHO.

I’d use OID, you can make oid request through IOCTL as well as WMI. NDIS does most of the “microsoft things” for you so what we need to do in the driver is pretty straightforward.

A well structured IOCTL handler should separate the meat from the OS dependent layer nicely such that the workhorse can be reuse in other OS/environments with no or minimum changes.

–
Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Mon, 11/10/08, David R. Cattley wrote:

> From: David R. Cattley
> Subject: RE: [ntdev] Handling IOCTLs in NDIS miniport drivers
> To: “Windows System Software Devs Interest List”
> Received: Monday, November 10, 2008, 8:57 AM
> The short answer is no, you cannot create a WDFDEVICE from
> within a
> ‘miniport’ driver. More to the point, you cannot
> create a WDFQUEUE either
> or WDFREQUEST or any of the stuff that would make it
> possible to handle I/O
> requests with WDF.
>
> The NDIS/KMDF sample demonstrates the one-and-only
> capability available to
> an NDIS/KMDF driver - I/O targets.
>
> Depending on what you want to do from usermode you have
> these options:
>
> 1. Create an ‘auxilary’ named device object with
> NdisMRegisterDevice and
> handle IRPs directly.
>
> 2. Create a KMDF ‘filter’ driver and place it in
> the stack with your NDIS
> Miniport as an UpperFilter. This allows you to get inline
> with the IO on
> the actual device stack by why you would want to, I
> don’t know. The NDIS
> Miniport driver would need to ‘connect’ up with the
> filter driver. This can
> be accomplished with an IRP_MN_QUERYINTERFACE to the
> ‘top’ of the device
> stack.
>
> 3. Create a KMDF ‘filter’ driver and place it in
> the stack with your NDIS
> Miniport as a LowerFilter. Create KMDF control device
> objects or enumerate
> child devices per NIC depending on what you are trying to
> accomplish. You
> can send requests from the NDIS miniport to the KMDF filter
> since the FiDO
> will be in the same device stack as the NDIS Miniport
> (FDO). You could, for
> instance, export an interface from the FiDO and retrieve it
> via an
> IRP_MN_QUERYINTERFACE request in the NDIS FDO (or if you
> are NDIS/KMDF
> WdfIoTargetQueryForInterface()).
>
> Without knowing a lot more about the problem you are trying
> to solve (not
> the tools you are trying to use to solve it) and the nature
> of the interface
> you wish to use in common, it is rather difficult to give
> good advice. The
> points above are just ideas and are not necessarily
> suitable to anything you
> might try to accomplish so don’t expect much.
>
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Monday, November 10, 2008 11:38 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Handling IOCTLs in NDIS miniport drivers
>
> Hi all,
>
> I’m working on NDIS miniport driver, and I need it to
> communicate with user
> mode. I choosed to use ioctls, because I want to share
> ioctls implementation
> from another driver I have. However, the another one is
> kmdf-based driver,
> and it uses EvtIoDeviceControl dispatch callback to handle
> ioctls.
>
> From netvmini sample in wdk I could find the call for
> NdisMRegisterDevice to
> create an interface for usermode. It gets a dispatch table
> as an agrument,
> and the callback for dispatching is WBM’s.
>
> Is it any way to create a WDF interface to usermode from
> ndis miniport
> driver?
> From http://www.osronline.com/showThread.cfm?link=108185
> (message 6 by Anton
> Bassov) I can’t call for WdfDeviceCreate to create a
> framework device
> object. In the other hand, there is an NDIS sample in kmdf
> source, so I
> would assume that there is a way to accomplish my needs.
>
> Additional option that I thought about is to create a
> WDFREQUEST within WDM
> dispatch routine, but it seems a kind of ugly hack :frowning:
> Isn’t there any more
> elegant solution?
>
> Any advise is more then welcome !!!
>
> Thanks,
> S.
>
>
>
> —
> 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
>
>
> —
> 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

__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at
http://ca.toolbar.yahoo.com.

5

Calvin is of course right and I should have asked the underlying question of
why you think you need to intercept/process IOCTL IRPs in the first place.
If you can remove that aspect of the design and communicate with the NDIS
Miniport via NdisRequest() or custom (GUID mapped) OIDs and WMI, then,
avoidance is the the best solution.

I had assumed (perhaps incorrectly) that the OP really does need to do some
performant I/O from usermode for which restrictions of Ndis Requests would
be an issue. NDIS Requests are serialized in NDIS (3/4/5) 5.x so that only
a single one is ‘active’ on any Miniport at a time. This is fine for
mapping to inherently synchronous operations to but (as we all learned with
NDISTAPI, WiFi, etc.) is lousy if you want to overlap multiple operations on
a miniport or have long-running requests.

Thanks for keeping me honest :slight_smile:

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Monday, November 10, 2008 1:22 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Handling IOCTLs in NDIS miniport drivers

Not to disagree with Dave at all but personally, I always stay away from the
idea of creating an aux devobj in a production miniport ndis driver, not
because I don’t know how to do it - it just creates more problems than it’s
supposed to solve, like what computers do, IMHO.

I’d use OID, you can make oid request through IOCTL as well as WMI. NDIS
does most of the “microsoft things” for you so what we need to do in the
driver is pretty straightforward.

A well structured IOCTL handler should separate the meat from the OS
dependent layer nicely such that the workhorse can be reuse in other
OS/environments with no or minimum changes.

–
Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Mon, 11/10/08, David R. Cattley wrote:

> From: David R. Cattley
> Subject: RE: [ntdev] Handling IOCTLs in NDIS miniport drivers
> To: “Windows System Software Devs Interest List”
> Received: Monday, November 10, 2008, 8:57 AM
> The short answer is no, you cannot create a WDFDEVICE from
> within a
> ‘miniport’ driver. More to the point, you cannot
> create a WDFQUEUE either
> or WDFREQUEST or any of the stuff that would make it
> possible to handle I/O
> requests with WDF.
>
> The NDIS/KMDF sample demonstrates the one-and-only
> capability available to
> an NDIS/KMDF driver - I/O targets.
>
> Depending on what you want to do from usermode you have
> these options:
>
> 1. Create an ‘auxilary’ named device object with
> NdisMRegisterDevice and
> handle IRPs directly.
>
> 2. Create a KMDF ‘filter’ driver and place it in
> the stack with your NDIS
> Miniport as an UpperFilter. This allows you to get inline
> with the IO on
> the actual device stack by why you would want to, I
> don’t know. The NDIS
> Miniport driver would need to ‘connect’ up with the
> filter driver. This can
> be accomplished with an IRP_MN_QUERYINTERFACE to the
> ‘top’ of the device
> stack.
>
> 3. Create a KMDF ‘filter’ driver and place it in
> the stack with your NDIS
> Miniport as a LowerFilter. Create KMDF control device
> objects or enumerate
> child devices per NIC depending on what you are trying to
> accomplish. You
> can send requests from the NDIS miniport to the KMDF filter
> since the FiDO
> will be in the same device stack as the NDIS Miniport
> (FDO). You could, for
> instance, export an interface from the FiDO and retrieve it
> via an
> IRP_MN_QUERYINTERFACE request in the NDIS FDO (or if you
> are NDIS/KMDF
> WdfIoTargetQueryForInterface()).
>
> Without knowing a lot more about the problem you are trying
> to solve (not
> the tools you are trying to use to solve it) and the nature
> of the interface
> you wish to use in common, it is rather difficult to give
> good advice. The
> points above are just ideas and are not necessarily
> suitable to anything you
> might try to accomplish so don’t expect much.
>
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@gmail.com
> Sent: Monday, November 10, 2008 11:38 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Handling IOCTLs in NDIS miniport drivers
>
> Hi all,
>
> I’m working on NDIS miniport driver, and I need it to
> communicate with user
> mode. I choosed to use ioctls, because I want to share
> ioctls implementation
> from another driver I have. However, the another one is
> kmdf-based driver,
> and it uses EvtIoDeviceControl dispatch callback to handle
> ioctls.
>
> From netvmini sample in wdk I could find the call for
> NdisMRegisterDevice to
> create an interface for usermode. It gets a dispatch table
> as an agrument,
> and the callback for dispatching is WBM’s.
>
> Is it any way to create a WDF interface to usermode from
> ndis miniport
> driver?
> From http://www.osronline.com/showThread.cfm?link=108185
> (message 6 by Anton
> Bassov) I can’t call for WdfDeviceCreate to create a
> framework device
> object. In the other hand, there is an NDIS sample in kmdf
> source, so I
> would assume that there is a way to accomplish my needs.
>
> Additional option that I thought about is to create a
> WDFREQUEST within WDM
> dispatch routine, but it seems a kind of ugly hack :frowning:
> Isn’t there any more
> elegant solution?
>
> Any advise is more then welcome !!!
>
> Thanks,
> S.
>
>
>
> —
> 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
>
>
> —
> 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

__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now at
http://ca.toolbar.yahoo.com.

—
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

6

Hello David and Calvin,

Thank you very much for your input. I considered to use ioctls and now wmi because I’m not familiar with wmi at all, and already have a user-mode api implemented, which is based on DeviceIoControl calls. I’ll look for a samples in DDK to see if it’s easy to port the implementation I already have to wmi. If you have any tips for me about where to look and how to learn it quickly, they are more then welcome!

Regarding the performance for i/o operations - most of them it’s not critical. So, seems that I would consider it.

Thanks again,
S.

7

No problem dude.

For mapping OID to WMI GUID, and how to access them from user mode C program, see the e100 miniport sample in DDK.

You can also use DeviceIoControl to send OIDs to miniport without using WMI. See http://www.osronline.com/DDKx/network/107ioctl_24fm.htm

Doing WMI with VBScript is by far, the easiest.

Good luck!

–
Calvin Guan
Broadcom Corp.
Connecting Everything(r)

— On Mon, 11/10/08, xxxxx@gmail.com wrote:

> From: xxxxx@gmail.com
> Subject: RE:[ntdev] Handling IOCTLs in NDIS miniport drivers
> To: “Windows System Software Devs Interest List”
> Received: Monday, November 10, 2008, 11:55 PM
> Hello David and Calvin,
>
> Thank you very much for your input. I considered to use
> ioctls and now wmi because I’m not familiar with wmi at
> all, and already have a user-mode api implemented, which is
> based on DeviceIoControl calls. I’ll look for a samples
> in DDK to see if it’s easy to port the implementation I
> already have to wmi. If you have any tips for me about where
> to look and how to learn it quickly, they are more then
> welcome!
>
> Regarding the performance for i/o operations - most of them
> it’s not critical. So, seems that I would consider it.
>
> Thanks again,
> S.
>
>
> —
> 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

__________________________________________________________________
Get the name you’ve always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/

8

Calvin, David,

Thanks a lot for your help, people!!!

S.