Gabriel Barazer wrote:
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.
tcpdump is always working in promiscous mode I think:
Apr 2 13:02:27 192.168.1.99 kernel: device eth0 entered promiscuous mode
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)
Great idea: I have checked all servers in our production environment.
The oldest kernel versions are 2.6.15.4 and 2.6.15.5. I noticed that the
server with kernel 2.6.15.4 hasn't 3 second timeouts for the last five
days (we are logging every occurence of the problem including the
involved machines) whereas the server with the kernel 2.6.15.5 has got
timeouts. I will check this tomorrow. Sorry, it's time to go home now :-)
Kind regards,
Leo
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
--
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
