Bug 21794

Summary: DHCP Renewal discards gateway route in some configurations
Product: Mageia Reporter: Frank Griffin <ftg>
Component: RPM PackagesAssignee: GNOME maintainers <gnome>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Normal CC: marja11, pterjan
Version: Cauldron   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: networkmanager CVE:
Status comment:

Description Frank Griffin 2017-10-01 04:59:32 CEST
This report is more for documentation than seeking a fix, so that others seeing the symptoms will have a reference.

The system involved is a desktop with two wired NICs one of which is not cabled to anything (intentionally, it's a 100MB on-mainboard unit; the other is a 1 GB card).

For years, I installed systems via network install using the active NIC, and during Summary I would configure the NIC as DHCP with "allow NM" set to the default of "auto" (I've never known what this means).  I also install NM and enable it, as I do on all my systems, using a NetworkManager.conf which does not include the rh keyword, just keyfile (as the rpm-supplied conf file does now too).

About 6 months ago, the system would periodically drop into a state where it could reach other LAN systems, but got "network not accessible" errors trying to get to hosts on the external internet.  A workaround of ifdown/ifup would correct this.

When I finally found time to diagnose this, the cause turned out to be that something was deleting the gateway entry in the routing table.

For example, the routing table would start as:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.100   0.0.0.0         UG    5      0        0 enp2s0
169.254.0.0     0.0.0.0         255.255.0.0     U     5      0        0 enp2s0
192.168.3.0     0.0.0.0         255.255.255.0   U     5      0        0 enp2s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

while after the change it would be:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.0.0     0.0.0.0         255.255.0.0     U     5      0        0 enp2s0
192.168.3.0     0.0.0.0         255.255.255.0   U     5      0        0 enp2s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Checking journalctl, I could narrow the timeframe for the change to suspiciously close to the time of DHCP renewal being handled by NM.  Figuring that this could be a conflict between net-applet and NM, I used MCC to remove the enp2s0 interface and then ran nmtui to activate it under NM alone.  The problem persisted.

Then I stopped and disabled NM, and redefined the interface with drakconnect.  The problem went away.

The NM docs say that NM reconstructs the routing table, but they don't say how.  Apparently something in this configuration causes it to delete the gateway line.  This does not happen with wireless NICs on any of my other systems with identical setups except for the one unused NIC.
Comment 1 Marja Van Waes 2017-10-01 14:18:32 CEST
Thanks, Frank!

Assignee: bugsquad => gnome
CC: (none) => marja11

Comment 2 Pascal Terjan 2017-10-01 16:06:06 CEST
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=bea6d05c1d3a92a14fd62267584e99b15f88687d may prevent triggering the bug.

(The patch prevents NM from deleting + adding the route if it did not change. In your case it seems it deletes it and does not add it back so not deleting it in the first place could help.

CC: (none) => pterjan

Comment 3 Frank Griffin 2017-10-01 20:41:49 CEST
Good catch !  If the maintainer can apply the patch, I'll revert my changes to test it.
Comment 4 Frank Griffin 2019-02-19 17:12:06 CET
I haven't seen this lately, so I assume the patch was applied and works.

Status: NEW => RESOLVED
Resolution: (none) => FIXED