GNOME Bugzilla – Bug 729354
[enh] track both route protocol and source for better connection matching
Last modified: 2014-05-08 15:22:41 UTC
NM needs to do a better job of excluding automatically-generated (RA, DHCP, kernel) routes when matching connections at startup. To do that, we should do a couple things: 1) track the route's "protocol" (rtnl_route_get_protocol() which returns RTPROT_ defines) independently of the route's source (kernel/ra/etc) 2) set the right route protocol based on the internal route source (eg, NM_PLATFORM_SOURCE_DHCP -> RTPROT_DHCP, NM_PLATFORM_SOURCE_RDISC -> RTPROT_RA) where we have a mapping 3) maybe hijack an RTPROT define for stuff that doesn't have a mapping, so we know it's been added dynamically by NetworkManager? 4) Then, when generating the connection in nm_device_generate_connection(), when adding IP configuration, we somehow tell nm_ip4_config_update_setting() not to add any routes that came from automatic sources like RA/DHCP/etc. We could refactor the 'source' flag to mean 'protocol' instead, and then simply have a gboolean 'external' flag indicating that the route came from outside NetworkManager. Thus we could differentiate between an externally-added RA-protocol route (protocol=RA, source=external) and an NM-added RA-protocol route (protocol=RA, source=internal). --- A second fix is to ignore IPv6 cache routes (flags & RTM_F_CLONED) at the same place, when generating the connection. These routes are temporarily created by the kernel when attempting to contact another host (even with ping6 when the host doesn't exist) and are destroyed by the kernel shortly after. They shouldn't be part of the initial connection generation. --- All this should happen in a generic manner to ensure that the "fake" platform doesn't require rtnetlink #defines or dependencies.
*** This bug has been marked as a duplicate of bug 729203 ***