none
NDIS NIC Communication RRS feed

  • Question

  • Hello,

    I have read quite a lot about NDIS drivers, but still do not have much practical experience.
    I still do not know how the communication between the NIC and the NDIS drivers is implemented.
    Does the communication from a NIC have to be to a Miniport driver? Is it not possible to make the communication direct to a Protocol Driver?
    How is the communication actually implemented in NDIS 6.0 and above? For instance, are there library functions which do the reading and writing from and to the NIC?

    Thank you for your help in advance!

    Wednesday, August 13, 2014 8:55 PM

Answers

  • NIC is Network Interface Card, i.e. it is the hardware for the device.  NDIS is Network Driver Interface Specification, i.e. the miniport is the software driver for the device.  You communicate from NDIS to the NIC by accessing the hardware as you would any other device in Windows, reading and writing the registers and ports.

    The protocol driver is a software only layer above NDIS.  Even if you had a unique protocol that you were writing yourself why would you want to tie the protocol to a single device, and tie the device to a single protocol?  The model of seperate protocol drivers versus the driver that controls the NIC go back further than Microsoft existed, and most people who ignored it regret it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Wednesday, August 13, 2014 9:07 PM
  • If you want Windows networking to use your device, you must provide an NDIS miniport driver - there is no way around that requirement. Networking relies very heavily upon layering of drivers. If your miniport and protocol driver were tied together tightly (or were a single driver), then filter drivers could not be layered between them.

    Your miniport driver exposes about a dozen entry points which the NDIS library calls when needed. You will be given outgoing packets in a data structure known as a Net Buffer List, or NBL, that you will then give to your hardware (typically by creating an entry in the hardware's Send ring buffer). Incoming packets will typically generate an interrupt, causing your miniport driver to be called. The miniport will then remove the entry from the hardware's Receive ring, package up the data in an NBL and indicate the NBL up the network stack by calling an NDIS library routine. The path that NBLs take through the network drivers is determined by Binding information placed in the registry by INF files (possibly modified by filter/intermediate drivers).

    Properties are queried and set using Object Identifiers (OIDs) which the NDIS library passes to another of your miniport driver routines.

    All of this is very well documented in the MSDN WDK docs here. Count yourself lucky that you're writing a network driver, the NDIS docs are the best docs in the WDK (the audio docs are the absolute worst).

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, August 14, 2014 12:03 AM
    Moderator

All replies

  • One detail I forgot to ask. Would not my NIC driver behave like a miniport driver? Doing the communication between the NIC and NDIS?
    Wednesday, August 13, 2014 9:01 PM
  • NIC is Network Interface Card, i.e. it is the hardware for the device.  NDIS is Network Driver Interface Specification, i.e. the miniport is the software driver for the device.  You communicate from NDIS to the NIC by accessing the hardware as you would any other device in Windows, reading and writing the registers and ports.

    The protocol driver is a software only layer above NDIS.  Even if you had a unique protocol that you were writing yourself why would you want to tie the protocol to a single device, and tie the device to a single protocol?  The model of seperate protocol drivers versus the driver that controls the NIC go back further than Microsoft existed, and most people who ignored it regret it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Wednesday, August 13, 2014 9:07 PM
  • If you want Windows networking to use your device, you must provide an NDIS miniport driver - there is no way around that requirement. Networking relies very heavily upon layering of drivers. If your miniport and protocol driver were tied together tightly (or were a single driver), then filter drivers could not be layered between them.

    Your miniport driver exposes about a dozen entry points which the NDIS library calls when needed. You will be given outgoing packets in a data structure known as a Net Buffer List, or NBL, that you will then give to your hardware (typically by creating an entry in the hardware's Send ring buffer). Incoming packets will typically generate an interrupt, causing your miniport driver to be called. The miniport will then remove the entry from the hardware's Receive ring, package up the data in an NBL and indicate the NBL up the network stack by calling an NDIS library routine. The path that NBLs take through the network drivers is determined by Binding information placed in the registry by INF files (possibly modified by filter/intermediate drivers).

    Properties are queried and set using Object Identifiers (OIDs) which the NDIS library passes to another of your miniport driver routines.

    All of this is very well documented in the MSDN WDK docs here. Count yourself lucky that you're writing a network driver, the NDIS docs are the best docs in the WDK (the audio docs are the absolute worst).

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Thursday, August 14, 2014 12:03 AM
    Moderator