Version: 3.4 (using KDE KDE 3.4.0) Installed from: Unlisted Binary Package I've been having this problem the last 2 KDE versions (not counting betas). I found some time right now to make a comparative analysis of the traffic and write this bug report. Here's a link to an Ethereal output while trying to upload a file via a FTP connection: http://mircea.bardac.net/temp/ftp.traffic.csv Note that I have tried to upload just a text file (t.txt - Unix like end-lines). The first packets are from Konqueror (unsuccessful attempt - failed at "Response: 550 /public_html/mircea/temp/t.txt: Permission denied". Starting from packet no. 201, you can see the traffic made by Midnight Commander (successful attempt) For some reason, Konqueror is not able to upload anything to that server. Looking through the packets, it seems that it automatically closes the upload - passive connection right after opening it, without pushing anything over it. The passive mode looks a bit broken.
Forgot to mention: I'm behind NAT and that's why I use passive-mode. I have the option for FTP passive mode turned on in Konqueror (I don't think it was enabled by default, although nowadays - with lots of WiFi hotspots and local LANs - it might be more appropriate to make it on by default). I don't need to upload things much on many servers, but it so happened that I had to do this on another server - not the one listed there. Surprisingly, it worked. I now suspect there might be something with that specific FTP-Daemon. Even so, Midnight commander manages to upload something so, I believe, it has a more largely-compatible way of doing this compared to konqueror (on the other hand, maybe it is addapted to that specific server). Anyhow, the bug persists with the server mentioned in the FTP traffic dump.
Passive mode is on by default in kio_ftp (well we try it first, and if it doesn't work we fallback to non-passive mode). The only differences I see in the logs are: - "stor" vs "STOR" - the current directory (the TYPE seems to be in binary mode at the time of the STOR in both cases) "139", "21.481399", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: cwd /public_html/<USERNAME>/<DIR>" "140", "21.627539", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 250 CWD command successful" "144", "21.775411", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: PASV" "145", "21.927609", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 227 Entering Passive Mode (<FTP-SERVER-IP>,143,205)." "150", "22.067307", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: stor /public_html/<USERNAME>/<DIR>/t.txt" "152", "22.209944", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 550 /public_html/<USERNAME>/<DIR>/t.txt: Permission denied" "304", "49.646823", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: PASV" "305", "49.787935", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 227 Entering Passive Mode (<FTP-SERVER-IP>,143,228)." "313", "50.072658", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: STOR /public_html/<USERNAME>/<DIR>/t.txt" "314", "50.216118", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 150 Opening BINARY mode data connection for /public_html/<USERNAME>/<DIR>/t.txt" Any chance you can try with telnet on the FTP port, to see which command really makes the difference? E.g. if "stor" is OK without the CWD being done first, and doesn't work with CWD done first? Or do I miss something else (you mentionned the connection being closed...)
When I mentioned the connection being closed, I reffered to the passive connection. I personally believe the problem lies somewhere between negotiating the PASV parameters and closing the FTP passive connection. The 2 significant parts are: MC: "304", "49.646823", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: PASV" "305", "49.787935", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 227 Entering Passive Mode (<FTP-SERVER-IP>,143,228)." "307", "49.788162", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "37737 > 36836 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=50729023 TSER=0 WS=2" "308", "49.927339", "<FTP-SERVER-IP>", "192.168.0.2", "TCP", "36836 > 37737 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460" "309", "49.927390", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "37737 > 36836 [ACK] Seq=1 Ack=1 Win=5840 Len=0" "310", "49.927979", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: TYPE I" "311", "50.072442", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 200 Type set to I" "312", "50.072591", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "55372 > ftp [ACK] Seq=187 Ack=813 Win=5840 Len=0" "313", "50.072658", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: STOR /public_html/mircea/temp/t.txt" "314", "50.216118", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 150 Opening BINARY mode data connection for /public_html/mircea/temp/t.txt" "315", "50.216516", "192.168.0.2", "<FTP-SERVER-IP>", "FTP-DATA", "FTP Data: 1035 bytes" "316", "50.216651", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "37737 > 36836 [FIN, ACK] Seq=1036 Ack=1 Win=5840 Len=0" "318", "50.358093", "<FTP-SERVER-IP>", "192.168.0.2", "TCP", "[TCP Dup ACK 308#1] 36836 > 37737 [ACK] Seq=1 Ack=1 Win=5840 Len=0" "319", "50.360110", "<FTP-SERVER-IP>", "192.168.0.2", "TCP", "36836 > 37737 [ACK] Seq=1 Ack=1037 Win=7245 Len=0" "320", "50.360213", "<FTP-SERVER-IP>", "192.168.0.2", "TCP", "36836 > 37737 [FIN, ACK] Seq=1 Ack=1037 Win=7245 Len=0" "321", "50.360237", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "37737 > 36836 [ACK] Seq=1037 Ack=2 Win=5840 Len=0" Konqueror: "142", "21.630748", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: SIZE /public_html/mircea/temp/t.txt" "143", "21.774788", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 550 /public_html/mircea/temp/t.txt: No such file or directory" "144", "21.775411", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: PASV" "145", "21.927609", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 227 Entering Passive Mode (<FTP-SERVER-IP>,143,205)." "146", "21.928579", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "49082 > 36813 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=50701159 TSER=0 WS=2" "147", "21.968585", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "43488 > ftp [ACK] Seq=170 Ack=653 Win=5840 Len=0" "148", "22.067111", "<FTP-SERVER-IP>", "192.168.0.2", "TCP", "36813 > 49082 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460" "149", "22.067156", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "49082 > 36813 [ACK] Seq=1 Ack=1 Win=5840 Len=0" "150", "22.067307", "192.168.0.2", "<FTP-SERVER-IP>", "FTP", "Request: stor /public_html/mircea/temp/t.txt" "152", "22.209944", "<FTP-SERVER-IP>", "192.168.0.2", "FTP", "Response: 550 /public_html/mircea/temp/t.txt: Permission denied" "153", "22.210127", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "43488 > ftp [ACK] Seq=207 Ack=708 Win=5840 Len=0" "154", "22.210288", "192.168.0.2", "<FTP-SERVER-IP>", "TCP", "49082 > 36813 [FIN, ACK] Seq=1 Ack=1 Win=5840 Len=0" "155", "22.358576", "<FTP-SERVER-IP>", "192.168.0.2", "TCP", "36813 > 49082 [ACK] Seq=1 Ack=2 Win=5840 Len=0" You will notice by analyzing the entire log that Konqueror uses the FTP-DATA connection only once (for listing the files) while MC uses FTP-DATA for listing the files AND uploading the file. I believe the server expected some input using the FTP-DATA protocol. The lines containing "FTP-DATA" actually contain traffic done between the client and the server using the last opened PASV connection. I'm no expert in FTP transfers, but, as it looks, I see it as following: 1. FTP client connects... changed dir, lists dirs.. etc. (doesn't matter the method used) 2. user wants to upload something 3. the client asks the server for a PASV connection 4. the server returns the PASV port (ip,HI_BYTE,LO_BYTE) => PASV_PORT=HI_BYTE<<8 & LO_BYTE (or >>, whatever). 5. client opens connection to PASV_PORT (surprisingly, this is only a control connection) = SYN, ACK.. normal TCP packets 6!!! MC seems to set the type now, using "TYPE I" 7. clients requires to STOR filename 8!!! client connects uses FTP-DATA protocol to transfer the file to PASV_PORT 9. usual TCP close connection packets FIN,ACK,SYN for the PASV connection done. Konqueror seems to skip some steps in this process (the "!!!"-marked steps).
Forget the "(surprisingly, this is only a control connection)" - I missunderstood something while analysing the output for the 2nd time. I forgot to remove the comment after I've added all the steps.
Fixed in KDE 3.4.1. Probably because of this line in the ChangeLog: kio-ftp: Try non-passive mode if passive mode fails Thanks.
That's not probably it, but we did change a couple of behaviours in kio_ftp that could account for that. But only note this happens only with buggy FTP servers.
Well, maybe, but ProFTPD 1.2.10 used on the server is the latest version. As I said, MC was working great with it, but KDE wasn't. The Ethereal capture revealed that kftp was indeed opening the passive mode connections, but didn't make any use of them (like MC does). Don't know exactly why, but you probably fixed that because it works now.
Well, it worked the first time I tested after KDE 3.4.1 installation. Now the problem is back. Same behaviour.
Can you test a more recent version, like KDE 3.4.2 or 3.5.0 alpha 1?
Tested today with KLAX with KDE 3.5 alpha 1 and still I get the "Check permissions" error on my first try, with or without "Enable PASV mode" checked.
Found FTP uploading working with: * KDE 3.4.3 * PASV enabled (checked) * Mark partially uploaded files (checked) I can't provide more info, sorry. I don't know any way of getting FTP server information from within KDE - maybe each kio_slave could have some logging facility accessible some way (maybe View menu), if enabled somewhere in the Control Center - I haven't created a wish for this (yet), nor I've searched.
> maybe each kio_slave could have some logging facility accessible some way They do, but your kio_slave must be compiled with debugging info.
IF I compile the kio_slave with debugging info, where could I get the info about server version, messages sent/received to/from the server and stuff like that? Note that most FTP clients show a window like this - only purely visual clients (explorer like) don't do this, hiding everything.
Every debugging info goes to ~/.xsession-errors.