im using proftpd 1.2.5 on redhat 7.2, a user is trying to upload a file that is around 90 megs, but, he keeps getting the same error, at different times during the transfer...


! Send error: connection reset
Transmitted 17920512 bytes in 487.1 secs, (360.66 kbps), transfer failed
! Recieve error: Blocking call cancelled


and then he is unable to login, and restart the upload for several minutes,

ive never seen "! Recieve error: Blocking call cancelled"

anyone know what it is? not sure whats resetting the connection in the first place, to cause that error...


thanks

Is the FTP client set for passive transfers? That seems to solve many issues.

yes, hes using passive mode...

To eliminate if it is a network issue you might want to run network tests (ping and traceroute) when the transfer is in progress and see what happens when the transfer quits.

If it fails under passive mode then you should try disabling it. You can also try adjusting the timeout setting in your FTP client. If that still doesn't help and assuming you're connecting from a Windows machine, try running the command line version of FTP. The culprit could be network latency, which we can't do much about.

ok, got the connection dropping sorted out... his cable company (rr) is having problems... be wonderful if they could check these things before they tell you your server is biting it... anyway...


im still curious as to what

! Recieve error: Blocking call cancelled

is...


thanks

Thats an error generated in relation to the internal functions of the ftp client.

Translated it means: Your transfer died.

As you have found out. ;-)

Gotta love/hate cryptic error messages for end-users. ;-)

Chuck

its like a foreign language to some of them... then they come to you "whats this mean?" "what did i do wrong?"


so much fun, thanks for the help :)

Blocking I/O refers to a call that waits until there is data to work on. I'm guessing a timeout would be a likely cause for a blocking call to be cancelled.

cortices,

your definition is inprecise. a blocking call 'blocks' (does not return) until there is no more data to be processed. the way it knows there is no more data is if it gets an EOF of some sort (specific to the protocol) or times out (no data received in a specific time frame). the timeout is in place so it doesnt keep blocking forever. for blocking calls - man read et al, for non-blocking calls man select and man poll.

cheers,
paul

You're right of course...that should be > no more data to work on <...