I’m new to windows drivers, so please forgive me if I’m asking a stupid question. I’m developing a usb network adapter and driver, and I’m looking for clarification on a few things. The microsoft documentation on NDIS has left me a little confused.
Adapter details:
-It’s wireless, but not a standard MAC protocol
-It handles all MAC layer considerations (i.e. it accepts raw IP frames)
-Target OS support Windows 7, 8, 8.1, 10
Questions:
-How many drivers do I need in my driver stack (i.e. minimum number)?
-Do I need a WDF driver below the miniport driver to manage the device?
Additional:
I originally pictured it as just a miniport driver, but this post http: lead me to think I’d need an additional WDF driver below the miniport. To that end do I need a protocol driver as well?
You’re going to write a single driver with an upper edge that “talks” NDIS and a lower edge that “talks” WDF (KMDF) to your USB device. This is a well-trodden path, and IIRC there’s even an example in the WDK for something similar.
As Peter said, the one driver you need is an NDIS-WDM driver. And yes,
there have been multiple samples including a WiFi driver though those
samples may be found in earlier WDKs (Vista/SRV2008 or Win7).
However you said above the medium is “Wireless” but not “WiFi” (e.g. 802.11)
and so your upper edge is expecting IP frames.
NDIS has medium types for that but you sure cannot bind into the WiFi
subsystem with such a medium type requrirement.
So that begs the question: What are you expecting your “Wireless” adapter
to look like to the system?
What sort of control model do you expect the system to exercise over your
adapter? (Possibly none)?
There are two “Wireless” network models in Windows where Windows itself
knows something about the medium and thus exposes a user-experience that is
standardized:
WiFi which your medium does not seem to be.
WWAN (Wireless WAN) which *might* be what your medium is. This stack
does support Raw IP framing but it also expects to be very much like a
Cellular data connection. There are specific control facets of this stack
you should look at to understand.
There is always the ‘third’ option which is you take on responsibility for
everything and your adapter just looks like an adapter (not a WiFi adapter
or WWAN Adapter).
So, what sort of adapter have you got? Does it require (for example) some
application to deal with connection establishment, authentication, etc?
This was what I was leaning toward. You’re right it really doesn’t fit into any standard category. I had looked into the WWAN approach, but it brings with it a surprising amount of baggage. It’s really just a dev board, but I need windows to see it as a generic network adapter.
That’s great I’ll have to go download the earlier WDKs. Do you have any additional resources or references you’d recommend? I understand there’s no book on NDIS drivers, so I’ll take anything I can find.
Start with the driver sample NDISEDGE from the SRV2008SP1 WDK (6001.18002)
if you can get it. It is a very simple and clean KMDF based shell of a
basic Ethernet NIC.
You will also want to have a look at any of the NDIS USB samples that use
KMDF at the lower edge to get an idea of how to structure communicating with
your USB device.
I know your device wants RawIP frames but you might find it easier to ‘shim’
that initially so you are only dealing with one unknown at a time.
For example you could take NDISEDGE as a Ethernet MAC and add ARP spoofing
to it pretty easily and then just peel off the IPv4 and IPv6 frames, strip
(e.g. advance past) the MAC header, and viola! you have an IP frame.
You can then use all of the support in Windows for Ethernet adapters to do
mundane things like set the IP address.
When you finally figure out what all is required to get your HW running and
packets flowing then you might tackle changing from an Ethernet medium
device to some other medium (rawip or whatever).
I should have also noted that if your ‘link’ is much like point-to-point
link you might also consider doing a CoNDIS driver and interfacing to the
NDISWAN / RAS system. But that is possibly an even more bewildering stack
to hook into.
You will be well served by reading the MSDN material for network devices.
It is well written and stable.
There was (is?) a book. I can’t say as I recommend it. It tops out at
NDIS 3.0 drivers but has plenty of material on DOS and Netware and of course
that barn-burner TokenRing. You can have my copy for half price plus
shipping
Thanks for the help so far. I took a look at the older WDK examples and they’ve cleared things up. I’m going to ask one more question since this thread has been so helpful. Let’s say I wanted to pass non-network information to and from the device (e.g. device specific settings, firmware updates, network statistics, etc.). Where and how would I do that since traditional device interfaces are not allowed in miniport drivers?
>Where and how would I do that since traditional device interfaces are not allowed in miniport drivers?
Your driver will expose WDF and you could use your own defined IOCTLs.
Igor Sharovar
An NDIS miniport driver isn’t able to expose a device through WDF, since the FDO is owned by NDIS. NDIS permits you to do IOCTLs, though, via NdisMRegisterDevice. Alternatively, NDIS allows you to define your usermode interface in a WMI MOF file, and NDIS will automatically translate that into OIDs for you. Or if you really want to use WDF, you can create a bus driver, enumerate a child PDO for NDIS to look at, and enumerate a second PDO for your usermode communication.
In most cases, NdisMRegisterDevice is the better option, since that takes you to a known quantity (IOCTLs). We have little documentation on the WMI route, and it’s not exactly obvious how to hack it on your own.
I am always grateful when Mr. Tippet lends a hand with his authoritative info.
To those who aren’t familiar: What Mr. Tippet said doesn’t mean that you can’t use WDF for the lower edge of your driver. You absolutely can. You write an NDIS driver, and then use WDF at your lower edge to handle your I/O Targets and the like. It makes things very convenient. Like I said before, this is a well-trodden path.
Right, thanks Peter for unpacking my jargon, and highlighting an important point that I had obscured. It’s easy to determine that, between the two of us, I’m not the one that is a professional educator.
