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:	Fri, 03 Feb 2012 15:38:14 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	"Yurij M. Plotnikov" <Yurij.Plotnikov@...etlabs.ru>
Cc:	netdev@...r.kernel.org
Subject: Re: Connect hangs for a while before returns -1 with ECONNREFUSED
 on 3.2 for loopback

Le vendredi 03 février 2012 à 10:25 +0400, Yurij M. Plotnikov a écrit :
> On kernel 3.2.0-0.bpo.1-amd64 I see some strange behaviour of connect() 
> in case of connection via loopback. Lets see the following steps (there 
> are two processes on the host, and the first one with two threads)
> 
> Thread1:
> 1. socket(PF_INET, SOCK_STREAM, 0) ->  3
> 2. bind(10.27.10.1:26820) ->  0 /* The address is bound to some interface, eth1 */
> 3. listen(3, 1) ->  0
> 
> sleep for a while
> 
> Thread2:
> 4. shutdown(3, SHUT_RD) ->  0
> 
> sleep for a while
> 
> Another process:
> 5. socket(PF_INET, SOCK_STREAM, 0) ->  4
> 6. connect(4, 10.27.10.1:26820)
> 
> connect() returns -1 with ECONNREFUSED but after some time. In case of 
> two peer hosts connect() returns -1 with ECONNREFUSED almost 
> immediately, so does for the other kernel versions.
> 
> In attachment c program to reproduce this problem.

Thanks for the report !

It seems related to IP route management.

Only the first attempt is not OK, and only using an IP different than
127.0.0.1

First attempt :

15:06:02.270278 IP 192.168.20.110.46885 > 192.168.20.110.12346: SWE
1383808520:1383808520(0) win 32792 <mss 16396,sackOK,timestamp 167718963
0,nop,wscale 8>
15:06:03.270877 IP 192.168.20.110.46885 > 192.168.20.110.12346: SWE
1383808520:1383808520(0) win 32792 <mss 16396,sackOK,timestamp 167719964
0,nop,wscale 8>
15:06:05.274875 IP 192.168.20.110.46885 > 192.168.20.110.12346: SWE
1383808520:1383808520(0) win 32792 <mss 16396,sackOK,timestamp 167721968
0,nop,wscale 8>
15:06:09.282875 IP 192.168.20.110.46885 > 192.168.20.110.12346: SWE
1383808520:1383808520(0) win 32792 <mss 16396,sackOK,timestamp 167725976
0,nop,wscale 8>
15:06:17.290878 IP 192.168.20.110.46885 > 192.168.20.110.12346: SWE
1383808520:1383808520(0) win 32792 <mss 16396,sackOK,timestamp 167733984
0,nop,wscale 8>
15:06:17.290883 IP 192.168.20.110.12346 > 192.168.20.110.46885: R 0:0(0)
ack 1383808521 win 0


2nd attempt (and following) : it works (RST packet immediately answered)

15:06:23.647940 IP 192.168.20.110.46886 > 192.168.20.110.12346: SWE
1784465174:1784465174(0) win 32792 <mss 16396,sackOK,timestamp 167740341
0,nop,wscale 8>
15:06:23.647945 IP 192.168.20.110.12346 > 192.168.20.110.46886: R 0:0(0)
ack 1784465175 win 0


If we flush ip route cache "ip ro flush cache", it blocks again.

No hint given in "netstat -s"

Hmmm...


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ