Bug 1313091
| Summary: | the restart of NetworkManager service disables a configured connection and creates a dynamic connection | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | João Avelino Bellomo Filho <jbellomo> |
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> |
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | aloughla, bgalvani, dcbw, fhirtz, lrintel, ptalbert, rkhan, thaller, vbenes |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-1.4.0-0.1.git20160606.b769b4df.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-03 19:08:17 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1350679 | ||
|
Description
João Avelino Bellomo Filho
2016-02-29 22:44:37 UTC
(In reply to João Avelino Bellomo Filho from comment #0) > Description of problem: > > A restart of the NetworkManager service disables a connection and create a > dynamic connection to the NIC related to the connection disabled. > # head -n 100 /etc/sysconfig/network-scripts/ifcfg-conn* > ==> /etc/sysconfig/network-scripts/ifcfg-conn0 <== > TYPE=Ethernet > BOOTPROTO=none > IPADDR=10.1.1.25 > PREFIX=32 > GATEWAY=10.1.1.1 > DEFROUTE=no What confuses NM is the presence of both a GATEWAY and DEFROUTE=no (which indicates not to set a default route). After a restart of the service, the connection matching code doesn't find a default route associated with the connection and discards conn0 as a possible match. NM should handle better this situation; however the configuration as written has some conflicting keys which should be fixed. I think ifcfg-rh should probably ignore GATEWAY when DEFROUTE=no and certainly warn about the configuration. (In reply to Dan Williams from comment #3) > I think ifcfg-rh should probably ignore GATEWAY when DEFROUTE=no and > certainly warn about the configuration. Right, but I wonder if this should be fixed at a higher level, because there is the same problem when using the keyfile plugin. Maybe consider this as a normalizable error during verify of NMSettingIPConfig and remove the gateway during normalization? The downside is that when never-default is enabled and a user adds a gateway it will silently disappear, which is kind of unexpected. IMO we should do the following: - ignore the gateway if never-default is set when loading a connection in both the ifcfg-rh and keyfile plugins, so that existing configurations continue to work - make gateway and never-default mutually exclusive and consider the IP setting invalid if both are present, so that users cannot create ambiguous configurations Please review branch bg/gateway-never-default-rh1313091. This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Having similar problems in Fedora 24 (See https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/Z3T5B4TDMMGEH45ZIH5PCBCB5VJVN45I/) (In reply to Joachim Backes from comment #9) > Having similar problems in Fedora 24 (See > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/ > thread/Z3T5B4TDMMGEH45ZIH5PCBCB5VJVN45I/) Hi, can you please show the output of 'nmcli c' before and after the restart? (In reply to Beniamino Galvani from comment #5) > IMO we should do the following: > > - ignore the gateway if never-default is set when loading a > connection in both the ifcfg-rh and keyfile plugins, so that > existing configurations continue to work > > - make gateway and never-default mutually exclusive and consider the > IP setting invalid if both are present, so that users cannot create > ambiguous configurations > > Please review branch bg/gateway-never-default-rh1313091. >> libnm-core: don't allow a gateway to be set with never-default this is a change in behavior on D-Bus: if a user happens to send Update(), the connection would now fail verification and be rejected. That might be right. But an alternative would be to make this a normalizable error and fix it during normalization. Then you also don't need the change to keyfile, because it would just be normalized. (you would need the change to ifcfg-rh, if you want to print a warning about it). (In reply to Thomas Haller from comment #11) > this is a change in behavior on D-Bus: if a user happens to send Update(), > the connection would now fail verification and be rejected. That might be > right. Yeah, unfortunately this changes behavior, however I'm not sure if it's worse than accepting an inconsistent configuration and report success. > But an alternative would be to make this a normalizable error and fix it > during normalization. > Then you also don't need the change to keyfile, because it would just be > normalized. > (you would need the change to ifcfg-rh, if you want to print a warning about > it). Sounds like a better idea to me, pushed bg/gateway-never-default-rh1313091-v2. I like v2. lgtm looks good to me too GW and never-default is working well over NM restart. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2581.html |