Created attachment 410634 [details] /var/log/messages trace of the connection attempt Description of problem: If a connection is configured to connect IPv4 via the Link Local method, the connection fails (regardless of how IPv6 is configured). Version-Release number of selected component (if applicable): NetworkManager-0.8.0-9.git20100429.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1. Configure or create a connection to connect IPv4 via Link Local (wired or wireless) 2. Attempt to connect the network. Actual results: It will attempt to connect, but then will fail. Expected results: It should work. Additional info: Am I missing something about how IPv4 link local works that affects this case (like firewall, etc?)
I'm getting the same behavior in NetworkManager-0.8.0-10.git20100502.fc12.x86_64. I'm willing to accept that I've got something misconfigured, but I've also tried turning off my firewall, to no effect. (For what it's worth, I'm just being completionist about this. This is by no means a priority for me.)
I can't seem to reproduce anymore with latest git, so we'll consider this fixed until you can test it out with the new build.
If you could give these a shot that would be great; I tested quite a bit with IPv4 link-local and couldn't get it to fail any more: https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc13 https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc12
NetworkManager-0.8.0-11.git20100503.fc12.x86_64 Same deal. While it's configuring Link Local 4, I can run avahi-autoipd -c wlan0 without any failure (I'm checking the return code). When using an auto connection, it does fail, so I know I'm doing that right. I've tried configuring without a firewall, that makes no difference. I do notice that during the configuration, the IPv4 routing table is empty, but when I tried adding the routes mentioned by avahi-autoipd, it didn't seem to help, but that might be because I'm trying to race against whatever packets avahi-autoipd is putting out. I even tried starting up the connection, adding the route & immediately running avahi-autoipd -r wlan0, but that didn't change anything either.
Created attachment 411967 [details] Log enhanced with avahi-autoipd output Poking deeper... Running "watch ps afx|grep [^]]avahi" during the connect attempt, I see avahi "probing" then "announcing" then "bound to" the link local address (though ip addr doesn't show that actually happen, so I'm guessing it just calls the supplied "script" to announce the result to NM). Then after a few seconds, NM fails the connection. To see if I could get better detail, I patched NM to have avahi-autoipd output its info to syslog. I'll attach the log. I think I've figured it out -- this smells like a SELinux policy bug -- when I run NetworkManager from the commandline (with --no-daemon and --log-level=debug), it does link-local 4 without any issues (other than to get some file contexts wrong, but that can be fixed).
I filed a bug against SELinux and am linking it to this bug.
Ok, it's a pretty clear indication that if you can run NM from the command-line and it works, then there are policy interactions. You can also run 'setenforce 0' and try to trigger the bug, and if that works, it's clearly a policy problem. So if you wouldn't mind testing that, and if that works (though you've already proven fairly conclusively that it's a policy issue) then we should file another bug against selinux-policy with this information and also the output of 'audit2allow -d'.
Oh, when you file the selinux-policy bug,can you drop this text into it for Dan Walsh or whoever gets it assigned? ------ NM executes avahi-autoipd. avahi-autoipd then chroots, drops privileges to the 'avahi' user & group, and then executes /usr/libexec/nm-avahi-autoipd.action which sends the configuration back to NM via D-Bus. ------ You can also use the "Clone Bug" functionality near the top-right of the page to preserve all the comments and create a new bug, then set the component to selinux-policy. Saves some time.
I've already filed the bug and made it block this bug. See Bug 589539. Running setenforce 0 definitely works.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.