August 1, 2008 at 5:26 am #5220
We are using WinpkFilter 3.0 to develop TCP/IP monitoring software.
We have observed that once the filter driver is installed, wireless adapters will fail to connect to a wireless access point and acquire an IP address via DHCP.
It occurrs on both Vista and Windows XP (x86). The problem is also exacerbated by consistent loss of connectivity on Windows XP when the network does function.
Additionally, while this is occassionally just an issue acquiring a connection, sometimes it results in a full lock-up of the system (which I understand could be a driver conflict)
My question is, how common are problems with wireless adapters? (I believe many wireless adapter software packages would incorporate TDI drivers)
And how can we identify what is causing these problems and subsequently fix them? What information do you need me to see about the computer configuration?
We need all adapters to function correctly and reliably with the driver installed…
Note: I have searched through the forums, and understand how to check and resolve issues with the use of the API and know to disable signed driver enforcement under Vista, but this is purely with just the driver installed.
Thanks for your time.August 1, 2008 at 9:07 am #6653
We are not aware about any problems with wireless adapters and WinpkFilter. However, please ensure that you are using the latest version of WinpkFilter.
Driver conflict with some other network software is possible and most usual problem of misbehave, details depend from what other third party low level network software you have installed on those systems.August 1, 2008 at 10:39 am #6654
How do we detect what the cause is, and how can we avoid having similar issues?
Do we try to isolate network providers? Bindings on Adapters? Disable device drivers such as WAN Miniport?
Currently 5 out of 10 different notebooks either fail to connect or lock up with the driver installed.
I am sure you understand that we cannot do this for each customer that has a different OS and/or wireless card. Would a custom build be able to remove these problems?
I am happy with the functionality the driver provides, but we are stuck on this problem.
Just looking for help…
Alternatively would the Local Network Monitor be a better option for monitoring and analysing network traffic?August 3, 2008 at 12:23 pm #6655
You still have not replied if you are using the latest WinpkFilter or ealier builds.
Try to e-mail us the list of installed drivers/softwares, this may sched some light.August 4, 2008 at 2:04 am #6656
Product name: Windows Packet Filter
* I have e-mail you the system information reports for two of the workstations.August 4, 2008 at 5:36 am #6657
Could you try to completely uninstall Symantec software and check if problem with WinpkFilter disappear? This would help to identify the problem.August 7, 2008 at 3:53 pm #6658
I have performed some experiments with wireless network adapter on Windows XP SP3 having Norton Internet Security installed. I can confirm that after installation of WinpkFilter NDIS IM driver wireless connectivity is lost. But it is restored after reboot. Sometimes network stack can’t be rebound dynamically and after installation of NDIS IM driver you may have to reboot. This probably the case your users have met with WinpkFilter (both reported cases had Symantec software installed).August 8, 2008 at 1:03 am #6659
Thanks for the investigation you have performed. It is often difficult for us to ask and assist customers to uninstall existing software from their machines to help diagnose problems.
On our side we have tracked down the second half of this problem to a line of code in our application. Once that line of code was executed, an adapter could no longer have its DHCP assigned IP address renewed. For example:
The problem would then remain until the network device is reset or the machine is rebooted (even after the driver is closed and the application is shutdown). The code we are using to manage a network adapter is as follows:
public Adapter(IntPtr hDriver, IntPtr hAdapter)
_buffer = new INTERMEDIATE_BUFFER();
_ptrBuffer = Win32Helper.Malloc(Marshal.SizeOf(_buffer));
_request = new ETH_REQUEST(hAdapter, _ptrBuffer);
_event = new ManualResetEvent(false);
ADAPTER_MODE mode = new ADAPTER_MODE(hAdapter, (uint) (MSTCP_FLAG.MSTCP_FLAG_SENT_LISTEN | MSTCP_FLAG.MSTCP_FLAG_RECV_LISTEN));
/* Ndisapi.SetHwPacketFilter Locks adapter until reset */
Ndisapi.SetHwPacketFilter(hDriver, hAdapter, (uint) NDIS_PACKET_TYPE.NDIS_PACKET_TYPE_DIRECTED);
Ndisapi.SetAdapterMode(hDriver, ref mode);
Ndisapi.SetPacketEvent(hDriver, hAdapter, _event.SafeWaitHandle);
Once we commented out the ‘Ndisapi.SetHwPacketFilter’ line the problem disappeared. Having reviewed the sdk sample code, I can see that SetHwPacketFilter is only used to set and restore the device from promiscuous mode; nevertheless, I wouldn’t have expected that outcome.August 8, 2008 at 5:52 am #6660
NDIS_PACKET_TYPE_DIRECTED limits packets received to only packets having the destination MAC address equal to local system MAC address. You have also to allow broadcast packets to let the system function normally:
NDIS_PACKET_TYPE.NDIS_PACKET_TYPE_DIRECTED | NDIS_PACKET_TYPE.NDIS_PACKET_TYPE_BROADCAST
You must be logged in to reply to this topic.