Re: 2.2.16 TCP problems (again)

[Rajeev Bector]

Hi  Alexey,
    Thanks for your reply. I will send you the tcpdump
in the next mail. Meanwhile,  let me try to clarify the
problem by giving the codepath that is executed.
 There are two packets back to back, (the first
one is the final ACK of the 3-way handshake and the
second one is a data packet).  Both packets end up
in the backlog queue because -

- the first ACK packet resolved to the listening socket ofcourse.
   But it was queued up in back_log queue since the sock_readers
   lock was held by the base context (so the connection really
   is still sitting as a half-open connection untill  _release_sock()
   is called.

- the 2nd packet arrives before __release_sock can be called and
  it too resolves to the listening socket (since there is nothing in the
  established hash yet). It too is put in the backlog_queue

- now when __release_sock() is called,  both packets are processed,
  the processing of the first one moves the connection to established
  state.  The second packet causes the following events to  occur

   - the sk is in TCP_LISTEN state but when we call tcp_v4_hnd_req it
     returns the same socket (since tcp_v4_search_req fails)
     now you call tcp_rcv_state_process which will return a 1 for
     any packet that has ACK bit set and sk->state == TCP_LISTEN
     and you end up sending an RST
     back.

I made a mistake in the previous posting. This thing is happening with
2.2.13
for me (I havent tried 2.2.16 but is probably the same)

Does that help ?

Thanks
Rajeev

----- Original Message -----
From: <[e-mail]>
To: "Rajeev Bector" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, June 29, 2000 10:46 AM
Subject: Re: 2.2.16 TCP problems (again)

| Hello!
|
| > resolve (do a tcp_v4_lookup) again and as a result
| > end up sending a RST back to the client.
|
| Please, send some tcpdump showing the problem.
|
|
| > Can someone tell me if its a known bug and if there is a
| > patch ?
| ...
| > Does anyone have any comments or am I missing something
| > completely in this one ?
|
| It is difficult to say. The place is dangerous, the problem
| is real, really showed and has been fixed in 2.3.
|
| But I still do not see how it is possible in 2.2.
| Packet is checked against list of requests when it falls
| to listening socket and correct established socket is found there.
| When accept() removes open request from queue, real socket is
| already in big hash table, so that there is no race window.
| Probably, it is me who missed something though...
|
| Alexey