[Vadim Smirnov]

I am not touching the ACK/SYN at all, I am modifying the ip_len and the payload only. that too, if the packet has payload then only i am modifying the packet.

If you change length of the TCP packet then you should modify SYN/ACK fields.

Is there any way I can drop the old packet? How can I remove it from the local stack?

Actually you already drop the original packet, but system generates it again and again (because your invalid packet is droped by remote system).

[Vadim Smirnov]

Probably you modify TCP packet and do this wrong. Destination system drops your packet and don’t send ACK for it, thats why your local stack sends packet again after some timeout.

[Vadim Smirnov]

You can try using MSTCP_FLAG_LOOPBACK_BLOCK for the adapter you work over. It drops incoming packets if source MAC is the same as local MAC. Regretfully there is no way to prevent packet indication on NT4 at all.

[Vadim Smirnov]

Personally I use this one

//
// Function recalculates IP checksum
//
VOID
RecalculateIPChecksum (
iphdr_ptr pIpHeader
)
{
unsigned short word16;
unsigned int sum = 0;
unsigned int i = 0;
PUCHAR buff;

// Initialize checksum to zero
pIpHeader->ip_sum = 0;
buff = (PUCHAR)pIpHeader;

// Calculate IP header checksum
for (i = 0; i < pIpHeader->ip_hl*sizeof(DWORD); i=i+2)
{
word16 = ((buff<<8)&0xFF00)+(buff[i+1]&0xFF);
sum = sum+word16;
}

// keep only the last 16 bits of the 32 bit calculated sum and add the carries
while (sum>>16)
sum = (sum & 0xFFFF)+(sum >> 16);

// Take the one’s complement of sum
sum = ~sum;

pIpHeader->ip_sum = htons((unsigned short) sum);
}

[Vadim Smirnov]

#define NDIS_FLAGS_DONT_LOOPBACK 0x00000080

[Vadim Smirnov]

NDIS_FLAGS_DONT_LOOPBACK and NDIS_FLAGS_SKIP_LOOPBACK prevents the packet from being indicated back. However, these flags are OS/NDIS specific. You can see some details here http://www.ndis.com/papers/loopback.htm

[Vadim Smirnov]

Could you please post the rule you have created and short description what it is supposed to do, probably there is something wrong with it.

[Vadim Smirnov]

Why only TCP/IP adapters can be filtered?

It is by driver design. However, driver can be extended to work below other protocols in addition to TCP/IP.

For example, you can add some flag to internal structure of packet in driver code and when program try send non TCP/IP packet to stack, driver can detect this by flag and just drop this packet…

TCP/IP is the primary protocol in the meantime and WinpkFilter main purpose is modification of it’s behaviour on different ways (firewall, NAT, VPN and etc…). Filtering absolutely all protocols on the system would cause a real mess and perfomance degradation (protocols can be joint into the stacks in the form of IM drivers, like the bridge you have mentioned).

[Vadim Smirnov]

WinpkFilter driver works between TCP/IP stack and it’s bound adapters, it does not filter non TCP/IP interfaces. As I understand you miss packets which are routed by network bridge and never reach TCP/IP stack. This is just how it should work.

However, driver can be modified to additionally support filtering between the bridge and real network interfaces below the bridge, it just requires some modifications in driver itself. If you own Source Code license you can easily do required modifications yourself, I think it should be enough to add network bridge protocol name to the list of filtered protocols.

[Vadim Smirnov]

Could you please provide more details? What OS you have expirienced this behaviour with? Is it incoming or outgoing ARP request? What network media do you use. Have you seen four response packets in WinpkFilter of using any network sniffer?

[Vadim Smirnov]

Where can I get the “virtual network interface” you mentioned ? Is it part of windows ?

Windows has built-in virtual loopback adapter, but you can make your own using one of the DDK samples.

[Vadim Smirnov]

In the meantime WinCE is not supported. There is a chance that it will be supported in the future if there is enough interest to this.

[Vadim Smirnov]

Hello Roelof,

WinpkFilter drivers works on the bottom of the Windows network stack (below TCP/IP), but application layer of Windows XP firewall works on the top of network stack (otherwise it won’t be able to control applications network access). So I don’t think that there is any easy solution to this problem.

However, may be setting up the virtual network interface, disabling Windows firewall for it and bridging it to the real network interface using WinpkFilter can solve the problem. It’s just the first idea, may be some other tricks are also possible…

Hope it helps…

[Vadim Smirnov]

You can also use medium type. See parameters passed/returned to/from NdisOpenAdapter: SelectedMediumIndex, MediumArray.

[Vadim Smirnov]

There is also a chance that you system is heavily loaded and user mode application can’t read driver log fast enough. In this case driver’s internal packet log is overloaded and it may drop some data blocks.

[Author]

Posts