On 04/02/2008 6:10:54 PM +0200, Leo <neleo@xxxxxxx> wrote:
I have made another test:
Between the client and the server I installed a router (just another
linux box forwarding the packets). On all three machines I have made a
tcpdump during the connection problem. On the client and the server the
tcpdump remains the same as the first tcpdump I ever posted:
In fact, you tested a more complicated setup to prove the point of the
problem not being on the network. Unusual, but still valid: your router
only serves as a packet sniffer.
You can do exactly the same on your simple setup by using tcpdump in
promiscuous mode: the packets captured will be all the interface receive
before the network stack processes them.
Possible conclusions:
1. It's definitely a client problem.
yup. The client network device "sees" the SYN/ACK packet, but it is not
processed by the network stack
I think this has something to do with net/ipv4/tcp_input.c which
contains code to initiate and process all the incoming tcp packets. I
took a look at it, but it is still a very large bunch of code to
"review" and I'm far from being as experienced in kernel code than
original programmers.
Are we able to find a kernel which doesn't not trigger the 3s delay ?
This way we would be able to know where to look at in the commits
involving this kernel part.
Leo, what kernel versions are you using? Could you please try older
kernels on the client, say 2.6.20 for starters? I have the feeling that
this bug is present for months... (2.6.20 was released on feb 2007)
Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
