shen zhenhui brilliant_hui at ...1378...
Thu May 16 20:26:02 EDT 2002

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)
                         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,
       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?
              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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020516/4f23d6d0/attachment.html>

More information about the Snort-devel mailing list