BUGs at tcp state transition?

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

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  : kadlecblackhole.kfki.hu, kadlecsunserv.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

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  : kadlecblackhole.kfki.hu, kadlecsunserv.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