Forum Replies Created
-
Posts
-
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.
Could you provide more details in regards to network configuration. Who assigns IP address to your internet connected network adapter? By other words, is Internet network adapter connected directly to ISP or through the router/NAT wchich assigns IP addresses over DHCP? Does it changes anything if you manually assign an IP address to network adapter inside VNWare OS?
At the moment we don’t have plans to update DeviceFilter for Windows 7. Regretfully this requires serious research but market demand for such tools is too low to compensate the development efforts.
Yes, you have to recalculate checksums if modify the packet content. What code do you need? Checksum recalculation?
Probably the easiest way is resetting the TCP session which tries to fetch the image you would like to block. Manipulations with HTTP server responses is far more complex task.
Philip,
That depends on the functionality you expect from your captive portal. iGateway is a simple NAT solution. What problems have you expirienced with it?
Yes, this is possible using WinpkFilter. You can bridge VirtNet adapter to the real network with WinpkFilter or emulate virtual network with WinpkFilter. However, note that if you use bridging and want your real card to receive packets for the VirtNet card MAC address then your real card must be in promiscuos mode.
If I understand you right you have two WAN connectons, need to distinguish them on packet level and match against the WAN link from the control panel?
In Windows multiply WAN connections can be established through NDISWANIP interface, on the packet level they can be distinguished my their MAC addresses. Regretfully, there is no strighforward way to match WAN link to the WAN connection name in the control panel. However, it can be done through quick packet analyses. You can get source IP address from the packet and match it against against the connection using IP helper/RAS API. Each WAN link has a single IP address assigned and it uniquly identifies the connection.
