Linux-kernel mailing list archive 2000-26,: Re: 2.2.16 TCP problems (again)

# Re: 2.2.16 TCP problems (again)

Rajeev Bector (rajeev@akamai.com)
Thu, 29 Jun 2000 11:09:37 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Miles Lane: "2.4.0-test3-1 -- kapmd consuming 79% of available CPU when system is"
- Previous message: Russell King: "Re: tty cleanup"
- Next in thread: Rajeev Bector: "Re: 2.2.16 TCP problems (again)"

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: <kuznet@ms2.inr.ac.ru>
To: "Rajeev Bector" <rajeev@akamai.com>
Cc: <linux-kernel@vger.rutgers.edu>
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Miles Lane: "2.4.0-test3-1 -- kapmd consuming 79% of available CPU when system is"
- Previous message: Russell King: "Re: tty cleanup"
- Next in thread: Rajeev Bector: "Re: 2.2.16 TCP problems (again)"