netdev - Re: TCP connection stalls under 2.6.24.7

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]

Message-Id: <200807101612.59380.thomas.jarosch@intra2net.com>
Date:	Thu, 10 Jul 2008 16:12:58 +0200
From:	Thomas Jarosch <thomas.jarosch@...ra2net.com>
To:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
Cc:	netdev@...r.kernel.org, Patrick McHardy <kaber@...sh.net>,
	Sven Riedel <sr@...urenet.de>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>
Subject: Re: TCP connection stalls under 2.6.24.7

On Thursday, 10. July 2008 15:17:53 you wrote:
> It looks as the smtp server receives the packets slowly and it's just
> behind the client. There's no more packet to/from port 53132 in the
> tcpdump.

Thanks for looking into this, Jozsef. If you take a look at the timing 
information, the connection was already running ~270 seconds without real 
data transfer. The mailserver then aborts the SMTP connection with the error 
msg: "421 mailbackup.webpage.t-com.de Lost connection to [217.85.147.6]"
Only after that the port is "changed" to the wrong one.

The time ranges between the retransmissions seem
to really go downhill after the first retransmission.

The linux box is connected via a mostly idle 2 mbit SDSL line, the mailserver
is located at the provider. So theoretically this shouldn't be slow at all.
This is also proved as 2.6.23.17 works without trouble.

As noted before, small mails below ~220kb always seem to get through.
Is there any feature in TCP that could trigger such a behaviour?
This smells like some queue getting full. I'll double check
there is not some kind of traffic shaping in place.

> > 13:44:51.681540 IP mailserver.smtp > linux.41085: P
> ...
>
> But the first packet above from the server looks just wrong in the
> context: the port of the client "changed". This is why the client sends
> the RST packet back as there's no such TCP connection there.
>
> Makes no sense at all...
>
> [Wild guessing: broken virtualized SMTP server migration?]

Oh, that really looks strange. Maybe the error handling
of the server/load balancer/whatever is broken.

The Fritz!box router-in-between worked fine for a day, but now we just had 
another mail stuck in the queue. So it seems to soften the problem a bit,
but does not solve it.

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