Description of problem: When using a NetworkManager with a dhcp server, a routing entry is not added for the server if the server is not within the assigned network mask. Version-Release number of selected component (if applicable): NetworkManager-0.9.8.1-3.git20130514.fc18 How reproducible: Always when configured for BOOTPROTO=dhcp Steps to Reproduce: 1. Setup NetworkManager on an interface with BOOTPROTO=dhcp 2. Allow dhcp to configure interface 3. Check the routing tables for the correct routing entry Actual results: No routing entry for the dhcp server is created Expected results: A specific route for the dhcp server should be created. Additional info: Given a configuration such as this one reported in the NetworkManager logs: Jul 10 16:16:41 dhclient[12533]: DHCPREQUEST on em1 to 255.255.255.255 port 67 (xid=0x255b9617) Jul 10 16:16:41 dhclient[12533]: DHCPOFFER from 96.147.132.1 Jul 10 16:16:41 dhclient[12533]: DHCPACK from 96.147.132.1 (xid=0x255b9617) Jul 10 16:16:41 dhclient[12533]: bound to 76.102.27.32 -- renewal in 117479 seconds. Jul 10 16:16:41 NetworkManager[546]: <info> (em1): DHCPv4 state changed preinit -> bound Jul 10 16:16:41 NetworkManager[546]: <info> address 76.102.27.32 Jul 10 16:16:41 NetworkManager[546]: <info> prefix 23 (255.255.254.0) Jul 10 16:16:41 NetworkManager[546]: <info> gateway 76.102.27.1 Jul 10 16:16:41 NetworkManager[546]: <info> nameserver '75.75.75.75' Jul 10 16:16:41 NetworkManager[546]: <info> nameserver '75.75.76.76' a routing entry for 96.147.132.1 should be created, so that if the interface is not the default route, the dhcp server can be contacted. The ISC dhclient-script (/usr/sbin/dhclient-script) performs this correctly in the function is_router_reachable(), by running ip -4 route add ${router}/32 dev ${interface} if the router is not in the new subnet (as in this case). However, NetworkManager uses it's own dhclient script, and does not add the correct route. "ip route list" should include a line similar to 69.252.97.6 via 76.102.27.1 dev em1 after the new address is configured (NOTE: in my case, the server identifier was different that the server that offered the address, but that's the way comcast sets up their dhcp system :)
NOTE: to clarify, this bug will only be visible if the interface is NOT the default route (ie. ifcfg-<interface> with DEFROUTE=no). The bug will cause the address on the interface to eventually expire, and cause the connection to reset (killing all open connections, very annoying especially if you're almost done with your 2G download :).
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is 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 change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Checked against NetworkManager-0.9.9.0-22.git20131003.fc20, and the problem still exists. Changing to F20
As a clarification on the original bug, the routing entry should actually be created for the dhcp-server-identifier (69.252.97.6 in the description above)... the logged "DHCPACK from 96.147.132.1" is actually the relay agent, and doesn't need a routing entry.
Created attachment 846878 [details] Patch to add route for dhcp4-server if needed I've created a patch to add a host routing entry for the dhcp4 server if it's not on the local subnet. I've tested this on my server, and it works as expected. I'm not sure if this makes sense to add for dhcp6 as well, but I can provide a patch for that too easily enough :). I guess the next step is to log an upstream bug as well, and post the patch against git there.
Filed upstream bug.
Created attachment 847421 [details] Updated patch with comment Added rationale for the route in a comment... as requested by upstream.
Created attachment 847935 [details] Latest upstream patch with better logging and device route if no gateway
Upstream bug resolved with commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=31fe84e467732463eabc8f70c2a419008e7a227c . Currently there is no F20 package yet available with this change.
NetworkManager-0.9.9.0-27.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-27.git20131003.fc20
Package NetworkManager-0.9.9.0-27.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-27.git20131003.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1733/NetworkManager-0.9.9.0-27.git20131003.fc20 then log in and leave karma (feedback).
NetworkManager-0.9.9.0-27.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Note that there is discussion to revert the patch of this bug. See https://bugzilla.redhat.com/show_bug.cgi?id=1448987#c4
Note that bug 1448987 basically reverted this change: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=36e97f5d7beba7ab5446c2b7c6c22523b1bca476