Forum Replies Created
-
Posts
-
Исходники wwwcensor включены в дистрибутив, можете их найти среди msvc примеров.
Ваша задача так же решаема, но невозможно же в самом деле написать пример под каждый конкретный случай 😉
I’m sorry for the delayed response. I’ve been away for the New Year holidays.
I have generated the new netcfgInstanceId , change it in my inf file and my filter driver is properly installed but it is connected with another machine and not able to communicate with each other.
Besides changing netcfgInstanceId in INF file you also have to change it in common.h and rebuild the driver from the source code. Have you rebuilt the driver?
And again, your manipulations with Characteristics value are incorrect.
Vikash,
Could you describe all the steps you did to customize and install the driver? The more complete details the better, I can’t make a guess from your short description.
@vikashm05 wrote:
1)How generate new GUID .
You can use guidgen utility to generate new GUID.
@vikashm05 wrote:
2)How to change it in winpk filter after generating a new GUID :
Change INF file and string in common.h. Then just rebuild LWF drivers.
Windows Packet Filter Kit 3.1 released:
– LWF driver updated according Windows 8 requirements
– Added VLAN tagging 802.1Q
– Added IPv6 support for built-in filtersBug fixes:
– Incorrect spinlock acquire in LWF driver
– Adapter list changed event in LWF driverIf you are eligible for a free update, please send the following details to support@ntkernel.com tо receive an update instruction:
1) Your order ID.
2) An approximate date of purchasing.You should use 0x40000 for LWF driver for system to install and start driver properly.
To eliminate compatibility issue with original standard WinpkFilter LWF you have to generate new GUID and replace it in both
NetCfgInstanceId present in my INF file is NetCfgInstanceId=”{5cbf81bd-5055-47cd-9055-a76b2b4e3697}”
and
#define FILTER_UNIQUE_NAME L”{5cbf81bd-5055-47cd-9055-a76b2b4e3697}” //unique name, quid name
Then rebuild LWF driver.
From your post it is not clear what kind of driver do you try to install along with WinpkFilter. Is it NDIS LWF, NDIS IM or protocol driver?
Characteristics to use in INF depend on the type of your driver. For Windows Vista and higher WinpkFilter installs NDIS LWF filter driver and corresponding Characteristics value is NCF_LW_FILTER = 0x40000.
You are using NCF_NDIS_PROTOCOL|NCF_FILTER|NCF_NO_SERVICE = 0x4410, which an example can be used for the protocol part of NDIS IM driver.
So, if you are trying to install NDIS LWF driver you have to use NCF_LW_FILTER, if NDIS Intermediate then NCF_NDIS_PROTOCOL|NCF_FILTER|NCF_NO_SERVICE.
If you are trying to create the custom build of WinpkFilter NDIS LWF then besides changing driver name please note to generate new GUID to be used in common.h and in INF file (NetCfgInstanceId). This value uniquely identifies filter driver instance.
NDIS-hook driver intercepts the particular binding between TCP/IP and network interface, while NDIS IM and LWF drivers intercept all bindings (between all installed protocols and network adapters). This explains the different behaviour.
By the way, what version of VMWare are you using? In the neighbor thread of the forum we are discussing another example of VMWare behavior, although your problem were not reproduced.
Most probably this is VMWare bridge, in order to support bridging of guest OS it has to put real network interface into promiscuous mode and has to filter out loopback indications. Since packets are repackaged by WinpkFilter it may miss to recognize loopback and reroute it. I have experienced similar problems when experimented with ethernet bridging. There is another post on forum regarding VMWare, so I plan to do some tests with it. By the way, do you experience any problems in getting IP address for the guest vmware OS bridged to real NIC?
From what I can see each outgoing echo request is looped four times. Probably this caused by loopback packet indication when outgoing packet sent from one protocol is indicated back to all installed protocols (without this functionality wireshark would not be able to collect outgoing packets). And in your test loopback packet is routed back into the network (note the decreased ttl). Difficult to say who has routed the packet as WinpkFilter does not implement routing but WinpkFilter repackages network packets and one of the installed network components may fail to recognize the packet it just sent out and rerouted it. What network components do you have installed? Here I mean protocols drivers like winpcap and various virtual machine bridge and NAT components? Details in the network configuration also may help.
I had not heard about such issues before, however I think it can be related to filter layering with VMWare bridging driver which is also probably implemented as NDIS LWF or NDIS IM driver. In order to support virtual network adapter with its own MAC address VMWare bridging driver probably puts real hardware NIC into promiscuous mode and clone received packets to virtual NIC inside VMWare. Here you probably have a sort of conflict between filter drivers, when packets for virtual NIC MAC address are not delivered to VMWare driver. Could you try uninstall VMWare, reboot and reinstall while keeping Winpkfilter installed? It may change drivers layering and fix the issue.
