Bug 587845

Summary: IPv4 Link Local connections always fail
Product: [Fedora] Fedora Reporter: Scott Schmit <i.grok>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dcbw
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-03 10:14:24 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 589539    
Bug Blocks:    
Description Flags
/var/log/messages trace of the connection attempt
Log enhanced with avahi-autoipd output none

Description Scott Schmit 2010-04-30 22:56:07 EDT
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 15:00:48 EDT
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 06:13:54 EDT
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 08:29:13 EDT
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 07:21:34 EDT

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 08:11:18 EDT
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 08:12:43 EDT
I filed a bug against SELinux and am linking it to this bug.
Comment 7 Dan Williams 2010-05-06 19:22:23 EDT
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 19:24:01 EDT
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-06 20:04:07 EDT
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 11:55:09 EDT
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 10:14:24 EST
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.