After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 682616 - NM copies routing cache entries to main table
NM copies routing cache entries to main table
Status: RESOLVED DUPLICATE of bug 671767
Product: NetworkManager
Classification: Platform
Component: general
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2012-08-24 15:08 UTC by Philippe Gauthier
Modified: 2012-08-29 09:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philippe Gauthier 2012-08-24 15:08:13 UTC
The following is a bug that was posted on Ubuntu's bug tracker, but is also affecting other distributions. I am trying to use the Babel routing daemon on a system, and the described Network Manager behaviour is affecting it because it can make Babel publish all the routing cache entries to the mesh network.

The original bug report was posted at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1038541 and includes a patch and a temporary workaround.


Original description by Ben Jencks :

Any time an IPv6 route lookup happens, the kernel generates a new routing cache entry and notifies userspace using a netlink "new route" message with the RTM_F_CLONED flag set on the route.

Network Manager doesn't check for this flag, so it accepts it as a new real route and adds it to its internal route cache. Then, because the event triggers an interface update, it synchronizes its route cache with the kernel table, putting the cache entry in as a real host route.

I think NM might also overwrite the next hop of the route based on its internal idea of the default route, but I'm not sure.

This causes problems if you have interfaces not managed by NetworkManager, such as manually configured VPNs, since these host routes override the route entries that send traffic down those interfaces rather than to the default router.

To reproduce:
Ensure "Ignore automatically obtained routes" is unchecked in Edit Connection -> IPv6 -> Routes, because this blocks the last stage (copying the spurious route back to the kernel).
Connect to an IPv6 network.
run `ip -6 route` and observe no extra routes
run `ip -6 route get 2600::`
run `ip -6 route` again and observe the new static route to 2600:: via your default gateway

Expected behavior:
No changes to routing table due to a route lookup.
Comment 1 Pavel Simerda 2012-08-29 09:46:34 UTC

*** This bug has been marked as a duplicate of bug 671767 ***