Open boindil opened 2 years ago
Oh, yes, the timeout is for opening the TCP connection. It is not currently used for every read/write.
In my case it was an attempt to connect to freeSSHd: http://www.freesshd.com/ (identifies as SSH-2.0-WeOnlyDo 2.4.3)
In the Dial we expect to get a status code, but the freeSSHd replies with a single line SSH-2.0-WeOnlyDo 2.4.3
, then the next ReadLine() hungs.
@jlaffaye does it make sense to set SetReadDeadline on the underlying network connection in the Dial ?
I had the same problem
Same problem here. This also happens when connecting to an HTTP server (which doesn't send anything on its own). The Dial hangs until the remote server closes the connection.
EDIT: For anybody else dealing with this, I came up with a different way of handling the timeout for the entire connection process. Basically I use a custom DialFunc that stores all the connections generated:
var netCons []net.Conn
dialOpt := ftp.DialWithDialFunc(
func(network, address string) (net.Conn, error) {
dialer := net.Dialer{}
c, err := dialer.Dial(network, address)
if c != nil {
netCons = append(netCons, c)
}
return c, err
})
Then I start a routine which, after some timeout delay, if the connection attempt hasn't completed yet, either closes all those connections, or uses SetDeadline with time in the past to get that 'timeout' error. This interrupts the connection attempt, no matter what state it is in.
Describe the bug The connection attempts to not abort properly
To Reproduce I've set up an ftp server that can be reached somewhat, but is not fully functional (as tested via telnet)
Expected behavior dialing is aborted after timeout p.s.: adding DialWithContext and adding a context that is cancelled after x seconds does not work either
FTP server
Debug output DialWithDebugOutput literally does nothing when it comes to the error. I guess that somethings waiting for more data to be submitted by the FTP server, but that never happens - thus its hanging.
Additional context Go:
go version go1.18.1 linux/amd64
sometime EOF error, sometimes not
corresponds to telnet tests, but this is still not a working FTP connection (command line FTP clients do not work either) note the
^C
in the lower left. The connection would stay open until I did something, while the first one aborts immediately (i guess thats the EOF case)