From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8521 invoked by alias); 5 Apr 2006 03:14:25 -0000 Received: (qmail 8509 invoked by uid 22791); 5 Apr 2006 03:14:24 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Apr 2006 03:14:22 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FQyTC-0008Hh-O9 for ecos-discuss@sources.redhat.com; Wed, 05 Apr 2006 05:14:10 +0200 Received: from grante.dsl.visi.com ([208.42.141.248]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Apr 2006 05:14:10 +0200 Received: from grante by grante.dsl.visi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Apr 2006 05:14:10 +0200 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Wed, 05 Apr 2006 03:14:00 -0000 Message-ID: User-Agent: slrn/0.9.8.1 (Linux) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] RedBoot TCP socket stays in TIME_WAIT state forever. X-SW-Source: 2006-04/txt/msg00034.txt.bz2 When I close a TCP socket in RedBoot, the socket gets stuck in the TIME_WAIT state forever. Here is the sequence of events: 1) call __tcp_close() which transitions to _FIN_WAIT_1 2) the TCP stack sends a FIN 3) the TCP stack receives a FIN+ACK 4) the TCP stack transitions to _TIME_WAIT and sends and ACK Then it just sits there forever in the _TIME_WAIT state. Well perhaps not forever, but 1) I've waited several hours and it never changed, and 2) after studying the source code, I can't see any way for it to exit that state. AFAICT, the only way to get out of _TIME_WAIT state is if somebody called tcp_send() while in that state so that a timer gets set with the do_close() callback. How would tcp_send() ever get called once we've hit step 4) above? Everything's been ACKed so there is no reason for the stack itself to ever try to send anything, and calling __tcp_write() in the application code is just going to return immediately becuase the socket isn't in a valid state for calling write(). Shouldn't the 1s/2m timer be set when the socket transitions to the _TIME_WAIT state? FWIW, here's the BSP_LOG output: ------------------------------8<------------------------------ SYN from 192.168.2.4:48331 (seq a352dcb8) tcp_send: state[2] flags[SA] ack[a352dcb9] data[0]. _SYN_RCVD timer cancel. ACK received - connection established Rcvd tcp ACK 1 tcp data: seq[a352dcb9] len[27]. tcp data: pkt[7e9138] len[27]. tcp_send: state[4] flags[PA] ack[a352dcd4] data[10]. Rcvd tcp ACK b seq advance 10 tcp data: seq[a352dcd4] len[0]. tcp_read: read 27 bytes. pkt[7e9138] freed. tcp_read: no more data. tcp_send: state[4] flags[PA] ack[a352dcd4] data[27]. Rcvd tcp ACK 26 seq advance 27 tcp data: seq[a352dcd4] len[0]. Rcvd tcp ACK 26 tcp data: seq[a352dcd4] len[6]. tcp data: pkt[7e9138] len[6]. tcp_read: read 6 bytes. pkt[7e9138] freed. tcp_read: no more data. __tcp_close: going to _FIN_WAIT_1 tcp_send: state[7] flags[FA] ack[a352dcda] data[0]. tcp free_rxlist. Rcvd tcp ACK 27 seq advance 0 _FIN_WAIT_1 --> _TIME_WAIT ------------------------------8<------------------------------ -- Grant Edwards grante Yow! There's a SALE on at STRETCH SOCKS down at the visi.com "7-11"!! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss