>When the in.ftpd was left in this "hung" state, I did a "truss -p", >which revealed that ftpd keeps on read(2)ing zero bytes from the >network socket in a tight loop, hence the CPU time consumed. The >most plausible scenario (without any kind of access to the source >code) is that the client telnet, when receiving SIGINT/QUIT, creates >an "exception" condition in the receiving socket, which is not >examined as it should by ftpd. The next kill is bogus, you might >just as well shut down the telnet connection (^]-close - tried it >out successfully). It just creates an EOF condition on ftpd's input, >which is not handled appropriately. > >The whole thing is that telnet is able to relay the INT/QUIT signals >whereas the ftp client is not. Such bugs may exist in all TELNET- >based protocol servers. The simple truth is that the Solaris FTP server tries to be clever about handlign telnet options in the FTP command channel; unfortunately, the code has a bad bug, as you have noticed. Casper
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:40:15 PDT