All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ludwig Nussel <ludwig.nussel@suse.de>
To: netfilter-devel@lists.netfilter.org
Subject: TCP window tracking has bad side effects
Date: Wed, 1 Dec 2004 12:02:55 +0100	[thread overview]
Message-ID: <20041201110253.GA9536@suse.de> (raw)

Hi,

Recent state matching code apparently added some kind of TCP window
tracking which marks out of sequence packets as INVALID.

Previously one could use some minimal filter rules like this on a
client machine:

iptables -F 
iptables -X 
iptables -P INPUT DROP 
iptables -P FORWARD DROP 
iptables -P OUTPUT ACCEPT 
iptables -A INPUT -j ACCEPT -i lo 
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED 


With TCP window tracking those rules no longer work for services
that use fixed ports (e.g. NFS) and one side crashes or terminates
the connection in other ways without notifying the peer (e.g. link
down). When the crashed machine comes up again and tries to
reestablish the connection it sends a SYN. The remote end finds that
confusing and replies with an ACK as probe. Since that ACK does not
fit any window it's discarded as INVALID. The remote side can now
sit there forever sending ACKs and no new connection can be
established. Previously, without window tracking, the ACK was
accepted and answered with RST, the remote closed the connection and
a new one could be established. 

Is there a way to disable the window tracking and revert to the old
behavior?

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE LINUX AG, Development
 V_/_  http://www.suse.de/

             reply	other threads:[~2004-12-01 11:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-01 11:02 Ludwig Nussel [this message]
2004-12-01 12:16 ` TCP window tracking has bad side effects Jozsef Kadlecsik
2004-12-01 15:39   ` Ludwig Nussel
2004-12-03  8:44     ` Jozsef Kadlecsik
2004-12-06  8:35       ` Jozsef Kadlecsik
2004-12-09 16:26         ` Ludwig Nussel
2004-12-10 10:03           ` Jozsef Kadlecsik
2004-12-10 20:32             ` David S. Miller
2004-12-10 22:14               ` Jozsef Kadlecsik
2004-12-10 17:22           ` Bill Rugolsky Jr.
2004-12-10 19:42             ` Jozsef Kadlecsik
2004-12-10 19:51             ` David S. Miller
2005-01-10 17:13               ` Jan Du Caju
2005-01-10 17:16                 ` Phil Oester
2004-12-02  0:54   ` Phil Oester

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041201110253.GA9536@suse.de \
    --to=ludwig.nussel@suse.de \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.