Bug 1005416 - NM should treat routes differently depending on their origin
NM should treat routes differently depending on their origin
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: 7.0
Assigned To: Thomas Haller
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-06 16:43 EDT by Thomas Haller
Modified: 2014-06-17 22:48 EDT (History)
5 users (show)

See Also:
Fixed In Version: NetworkManager-0.9.9.0-37.git20140131.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 08:23:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 722843 None None None Never

  None (edit)
Description Thomas Haller 2013-09-06 16:43:58 EDT
This is a bug for tracking the implementation of a new functionality in NetworkManager.


Currently, NM treads all routes the same, regardless how they were configured.
Routes should be tagged internally in NM depending on their origin (e.g. DHCP, RA, static, ...).


One use of this is for example in bug #999544. Currently NM considers the activation of a connection as failed, when a route cannot be set. This makes mostly sense for manually configured routes, because a partial failure of setting a route cannot be displayed to clients. This behaviour might be undesired for routes from DHCP because a wrong configured route on the DHCP server could make the connection unusable.
Comment 2 Dan Williams 2014-01-20 12:52:52 EST
Over to you thomas; I'll try to merge dcbw/vpn-no-iface this week to provide the basis for your work here.  Thanks!
Comment 3 Thomas Haller 2014-01-21 15:09:58 EST
A related discussion to this topic took place at https://bugzilla.gnome.org/show_bug.cgi?id=721771#c20 and following
Comment 4 Thomas Haller 2014-01-23 11:49:38 EST
Created upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=722843
Comment 5 Dan Williams 2014-01-24 12:59:07 EST
vpn-no-iface was merged along with your fix for better handling of externally-sourced routes.
Comment 6 Dan Williams 2014-01-24 12:59:21 EST
vpn-no-iface was merged along with your fix for better handling of externally-sourced routes.
Comment 9 Vladimir Benes 2014-04-28 06:52:04 EDT
reproducer:
setting 192.169.0.128/24 192.168.0.1 with routes to 192.168.0.22 fails localy, 

but after starting dnsmasq with:
interface=enp0s25
dhcp-range=enp0s25,192.169.0.222,192.169.0.229,4h
dhcp-option=121,10.0.0.0/24,192.168.0.22

and connecting from other box I was able co get address and activate connection correctly.

there was a message about failing routes:
Apr 28 12:45:29 dhcp131-232 NetworkManager[941]: <error> [1398681929.384658] [platform/nm-linux-platform.c:1366] add_object(): Netlink error adding 10.0.0.0/24 via 192.168.0.22 dev enp0s25 metric 1 mss 0 src unknown: Unspecific failure
Comment 10 Ludek Smid 2014-06-13 08:23:29 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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