Created attachment 504056 [details] syslog output for the duration of a connection attempt until confirmation that routes are not present (but IP addressing is...) Description of problem: Static routes configured in nm-connection-editor (or Gnome applet) are absent once the connection is established. Version-Release number of selected component (if applicable): NetworkManager-0.8.9997-2.git20110531.fc15.i686 NetworkManager-gnome-0.8.9997-2.git20110531.fc15.i686 How reproducible: Always Steps to Reproduce: 1. start nm-connection-editor to edit a (wireless) connection (untested on LAN) 2. Set IPV4 Addressing method to any of Manual, Automatic or Automatic (Addressing only) 3. If Manual, configure an appropriate IP address 4. Select Routes... 5. Add any route with a valid local gateway 6. Connect to the appropriate network Actual results: DHCP or Manual address is correctly obtained, only default route is present as handed out by DHCP server or Manual configuration Expected results: Extra routes should be present when running "route -n" Additional info: Connections to networks is EXTREMELY slow, even when set to Manual addressing. Setting IPv6 to Link-Local only corrected this.
Can you give us the routes you try to apply? You can list them from the connection with: $ nmcli con list id "your connection name" The routes are probably not applied because host part of the destination address is not zeroed and libnl fails to add them (return EINVAL). E.g. try: # ip route add 192.168.1.200/16 via 192.168.1.1 dev wlan0 metric 1 RTNETLINK answers: Invalid argument # ip route add 192.168.0.0/16 via 192.168.1.1 dev wlan0 metric 1 succeeds Patch to work around that in NM: diff --git a/src/nm-system.c b/src/nm-system.c index 88db659..952bf3e 100644 --- a/src/nm-system.c +++ b/src/nm-system.c @@ -128,6 +128,9 @@ nm_system_device_set_ip4_route (const char *iface, g_return_val_if_fail (route != NULL, NULL); /* Destination */ + /* Host bits has to be zeroed, else libnl doesn't set the route and returns EINVAL. + * The address is in network-byte order, so zero from left */ + ip4_dest &= (0xFFFFFFFF >> (32 - ip4_prefix)); dest_addr = nl_addr_build (AF_INET, &ip4_dest, sizeof (ip4_dest)); g_return_val_if_fail (dest_addr != NULL, NULL); nl_addr_set_prefixlen (dest_addr, (int) ip4_prefix); Maybe We should file a bug against netlink.
Hmmm... I had a host route and a net route added, take out the host route and the net route succeeds. However, ip route add 192.168.1.5/32 succeeds, but adding the same line in the connection GUI fails. See output in attachment. with a /32, all bits are significant, netlink gets it just fine.
Created attachment 504126 [details] nmcli and ip route output showing failure to add static (host) route
> ipv4.routes: { dst = 192.168.1.5/32, nh = 192.168.1.8, mt = 1 } The route is not added intentionally. The route dst address is on the same subnet as specified in the interface. In that case, the destination is accessible without gateway. I think, IP configured on your interface is something like 192.168.1.3/24. So if the route dest addresses is more specific that 168.192.1.x/24, it won't be added. Though, routes such as these would get applied: { dst = 192.168.2.5/32, nh = 192.168.1.8, mt = 1 } { dst = 192.168.0.0/16, nh = 192.168.1.8, mt = 1 } The code is in src/nm-system.c:nm_system_apply_ip4_config() /* Don't add the route if it's more specific than one of the subnets * the device already has an IP address on. */ if (ip4_dest_in_same_subnet (config, nm_ip4_route_get_dest (route), nm_ip4_route_get_prefix (route))) continue;
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping