Date: Thu, 12 Dec 1996 22:56:18 -0700 (MST) From: Marc Slemko <marcs@znep.com> To: hackers@FreeBSD.org Subject: Re: TCP FIN/ACK storm oddity Message-ID: <Pine.BSF.3.95.961212205601.9741G-100000@alive.ampr.ab.ca> In-Reply-To: <Pine.BSF.3.95.961211173514.29879H-100000@alive.ampr.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Ok, a bit more data. It seems after 50 minutes or so the state on the FreeBSD box goes from ESTABLISHED to CLOSE_WAIT. Then I make telnet active again, and it exits. The flood of packets starts, and the connection goes into the LAST_ACK stage. I have put a filter in on the FreeBSD box which (obviously) stops the flood. If I remove the filter too quickly (a couple of minutes) the first traffic I get: 03:49:01.543147 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: F 541 865:541865(0) ack 1325056048 win 2048 03:49:01.543355 darkly.worldgate.com.1701 > futurity.worldgate.com.telnet: F 1:1 (0) ack 1 win 17153 (DF) [tos 0x10] 03:49:01.544357 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: . ack 1 win 2048 03:49:01.544561 darkly.worldgate.com.1701 > futurity.worldgate.com.telnet: F 1:1 (0) ack 1 win 17153 (DF) [tos 0x10] 03:49:01.545629 futurity.worldgate.com.telnet > darkly.worldgate.com.1701: . ack 1 win 2048 So darkly gets a FIN, replies with a FIN, then keeps getting acks back in response to the FINs so it keeps sending FINs. Something is certainly wrong here. My first reaction is that once darkly gets the ack to its FIN, it should stop. However, I don't have the books at home to look it up. Julian Elischer made the good suggestion of disabling the T/TCP extensions, so I tried it with them (net.inet.tcp.rfc1644=0) disabled and, for the fun of it, the RFC1323 stuff disabled too. No difference; it still happened. It also happens if I connect from a BSD/OS 2.0 box to the Ascend; haven't tried a more diverse platform yet. I haven't been able to make the same thing happen with a simple test between two FreeBSD boxes (ie. one sending data constantly, suspend telnet, see if it messes up) but that doesn't mean it can't. OTOH, I would not be the least suprised if it were a bug in Ascend's silly software; they have enough of them, they'd never notice another one. On Wed, 11 Dec 1996, Marc Slemko wrote: > We ran into a situation with a FreeBSD-stable box and an Ascend MAX > 4000 router that was somewhat odd. The MAX has a pretty little full > screen display that is constantly updated with status information. I > telnetted to the MAX from the freebsd box, and then suspended the > telnet session and forgot about it, leaving it stopped in the > background on the FreeBSD box. A few hours later, I remembered it and > brought it back to the foreground. It started displaying a whole > bunch of updates very quickly then, as expected, died because it had > been suspended too long. > > After it died, I observed a flood of packets such as the following on > the ethernet: > > 16:31:46.852314 futurity.worldgate.com.telnet > darkly.worldgate.com.1194: . ack > 490176104 win 2048 > 16:31:46.852489 darkly.worldgate.com.1194 > futurity.worldgate.com.telnet: F 490 > 176104:490176104(0) ack 595604 win 17153 (DF) [tos 0x10] > 16:31:46.853961 futurity.worldgate.com.telnet > darkly.worldgate.com.1194: . ack > 490176104 win 2048 > 16:31:46.855045 darkly.worldgate.com.1194 > futurity.worldgate.com.telnet: F 490 > 176104:490176104(0) ack 595604 win 17153 (DF) [tos 0x10] > 16:31:46.855161 futurity.worldgate.com.telnet > darkly.worldgate.com.1194: . ack > 490176104 win 2048 > 16:31:46.855364 darkly.worldgate.com.1194 > futurity.worldgate.com.telnet: F 490 > 176104:490176104(0) ack 595604 win 17153 (DF) [tos 0x10] > 16:31:46.856240 futurity.worldgate.com.telnet > darkly.worldgate.com.1194: . ack > 490176104 win 2048 > 16:31:46.856503 darkly.worldgate.com.1194 > futurity.worldgate.com.telnet: F 490 > 176104:490176104(0) ack 595604 win 17153 (DF) [tos 0x10] > > futurity is the MAX, darkly is the FreeBSD box. A tcpdump -w stored a > dozen megs of this in a couple of minutes. > > It looks like darkly is trying to close the connection to futurity, so > it is sending a FIN. It then gets an ACK back from futurity, as it > should. However, why does darkly send another FIN? Shouldn't it then > shutup and let things close? Should futurity be ignoring any more > FINs it gets after the first one? > > The other possibility is that the connection is already closed on > darkly, and futurity is the one trying to send an ACK. However I don't > see why darkly would send a FIN in response to an ACK for a connection > it no longer knew anything about; it should send a RST from my reading > of things. > > Unfortunately I don't know exactly what state the connection was in on > the FreeBSD box while this was happening. After a few minutes of > this, I put a packet filter in on the FreeBSD box to stop the packets > and the storm died. > > Any ideas? > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961212205601.9741G-100000>