Message-ID: <20080827165142.4bc7b70f@tux>
Date:	Wed, 27 Aug 2008 16:51:42 -0300
From:	Dâniel Fraga <fragabr@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>, thomas.jarosch@...ra2net.com,
	billfink@...dspring.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility
 workaround

On Wed, 27 Aug 2008 13:22:22 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:

> ...thus there could be other ports that are related as well, do you 
> remember what exactly started working in that particular case :-)?

> Which of the connections? Mail, nntp, ftp, or the etc.? :-) To the host ip 
> which was given for the tcpdump filter, definately nothing was resumed.

	Ok. Let's focus on mail:

1) first, my client (Claws-mail -- but it happened with Outlook of
other users too) is working perfectly. I can download new messages. It
connects to port 995 on the server without problems.

2) suddenly it gives me an error message, that it cannot authenticate
anymore (sorry, I don't have the exact message). If I try again to
download new messages, it gives the same error. The connection to port
995 seems stalled or, better yet, cannot complete succesfully. It seems
to time out.

3) the server will stay this way, until I do an "nmap" to the server.
This way, everything goes back to normal.

	So, the server at point 2 got stalled and just an nmap server
can force the server to go back to normal behaviour (I discovered that
nmap solved the issue by luck).

> I was think that at a time (even thought of enquiring you about this 
> part of the config), but the tcpdump log shows a problem that is 
> unlikely to depend on timers in any way (and at least some timer expires 
> because the SYNACKs are retransmitted, so it's not in some infinite wait 
> bug). I'd like to know what causes that and try to solve it.

	Ok.

> Once we know the reasons, we can probably easily determinate whether 
> there's need to experiment with the timers. Trying to conquer all problems 
> at once, when not even knowing how many problems one is going to find is 
> not that easy either. Besides, I'd be more concerned about the timers on 
> the client after seeing that nothing goes in the network while the nmap 
> trick resolves the thing.

	Ok.

> The server's log captured not only 995 traffic but everything else to the 
> host with the given ip (including udp which should show the tunnelled 
> traffic I guess). Unless there's some other route to that host with 
	
	Ok, that's because I forgot to restrict traffic to port 995 on
the server. Sorry.

> This makes me wander if the network behavior is at all related to 
> resolving of the problem. Only thing I can think of is that for some 
> reason the userspace gets notified much later than it should about
> TCP reset and therefore is waiting until that happens and can only
> then continue.

	What I can assure you is that other users (which use Microsoft
Outlook Express) had the same problem, so, in this case, we can be
pretty sure it isn't related to user space client.

> It would be too easy explanation, yeah :-). Can you still please check 
> next time that there aren't even near that many server processes at the 
> server :-).

	Ok, when I get the problem I'll check this.

> Adding this wouldn't hurt btw:
> 
> cat /proc/net/tcp

	Ok.

-- 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists