Wireshark doesn't show the Ethernet interface after the miniport driver is installed. Wireshark shows "No interfaces found". But Microsoft Message Analyzer and NetMon can locate the adapter interface and show the captured packets.
But if I restart the machine then Wireshark is able to find the interface. I suspect it's due to binding issues between WinPcap and my miniport driver. Please correct me if I'm wrong! Do I need to change the INF file or look at the OID requests part as the NPF filter (used by WinPcap) isn't able to get it's hands on the miniport driver ?
With regards,
Jenson
From what I recall, if network adapters are installed or removed the pcap service needs to be restarted to pick up the changes.
To stop the service, from a command line with Administrator rights:
net stop npf
To start it again:
net start npf
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 have a NDIS light-weight filter (LWF) driver to capture all network traffic. It's open-sourced here. The installer is provided here.
The issue is that I found my filter will cause all Wi-Fi adapters can't receive any packets. I have received many complaints here: https://github.com/nmap/nmap/issues/373
The reproduce steps are:
Installed this filter using the installer (npcap-0.10-r14.exe).
Launch Wireshark GUI (latest stable version Wireshark 2.2.1), then only Wi-Fi connections are broken. Wired connections are not affected.
During the connection loss, I try to capture packets on the no-connection Wi-Fi adapter via Wireshark, I can still see outgoing traffic, but no incoming traffic. (most outgoing traffic will be the ARP requests after a few seconds because no packets received)
Wait for 90-100 seconds, then the Wi-Fi connections are recovered. Everything is fine now.
Close and re-start Wireshark now will not cause this issue again.
But if I restart my filter (like using net stop npcap and net start npcap) or re-install it via the installer. And repeat from step 2, then this issue happens again.
So this issue seems to only happen when the NDIS filter loads at the first time, and only happen to Wi-Fi adapters.
Then I checked the debug trace of my NDIS filter in DbgView (via installing the debug version npcap-0.10-r14-debug.exe). I saw that my ReceiveNetBufferListsHandler function NPF_TapEx is never called during the connection loss. The SendNetBufferListsHandler function NPF_SendEx is still working fine.
So I believe some things happened when launching Wireshark causes NDIS doesn't pass on the received packets. So my NDIS filter and upper Windows OS doesn't receive any incoming packets at all.
I noticed that Microsoft said Optional NDIS Lightweight Filters (LWF) could cause 90-second delay in network availability here. But it only happens when:
If an optional NDIS Lightweight Filter (LWF) driver is installed and the driver is not started, the network will not be available for up to 90-seconds.
However, my filter driver has been started by the installer, not by launching the Wireshark GUI. And this connection loss only happens to Wi-Fi connections. So I believe this is not the cause.
I'm testing this issue on Win10 14393 x64. But it seems to happen for all platforms. Does anyone have any ideas that why this issue happens? Thanks!
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.
The general situation: I have Windows 7 64-bit professional, network connection via ethernet and plugged USB GSM modem. The problem is that sometimes my Internet provider has some outage and during such time I'd like to automatically use USB modem. I've already written some Perl code that actively tests if connection is down and can run a shell command to switch the adapter used for Internet access.
The question is how to change the adapters from command prompt. I'd prefer not giving the script administrative privileges but if it's unavoidable, I can bear this.
Preliminary look-around:
C:\Windows\system32>wmic nic get name, index
Index Name
0 WAN Miniport (SSTP)
1 WAN Miniport (IKEv2)
2 WAN Miniport (L2TP)
3 WAN Miniport (PPTP)
4 WAN Miniport (PPPOE)
5 WAN Miniport (IPv6)
6 WAN Miniport (Network Monitor)
7 Realtek PCIe GBE Family Controller
8 WAN Miniport (IP)
9 Microsoft ISATAP Adapter
10 RAS Async Adapter
11 Teredo Tunneling Pseudo-Interface
12 Microsoft ISATAP Adapter
13 Microsoft 6to4 Adapter
"netstat -rn" shows that adapter for Local Area Connection has higher priority for binding than the modem, which is good.
The usage of my USB modem for casual user consists of running a bespoke application for it and clicking a button "Connect/Disconnect". AFAIK the app doesn't have command line options.
In one direction I figured out a workaround that has additional advantage of keeping the connection alive: AutoConnect 0.1.3.1 by Jarek "Shider" Wieczorek. AFAIK it has no command line options, but just running it after it has been once configured establishes GSM connection and later reconnects in case, which is great.
Now I stuck on how to switch back to LAN (which is my primary, quicker access to the net) after some time, when Internet access has been restored. After killing AutoConnect, the connection is still via modem. I suspected that switching back could be some netsh command but haven't found anything obvious in the help. In a desperate attempt I thought of disabling the modem using devcon.exe but the program downloaded from
http://support.microsoft.com/?kbid=311272
didn't run (some errors that I won't cite because they're actually unrelated to the main issue) and before downloading huge Windows Driver Kit 7.1.0 for a hopefully better version I thought I'll ask here for some suggestion/solution :)
Thank you in advance for any neat general solution or a small specific solution on how to turn off USB connection (maybe Windows will automatically use LAN then) or switch to LAN.
EDIT:
Belatedly, I came up with a solution. Supposing a modem connection has the name ABCD, the following terminates it after closing AutoConnect:
rasdial ABCD /disconnect
However, I still think the whole idea I presented is quite awkward and would gladly see some neat approach. Thanks.
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