Forum Replies Created
-
Posts
-
if (packet.source == x.x.x.x || packet.destination == y.y.y.y) then forward(packet, ipdest).
Is that possible to define this kind of rules with the WinpkFilter framework ?
Yes, this is possible. However you have to write the forwarding code by yourself.
I noticed that some virtual interfaces don’t appear in the adapters list (such as ms loopback adapters). In spite of it, could I be able to forward packets to a virtual interface ?
WInpkFilter NDIS IM driver binds only to ethernet and wan media (defined by FilterMediaTypse in INF files). Probably Microsoft Loopback adapter specifies his media as nolower. It is possible to change WInpkFilter INF files to bind to this type of network interfaces, although I find this unsafe (as you may bind to intarfaces you don’t need at all). The safer way is using different virtual network interface like VirtNet available on this web-site. VirtNet declares itself as ethernet interface.
Finally, I already have an application that should integrate this new functionnality. Is there a difference in terms of performance between kernel or user mode for this kind of application ?
Of course kernel mode implementation is faster. You don’t have to waste processor cycles for transition packets from user to kernel and back. However, CPU on desktop computers these days are powerful enough to smooth the difference.
As far as i can see during the winpkflt installer there is some reading and writing of registry keys done. Is there any need for particular registry settings for getting the drivers working?
These registry operations are done by DriverSigning utility which disables WHQL signature requirement if this is enabled. This is actual for Windows XP/2003 and allows to avoid unnecessary warnings.
But installing the drivers with the snetcfg.exe does not work for me 🙁
If installer does install successfully but you can’t do the same when calling snetcfg manually then may be this is about privileges your command line has? Try to start CMD as administrator.
If installation fails them something is definitely wrong with driver signing. We have customers who initially have signed drivers following Microsoft guide, but something was missed and installation failed.So far each such case was successfully resolved. Try to install signed drivers manually (through the Local Area Connection properties) to see if system complains on signing.
Note, that for the NDIS IM drivers you have to sign both CAT file and driver binary (embedded signature). May be this the case.
Creating an absolutely silent installation is possible, but prior to installing driver you have to install your certificate as trusted one. In this case system won’t ask user if he trusts the particular vendor during driver install process. This is not recommended by Microsoft. though.
I think TDI driver you have installed just does not support Windows 7 and 2008 R2. You have to get an updated one.
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.
