[Snort-devel] TCP STATE TRANSITIONS IN STREAM4

Martin Roesch roesch at ...402...
Fri May 17 08:22:02 EDT 2002


These state transitions are derived from both looking at Steven's state
transition diagrams and from empirical analysis of real network traffic.
The FIN|PSH|ACK packets are commonly seen returning from web servers and the
client does see the traffic.

The naked FIN packets shouldn't occur, but I've seen some screwy TCP stacks
do it that way so we have to account for it.

In the IP networking world, you're supposed to be lax on accepting traffic
that you receive and stingy about the traffic you transmit, this is a real
world example of that maxim.

     -Marty


On 5/16/02 11:24 PM, "shen zhenhui" <brilliant_hui at ...1378...> wrote:

> Hi buddy
> I got confused with the tcp state flow defined in the stream4 preprocessor.
> this part is implemented in the UpdateState sub-routine.
> first of all, let¹s take a look at the normal TCP connection CLOSE sequence
> described in rfc793.
>     SERVER                                                 CLIENT
> 1.  ESTABLISHED                                          ESTABLISHED
> 2.  (Close)
>     FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT
> 3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT
> 4.                                                       (Close)
>     TIME-WAIT   <-- <SEQ=300><ACK=101><CTL=FIN,ACK>  <-- LAST-ACK
> 5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED
> 6.  (2 MSL)
>     CLOSED       
>                        Normal Close Sequence
> 
> 
> now let¹s see how stream4 did with it step-by-step. and my personal questions
> begin with the symbol Œ # ¹ .
> 
> suppose we identified a packet p coming from the server side,
> 
> switch(ssn->client.state)
> 
> {
> 
>      case ESTABLISHED:
> 
>             ...
> 
>             else if(p->tcph->th_flags == TH_FIN)
> 
>             {
> 
>                    ssn->client.state = CLOSE_WAIT;
> 
>                    ssn->server.state = FIN_WAIT_1;
> 
>             }
> 
>       # as we know, FIN segments, unlike RST, should also have the ACK flag
> set. so how could this case happen in reality?
> 
>    ...
> 
> case CLOSE_WAIT:
> 
>             if(p->tcph->th_flags == TH_ACK)
> 
>             {
> 
>                    ssn->server.state = FIN_WAIT_2;
> 
>             }
> 
>             else if(p->tcph->th_flags == (TH_ACK|TH_PUSH|TH_FIN))
> 
>             {
> 
>                    ssn->server.state = FIN_WAIT_2;
> 
>                    ssn->client.state = LAST_ACK;
> 
>             }
> 
>            # since Client is already in CLOSE_WAIT state, there¹s no way for
> it to receive tcp segments coming
> 
> from the server side. instead Server waits for ACK and FIN packets from
> Client. then how could Client know
> 
> the Server side enters into FIN_WAIT_2 state?
> 
> 
> 
> could you help to solve my perplexity?
> 
>                  
> sheridan
> 


-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Professional Snort Sensor and Management Console appliances
roesch at ...402... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org





More information about the Snort-devel mailing list