netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Aug 2008 23:32:34 +0300 (EEST)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	"Dâniel Fraga" <fragabr@...il.com>
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, Dâniel Fraga wrote:

> 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).

The exact message is not that big deal :-).

> 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.

Ok. Though this all opens more questions than answers... :-(, why isn't 
there any traffic in neither of the tcpdumps then (not in the client's
nor in the server's).

> 	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 guess it might have something to do with the additional 3-way 
handshake that gets attempted but who knows...

> > 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.

I don't think it was bad at all... :-) I just meant that there wasn't any 
other visible traffic, which is very very strange because nothing port 995 
related (or anything else) seems to happen during the nmap... Which 
network interfaces the server has? Could things get routed through some 
other iface during the time of trouble (and during the nmap solution), 
that would explain why it isn't visible in the tcpdump which is for the 
specific interface.

> > 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.

Ah, ok.



-- 
 i.