WinpkFilter 3.0: Wireless Access Failure

[Methusaleh]

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.

[Vadim Smirnov]

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.

[Methusaleh]

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?

[Vadim Smirnov]

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.

[Methusaleh]

Product name: Windows Packet Filter
File: ndisapi.dll
Version: 3.0.4.1

* I have e-mail you the system information reports for two of the workstations.

[Vadim Smirnov]

Could you try to completely uninstall Symantec software and check if problem with WinpkFilter disappear? This would help to identify the problem.

[Vadim Smirnov]

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).

[Methusaleh]

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:

ipconfig /release

followed by:

ipconfig /renew

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.

[Vadim Smirnov]

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

[Author]

Posts