Forum Replies Created
-
Posts
-
Official information on driver signing is available here
http://www.microsoft.com/whdc/winlogo/drvsign/kmsigning.mspx
A thought: Before installing WinpkFilter, i disabled driver signing enforcement (F8 menu). When I restarted my computer I didn’t do that. Do you think it’s because of that? Maybe the network could not initialize because the WinpkFilter driver was not loading.
Yes, thats right. WinpkFilter driver is not signed and to get it working on x64 you have to load with disabled driver signing enforcement each time.
Sometimes NDIS IM driver installation requires a reboot. Not always network stack can be rebuilt dynamically.
Installation of NDIS IM drivers requires network stack to unbind from network interfaces and binds again. This operation may bring your network down for a short period of time. Generally it is recommended to reboot after drivers installation because in some cases network stack is not able to reconfigure itself dynamically.
If you have created WinpkFilter based software and restarting it causes network connection problems then most probably this is a bug in your software. Note, that when you put network interfaces into the tunnel mode you ought to filter packets. If your application is suspended but network adapters are still in tunnel mode the network won’t function.
P.S. Your report is really messy to realize what you are trying to report 🙄
Looks like linker is unable to find or to take proper version of ndisapi.lib. Try to set path to ndisapi.lib in project setting instead of pragma.
Для этого существует NDIS MUX Intermediate Drivers (NDIS 5.1)
The number of virtual miniports exposed by a MUX intermediate driver can be different than the number of lower physical adapters that are bound to the driver. A MUX intermediate driver exposes virtual miniports in a one-to-n, n-to-one, or even an m-to-n relationship with underlying adapters. This results in complicated internal bindings and data paths.
В данном случае STATUS_PENDING означает, что TDI клиент обработает полученные из сети данные позже и затем вернет переданный ему буфер. Данные из Tsdu лучше забрать до вызова оригинального обработчика, так как если это сделать позже, то можно получить race condition.
First, Windows VPS, an example Virtuozzo based ones, do not allow you to install custom drivers on them. The set of third party drivers which are allowed to load is defined by VPS vendor. I don’t know what VPS software is used at GoDaddy, but probably this is similar situation.
Second, any Windows will disconnect the remote session during NDIS IM drivers installation because the network stack is rebound and existing connections are dropped.
And third, even NDIS IM driver installation may require system reboot if stack can’t reinitialize dynamically.
SendPacketToAdapter can send any packet on the network even if it is not in correct format. I think you just don’t form the correct INTERMEDIATE_BUFFER. I’m not sure I fully understand what you are doing in your C# code as I’m not really experienced in C#, but to my limited knowledge the code is incorrect.
byte[] newPacket = new byte[sizeof(ETHER_HEADER) + sizeof(IPHeader) + sizeof(UdpHeader) +
sizeof(PlatformHeader) + dataLength + sizeof(GPSHeader)];
...
IntPtr outgoingPacket = Marshal.AllocHGlobal((IntPtr)(newPacket.Length));
Marshal.Copy(newPacket, 0, outgoingPacket, newPacket.Length);
ETH_REQUEST outgoingRequest = new ETH_REQUEST();
outgoingRequest.hAdapterHandle = Request.hAdapterHandle;
outgoingRequest.EthPacket.Buffer = outgoingPacket;In your code above you use newPacket as managed INTERMEDIATE_BUFFER and outgoingPacket as unmanaged INTERMEDIATE_BUFFER. However, the size for allocation for newPacket must be sizeof(INTERMEDIATE_BUFFER), not the size you have used above. As well when you copy managed INTERMEDIATE_BUFFER into unmanaged memory once again you should copy sizeof(INTERMEDIATE_BUFFER).
Note that you have to initialize INTERMEDIATE_BUFFER fields (you can copy values from the original structure and adjust m_Length).
Also note that the resulted packet must fit into MAX_ETHER_FRAME (more exactly it should not exceed network interface MTU value).
It looks like ctx->old_handler = NULL. You can inspect the code to check how could it happen, may be this is a sort of race condition.
1) According to the above scenario, can I use your WinpkFilter 3.x product to do it?
Sure you can.
2) Can I set a specific device adapter filter so that ONLY UDP packets going to a specific port are grabbed via a ReadPacket() call?
Yes, you can use built-in WinpkFilter filters for this.
3) Can I use the “listen” mode to grab the packets, and signal to DROP bad packets but let the good ones pass through? I really don’t want to have to re-send the good packets to the loopback address or use tunneling mode. I’d like to just drop the bad packets and let things be as normal for the good packets.
No, if you suppose to drop packets you should be filtering in tunnel mode. Listen mode only gives you a copy of the packet while passing the original one.
4) Can I open up multiple device adapter handles and set different filters for them so that simultaneous ReadPacket() calls return different packets based on the different filters?
Yes, you can open multiply adapters and set adapter specific filters.
5) Is there a way to not have to keep calling the ReadPacket() method inside of a loop? Like, set the adapter to execute a callback function when a new packet is on the buffer? This would support an event driven model which is much more efficient on the CPU.
Driver code can’t callback user mode code. If to be precise, you can execute a code in user mode part of the memory, but it can’t be safe (as packets arrive from the network at IRQL_DISPATCH_LEVEL but user mode memory can be paged out) and it also would be a security hole (as user mode code is executed with kernel mode privilege).
6) After reviewing your product documentation, I noticed there is no structure documentation for the Adapter structure that is used commonly throughout your product as an Integer Pointer Handle. You have all the other structures documented, why not this very important one? I figured it must be a common structure in NDIS, but after some research, I’m finding that driver developers start adding their custom fields to it. What is the WinpkFilter structure associated with individual Adapter handles, i.e “_ETH_REQUEST.hAdapterHandle” ?
This is internal WinpkFilter structure and it is not accessible from user mode (it is allocated from kernel memory).Thats why it is opaque.
