Closed dryeo closed 3 years ago
LewisR
commented
3 years ago I should add that when I attempted to force the situation, I terminated the FTP connection on the server side without first downloading a file, but exiting did not trigger the trap. It appears that a transfer must have first taken place (in my case, I was only uploading files and the connection timed out overnight). Exiting ncFTP by typing "exit" at the program's prompt generated the trap.
dmik
commented
3 years ago Looks like a regression of 99f3976c3f55464be2c088c023854de98ce98695 (ponters not checked for NULL). I cannot reproduce it t (you didn't provide any working FTP link and I don't have one) but it should be easy to fix. Please try http://rpm.netlabs.org/test/libcx0.7z.
dryeo
commented
3 years ago This seems to work. Tested on ftp.arcanoae.com and a locally running ftpser.
ncftp / > bye
*** ENOTSOCK, retrying (attempts left 2)
*** ENOTSOCK, retrying (attempts left 1)
*** ENOTSOCK, retrying (attempts left 0)
Could not write to control stream: Socket operation on non-socket.Thanks
dmik
commented
3 years ago Ok, good. I wonder why it can not write to the socket. Was this error present before (note that *** are debug lines, won't be part of the release build)? Might be some other TCP/IP for OS/2 speciality...
LewisR
commented
3 years ago The socket issue is because the FTP connection has timed out on the server side. I tried to test this again, but forcing the server to close the connection did not produce the trap, and on my server, timeout is excessively long, making quick testing rather difficult. I'm glad that Dave was able to get his to choke(!) sooner. :-)
Thanks for the quick fix!
LewisR
commented
3 years ago I should add that ncFTP has always advised of a failed write attempt to a non-socket. It's just that after that, it would exit cleanly without the trap. Maybe that's just ncFTP being more verbose in its reporting than necessary when trying to close the connection.
StevenLevine
commented
3 years ago My guess is that the timeout cleanup is not quite right. The ENOTSOCK is probably because ncFTP closed the socket in response to the timeout, but neglected to update the lists it uses to prepare the fd_sets passed to select.
It also not clear why ncFTP needs to do a select in response to a bye when there are no more connections to process.
dryeo
commented
3 years ago @dmik, previously ncftp did not post the ENOTSOCK lines, just the control stream line, guess a slightly different code path now that ENOTSOCK is returned.
@steven, ncftp doesn't know the connection has timed out till it tries to close the already closed connection. Another point is the previous trap only seemed to happen if a file was transferred, perhaps causing more sockets to be open.
LewisR
commented
3 years ago I always thought that the ENOTSOCK was because ncFTP does not check the state of the socket first, before attempting shutdown(). It might be worthwhile to set an explicit value for control-timeout in the config file, but there is really no way for the client to know what the server's timeout setting may be. This option (control-timeout) tells ncFTP to consider the connection dropped if no data has been received over the control channel in that amount of time. I guess it defaults to forever, which is probably safe - except for this noise upon exit, where the client onsiders the connection still valid. Anyway, we can discuss ncFTP's quirks in a more appropriate venue. :-)
If ncftp's connection times out and then ncftp is closed, it now (since updating to the exp versions of libc and libcx) traps
To reproduce, open a ftp connection such as the testers ftp and download a file. Wait until the server times out. Both Lewis and I saw it after waiting overnight. I also experienced it after locally running ftpser, downloading a file and waiting a couple of hours. Then enter bye to close the connection and program. At this point it crashes,
It should simply close the program.
Sorry if this is the wrong place to post this, as the issue appeared after updating libcx, it seems to be a libcx issue.