Forum Replies Created
-
Posts
-
I would advise you to check if ndisapi.dll built with MinGW really exports required functions. May be project needs some rework to be properly used with MinGW.
Yes, filters allow you to reduce the number of packets indicated to user mode for processing thus improving overall performance.
Note, that only unmanaged block of memory can be passed to WinpkFilter driver. To simplify marshalling STATIC_FILTER_TABLE for C# is declared to contain fixed size array of filters (256).
//
// Static filters table to be passed to WinpkFilter driver
//
[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct STATIC_FILTER_TABLE
{
public uint m_TableSize; // number of STATIC_FILTER entries
[MarshalAs(UnmanagedType.ByValArray,SizeConst=256)] // For convinience (easier marshalling to unmanaged memory) the size of the array is fixed to 256 entries
public STATIC_FILTER[] m_StaticFilters; // Feel free to change this value if you need more filter entries
}So in order to fix the marshalling error you have to change your code like this:
pFilters.m_TableSize = 7;
pFilters.m_StaticFilters = new STATIC_FILTER[256];You pass 256 filters to drivers but only 7 are valid as indicated by pFilters.m_TableSize
Hmm, link errors look like you have different name mangling in DLL and application. Strange issue if you have rebuilt both projects with the same compiler. May be you have to do some changes to NDISAPI.DLL to build properly with MinGW. Regretfully,I have never used MinGW and I can hardly advise how to persuade it to make proper linkages.
You may consider using C interface instead C++ one, it won’t have problems like this.
3G modem won’t appear in the list as dedicated network adapter, but you will see an active WAN link under NDISWANIP network interface when connection is established.
The link seems to be correct however, because if I don’t do this I have one more error. Any idea to fix this error ?
Try to rebuild ndisapi.dll with your compiler and then link to your application. Different C++ compilers use different name mangling for C++.
I also have another question : I ran listadapters.exe and it shew me a list of interfaces. Then, I plugged a 3G key and ran again the program : it shew me the same list as before. Is this normal ?
In Windows all WAN devices are visible as NDISWANIP virtual Ethernet interface, so adding another modem does not change the list of adapters. If you establish the connection using 3G modem you will see it in the list of the active WAN links.
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 🙄
