NDIS miniport/filter driver

NTDEV
1

Hi together,

I have a USB driver for a special Ethernet USB hardware based on KMDF. Now I want to use the USB driver as a classical windows network device (e.g. to open sockets etc.) also and implement NDIS (with KMDF).

The USB driver owns a WDF driver object and creates a couple of WDF device objects to communicate with the user mode application (addDevice).
Is it now possible to register the driver object to the ‘NDIS library’ and implement all NDIS functions/callbacks within one driver (sys file), e.g. as a NIDS miniport/filter driver running parallel to the existing device objects?

thanks and best regards
Horst

2

xxxxx@freenet.de wrote:

I have a USB driver for a special Ethernet USB hardware based on KMDF. Now I want to use the USB driver as a classical windows network device (e.g. to open sockets etc.) also and implement NDIS (with KMDF).

Doesn’t one automatically imply the other? That is, the way you get a
“classical network device” is by implementing NDIS.

The USB driver owns a WDF driver object and creates a couple of WDF device objects to communicate with the user mode application (addDevice).
Is it now possible to register the driver object to the ‘NDIS library’ and implement all NDIS functions/callbacks within one driver (sys file), e.g. as a NIDS miniport/filter driver running parallel to the existing device objects?

Yes, with a little bit of rework. You have to use KMDF in “miniport
mode”, because NDIS needs to do all of the dispatching. That might make
your custom device object a bit awkward. Here’s a blog post that talks
about this:

http://blogs.msdn.com/b/ndis/archive/2014/07/20/writing-an-ndis-driver-with-wdf.aspx

It MIGHT be easier to have your USB device spawn another device object
that loads the NDIS driver. I don’t know the tradeoffs of that design
decision.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

> It MIGHT be easier to have your USB device spawn another device object that loads the NDIS driver. I don’t know the tradeoffs of that design decision.

The reasons I’ve seen to do that are (in decreasing order of likelihood):

* You need USB selective suspend, and you must ship your driver on OS versions prior to Windows 8. Starting with Windows 8, NDIS has native support for USB selective suspend, so it is no longer necessary to build your own bus driver.

* Your bus enumerates a single device, and you want multiple independent functions, and you can’t use your bus’s own ability for multi-function devices. We see this most commonly with PCI-connected devices that want to expose both storage & networking miniports. But some USB gadgets want to expose mass storage (although their firmware typically just expose themselves as multi-function devices to the bus, which solves a lot of problems).

* You must manually manage the device interfaces ( msdn.com/ff549460 ) on your FDO, and NDIS’s management is for some reason not good enough for you.

For a typical USB gadget, it’s not worth the trouble. You should be fine just following Tim’s instructions of putting WDF into miniport mode.

4

Hi,

thanks for the quick response.

The actual driver uses a FDO and a couple of device objects with symbolic names for the application communication. So when I look to the KMDF MSDN:

“Miniport drivers cannot use the framework’s control device objects.”
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540778(v=vs.85).aspx

At the end I can not use a KMDF miniport driver? (see also point three from Jeffrey?).

So maybe it’s better to write a separate NDIS driver which will be loaded by the USB driver, and create a driver-driver communication?

thanks and regards
Horst

5

You can’t use KMDF to create a CDO, but you can use NDIS to create one. See NdisRegisterDeviceEx.