Bug 1251644 - dhclient-script does not respect DEFROUTE/GATEWAYDEV if Classless Static Routes are offered
Summary: dhclient-script does not respect DEFROUTE/GATEWAYDEV if Classless Static Rout...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-08 10:14 UTC by Jetchko Jekov
Modified: 2015-11-01 02:38 UTC (History)
3 users (show)

Fixed In Version: 4.3.3-1.fc23 dhcp-4.3.3-5.fc23
Clone Of:
Environment:
Last Closed: 2015-11-01 02:38:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
proposed fix for the issue (1.05 KB, patch)
2015-08-08 10:26 UTC, Jetchko Jekov
no flags Details | Diff
Fix for gateway not in the end of rfc3442 routes list (1.20 KB, patch)
2015-10-06 07:55 UTC, Jetchko Jekov
no flags Details | Diff

Description Jetchko Jekov 2015-08-08 10:14:50 UTC
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

Comment 1 Jetchko Jekov 2015-08-08 10:18:41 UTC
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;
}

Comment 2 Jetchko Jekov 2015-08-08 10:26:35 UTC
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.

Comment 3 Jiri Popelka 2015-08-11 14:19:51 UTC
(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.

Comment 4 Jetchko Jekov 2015-08-11 19:41:37 UTC
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*.

Comment 5 Fedora Update System 2015-09-04 09:43:36 UTC
dhcp-4.3.3-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15078

Comment 6 Fedora Update System 2015-09-04 23:22:23 UTC
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

Comment 7 Fedora Update System 2015-09-06 01:09:12 UTC
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.

Comment 8 Fedora Update System 2015-09-06 17:04:39 UTC
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.

Comment 9 jay.rhine 2015-10-05 19:57:41 UTC
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!

Comment 10 Jetchko Jekov 2015-10-06 07:55:00 UTC
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 )

Comment 11 Fedora Update System 2015-10-13 13:45:45 UTC
dhcp-4.3.3-5.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c623227339

Comment 12 Fedora Update System 2015-10-14 02:13:13 UTC
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

Comment 13 Fedora Update System 2015-11-01 02:38:34 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.