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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0807101457380.13027@blackhole.kfki.hu>
Date:	Thu, 10 Jul 2008 15:17:53 +0200 (CEST)
From:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
To:	Thomas Jarosch <thomas.jarosch@...ra2net.com>
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 Mon, 7 Jul 2008, Thomas Jarosch wrote:

> On Monday, 7. July 2008 11:18:32 you wrote:
> > I'll upgrade to 2.6.25.10 and see if it helps,
> > there is a TCP connection timeout fix in there:
> > http://kerneltrap.org/mailarchive/linux-kernel/2008/6/14/2122714
> 
> After upgrading to 2.6.25.10, the TCP connection still stalls.
> 
> I temporarily disabled PMTU discovery, TCP window scaling, TCP SACK
> and manually forced the MTU to 1400 with no noticable effect.
> 
> I also added a "iptables -I INPUT -s IP.OF.MAIL.RELAY -j ACCEPT"
> to make sure it's not related to conntrack on the double.
> 
> So here are the current results:
> - 2.6.23.16: Working
> - 2.6.24: Stalling connection
> - 2.6.24.7: Stalling connection
> - 2.6.25.10: Stalling connection
> 
> Attached is a tcpdump of a stalling connection with the
> sensitive information replaced by "xxxxx", so please ignore the broken
> checkums at the beginning. The dump was created using 2.6.24.7.
> 
> Jozsef Kadlecsik suggested this is not related to netfilter,
> so I'm now asking for help on netdev.
> 
> Here's the text output from tcpdump:
> -----------------------------------------------------------
> 13:40:14.140625 IP linux.53132 > mailserver.smtp: S 943411848:943411848(0) win 5808 <mss 1452,sackOK,timestamp 5386646 0,nop,wscale 2>
> 13:40:14.206523 IP mailserver.smtp > linux.53132: S 4213328541:4213328541(0) ack 943411849 win 65535 <mss 1400>
[...]
> 13:42:04.198938 IP linux.53132 > mailserver.smtp: . 214152:215552(1400) ack 553 win 7504
> 13:42:04.198970 IP linux.53132 > mailserver.smtp: . 215552:216952(1400) ack 553 win 7504
> 13:43:50.437541 IP linux.53132 > mailserver.smtp: . 155928:157328(1400) ack 553 win 7504
> 13:43:50.696615 IP mailserver.smtp > linux.53132: . ack 157328 win 65535
> 13:43:50.696641 IP linux.53132 > mailserver.smtp: . 216952:218352(1400) ack 553 win 7504
> 13:43:50.696671 IP linux.53132 > mailserver.smtp: . 218352:219752(1400) ack 553 win 7504

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.

> 13:44:51.681540 IP mailserver.smtp > linux.41085: P 3630759848:3630759915(67) ack 1371960018 win 65535
> 13:44:51.681568 IP linux.41085 > mailserver.smtp: R 1371960018:1371960018(0) win 0
> 13:44:51.681583 IP mailserver.smtp > linux.41085: F 67:67(0) ack 1 win 65535
> 13:44:51.681594 IP linux.41085 > mailserver.smtp: R 1371960018:1371960018(0) win 0

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?]

Best regards,
Jozsef
-
E-mail  : kadlec@...ckhole.kfki.hu, kadlec@...l.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary
--
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