Red Hat Bugzilla – Bug 1251644
dhclient-script does not respect DEFROUTE/GATEWAYDEV if Classless Static Routes are offered
Last modified: 2015-10-31 22:38:37 EDT
Description of problem: There is no code in dhclient-script handling the case when Classless Static Routes option (RFC3442) is present and DEFROUTE/GATEWAYDEV variables are set in network configuration scripts. This leads to installing default gateway even if DEFROUTE=no and/or GATEWAYDEV is set to another interface Version-Release number of selected component (if applicable): dhcp-client-4.3.2-12.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. Set dhcp server to offer Classless Static Routes dnsmasq example (from neutron dhcp agent): tag:tag0,option:classless-static-route,192.168.128.80/28,192.168.128.17,0.0.0.0/0,192.168.128.17 tag:tag0,249,192.168.128.80/28,192.168.128.17,0.0.0.0/0,192.168.128.17 tag:tag0,option:router,192.168.128.17 tag:tag0,option:dns-server,192.168.128.18 2.on the client machine/instance issue: dhclient -4 -d -v -e DEFROUTE=no ethX 3. Actual results: dhcp offered gateway is installed Expected results: gateway should not be installed Additional info: I tested it with package from rawhide but the behavior is the same every supported Fedora/RHEL/CentOS version
Little follow-up: that's example of the lease which client is getting in such case: # dhclient -4 -d -v -sf /bin/true -lf /dev/stdout eth1 Internet Systems Consortium DHCP Client 4.3.2 Copyright 2004-2015 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth1/fa:16:3e:9e:0b:55 Sending on LPF/eth1/fa:16:3e:9e:0b:55 Sending on Socket/fallback Created duid \000\001\000\001\035X\223d\372\026>\236\013U. default-duid "\000\001\000\001\035X\223d\372\026>\236\013U"; DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4 (xid=0x2df9680d) DHCPREQUEST on eth1 to 255.255.255.255 port 67 (xid=0x2df9680d) DHCPOFFER from 192.168.128.2 DHCPACK from 192.168.128.2 (xid=0x2df9680d) lease { interface "eth1"; fixed-address 192.168.128.5; option subnet-mask 255.255.255.240; option routers 192.168.128.1; option dhcp-lease-time 86400; option dhcp-message-type 5; option domain-name-servers 192.168.128.2; option dhcp-server-identifier 192.168.128.2; option dhcp-renewal-time 43200; option classless-static-routes 28.192.168.128.208 192.168.128.1,0 192.168.128.1; option broadcast-address 192.168.128.15; option dhcp-rebinding-time 75600; option host-name "host-192-168-128-5"; option domain-name "openstacklocal"; renew 6 2015/08/08 20:09:24; rebind 0 2015/08/09 07:16:04; expire 0 2015/08/09 10:16:04; }
Created attachment 1060560 [details] proposed fix for the issue This fixes my issue with minimal edit. Also I found that logic there doesn't not conform to RFC 3442 and took a liberty to reorder things slightly. That part actually can be ignored. Maybe its that way because of some broken dhcp server implementations.
(In reply to Jetchko Jekov from comment #2) > Also I found that logic there doesn't not conform to RFC 3442 and took a > liberty to reorder things slightly. That part actually can be ignored. Not sure what part is mandatory and which can be ignored so I've merged the patch as it is. Thank you.
Well as the comment in the script says as well as the RFC3442 itself: "If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option." But the script was setting new_routers="" only if there is a default route included in the "classless static routes" option. So I just moved that part outside of the if [ "${target}" = "0" ] construct. This I meant to be ignored if deemed necessary. I don't know can there be a way when the dhcp client receives something in the |router" option but the "classless static routes" option doesn't include it as a route. Anyway RFC is quite specific with using *MUST*.
dhcp-4.3.3-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15078
dhcp-4.3.3-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update dhcp'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15078
dhcp-4.3.3-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Jacob, Jiri, I can't help but notice that by putting the 'new_routers=""' line within the for loop, it will always reset the 'new_routers' value even if it has ALREADY been set from the classless_static_routes option. This is not a problem if the default route is the last one in the list. This does appear to be the case in the DHCP server that I'm using, but looking at the RFC spec I don't see anything that requires the default route to be last. So unless, I'm missing something the 'new_routers=""' line should be moved to a separate if statement before the for loop OR just deleted and go back to the slightly not fully RFC compliant behavior of accepting the routers options for the default route if not default route is specified in the classless_static_routes options. Thanks!
Created attachment 1080160 [details] Fix for gateway not in the end of rfc3442 routes list Hi, You are right of course. I tried to come with least intrusive patch as possible and apparently I screwed it up for cases like you are describing ... Will this patch fix this problem? ( I am not in the office and haven't tested it yet )
dhcp-4.3.3-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c623227339
dhcp-4.3.3-5.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update dhcp' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c623227339
dhcp-4.3.3-5.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.