1

I was creating an ftp client using the goftp library. Connecting to the server works but when I try to list the contents of the current directory the server hangs with 229 Entering Extended Passive Mode. I read that it could be a firewall issue but if I use Filezilla to connect to the FTP server it just works.

What am I doing wrong?

Here is the code that I'm using:

    c, err := ftp.Dial(
        os.Getenv("ftpserver"),
        ftp.DialWithExplicitTLS(
            &tls.Config{
                InsecureSkipVerify: true,
            },
        ),
        ftp.DialWithDebugOutput(os.Stdout),
        ftp.DialWithTimeout(5*time.Second),
    )

    err = c.Login(os.Getenv("username"), os.Getenv("password"))
    if err != nil {
        log.Fatal(err)
    }

    fmt.Println(c.List("/"))

    // Do something with the FTP conn

    if err := c.Quit(); err != nil {
        log.Fatal(err)
    }

and this is the output that it gives me:

220 (vsFTPd 3.0.3)
AUTH TLS
234 Proceed with negotiation.
USER username
331 Please specify the password.
PASS pasword
230 Login successful.
FEAT
211-Features:
 AUTH TLS
 UTF8
 EPRT
 EPSV
 MDTM
 PASV
 PBSZ
 PROT
 REST STREAM
 SIZE
 TVFS
211 End
TYPE I
200 Switching to Binary mode.
OPTS UTF8 ON
200 Always in UTF8 mode.
PBSZ 0
200 PBSZ set to 0.
PROT P
200 PROT now Private.
EPSV
229 Entering Extended Passive Mode (|||7339|)

samoorai
  • 31
  • 1
  • 5
  • `EPSV` is a command sent by the client, but it is not oblidged to do this, and this might explain why that "Filezilla" thing works. Have you tried to [connect with `EPSV` disabled](https://pkg.go.dev/github.com/jlaffaye/ftp#DialWithDisabledEPSV)? Does it work? – kostix Jul 11 '22 at 10:53
  • I tried disabling EPSV but the application returns `227 Entering Passive Mode (46,232,211,30,22,51)` and it hangs indefinetly. Edit: I noticed that the last command sent is `PASV` so disabling EPSV forces the client to use PASV comand, how can I disable it compleately? – samoorai Jul 11 '22 at 13:48
  • I'm not sure you can: actually, I was under an impression active mode was not actually used on "real" internet: it supposes _the client_ opens a listening socket, tells the server what it is and the server then connects to the client (!) which sort of reverses the server and the client. Provided most of the clients are behind firewalls (and NATs), this just does not realistically work. – kostix Jul 11 '22 at 14:50
  • Thanks for your answer. So do you know how can I fix this problem? – samoorai Jul 11 '22 at 21:35
  • Well, I don't. I mean, given the information we have so far, I have no more educated guesses at hand. If I were you, I'd turn to a tool such as `tcpdump`/`Wireshark` to see what's happening "on the wire" in an attempt to understand possible causes. But this requires familiarity with networking protocols. OK, a couple more: you can notice that the numbers in the parentheses after that log entry regarding PASV is the octets of the IP address and the octets of the port number—high then low… – kostix Jul 12 '22 at 10:10
  • …(see [here](https://stackoverflow.com/a/14534235/720999) for more info), so you could try to use `telnet` or netcat (`nc`) (or something like this) to try to connect to the server's socket and see whether it would respond. Another approach is to try to enable some verbose logging in that "Filezilla" thing and see how what gets there is different from what your program logs (the logs _will_ be different but you should seek for general weirdness). – kostix Jul 12 '22 at 10:12
  • Thank you for your answers. After days trying to debug the problem, I tried with every tool possible and I also looked at the Filezilla debug to see if there was something wrong, in the end I think I'm going to implement the same application functionalities with an SSH session to the server using scp. For now this seems the only solution for my problem. – samoorai Jul 23 '22 at 19:35
  • I think downgrading is the answer, but fwiw, I noticed in Wireshark that while the initial connection was established using TLS1.2, new data connections were hanging when the client tried to establish a new connection using TLS1.0. – user14375540 Aug 31 '22 at 22:28

1 Answers1

0

I ran into the same thing. It appears to be related to this issue. A fix is suggested here and that worked for me - downgrade to v0.0.0-20220301011324-fed5bc26b7fa

$ go get github.com/jlaffaye/ftp@v0.0.0-20220301011324-fed5bc26b7fa
go: downloading github.com/jlaffaye/ftp v0.0.0-20220301011324-fed5bc26b7fa
go: downgraded github.com/jlaffaye/ftp v0.0.0-20220829015825-b85cf1edccd4 => v0.0.0-20220301011324-fed5bc26b7fa