http://bugzilla.suse.com/show_bug.cgi?id=975913
http://bugzilla.suse.com/show_bug.cgi?id=975913#c9
--- Comment #9 from Jean Delvare ---
I tested it again (up-to-date Leap 42.1, lftp version 4.6.4.) I no longer have
IPv6 disabled on this machine, as the bug which made me do that was fixed
meanwhile.
With "set dns:order inet", only the ipv4 address is tried, as expected.
Without it (default behavior), the ipv6 address is tried first, fails ("Network
unreachable") and lftp immediately falls back to the ipv4 address (which
works.) This is the right behavior, as ipv6 is not configured on this machine.
Now I disabled IPv6 to test this specific bug again (unchecked the "Enable
IPv6" option in the yast network module) and restarted the machine. lftp still
tries IPv6 first, and that fails with "Cannot assign requested address" as
mentioned in the original bug report. It does NOT fall back to IPv4, even
though there was an IPv4 address is the list for the target host.
This is the key problem as far as I'm concerned. If lftp gets a list of
possible addresses for the target host, it should try them all, and only give
up if they all fail (or all hope is otherwise lost.)
I think we want this commit from upstream:
https://github.com/lavv17/lftp/commit/58bfcfc2b00c6f3524ed4988ba7c5f4cd6867c...
This commit is upstream since lftp v4.7.2, which would explain why you don't
have the problem on Tumbleweed. Can we get it backported to Leap 42.1 and 42.2?
And I don't think we want to change the address order. If lftp wants to try
IPv6 first, that's fine, as long as it falls back to IPv4 as needed.
(Maybe whoever resolves the host name should not return IPv6 addresses to the
caller in the first place, I don't know what is considered the correct behavior
in this case.)
--
You are receiving this mail because:
You are on the CC list for the bug.
