I have built and installed the netvmini on windows 7/8. And Im able to ping from one IP to the other.
But I have some doubts with respect to its functionality which are listed below:
In which layer does the driver get placed w.r.t OSI layers.
Does the driver route the packets w.r.t the IP addresses given by the Application.
What is the role of NDIS protocol driver.
What is the difference between NDIS protocol driver and miniport driver.
Looking forward to some answers which will be of great help...
In the 2nd layer (MAC)
No, routing is done by the IP protocol (3rd layer). MAC layer operates with MAC addresses.
There is no specific role, as is. The role is defined by the driver developer and the location of the driver in the network stack. Protocol drivers are the highest level NDIS drivers and reside above miniport and filter drivers. Therefore, they naturally belong to higher layers of OSI model, e.g. they can implement functionality related to the transport layer (4th layer). See more here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff566823%28v=vs.85%29.aspx
Miniport driver is the lowest driver in the network stack, except for the bus driver. Usually it will implement functionality related to the 2nd layer (MAC). See more here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff565951(v=vs.85).aspx
Related
We have an NDIS LWF driver, and it seems like it cannot get attached to Virtual Network Adapters, for example the one that Kerio Control VPN client creates (Kerio Virtual Network).
When i try to install the NDIS LWF in the network adapter manually by giving it our INF file (Install -> service -> Have disk), the driver doesn't appear in the network service list.
Then i found out that i if add nolower in the FilterMediaTypes in the inf file, it does appear in the network service list, but even then, when i click on OK, it doesn't get added to the list of items and doesn't get attached.
My question is, How can i attach to this Kerio Virtual Network Adapter in order to monitor its packets?
LWFs cannot bind to a network interface that has HKR, Ndi\Interfaces,LowerRange,,nolower in its INF. Generally speaking, the network interface ought to have at least one real LowerRange, and it's reasonable to ask the vendor to add one. For whatever it's worth, we (the Windows OS team) originally shipped the Bluetooth PAN adapter with nolower, and then later realized we needed to update it to have something there, so LWFs could bind to it. Perhaps that anecdote helps motivate this vendor to update their INF.
If the NDIS datapath uses a 14 byte Ethernet-like header and is roughly compatible with Ethernet's ideas of unicast & multicast, then ethernet is the correct thing to put in LowerRange. See the docs for more details.
It's not supported to try and add the nolower token to your LWF driver INF's FilterMediaTypes; you can't reasonably expect to bind to any unknown type of interface. What if the next network adapter indicates packets in some yet-to-be-invented framing layer — how could your LWF possibly make sense of those packets? For that reason, nolower is not a binding interface; it's a special token that means "the empty list".
LWFs also cannot bind to CoNDIS network adapters. This is simply because the LWF programming model has never been extended to cover all the additional signaling for connection management.
I am not personally familiar with the "Kerio" network interface — I don't know if it has nolower in its INF or whether it's CoNDIS (!ndiskd would tell you this). If it's the former, you should ask that vendor to update their INF.
I am looking at implementing USB communication on a MCU which has a USB engine built into it. Basically you have access to the pipes/endpoints.
I am a little bit confused on the USB stack now. It appears that drivers operate on another level above the pipe/endpoint setup, so the pipe/endpoint is like a middle level layer that drivers are built on. Is this correct?
Secondly, I am interested in simulating serial communication over USB. It appears windows has a premade driver so on the computer side I do not need to program the pipe level.
How do I find out what I need to implement on the MCU to make it behave correctly with the generic serial driver?
This is an answer to your second question regarding the serial communication.
The USB standard defines a communication device class (CDC) for serial communication. The required drivers on the host side are implemented by Windows, macOS, Linux and many more operation systems.
The relevant CDC subclass is PSTN. The relevant documents are found in Class definition for Communication Devices 1.2.
The device basically implements four endpoints:
Control endpoint for configuration requests (baud rate, DTR state etc.). Have a look at SetLineCodeing, GetLineCoding and SetControlLineState.
Bulk endpoint for USB to serial transmission
Bulk endpoint for serial to USB transmission
Interrupt endpoint for notifications (DCD state, errors). See SerialState.
And of course you need to get the device descriptor right.
On top of that, you need to implement all the standard USB requests.
Chances are high that this has already been written for your MCU, both the standard requests and the serial communication. So why not use the existing code?
I'm looking to write a simple Windows driver to enable running TCP/IP over a proprietary RF module. The module already provides Ethernet-style data packets with source/destination MAC, so I just need to layer IP packets (generated by the regular Microsoft IPv4 subsystem), set the MTU appropriately so they will be the right size, and then call the module's serial API. I'll need to be able to handle transmit statuses and implement an ARP protocol as well. I want the driver to expose a new interface similar to a wifi or ethernet card in Network Connections and use the normal Windows IP stack.
The module is UART and might be connected via FTDI chip, RS-232 converter, or native UART on an IoT Core board, so it will just be talking to a generic serial port. I am fine with only running on Windows 10, but I'm still not sure what to use. Can I use the UWP VPN provider? Do I need to write an NDIS miniport driver, or an interface provider? Also, how will I handle the driver needing complete control over the serial port at all times? I can't write a serial driver as it might be connected via many different types of serial ports.
I am modifying a monitor controller for a prototype. It would be convenient to send commands to the prototype using DDC/CI. In Windows, I can't find an obvious way to send a DDC/CI command to a "display dependent device".
The Monitor Configuration API can send virtual control panel commands, but it does not give access to display dependent devices (which would have an I2C address other than 0x6e).
Nicomsoft's WinI2C/DDC product seems to give access to a display dependent device, but it is end-of-life. I would prefer not to build a dependency on an end-of-life product.
NVIDIA's NVAPI has an I2C API, but I would like a solution that also works with Intel and AMD graphics adaptors.
A solution exists for windows which respect XDDM driver display model. Windows 8 and 10 use WDDM.
In XDDM there is a windows O.S. supplied video port driver, and the hardware vendor supplies a miniport driver. When the miniport driver call's the video port driver's edid helper api (VideoPortDDCMonitorHelper), the miniport must supply 4 i2c function pointers as arguments.
In order to utilize these interfaces however you must be acting as the video port driver. So you have to write a video port lower filter driver which just passes along all the interfaces on from the windows supplied video port driver to the miniport driver. Hook the api's and export them to a usermode driver or ioctl which an application can call.
It may be possible to simply mount an instance of the miniport driver and some how get it to call VideoPortDDCMonitorHelper. But with out the help of the actual video port driver it would be difficult to get guidance on how to do that. Also you would have 2 instances of the driver running which may be against the rules for windows.
It does not appear this solution works for windows 8 and 10 because they use a different display driver model which doesn't appear to expose low level control of i2c. It is internal to the miniport driver.
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
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:
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.
The requests are coming from TCPIP. If you don't want TCPIP to send data, then unbind it from the adapter.
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