Just asking if anyone has already resolved this issue. I can debug it my self, but it could take hours, and still might fail.
Background:
Linux (Ubuntu)
duplicati_2.0.6.2-1_all.deb
FTPS protocol (Works over IPv4)
TLS self-signed, fingerprint specified
Network connection over IPv6 is know to work, DNS-NAME with IPv6 AAAA records is used. Server is reachable with TCP / TLS as specified above.
Problem? Duplicati says Listing remote folder, when it’s stuck there is no TCP connection to the server. And seems to hang indefinitely, I’ve waited for the remote listing to happen for 10 minutes, nothing happens.
If this is known problem or there are some suggested solution, I would prefer it. Logs or error messages doesn’t give any indication why it’s hanging. But afaik, it should work without any problems.
Yes, I’m aware that this is most likely related to somehow some libraries being used. Yet, I’m also wondering why IPv6 is a problem in 2021.
If no suggestions come in a week, I’ll start either looking at the problem or tunneling it over SSH.
Only suggestion I have (having nothing close to this setup) is also try FTP (Alternative) which is FluentFTP which seems more capable and configurable than what Microsoft provides in their FTP.
For example, it gives you a choice of implicit and explicit encryption, which I think also moves ports.
I know you have IPv4 working with FTPS, but it wasn’t clear if you have (or can test) IPv6 with FTP.
I’m not an expert on certificates in general, and definitely not an expert on IPv6 needs, if any exist…
I didn’t look to see what they are doing there but I do know that there is a network library out there from Apache Software Foundation that has no working IPV6 in 2021. Of course not all internet companies have IPV6 yet either in 2021.
That actually fits with what I saw on my logs on server side, I today checked those. It seems that the client doesn’t even make a any kind of network request to cnnect. I’ve also found out that some other clients / services get messed with DNS names without A record, if IPv6 record is only present.
Based on quick analysis, there’s request to connect (TCP / SYN) over IPv6 never came to the server, I haven’t yet checked if AAAA DNS query was ever made, I’ll check it out now…
Just as background: it’s my FTPS Filezilla Server with working IPv6, and as example Filezilla Client works perfectly over IPv6 only network, with the server.
Anyway cut the story short (Client side):
DNS query for A/AAAA was done
TCP / SYN to the address wasn’t ever sent
Client hangs forever
Sounds ahem, pretty broken to me. Confirmed. Afaik, no timeout applies to this situation. I’ve waited over an hour, and it’s still stuck. → It means that it’s just even more broken than I expected.
My primary question is what “FTP client library” the Duplicati is using by default? Something from Mono / .NET? Or something else? Is there an option to use lftp / aftp or something similar?
Yes, I did see that message, but somehow I didn’t recognize it on Windows system (I’m not using GUI). But now in the evening on Linux it was clearly in the help under the targets as aftp and checking cli help revealed the parameters needed. Initially probably got confused because that alternative is in front of ftp and not after it. I were mentally looking something like ftp-alt or similar.
Just added --aftp-encryption-mode=explicit to config and changed ftps to aftp and now it all works, awesome. I remember that with the old duplicati 1.3 I also had to use lftp which was bit more configurable than the default option to get everything to work as required.
After thinking for a while, is there some specific reason why FluentFTP is only as alternate secondary option, if it’s generally (?!?) better? Just wondering. I think I’ve had those “stuck forever” issues with FTP earlier without any reason and those were basically impossible to debug because there’s not enough FTP logging on client side. But if that’s the “feature” of primary FTP lib, then I start to understand why that’s happening every now and then. Some key timers are clearly missing, which would abort things which are very very clearly taking way too long. Like TCP connection handshake taking more than an hour.
I’d guess because it was done as second option in 2016.
Program had a different name and developer at the time. Alternative ftp backend #1690 is the pull request to add it.
