From: Patrick McHardy <kaber@trash.net>
To: Luca Landi <l.landi@gif.it>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Bug with conntracks created arbitrarily through netlink
Date: Wed, 24 Sep 2008 20:00:53 +0200 [thread overview]
Message-ID: <48DA8055.8070501@trash.net> (raw)
In-Reply-To: <1222278224.8300.87.camel@quasar>
Luca Landi wrote:
> Hello everybody,
>
> I think I have found a bug with conntracks created by userspace through
> netlink. The bug resides in the kernel.
>
> Basically, when you create a new conntrack through netlink, you normally
> do so in advance. That is, before any actual packet of that connection
> arrives (or goes out). (Sidenote: in fact honestly I can't think of
> situations where one would want to manually create a conntrack truly
> after the connection to be tracked was already in progress, and also I
> guess that that would be anyway impossible as such a conntrack would
> have been created automatically by the kernel).
>
> Anyway, as such manual in-advance creation (through netlink) does not go
> through the L4 initialization normally done by l4proto->new() (as well
> as all the other things done by init_conntrack()), this at least in the
> case of a TCP connection does affect tcp_in_window() in that when it
> sees the first ever packet for that connection (normally the SYN),
> tcp_in_window() regardlessly goes through the
> "i-am-in-the-middle-of-a-connection" codepath, not syncing properly with
> the window. The outcome is that after some kbytes of data transferred,
> tcp_in_window() starts rejecting packets. In case of nat-ed connections
> this also means that packets won't be nat-ed any more. Seen all this
> happening live myself.
>
> I already went through the analysis of the relevant kernel code, spotted
> what happens exactly at every stage, and found (and tested successfully)
> a possible fix. Just wondered whether you knew this already and had a
> good argument for it. I know about the "be-liberal-with-windows" flag,
> which might be considered as a ready workaround, but I thought we could
> and should do better for this case. What do you think?
>
> PS: I'm using ubuntu 8.04 and working with its official kernel. At a
> superficial glance at the latest stable from kernel.org it seems to me
> that the problem is still there. Blame me if I am mistaken.
We're automatically enabling the be-liberal logic for picked up
connections nowadays, so you shouldn't get out of window packets.
Which kernel does ubuntu 8.04 use?
next prev parent reply other threads:[~2008-09-24 18:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 17:43 Bug with conntracks created arbitrarily through netlink Luca Landi
2008-09-24 18:00 ` Patrick McHardy [this message]
[not found] ` <1222287997.6546.22.camel@quasar>
2008-09-24 20:41 ` Patrick McHardy
2008-09-25 8:56 ` Luca Landi
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=48DA8055.8070501@trash.net \
--to=kaber@trash.net \
--cc=l.landi@gif.it \
--cc=netfilter-devel@vger.kernel.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.