From: Ludwig Nussel <ludwig.nussel@suse.de>
To: netfilter-devel@lists.netfilter.org
Subject: Re: TCP window tracking has bad side effects
Date: Wed, 1 Dec 2004 16:39:03 +0100 [thread overview]
Message-ID: <20041201153903.GA16807@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0412011308520.27175@blackhole.kfki.hu>
[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]
Jozsef Kadlecsik wrote:
> On Wed, 1 Dec 2004, Ludwig Nussel wrote:
> > 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 end must send an ACK segment which is in the window (see
> RFC793, p68), thus the window tracking code could let it through.
My description probably wasn't unambiguous. The client has the
packetfilter, crashes and reboots. The server does not notice and
just sees an out of sequence SYN for an existing connection (same
ip/port). The server responds with an ACK which contains the
sequence numbers it expects for that connection (p36 in above cited
rfc). On the client side this ACK does not belong to the SYN it sent
and is discarded whereas it should be answered with RST.
> > 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?
>
> Yes, you can disable it anytime:
>
> echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
Doesn't help.
> But a full tcpdump from such a session and the log entries on the
> invalid packets would be useful for us to recheck the code.
tcpdump file attached. 192.168.42.1 is the server and 192.168.42.2
the client with packetfilter.
The log of a dropped ACK packet looks like this:
SRC=192.168.42.1 DST=192.168.42.2 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=26022 DF PROTO=TCP SPT=9999 DPT=8888 WINDOW=1448 RES=0x00 ACK URGP=0 OPT (0101080A015EB588FFFD6ED1)
cu
Ludwig
--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/
[-- Attachment #2: tcpdump46818 --]
[-- Type: application/octet-stream, Size: 975 bytes --]
next prev parent reply other threads:[~2004-12-01 15:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-01 11:02 TCP window tracking has bad side effects Ludwig Nussel
2004-12-01 12:16 ` Jozsef Kadlecsik
2004-12-01 15:39 ` Ludwig Nussel [this message]
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=20041201153903.GA16807@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.