dhclient sending requests on multiple interfaces when interface clause present in dhclient.conf
name: Bug report
about: Create a report to help us improve
Describe the bug dhclient is sending requests on multiple interfaces when an interface clause is present in dhclient.conf.
To Reproduce Steps to reproduce the behavior:
- Configure dhclient with an interface clause to request specific options on only that interface. Example config:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
host-name, netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes;
interface "ens192" {
also request domain-name, domain-name-servers, domain-search,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
dhcp6.sntp-servers, ntp-servers;
}
- Run dhclient on an interface other than the one with the interface clause in dhclient.conf. For example, execute dhclient on ens224 when the interface clause in dhclient.conf is for ens192
$dhclient ens224 -v
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens192/00:50:56:8d:62:f5
Sending on LPF/ens192/00:50:56:8d:62:f5
Listening on LPF/ens224/00:50:56:8d:d0:0f
Sending on LPF/ens224/00:50:56:8d:d0:0f
Sending on Socket/fallback
DHCPREQUEST for 11.0.1.55 on ens192 to 255.255.255.255 port 67
DHCPREQUEST for 11.0.2.55 on ens224 to 255.255.255.255 port 67
DHCPACK of 11.0.1.55 from 11.0.1.10
RTNETLINK answers: File exists
bound to 11.0.1.55 -- renewal in 35039 seconds.
- Observe dhclient sends requests on both ens192 and ens224
Expected behavior I Expected dhclient to only send a request on ens224. Based on the documentation for dhclient.conf:
interface "name" { declarations ... } A client with more than one network interface may require differ- ent behaviour depending on which interface is being configured. All timing parameters and declarations other than lease and alias declarations can be enclosed in an interface declaration, and those parameters will then be used only for the interface that matches the specified name. Interfaces for which there is no in- terface declaration will use the parameters declared outside of any interface declaration, or the default settings
Based on the wording above, I expect the interface being configured is the one passed to dhclient. I may be misunderstanding the documentation of how the interface clause in dhclient.conf is expected to work.
Environment:
-
dhclient: isc-dhclient-4.4.1
-
OS: Debian GNU/Linux 11 (bullseye)
-
Default package in Debian 11
Additional Information running dhclient on the interface with the interface clause (ens192) works as expected and only send requests on that interface:
$dhclient ens192 -v
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/ens192/00:50:56:8d:62:f5
Sending on LPF/ens192/00:50:56:8d:62:f5
Sending on Socket/fallback
DHCPREQUEST for 11.0.1.55 on ens192 to 255.255.255.255 port 67
DHCPACK of 11.0.1.55 from 11.0.1.10
bound to 11.0.1.55 -- renewal in 34541 seconds.
Some initial questions
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Tried compiling v4_4_3 from source and same behavior was observed
- Are you sure what you would like to do is not possible using some other mechanisms? Technically possible with supersede, not ideal
Describe the solution you'd like I would like dhclient to only send and listen on the interface dhclient is run on
Describe alternatives you've considered I could accomplish the end goal with the supersede statements, however then when network changes are made, the supersede on each client needs to be updated.
Participating in development Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? Yes
Contacting you How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them. email/github