Date: Sat, 26 Jul 2008 18:28:37 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: freebsd-net@freebsd.org Cc: Bernd Walter <ticso@cicely7.cicely.de> Subject: (syncookckie bug?) Re: TCP zombie connections with 7-RELEASE and STABLE from 15th june Message-ID: <20080726162836.GB75357@cicely7.cicely.de> In-Reply-To: <20080718135931.GA48087@cicely7.cicely.de> References: <20080718135931.GA48087@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
After sysctl net.inet.tcp.syncookies=0 the problem is not reproduceable anymore. But of course I'm not entirely happy with disabling syncookies, so this is not a good workaround. On Fri, Jul 18, 2008 at 03:59:31PM +0200, Bernd Walter wrote: > 14:45:58.109631 IP 213.83.6.106.3270 > 85.159.14.110.443: S 470580731:470580731(0) win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 1097693791 0> > 14:45:58.109753 IP 85.159.14.110.443 > 213.83.6.106.3270: S 1364510055:1364510055(0) ack 470580732 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 2811134076 1097693791> > 14:45:58.114324 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 1 win 33304 <nop,nop,timestamp 1097693796 2811134076> > 14:45:59.816810 IP 213.83.6.106.3270 > 85.159.14.110.443: F 1:1(0) ack 1 win 33304 <nop,nop,timestamp 1097695539 2811134076> > 14:45:59.816900 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 2 win 8326 <nop,nop,timestamp 2811135743 1097695539> > 14:45:59.818445 IP 85.159.14.110.443 > 213.83.6.106.3270: F 1:1(0) ack 2 win 8326 <nop,nop,timestamp 2811135744 1097695539> > 14:45:59.822859 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097695545 2811135744> > 14:46:00.415401 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 1 win 0 > 14:46:00.420082 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696156 2811135744> > 14:46:00.420139 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.424772 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696162 2811135744> > 14:46:00.424847 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.429065 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696166 2811135744> > 14:46:00.429089 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.433247 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696170 2811135744> > 14:46:00.433305 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.437641 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696175 2811135744> > 14:46:00.437700 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.442408 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696180 2811135744> > 14:46:00.442445 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.447231 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696184 2811135744> > 14:46:00.447291 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.451525 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696189 2811135744> > 14:46:00.451587 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.455957 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696194 2811135744> > 14:46:00.456024 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.460666 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696198 2811135744> > 14:46:00.460732 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.465092 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097696203 2811135744> > 14:46:00.465150 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > [...] > 14:46:31.182624 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:31.182978 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727660 2811135744> > 14:46:31.183006 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:31.183146 IP 85.159.14.110.443 > 213.83.6.106.3270: F 1:1(0) ack 1 win 65535 > 14:46:31.183173 IP 85.159.14.110.443 > 213.83.6.106.3270: F 1:1(0) ack 1 win 65535 > 14:46:31.184038 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727661 2811135744> > 14:46:31.184124 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727661 2811135744> > 14:46:31.184157 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727661 2811135744> > 14:46:31.184740 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727662 2811135744> > 14:46:31.185174 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727662 2811135744> > 14:46:31.186762 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727664 2811135744> > 14:46:31.187366 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727664 2811135744> > 14:46:31.187380 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727664 2811135744> > 14:46:31.187573 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 <nop,nop,timestamp 1097727665 2811135744> > > 443 is a self written server, but it also happens with port 80 and > sslproxy. > The client is a telnet, which disconnects directly after connecting, > so the disconnect is initiated from the client, which seems to be > important for this problem to trigger. > > You can see that the FIN handshake completes and netstat on the > client box shows the connection in TIME_WAIT. > The server however has the connection still in ESTABLISHED state. > > What happens in the application code looks quite silly. > I do a typical accept loop and then I process the data in a > new thread. > After my thread terminates and closes it's filedescriptor the select > loop accepts the old connection again. > This doesn't happen in every case but almost always. > Finally after 30 seconds without data to read my newly created thread > closes the zombie connection again. > > The question is why accept returns me a filedescriptor for a connection > which was already returned and should have been closed? -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080726162836.GB75357>