Mailing List Archive: BUGs at tcp state transition?

BUGs at tcp state transition?

Sep 17, 2007, 6:43 PM

Post #1 of 3 (8523 views)

Hi, all.
When I tested 2.6.20.16, found something strange. The following is
the test case:
1. Establish a connection between client and server [Client and Server
in EST state]
2. Power down server [ client in EST state ]
3. CTL+C the client. client should invoke close() API, and send FIN. [
FW state]
4. client retransmit the FIN due to timeout [ Now, FW -> LAST_ACK ]
Here the bug happens. FW is a active close state, but LAST_ACK is a
passive close state. The correct state is FW -> FW. The ip_conntrack TCP
state is wrong!

Also I looked the kernel source. And found the bug.
ip_conntrack_proto_tcp.c at line 201

/*fin*/ { sIV, sIV, sFW, sFW, sLA, sLA, sLA, sTW, sCL, sIV },
/*
* sNO -> sIV Too late and no reason to do anything...
* sSS -> sIV Client migth not send FIN in this state:
* we enforce waiting for a SYN/ACK reply first.
* sSR -> sFW Close started.
* sES -> sFW
* sFW -> sLA FIN seen in both directions, waiting for
* the last ACK.
* Migth be a retransmitted FIN as well... [ Wrong
state!!!]

It's easy to check a FIN packet is a restransmitted packet or not, but
we need check every TCP packet in tcp_packet() function, Its performance
is too bad. I don't like this. Anyone can give a good solution?

Thanks in advance :)

BR. Wei Dong

Re: BUGs at tcp state transition? [ In reply to ]

kadlec at blackhole

Sep 18, 2007, 2:05 AM

Post #2 of 3 (8134 views)

Permalink

Hi,

On Tue, 18 Sep 2007, Dong_Wei wrote:

> When I tested 2.6.20.16, found something strange. The following is the test
> case:
> 1. Establish a connection between client and server [Client and Server in EST
> state]
> 2. Power down server [ client in EST state ]
> 3. CTL+C the client. client should invoke close() API, and send FIN. [ FW
> state]
> 4. client retransmit the FIN due to timeout [ Now, FW -> LAST_ACK ]
> Here the bug happens. FW is a active close state, but LAST_ACK is a passive
> close state. The correct state is FW -> FW. The ip_conntrack TCP state is
> wrong!
>
> Also I looked the kernel source. And found the bug.
> ip_conntrack_proto_tcp.c at line 201
>
> /*fin*/ { sIV, sIV, sFW, sFW, sLA, sLA, sLA, sTW, sCL, sIV },
> /*
> * sNO -> sIV Too late and no reason to do anything...
> * sSS -> sIV Client migth not send FIN in this state:
> * we enforce waiting for a SYN/ACK reply first.
> * sSR -> sFW Close started.
> * sES -> sFW
> * sFW -> sLA FIN seen in both directions, waiting for
> * the last ACK.
> * Migth be a retransmitted FIN as well... [ Wrong
> state!!!]

Yes, that's true. But we keep only one state in the conntrack entry, and
therefore just from the state table we cannot figure out wether the packet
is a retransmitted FIN or a FIN from the other direction.

> It's easy to check a FIN packet is a restransmitted packet or not, but
> we need check every TCP packet in tcp_packet() function, Its performance
> is too bad. I don't like this. Anyone can give a good solution?

The effect of the bug is that instead of keeping a 2min timer, we start a
shorter, 1min one and when it goes off, we may destroy the conntrack entry
prematurely. Then some late FIN/ACK packets might be detected as invalid
ones by conntrack.

Similarly to the efforts we make to detect reopened and half-open
connections, we could check retransmitted FINs. But is it worth?

Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary