diff options
author | Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> | 2007-10-11 14:35:52 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2007-10-11 14:35:52 -0700 |
commit | 17311393f969090ab060540bd9dbe7dc885a76d5 (patch) | |
tree | cc8f9a460679870c51b194c8927f998b243a98f7 /net/netfilter/xt_CLASSIFY.c | |
parent | d71fce6b932d83e0a1caa49dfa5a536fd50f07c9 (diff) | |
download | op-kernel-dev-17311393f969090ab060540bd9dbe7dc885a76d5.zip op-kernel-dev-17311393f969090ab060540bd9dbe7dc885a76d5.tar.gz |
[NETFILTER]: nf_conntrack_tcp: fix connection reopening
With your description I could reproduce the bug and actually you were
completely right: the code above is incorrect. Somehow I was able to
misread RFC1122 and mixed the roles :-(:
When a connection is >>closed actively<<, it MUST linger in
TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
However, it MAY >>accept<< a new SYN from the remote TCP to
reopen the connection directly from TIME-WAIT state, if it:
[...]
The fix is as follows: if the receiver initiated an active close, then the
sender may reopen the connection - otherwise try to figure out if we hold
a dead connection.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/netfilter/xt_CLASSIFY.c')
0 files changed, 0 insertions, 0 deletions