TCP tracking states

TCP tracking states

[Henrik Nordstrom]

The recent discussions and Oskar Andreassons work on a iptables 
tutorial made me take a closer look into the TCP tracking states, and 
I notices a couple of odd things that looks like they may be bugs..


1. What is the use of LAST_ACK? From what I can tell this state can 
only be reached if the connection is already in the LAST_ACK state..

2. The support for half-closed connections is very poor, and differs a 
lot depending on which side closed first.


To deal with 2, may I propose that the following symmetric FIN state 
machine is used instead of the odd assymetric one used today:


ESTABLISHED / FIN  -> FIN_WAIT

FIN_WAIT / ACK(R) -> CLOSE_WAIT

CLOSE_WAIT / FIN(R) -> TIME_WAIT (or a new FIN_WAIT2 state)

TIME_WAIT / ACK -> TIME_WAIT


And for completeness

FIN_WAIT / FIN(R) -> TIME_WAIT (or a new FIN_WAIT2 state)


Regards
Henrik

Re: TCP tracking states

[Henrik Nordstrom]

On Saturday 06 July 2002 00.38, Henrik Nordstrom wrote:

> 1. What is the use of LAST_ACK? From what I can tell this state can
> only be reached if the connection is already in the LAST_ACK
> state..

This also seems to be true for the LISTEN state...

Regards
Henrik

Re: TCP tracking states

[Henrik Nordstrom]

On Saturday 06 July 2002 00.38, Henrik Nordstrom wrote:

> To deal with 2, may I propose that the following symmetric FIN
> state machine is used instead of the odd assymetric one used today:
>
>
> ESTABLISHED / FIN  -> FIN_WAIT
>
> FIN_WAIT / ACK(R) -> CLOSE_WAIT
>
> CLOSE_WAIT / FIN(R) -> TIME_WAIT (or a new FIN_WAIT2 state)
>
> TIME_WAIT / ACK -> TIME_WAIT

On a second reflection it gets a little bit more complex than this. 
Need to keep track of which side has closed down, causing a small 
explosion in states...

FIN_WAIT_ORIGINAL
FIN_WAIT_REPLY
CLOSE_WAIT_ORIGINAL
CLOSE_WAIT_REPLY
FIN_WAIT2_ORIGINAL
FIN_WAIT2_REPLY
TIME_WAIT

State descriptions:

FIN_WAIT	-> Wait for ACK to FIN

CLOSE_WAIT	-> Wait for FIN in other direction



ESTABLISHED / FIN	-> FIN_WAIT_ORIGINAL

FIN_WAIT_ORIGINAL / ACK(R) -> CLOSE_WAIT_ORIGINAL

FIN_WAIT_ORIGINAL / FIN(R) -> FIN_WAIT2_ORIGINAL

CLOSE_WAIT_ORIGINAL / FIN(R) -> FIN_WAIT2_ORIGINAL

FIN_WAIT2_ORIGINAL / ACK -> TIME_WAIT


And identical in the other direction, s/ORIGINAL/REPLY/


Can be simplified by using TIME_WAIT for FIN_WAIT2_* if one likes, but 
isn't really fair if tuning is to be allowed for FIN_WAIT..

Regards
Henrik

Re: TCP tracking states

[Jozsef Kadlecsik]

On Sat, 6 Jul 2002, Henrik Nordstrom wrote:

> The recent discussions and Oskar Andreassons work on a iptables
> tutorial made me take a closer look into the TCP tracking states, and
> I notices a couple of odd things that looks like they may be bugs..
>
> 1. What is the use of LAST_ACK? From what I can tell this state can
> only be reached if the connection is already in the LAST_ACK state..
>
> 2. The support for half-closed connections is very poor, and differs a
> lot depending on which side closed first.

[...]

Yes, those are inconsystencies.

Could you have a look at the tcp_window_tracking patch? I spent a couple
of time on refining the state transitions in that patch, still there
might be room to improve them...

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary