Bug 1334884

Summary: Fails to finish connect to ethernet after update to F24
Product: [Fedora] Fedora Reporter: Milan Crha <mcrha>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 24CC: bgalvani, dcbw, fgiudici, lkundrak, lrintel, mcrha, psimerda, sgraf, thaller
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.2.4-2.fc24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-19 19:50:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
[PATCH] libnm-core: ip-config: normalize may-fail for disabled IP methods
none
[PATCH v2] libnm-core: ip-config: normalize may-fail for disabled IP methods none

Description Milan Crha 2016-05-10 17:45:02 UTC
I just updated from Fedora 23 to Fedora 24 using `dnf distro-sync ...` and rebooted the machine, when an ethernet connection fails to finish. The spinning circle says:

   Requesting an ethernet network address for 'em1'...

and doesn't seem to get anywhere. The WiFi connection luckily works. This is with NetworkManager 1.2.0-1.fc24.x86_64.

I tried couple older versions and ended with NetworkManager 1.2.0-0.6.beta1.fc24.x86_64, which connects to the ethernet instantly.

I do not think there is anything special about that connection, the IPv6 is disabled (set to "Ignore"), the rest seems to be pretty much standard, using DHCP.

-----------------------------------------------------------------------------

When I run:

   # dnf clean all
   # dnf update --enablerepo=fedora --enablerepo=updates \
          --enablerepo=updates-testing

the only list of packages to update, as of now, are:

   NetworkManager x86_64 1:1.2.0-1.fc24 updates-testing
   NetworkManager-adsl...
   NetworkManager-bluetooth...
   NetworkManager-config-connectivity-fedora...
   NetworkManager-glib...
   NetworkManager-libnm...
   NetworkManager-team...
   NetworkManager-wifi...
   NetworkManager-wwan...

Comment 1 Beniamino Galvani 2016-05-11 08:58:10 UTC
Can you please uncomment "level=TRACE" in /etc/NetworkManager/NetworkManager.conf, run "systemctl restart NetworkManager" and when the issue happens, attach the output of "journalctl -u NetworkManager -b"? Thanks!

Comment 3 Beniamino Galvani 2016-05-11 13:07:33 UTC
A quick fix for this should be:

 $ nmcli connection mod em1 ipv6.may-fail yes

(or uncheck "require ipv6 addressing to complete" in nm-applet).

The reason is that since commit 7d1709d7f649 ("device: check may_fail
when progressing to IP_CHECK"), NM will not progress the activation if
IPv6 doesn't reach IP_DONE (unless may-fail=yes). But when the
ipv6.method is set to 'ignore' the IPv6 status goes to IP_FAIL
instead of IP_DONE, and thus IPv6 is never considered completed.

I think this is wrong, I'll prepare a patch.

Comment 4 Beniamino Galvani 2016-07-01 15:32:50 UTC
Created attachment 1174983 [details]
[PATCH] libnm-core: ip-config: normalize may-fail for disabled IP methods

Comment 5 Thomas Haller 2016-07-05 08:51:07 UTC
(In reply to Beniamino Galvani from comment #4)
> Created attachment 1174983 [details]
> [PATCH] libnm-core: ip-config: normalize may-fail for disabled IP methods

     _("property cannot be TRUE when method is set to ignore"));
                           ^^^^ FALSE


- return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
+ return NM_SETTING_VERIFY_NORMALIZABLE;

You can also make the verify() failures NORMALIZABLE. In this case, nm_connection_verify() still returns TRUE, but nm_connection_normalize() has something to fix.
For NM core, it doesn't matter because it always just right away normalizes the connection. For a client, the difference is, that an ill connection appears to be valid.
It seems to me, that as we previously allowed for such configurations, we should not start marking them invalid now. Thus, NM_SETTING_VERIFY_NORMALIZABLE is preferable.
Then, also add a comment:
  /* Failures from here on, are NORMALIZABLE... */




rest lgtm.

Comment 6 Beniamino Galvani 2016-07-05 11:44:30 UTC
Created attachment 1176389 [details]
[PATCH v2] libnm-core: ip-config: normalize may-fail for disabled IP methods

(In reply to Thomas Haller from comment #5)
> 
>      _("property cannot be TRUE when method is set to ignore"));
>                            ^^^^ FALSE

Ok; changed to "should be TRUE" because NORMALIZABLE is returned now.
 
> You can also make the verify() failures NORMALIZABLE. In this case,
> nm_connection_verify() still returns TRUE, but nm_connection_normalize() has
> something to fix.
> For NM core, it doesn't matter because it always just right away normalizes
> the connection. For a client, the difference is, that an ill connection
> appears to be valid.
> It seems to me, that as we previously allowed for such configurations, we
> should not start marking them invalid now. 

Right, fixed in v2.

Comment 7 Francesco Giudici 2016-07-05 12:27:38 UTC
lgtm

Comment 8 Thomas Haller 2016-07-05 13:16:27 UTC
(In reply to Beniamino Galvani from comment #6)
> Created attachment 1176389 [details]
> [PATCH v2] libnm-core: ip-config: normalize may-fail for disabled IP methods

If a NMSetting has multiple invalid conditions, then verify() *must* return the most severe error status.

nm-setting-ip6-config.c:verify() gets that wrong.

If a connection has
  ipv6.method="ignore"
  ipv6.may-fail=no
  ipv6.token=::0:1
then then entire setting is invalid (due to a non-normalized token). thus, the function should return NORMALIZABLE_ERROR. In v2, it wouldn't.

that's what the comment 
  /* Failures from here on are NORMALIZABLE... */
means.
But it must come after
  /* Failures from here on are NORMALIZABLE_ERROR... */

Comment 9 Thomas Haller 2016-07-05 13:17:23 UTC
rest lgtm

Comment 10 Beniamino Galvani 2016-07-06 08:16:35 UTC
(In reply to Thomas Haller from comment #8)
> If a NMSetting has multiple invalid conditions, then verify() *must* return
> the most severe error status.

Fixed and applied to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ac73758305faf938318e6c888faf8bc954b8289d

nm-1-2:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-2&id=b5b7260873563d5f1a5bced3f2c98d7d1df7f8b4

Comment 11 Fedora Update System 2016-08-05 07:53:17 UTC
NetworkManager-1.2.4-1.fc24 network-manager-applet-1.2.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f739ece3cf

Comment 12 Fedora Update System 2016-08-05 21:21:48 UTC
NetworkManager-1.2.4-1.fc24, network-manager-applet-1.2.4-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-f739ece3cf

Comment 13 Fedora Update System 2016-08-18 16:39:23 UTC
NetworkManager-1.2.4-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364

Comment 14 Fedora Update System 2016-08-19 00:57:02 UTC
NetworkManager-1.2.4-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364

Comment 15 Fedora Update System 2016-08-19 10:29:31 UTC
network-manager-applet-1.2.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f739ece3cf

Comment 16 Fedora Update System 2016-08-19 19:49:47 UTC
NetworkManager-1.2.4-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.