Bug with conntracks created arbitrarily through netlink

[Luca Landi <l.landi@gif.it>]

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.