GNOME Bugzilla – Bug 609085
org.freedesktop.DBus.Error.NoReply timeout accessing u/p FTP
Last modified: 2010-02-07 20:07:38 UTC
Trying to access to a FTP service results in a timeout: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connectionwas broken. Steps to reproduce: 1. Enter ftp://ftp.xxx.dom/ in the location 2. Enter username and password 3. Wait timeout The TCP stream captured by tcpdump shows: 220 Welcome to FTP service. ---> FEAT 211-Features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS 211 End ---> USER user 331 Please specify the password. ---> PASS XXXX 230 Login successful. ---> TYPE I 200 Switching to Binary mode. ---> SYST 215 UNIX Type: L8 ---> CWD / 250 Directory successfully changed. ---> EPSV 229 Entering Extended Passive Mode (|||60055|) Using CLI ftp client: ftp -d ftp.xxxx.dom Trying *.*.*.*... Connected to ftp.xxxx.dom (*.*.*.*). 220 Welcome to FTP service. Name (ftp.xxxx.dom:yyyy): user ---> USER user 331 Please specify the password. Password: ---> PASS XXXX 230 Login successful. ---> SYST 215 UNIX Type: L8 Remote system type is UNIX. Using binary mode to transfer files. ftp> ls ftp: setsockopt (ignored): Permission denied ---> PASV 227 Entering Passive Mode (*,*,*,*,235,42) ---> LIST 150 Here comes the directory listing. drwxr-xr-x 2 1109 1096 4096 Jul 01 2005 cgi-bin drwxrwxr-x 2 1109 1096 4096 Apr 16 2006 data drwxrwxr-x 2 1109 1096 4096 Jul 01 2005 errors drwxrwxr-x 4 1109 1096 4096 Nov 11 2006 html dr-xr-xr-x 2 1109 1096 4096 Feb 05 03:03 logs dr-xr-xr-x 2 1109 1096 12288 Jul 01 2005 stats 226 Directory send OK. ftp> ---> QUIT 221 Goodbye. This server needs PASV in order to work. Other FTP services work fine. I guess the problem may be in the use of EPSV instead of PASV, and may be the port in the EPSV reply it's related because *sometimes* the FTP connection works. ie. with EPSV port 60237: tcp 0 0 192.168.1.2:44410 *.*.*.*:21 ESTABLISHED 4276/gvfsd-ftp tcp 0 1 192.168.1.2:59112 *.*.*.*:60237 SYN_SENT 4276/gvfsd-ftp tcp 0 0 192.168.1.2:44413 *.*.*.*:21 ESTABLISHED 4276/gvfsd-ftp tcp 0 1 192.168.1.2:58419 *.*.*.*:60286 SYN_SENT 4276/gvfsd-ftp
GVfs tries EPSV, PASV, EPRT and PORT (in that order) for data connections. EPSV and EPRT are only tried if the server indicates it supports them and it claims it does (see the FEAT command). We're doing this for IPv6 support (which doesn't support PASV at all). I have no idea why the connection is failing, but I suppose there's a NAT or so involved and that NAT does know about forwarding PASV ports, but does not know about EPSV. The error you're getting is that the server does not fail on a connection request, so gvfs assumes it's just slow and keeps waiting. The side effect is that dbus times out faster and reports the error you see. Now what we could try to do is: (1) Make you fix the really bad ftp server you're trying to connect to (2) prefer PASV to EPSV on IPv4 connections. But that's a dangerous change that I'm not sure I like. (3) Timeout faster. I don't think gio has API for setting a timeout on connection attempts though, so this might be a tiny bit hard. (4) Make DBUS not throw errors if we take a bit of time. One of them would solve the problem, all of them are a good idea, none of them is easy to do I guess. Also, is there a way I could test the FTP server should I attempt to fix it?
I'm using NAT, but there isn't any kind of helper for FTP AFAIK. The ISP providing the FTP service has IPv6 connectivity in his servers, but my Internet connection provider just provides IPv4, so I'm using IPv4 to connect the server. I don't know if this information helps. 1. I'm sorry but "the really bad ftp server" it's in my ISP and I can't make anything to "fix" it. I don't know what's wrong, I don't know if it's server's fault or something else. 2. Previous version of gvfs worked, I don't know if using EPSV instead of PASV is a new change. 3 and 4, I guess this is to move to PASV because EPSV fails, isn't it? I don't think I can provide you access to the FTP server. Let me think about how to find more information, or just close the bug if there's nothing that can be done to fix it.
I took approach 2 now, the fix should be in git master. It does a bunch of magic now to ensure that EPSV is preferred to PASV for IPv6 but not for IPv4, so hopefully everything should continue working for all the broken FTP servers out there.
Thank you Benjamin!