Forum Replies Created
-
Posts
-
I had some time over the weekend to play with with bridging WiFi and one of the possibilities is enabling Link Layer Discovery Protocol, with the configuration below Wi-Fi adapter without IP address was successfully bridged to the wired network:
Hmm, interesting case. I don’t have a quick answer because I have never tried this kind of setup. If I have some spare time over the weekend I will give it a try.
For the sample code you can check the Ethernet Bridge source where promiscuous mode is used:
Check the line 208 in https://github.com/wiresock/ndisapi/blob/master/examples/ethernet_bridge/EthernetBridge.cpp
I have had one recent similar report regarding Windows 10 Enterprise. And it may happen that Microsoft has reinforced driver signing requirements for the Enterprise editions of Windows (code signing certificate expiry is validated against the install date instead signing date). Will check when have some spare time.
The driver is production signed, so you should not have digital signature problems with installing it. Do you use the driver build from amd64 folder?
Driver version returned by CNdisApi::GetVersion() is: 34025472
In hex this is 0x02073000 or version 3.2.7.
And if NDISAPI returns this value then it definitely means that driver is loaded!
Source code for latest version of ndisapi with a couple of new samples is now available on Github. I’ve just tested dnstracer with and and without WinpkFilter driver installed and availability of the driver was reported properly (so the calls to CNdisApi::IsDriverLoaded worked correct).
What was the Windows version you have tested? I’m not sure, but if you use NCF_HIDDEN attribute for your driver build then it may also affect netcfg output.
block the list of ip addresses which is ddosing us
WinpkFilter built-in filters allow IP address based blocking.
You could use WinpkFilter library to redirect UDP packets for processing in user mode and pass everything else. In your application you can implement any sort of analyses for redirected UDP (including sub string search and etc. ) packets and decide to block/pass or even modify them.
Sure, it is possible using built-in WinpkFilter filter engine if the criteria for the packets is not too complex (UDP packets with particular IP/port information). If you need something more complex you can redirect UDP packets for the processing in the application and block the rest in the kernel.
If two different application operate on different network adapters then yes, they can share single filter driver. Otherwise, no because there is only one copy of the packet in the driver.
So you have two choices, build your filtering engine as a dedicated service process and use from two different applications, or build two different filter drivers, one per application. First approach probably better from the performance point of view.
WinpkFilter 3.2.16.1 update:
- Fixed SetAdaptersStartupMode behavior
- Fixed NdisrdRequest behaviour in WOW64 mode
If you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:
Your order ID.
An approximate date of purchasing.
