Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 587845 - IPv4 Link Local connections always fail
Summary: IPv4 Link Local connections always fail
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
Depends On: 589539
TreeView+ depends on / blocked
Reported: 2010-05-01 02:56 UTC by Scott Schmit
Modified: 2010-12-03 15:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-03 15:14:24 UTC

Attachments (Terms of Use)
/var/log/messages trace of the connection attempt (deleted)
2010-05-01 02:56 UTC, Scott Schmit
no flags Details
Log enhanced with avahi-autoipd output (deleted)
2010-05-06 12:11 UTC, Scott Schmit
no flags Details

Description Scott Schmit 2010-05-01 02:56:07 UTC
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):

How reproducible:

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?)

Comment 1 Scott Schmit 2010-05-02 19:00:48 UTC
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.)

Comment 2 Dan Williams 2010-05-03 10:13:54 UTC
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.

Comment 3 Dan Williams 2010-05-03 12:29:13 UTC
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:

Comment 4 Scott Schmit 2010-05-04 11:21:34 UTC

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.

Comment 5 Scott Schmit 2010-05-06 12:11:18 UTC
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).

Comment 6 Scott Schmit 2010-05-06 12:12:43 UTC
I filed a bug against SELinux and am linking it to this bug.

Comment 7 Dan Williams 2010-05-06 23:22:23 UTC
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'.

Comment 8 Dan Williams 2010-05-06 23:24:01 UTC
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.

Comment 9 Scott Schmit 2010-05-07 00:04:07 UTC
I've already filed the bug and made it block this bug. See Bug 589539.

Running setenforce 0 definitely works.

Comment 10 Bug Zapper 2010-11-03 15:55:09 UTC
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:

Comment 11 Bug Zapper 2010-12-03 15:14:24 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.