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.
Related
The closest thing to a solution I've found is using Get-NetConnectionProfile to return all active interfaces, which works fine when there's only an active physical interface and the VPN itself. However, this would not work if the user's machine has 2 active physical interfaces (e.g Wi-Fi + Ethernet) along with the VPN.
Ideally, I'd like a solution that works similarly to "ifconfig -v" in MacOS, which tells you the effective interface for a virtual interface:
Unfortunately it seems there is no sure-fire way to get the underlying physical adapter for a VPN using a Windows API. Short of involving a packet sniffer such as Wireshark, the best solution I found involves parsing the output of two PowerShell commands: Get-NetAdapter and Get-NetRoute.
With the information from these commands, I can know which interfaces are virtual and which ones are physical, and I can rank the physical interfaces by 3 different criteria (in case of tie, we move on to the next criteria):
Sorting the physical interfaces by the interface metric + the route metric to the default gateway (0.0.0.0).
Wired connections over wireless ones (PhysicalMediaType=802.3).
Prioritizing faster adapters.
With this logic all the VPNs I tested appear to reflect the expected network interface, although some VPNs let you force traffic through a particular physical adapter in which case obviously this all goes out the window.
First,
You can install wireshark or some other traffic monitoring tool and capture the relevant packets (filtering using openvVPN protocol or port etc.)
Second,
As far as I know there is no hard linking between the virtual network interface and the regular (ethernet, WIFI etc.) interface, at least not in OpenVPN (there are diffrent VPN protocols). The openVPN packets will be routed to the remote server using you OS routing table.
This way if your ethernet interface is your primary default gateway, and it gets unplugged, your VPN service will be able to recover, since it will have a route to your remote VPN-server address using your WIFI interface.
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
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
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
I'm looking for a method to acurately determine if an interface is the physical 802.3 ethernet port on a pc in windows.
Using ipconfig /all I can list all the interfaces, and when I do this on my pc several entries can be listed here including VPN, Bluetooth, Wifi and the physical ethernet interface.
I'm looking for something like, "isPhysical(interface)".
(It's ok to have multiple physical lan ports, I just want to know if it is a physical port or not).
UPDATE:
Jay and Chris thanks!
(Not enough space in the comments so I'll post here)
I'm currently looking at using WMI Win32_NetworkAdapter.
However, it shows 4 interfaces with AdapterType="Ethernet 802.3".
I only have 1 phyical port on my pc the others have the Name, "Virtual Machine Network Services Driver". (I assume these are installed by my company for some nefarious reason)
I found the attribute I need in the interface, but it's not available in winXP!!!
PhysicalAdapter Data type: boolean
Access type: Read-only
Indicates whether the adapter is a
physical or a logical adapter. If
True, the adapter is physical. Windows
Server 2003, Windows XP, Windows 2000,
and Windows NT 4.0: This property is
not available.
Is there any way to determine if it's a physical port, other than doing a text filter for the word "Virtual" in the name?
UPDATE 12/08
Looks like the virtual interfaces are added when you have a VM installed.
Here's some details about the virtual adapter:
http://blogs.msdn.com/virtual_pc_guy/archive/2005/04/01/404816.aspx
Found an issue where if the user doesn't have admin rights the WMI interface doesn't return the data needed. So, now looking at the GetAdapterInfo method. However, it seems to add 'virtual machine services driver" to the actual adapter's description, making the 'virtual' text check invalid.
And the structure returned by GetAdapterInfo:
http://msdn.microsoft.com/en-us/library/aa366062(VS.85).aspx
Call GetIfEntry and look for a dwType of IF_TYPE_ETHERNET_CSMACD in the MIB_IFROW structure returned.
Or in .NET, look for a System.Net.NetworkInformation.NetworkInterface with a NetworkInterfaceType of Ethernet.
The best way I've seen so far with any system Windows 2000 SP2 and up is using WMI.
http://msdn.microsoft.com/en-us/library/aa394582(VS.85).aspx
Win32_NetworkAdapter
http://msdn.microsoft.com/en-us/library/aa394216(VS.85).aspx
And you can use the namespace System.Net.NetworkInformation Jay mentioned. Here is a link about detecting what network cards are connected or disconnected:
http://felizk.dk/?p=43
If a machine has two NICs, how will you pick which one is the right one? The only way I've seen this done is giving the user a dropdown combo with each interface's IP address. See Wireshark for an example -
If there are other solutions, I'd like to hear them -
Check interface via:
Call GetIfEntry and look for a dwType of IF_TYPE_ETHERNET_CSMACD in the MIB_IFROW structure returned.
Or in .NET, look for a System.Net.NetworkInformation.NetworkInterface with a NetworkInterfaceType of Ethernet.
And check if the name contains the text, "Virtual".
---This seems like a lame way to check, but so far it's the only method I see to ignore those virtual 802.3 adapters.
I'm not sure of the answer - but be aware that it is possible to have multiple ethernet interfaces.