I have a Windows XP system with 2 NIC cards. 1 NIC card is used to just used to set some configuration to LabView. The other NIC is used to pump data real-time to another device using tcpip (not able to use UDP). The issue is that it cannot stop and rest for 125ms, once this happens we have problems.
The network we are on is pretty isolated, so nothing much is going on on the other NIC. Using Wireshark I can not correlate any event that happens on the other NIC, and do not see anything else with the Windows event logs.
Any ideas?
Is there a way to set the priority so that the real-time NIC doesn't get interrupted?
If nothing is going on, on the other NIC, and nothing is seen in the Windows event logs, what else could be going on to interrupt the real-time NIC?
Related
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.)
In Miniport drivers we have two status indications(NDIS_STATUS_MEDIA_CONNECT/NDIS_STATUS_MEDIA_DISCONNECT) to know whether LAN is disconnected or not.
Can we use the same indications in LWF to know the status of Media associated with LAN. I have two scenarios that I want get the indications or handles for.
When Wire connected to NIC is pulled and re-connected.
When two PC's are connected through a wire, I will power down the other PC where LWF is not running.
Appreciate your help.
Thanks
Drivers written in the last 10 years should not use NDIS_STATUS_MEDIA_CONNECT or NDIS_STATUS_MEDIA_DISCONECT. Those were retired with NDIS 5.x. Instead, use NDIS_STATUS_LINK_STATE.
Filter drivers may listen for NDIS_STATUS_LINK_STATE. They can also query the current link state at any time, by issuing OID_GEN_LINK_STATE.
If your filter originates NBLs, I encourage you to monitor the link state. It's just a waste of CPU cycles to try and originate NBLs when the link is down -- the packets will just get returned to you.
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 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
My application communicates with several GSM electric controllers, that means that I have to send anywhere between one to twenty messages every few hours. right now I'm working with HUAWEI Mobile Connect - 3G. it is a USB device that uses a comm port for the pc communication and I'm using GSMComm to send messages and read/delete messages from the device.
Every two seconds I'm checking the device's storage, and if there is any message, I will then read it and store it locally and then clear the device's storage. I'm not sure if I'm working correctly, but it seems to me as if it is a very unreliable device:
Every time I boot my machine, I must remove the device from the USB or my machine will get stuck at the BIOS start up screen (or whatever the name is).
Very frequently the comm port can become unavailable for some reason. I have to close and re open the port, and at times that may not even help.
In the production machine of my client, when he uses one of his software's that utilize the first comm port, he will get a warning message from the software about problems in the port if the device is plugged in (the device port is around 28 or something).
If you've been using a device which you consider reliable, or have been working with the same device as I work with, or you just think that I'm doing it wrong, I'd like to get an advice from you.
Thanks.
This sounds like an issue with your modem. Have you tried any other models? Consumer USB models tend to be unreliable. The preferred method, though slightly more expensive, is using a commercial grade modem in situations where you need the reliability.
Some modems to look at:
Wavecom Fastrack
Sierra Wireless Airlink
These use a serial port or ethernet to communicate with the host which is far more reliable. Serial ports may not be available in your particular situation but even a USB to RS232 adapter will be more reliable.
One further option is to use a smartphone, there are several applications that you can act as a gateway through HTTP.
SMS Gateway for Android:
https://market.android.com/details?id=eu.apksoft.android.smsgateway&hl=en
i have not used this method, but it seems like some people are having luck with it. it may not be any more reliable then your USB modem though.
Hope that answers your question.
I have used WaveCom's modem for sending messages in bulks and found it to be reliable. One difference though, in my implementation was i used Kannel as an SMSC, so my queues were automatically handled by Kannel. But sending multiple requests like 40+ per minute didnt pose any problems for me.
Hope this helps.