[Vadim Smirnov]

The code above do the following:

1) Release event for packet indication.
2) Set adapter into passthru mode (the state it was before you set TUNNEL mode).
3) Flush packet queue associated with the adapter.

For temporary stop filtering: 1 – is not necessary, 2 – should be be done, otherwise (if you exited the loop) the network will be forzen after all WinpkFilter internal buffers are used, 3 – should be done because if you have existed packet reading loop, to that moment you can have internal buffer pool exosted and the network frozen.

So, in addition to exiting the loop you should set the default mode over the interface and flush its packet queue. If you want to restore filtering, then set tunnel mode and enter the loop again.

[Vadim Smirnov]

Please pay attention to the routine below (it is available in PassThru and PacketSniffer samples), which actually stops WinpkFillter operations over the network interface and releases resources:

void ReleaseInterface()

{

// This function releases packets in the adapter queue and stops listening the interface

ADAPTER_MODE Mode;



Mode.dwFlags = 0;

Mode.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[iIndex];



// Set NULL event to release previously set event object

api.SetPacketEvent(AdList.m_nAdapterHandle[iIndex], NULL);



// Close Event

if (hEvent)

CloseHandle ( hEvent );



// Set default adapter mode

api.SetAdapterMode(&Mode);



// Empty adapter packets queue

api.FlushAdapterPacketQueue (AdList.m_nAdapterHandle[iIndex]);

}

[Vadim Smirnov]

1) First issue with direct NDIS_OPEN_BLOCK modification works just like you have described. The only fix is hooking internal NDIS-routines and repatching the NDIS_OPEN_BLOCK each time when handlers are changed,

2) The second approach with substitution on NDIS_OPEN_BLOCK works fine, and in your case problem is somethere else, lines you have provided look OK.

In general NDIS hooking driver is relatively complicated and it is difficult to design such a driver from the scratch. So I would recommend to use one of the documented approaches (intermediate, filter hook or etc…) or license ready NDIS hooking solution instead of trying to create the new one.

[Vadim Smirnov]

Please refer DDK samples, it contains everything you need.

[Vadim Smirnov]

If you ask about WinpkFilter, then you can do it using the SendPacketToMstcp (if you want packet to be indicated from the name of another interface to the local TCP/IP stack) and SendPacketToNetwork (if you want it to be sent over the network from the interface different from received one). For both calls you should use corresponding network interface handles, both routines can be called with difefrent handles for the same packet any times you want. One note, if you want to bridge WAN interface you should also modify MAC addresses in the packet (this is point-to-point connection and MAC’s are used to distinguish different connections), otherwise NDISWAN won’t be able to find the corresponding link and may even crash the system…

[Vadim Smirnov]

I’m afraid no way without additional tricks like TDI filter driver.

[Vadim Smirnov]

The information was sent. Thank you for your interest.

[Vadim Smirnov]

Yes, we are sorry. but older versions (before 2.4 series) may have problems when running on Windows XP SP2. It does not mean that you MUST have problems, but it is possible and depends of your software/hardware configuration.

[Vadim Smirnov]

WinpkFilter installation scripts (for Windows 2000/XP/2003) were updated in order to support compatibility with the latest released version of Kerio Personal Firewall. Details: Group:”Network” Start:0 were changed to Group: “Streams Drivers” Start:1.

[Vadim Smirnov]

WinpkFilter 2.4.1 released. This service release improves WinpkFilter support for some network interfaces (an example BUFFALO LPC4-CLX Fast Ethernet Adapter) under Windows 2000 and Millennium Edition. MS Visual Basic samples were also moved into the main package.

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

[Vadim Smirnov]

You should link ndisapi.lib.

[Vadim Smirnov]

Hmm, but which IOCTL’s you are interested in? An example, do you need capture IOCTL’s over DeviceIp and DeviceMULTICAST? These devices also allow sending packets; an example DeviceIp is used for sending ICMP packets (ping.exe->ICMP.DLL->DeviceIp). But in general I don’t think that you really need all that stuff.

[Vadim Smirnov]

The firewalls you have mentioned use NDIS-hooks and I don’t think that their drivers are WHQL certified. An example, ZoneAlarm uses technology based on some undocumented NDIS structures which can be changed by MS anytime. Do you think that such driver can be WHQL? However, NDIS hooks is still the most effective way to desigh the firewall kernel, and that fact that MS officially don’t recommend this is not enough to stop using it.

[Vadim Smirnov]

Hardly likely that NDIS-hooking driver can be WHQL, but I don’t know for sure. In any case the question of certification is usually the question of money you can pay for it. In order to avoid additional problems I think you will need to create NDIS IM driver for XP if you really need certication.

[Vadim Smirnov]

Normally TCP/IP for the Ethernet uses the following flags combination:

NDIS_PACKET_TYPE_BROADCAST | NDIS_PACKET_TYPE_DIRECTED | NDIS_PACKET_TYPE_MULTICAST;

I’m not sure how usage of NDIS_PACKET_TYPE_ALL_LOCAL breaks the functionality but the request to set this filter is sent directly to the NDIS. However, why do you need this filter? Is there any OS dependence where filter works (an example works on XP but don’t work on Windows 2000)?

P.S. Please confirm that you have received your order, since it may appear that our e-mails can’t reach you.

[Author]

Posts