Hi! It turns out that dhcpcd 6.11.5 can set static routes passed by the DHCP server fine while 7.x.x cannot (tried 7.0.1 and 7.0.5). Syslog reads [dhcpcd] if_route (ADD): Network is unreachable and the error has been reported at https://forums.gentoo.org/viewtopic-p-8235420.html#8235420 by another user before. Downgrade to 6.11.5 fixes the issue. Best, Sebastian
The forum post lists classless static routes - different from normal static routes in DHCP parlance. My testing shows it works fine. I asked for an exact ISC dhcpd.conf file I can put on my test server to replicate the issue, but so far non is forth-coming. If privacy is a concern (for whatever reason) about posting it publically, please email it to me - roy@marples.name.
Hi Roy, thanks for your interest! I don't have access to that DHCP server's config myself. I'm optimistic that I can get you a copy. Please stay tuned.
What I learned more now: * It's OpenStack Neutron with dnsmasq * It's indeed _classless_ static routes with /24 ranges
The error seems to be caused by host routes. This fix seems to fix it for me, hopefully nothing else is broken as DHCP routing can be tricky. https://roy.marples.name/git/dhcpcd.git/commit/?id=d3753a8676f88ddf4a29218904dbe2701c948157
Thanks Roy, I can confirm this is regarding the magic route 169.254.169.254/32 that OpenStack Neutron uses in order for an instance to reach the OpenStack metadata server. Using dhcpcd 6.x this worked like a charm, in 7.x it no longer does. Once Sebastian provides me with a new image that contains your fix I will be able to verify that DHCP host routes (hence reachability of the metadata server) are back to normal again.
(In reply to Roy Marples from comment #4) > https://roy.marples.name/git/dhcpcd.git/commit/ > ?id=d3753a8676f88ddf4a29218904dbe2701c948157 I have installed 9999 with that fix in VM talking to that very DHCP server, rebooted, and checked "ip route" output for the expected route: Passed. I believe we're good to go.
Good news! I added a related fix here after some more code review: https://roy.marples.name/git/dhcpcd.git/commit/?id=2bbafa97f6c577aa6fda7a827a11b58f3c3f01e5 Can you test that also please? My testing shows that it still works fine.
(In reply to Roy Marples from comment #7) > Good news! > > I added a related fix here after some more code review: > https://roy.marples.name/git/dhcpcd.git/commit/ > ?id=2bbafa97f6c577aa6fda7a827a11b58f3c3f01e5 > > Can you test that also please? > My testing shows that it still works fine. Looks like it still works, yes. My testing process was: * Create Gentoo VM * SSH into VM * On the Shell: sudo -s echo '=net-misc/dhcpcd-9999' \ > /etc/portage/package.unmask/net-misc--dhcpcd--9999 echo '=net-misc/dhcpcd-9999 **' \ > /etc/portage/package.keywords/net-misc--dhcpcd--9999 emerge -av =net-misc/dhcpcd-9999 etc-update --automode -5 reboot * SSH into VM again * On the Shell: ip roote
This should now be fixed in dhcpcd-7.0.7 which is now in portage.
(In reply to Roy Marples from comment #9) > This should now be fixed in dhcpcd-7.0.7 which is now in portage. I'll close it as fixed. Many thanks!
