> Gary Mills wrote: > > It's always for the data connection, with the > process sleeping > > in read() on that socket. I assume it's waiting > for a FIN from > > the client. Shouldn't this state time out? > > As described in RFC 793, no, it should not time out. > That's the > alf-open state: we've sent FIN to the peer, and he's > ACK'd our FIN, and > we're waiting for him to send FIN. He could easily > send an arbitrary > amount of additional data to us before closing, so we > can't just time > out -- especially with the application still waiting > in read().
Okay, so that explains why the FTP server is blocked forever in a read(). Of course, the server should be able to accomodate anything that the client sends or doesn't send to it. > > # ndd /dev/tcp tcp_fin_wait_2_flush_interval > > 675000 > > > > It never does. Is the server supposed to take some > action? > > All of the timeouts are set in the ftpaccess file. > Is there a bug > in the Solaris kernel? I can't find one that's > documented. > If the local application has issued close(), and if > the socket hangs > around for more than 675 seconds then that sounds > like a bug. > > But since the application is sitting in read(), the > timer has no effect, > and can't have an effect. It'd break TCP if it did. Thanks. I see now that the bug is in the FTP server. It's not honouring its timeout on the data connection. I have this set to six hours, but some server children have been around for a week. I'll begin by looking at the source to be certain that I've set the timeout correctly, and that its actually interrupting the read(). -- This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
