diff options
| author | Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> | 2007-11-05 12:37:55 +0100 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2007-11-16 08:27:38 -0800 |
| commit | 0ac38060c5e1e12e851ed3e281597286b57f9ad1 (patch) | |
| tree | 2ea94fa104107a9589abec322045b77739b5fdbf /drivers/net/ibm_emac/ibm_emac_debug.c | |
| parent | c6736fd46ba478b59f8293457648432154f0f422 (diff) | |
NETFILTER: nf_conntrack_tcp: fix connection reopening
Upstream commits: 17311393 + bc34b841 merged together. Merge done by
Patrick McHardy <kaber@trash.net>
[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>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/net/ibm_emac/ibm_emac_debug.c')
0 files changed, 0 insertions, 0 deletions