NDIS and miniport driver

Question

I am trying to modify a ethernet driver using WDK tools provided in Visual Studio 2012.

The samples provided in the WDK are 'miniport adapter' and 'NDIS Light Weight Filter' among others. I am still at the very beginning of driver writing and hence finding it tough to navigate through the code.

I was able to install the miniport adapter after building it in Visual Studio 2012 [Shows up as 'Microsoft Virtual Miniport Adapter' in my network adapters list.] I am able to assign it a IP address and Subnet mask also.[I found out that this does not connect to any physical device on my PC].

I also setup the 'Debug View' software to check the driver messages from my adapter.[ I used 'DbgPrint' statements in the code and then built it.] But, The debug messages are printed repeatedly.

1- Why are the messages printed again and again? The messages are from the 'datapath.c' file of the program and is from the function 'MPSendNetBufferLists'. ['Net Buffer' specifies data sent or received on the network.]

2- I setup Wireshark to capture the data on the adapter and it shows that there are requests from ARP,HTTP,SSDP,MDNS etc coming out of it. I am not able to understand what is actually talking to the adapter? and how can I stop it from talking?

I can use 'ping' to see if there is a connection on the IP address I have assigned to the adapter and it responds with a success telling all packets were sent and there was no packet loss.

My goal is to send and receive 'data' packets via a IP address to this ethernet adapter. ie- I want an application to connect to the IP address assigned to the adapter and talk to it.

3- Can I actually do it with the samples provided in WDK?

Any other suggestions or advice are welcome.

PS- I wasn't able to use the windows debugger built into Visual Studio 2012. I used 2 PCs and was able to connect and install the driver onto the 'target' PC but couldn't do anything with breakpoints etc. The code and Program just did nothing after installing the driver on the 'target' PC. Any suggestions on this?. I thought I could do step-by-step debugging of drivers also.[I know I am wrong].

Thanks Aditya

Answer 1

NDIS miniport drivers, like many low-level drivers, are meant to talk to hardware. The miniport's responsibility is to take send packets from the OS, translate them into whatever format is required by the hardware, and instruct the hardware to send the packet on the wire.

The WDK could (and in fact, used to) include a real-world sample driver that sends packets on real-world hardware. But this leads to some confusion, since real-world drivers have to deal with lots of hardware-specific details that distract from the main point of the sample. If you starting from a real-world driver, the first thing you'd have to do would be to identify all the hardware-specific bits and rip those out, so you could replace them with your own hardware-specific bits.

Instead, the "netvmini" sample in the WDK is a fake driver. That means it pretends to have actual hardware, but secretly it's all a lie. When the OS sends packets to netvmini, the netvmini driver will simply broadcast those packets to any other netvmini miniport adapters installed on that machine. (In effect, installing 2 netvmini adapters on the same machine simulates what would happen if you had two real adapters plugged into the same Ethernet hub.) So in ASCII-art, this is what happens if you install two netvmini adapters on the same system:

       TCPIP                       TCPIP                      TCPIP
         |                           |                          |
Real physical miniport        Your netvmini #1           Your netvmini #2
         |                           \                          /
   [The Internet]                     [The netvmini virtual hub]

As hopefully the ASCII-art illustrates, your netvmini adapters don't have any path to the Internet. So your driver won't get a "real" IP address that can route to the Internet until you add in details of your hardware. Until then, Windows will just keep trying to send ARPs and HTTP requests that will never go anywhere.

To answer your specific questions:

1. The messages from MPSendNetBufferLists are printed every time the OS attempts to send a packet. Because the OS thinks that you have a real network connection, the OS will make several attempts to use it. Eventually that should quiet down a bit, when everything comes to the conclusion that this isn't a useful link.

2. The requests are coming from TCPIP. If you don't want TCPIP to send data, then unbind it from the adapter.

3. You can definitely send data to the adapter. In fact, you've observed that you're already sending random HTTP packets and etc. But the data won't actually reach the Internet, until you teach the driver how to talk to your real hardware.

If you're sitting there thinking "but I don't have hardware!", then you might want to create a virtual miniport of some sort. Virtual miniports are like netvmini in that they don't have real hardware, but they still do have some way to get the packets off the machine. For example, VPN miniports that operate at layer-2 (like L2TP) will typically install a second driver — an NDIS protocol driver — that sends and receives data from the "real" physical miniport. Then the virtual miniport talks to its protocol whenever it needs to get packets off the machine. The result is:

        TCPIP
          |
  Your virtual miniport
          |
   Your NDIS protocol
          |
The real physical miniport
          |
     The Internet

There are alternative architectures; for example, a VPN that operates at layer-4 (like SSTP) might decide to open a WSK socket instead of implementing an NDIS protocol driver:

        TCPIP
          |
  Your virtual miniport
          |
      WSK socket
          |
        TCPIP
          |
The real physical miniport
          |
     The Internet