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: