Subject: kern/26581: IPF blocks legitimate packets due to incorrect TCP window check
To: None <gnats-bugs@gnats.NetBSD.org>
From: None <jdolecek@NetBSD.org>
List: netbsd-bugs
Date: 08/07/2004 14:32:08
>Number:         26581
>Category:       kern
>Synopsis:       IPF blocks legitimate packets due to incorrect TCP window check
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 07 12:31:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Jaromir Dolecek
>Release:        NetBSD 2.0G
>Organization:
>Environment:
System: NetBSD s102-n054.tele2.cz 2.0G NetBSD 2.0G (SARUMAN.MP) #193: Sat Aug 7 13:54:23 CEST 2004 dolecek@s102-n054.tele2.cz:/usr/home/dolecek/soft/netbsd/sys/arch/i386/compile/SARUMAN.MP i386
Architecture: i386
Machine: i386
>Description:
	IPF checks if outgoing/incoming packet is within TCP window
	of the last checked packet for keep-alive rules. This check
	apparently expects successive sequence numbers, which
	at least in some cases doesn't work very well. IPF then
	drops packets, which might cause e.g. send(2) from application
	to fail with error.
	
>How-To-Repeat:
	With rule like on the local system:

		pass out quick on fxp0 keep state

	The problem showed up on my system with cvs update from a remote
	server, such as:

	> cvs up sys
	Write error: Permission denied
	...
	>
	
	This was reliably repeatable for me, so I can easily re-run this
	if needed.
>Fix:
	Making fr_tcpinwindow() return always success (1) fixes things
	for me apparently. I do not know enough IPF internals to see
	if the check is really necessary - disabling it might as well
	cause some security problem.
	security problem.
>Release-Note:
>Audit-Trail:
>Unformatted: