The comments in vsftpd.conf suggest that you need to run two separate instances, one with listen=YES and another with listen_ipv6=YES. This isn't true -- you only need to run one, with listen_ipv6=YES, and it'll accept Legacy IP connections. We should change the settings in the config file we ship.
The code differs for particular configuration listen/listen_ipv6. Therefore the behaviour can differ in some cases. I hit on a situation when usage of vsftpd depended on correct setting listen and listen_ipv6. Due to this two arguments I'm going to close it as "not a bug".
Unless vsftpd in the standard install listens on IPv6, this bug should remain open. I'm afraid I was unable to understand what you were saying in the above comment -- please could you elucidate?
vsftpd still does not listen by default on IPv6. vsftpd-2.3.2-2.fc15.x86_64 (While I do not know the vsftpd codebase) I find running two instances of the daemon for IPv4+IPv6 just a needless burden. Moreover even if there is a need for the two separate daemons the Fedora packaging must provide default + easy configuration of such setup.
Created attachment 481179 [details] xinetd config. Or maybe to switch completely by default to xinetd where it works OK, it is resource-cheaper and so it IMO suits most of the deployments better.
I've sent a patch to upstream that redesigns option 'listen' and obsoletes option 'listen_ipv6'. !!! The patch is NOT applied in Fedora yet. !!! Option listen is shifted to type 'enum' with possible values { inet, ipv4, ipv6, both }. Why this proposal? - I've applied a patch (due to BZ#592850) that fulfills information from man pages and default conf file about mutual exclusivity of these tho options. David Woodnhouse wrote me privately that it's wrong action and only man pages shall be adjusted. I don't think it. I'm convinced both possibilities should be adjustable. One instance of daemon should be able handle IPv6 + IPv4 but another use case can ask two instances - one for IPv4 and one fo IPv6. Each of instances on separate NICs. - Which of values will be by default could be discussed (my opinion ipv4 or both). - I don't think the man page should be adjusted to the code or vice versa. The functionality have to be designed for use cases.
(In reply to comment #5) > - Which of values will be by default could be discussed (my opinion ipv4 or > both). Both. Absolutely both. There is no excuse for shipping something that supports only Legacy IP by default, this far into the 21st century. It's bad enough that this bug has stayed open in Fedora for so long.
Well, at this time the IPv6 doesn't work - small number of real routers, the main producers doesn't believe the IPv6 as they should. Anyway, there is no content on IPv6. BUT...I would say "both". It's better to support all by default, no discussion about security (there is also an anonymous account enabled by default, etc.)
That is a disgustingly inappropriate thing to say in the context of Fedora. IPv6 works absolutely fine in Fedora and has done for *years*, with the exception of some packages which are just really slow to fix bugs, like this one. Also, there *is* content on IPv6. I habitually use Google over IPv6, Facebook over IPv6 and various other things. It's got to the point where I often won't even *notice* an outage of Legacy IP for some time. For a while due to this bug there was some content (the FTP site for the OpenConnect VPN client) which was *only* available via IPv6 and not Legacy IP :)
(In reply to comment #8) > IPv6 works absolutely fine in Fedora and has done for *years*, with the > exception of some packages which are just really slow to fix bugs, like this > one. this looks like vsftpd don't support IPv6 but it's not so. > > Also, there *is* content on IPv6. I habitually use Google over IPv6, Facebook > over IPv6 and various other things. It's got to the point where I often won't > even *notice* an outage of Legacy IP for some time. > Is the portion of whole IPv6 Internet traffic 50%+? > For a while due to this bug there was some content (the FTP site for the > OpenConnect VPN client) which was *only* available via IPv6 and not Legacy IP > :) Yes, IPv4 doesn't work via IPv6. You are surprised because you didn't respect man pages and information in default configuration file. Well, as I wrote above. I've sent proposal to upstream because both variants are wanted (IPv6only, IPv4 via IPv6) and I don't want to use additional option. My proposal should be transparent for admins and in addition one option would be removed. I'd appreciate you'll lobby for this change at upstream. I see it very useful because so kind of redesign should be applied by upstream.
(In reply to comment #9) > this looks like vsftpd don't support IPv6 but it's not so. A more correct way of saying it would be: vsftpd in Fedora does not work on IPv6 out of the box like everything else in Fedora does. > Yes, IPv4 doesn't work via IPv6. You are surprised because you didn't respect > man pages and information in default configuration file. I didn't respect it because it was *wrong*, as I stated when I first filed this bug over three years ago. I then set up a config which *worked*, at that point, to fix this bug. An upgrade to the vsftpd package silently broke my configuration, and *still* did not fix this bug in the out-of-the-box config. > Well, as I wrote above. I've sent proposal to upstream because both variants > are wanted (IPv6only, IPv4 via IPv6) and I don't want to use additional option. I'm not sure why we would distinguish between IPv4 and IPv6. Sometimes you only want to listen on one IP address or one interface; why not use the same mechanism? Just use the 'listen_address' option to set the IPv6 or Legacy IP address that you want to accept connections on, if you want to limit incoming connections.
(In reply to comment #10) > I'm not sure why we would distinguish between IPv4 and IPv6. Sometimes you only > want to listen on one IP address or one interface; why not use the same > mechanism? Just use the 'listen_address' option to set the IPv6 or Legacy IP > address that you want to accept connections on, if you want to limit incoming > connections. I was talking about it with Jiri and "listen_address" would bring some problems for existing configurations, let say it will be "incompatible". If you think about following example you will need options defined below. Example: All addresses on interface eth0, all IPv4 addresses, 1::2:3 IPv6 address 1. listen_address=eth0,0.0.0.0,1::2:3 (IMO the best solution) 2. listen_address=eth0 listen_address=0.0.0.0 listen_address=1::2:3 3. listen_address=eth0,0.0.0.0 listen_address6=eth0,1::2:3 (worse solution because of 2 options and duplicated "eth0") Also, you will want hostnames too: listen_address=my.fedora.box ... Anyway, I don't like daemons which silently listen on loopback there is no reason for it, there is no reason to firewall it explicitly. === what ALL leads to new parser and spoken incompatible config file. === What I know about the vsftpd it works through IPv6 loopback like: 1. connection from IPv6 <-> IPv6 loopback <-> core - CORRECT 2. connection from IPv4 <-> IPv6 loopback <-> core - WHY IPv6?! 3. kernel without IPv6, connection from IPv4 <-> IPv4 loopback <-> core - CORRECT
What's the issue with your option #1? Currently the listen_address doesn't take a list; it takes *one* address only. Why would it be incompatible to extend it to take a list? listen_address6 should just die; it was always a misfeature, like listen_ipv6 was. But it could be kept around for legacy compatibility if we must. I'm not sure what your comments about loopback are saying. We do expect "ssh localhost" and "ftp localhost" to work; why wouldn't we like dæmons which listen on loopback? And what's the bit about 'WHY IPv6?'? Is that referring to the IPV6_V6ONLY option, and the fact that as a purely internal detail, vsftpd actually accepts that on a socket which was opened with AF_IPV6? Why would anyone care about that?
Did this get fixed, or is it still broken in Fedora 16?
As was explained above the current state is correct. I've sent my proposal to upstream but I haven't any answer yet. The IPv6 will be set by default when the major part of traffic is via IPv6.
Comment 11 ended with the word 'correct' but it certainly wasn't much of an explanation. I was unable to work out what was being said. I did ask for clarification but none was forthcoming. Certainly, I cannot see any justification for having IPv6 fail to work out of the box. The comment about 'major part of traffic' is a red herring and not consistent with the rest of the Fedora distribution. IPv6 support across the distribution was a release 'feature' in the RHL days, long before the current Fedora feature process was invented. It's been an unwritten rule for years that network-facing dæmons should work with IPv6. Rather than arguing here, I suspect the best thing to do is to approach FESCO to request that they clarify the requirements.
https://fedorahosted.org/fesco/ticket/693
In accordance to FESCO decision the mutual exclusivity intended by upstream will be removed.
vsftpd-2.3.4-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/vsftpd-2.3.4-6.fc16
vsftpd-2.3.4-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/vsftpd-2.3.4-2.fc15
Package vsftpd-2.3.4-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing vsftpd-2.3.4-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15986 then log in and leave karma (feedback).
Thanks for the update. I think this still doesn't listen on IPv6 correctly by default. Don't you need to change the default vsftpd.conf file to use 'listen_ipv6=yes' in order to make it accept connections on *both* IPv6 and Legacy IP? I'm also confused by the vsftpd-2.3.4-noexclusive.patch patch. The 'listen' and 'listen_ipv6' options *are* mutually exclusive, aren't they? You haven't changed that.
Created attachment 534777 [details] Better patch Try this patch instead of the existing vsftpd-2.3.4-noexclusive.patch. It should fix the problem correctly.
(In reply to comment #23) > Created attachment 534777 [details] > Better patch > > Try this patch instead of the existing vsftpd-2.3.4-noexclusive.patch. It > should fix the problem correctly. The patch from comment #23 is not correct. If 'listen_ipv6' is enabled and there is no IPv6 address (only IPv4 addr) the IPv4 connection doesn't work.
That doesn't seem to be true here. I don't have any machines which are *really* stuck in the 20th century, so I simulated it by removing the IPv6 addresses from eth0: [root@i7 ~]# ip addr del fe80::225:64ff:fee8:e9df/64 dev eth0 [root@i7 ~]# ip addr del 2001:8b0:10b:1:225:64ff:fee8:e9df/64 dev eth0 [root@i7 ~]# ping6 www.kame.net connect: Network is unreachable [root@i7 ~]# rpm -Uhv ~dwmw2/fedora/vsftpd/f15/x86_64/vsftpd-2.3.4-2.fc15.x86_64.rpm Preparing... ########################################### [100%] 1:vsftpd ########################################### [100%] [root@i7 ~]# /sbin/service vsftpd restart Restarting vsftpd (via systemctl): [ OK ] [root@i7 ~]# ftp localhost Connected to localhost (127.0.0.1). 220 (vsFTPd 2.3.4)
Jiri? Can you explain why you think it doesn't work?
(In reply to comment #26) > Jiri? Can you explain why you think it doesn't work? Unfortunately not exactly. I guess it was fault in my network that I've rearranged meanwhile. I have to confirm now it works for me too. The patch from comment#23 is committed in rawhide.
vsftpd-2.3.4-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
vsftpd-2.3.4-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.