dhclient starts on all interfaces referred to in dhclient.conf regardless of command-line parameters
David W. Hankins
David_Hankins at isc.org
Tue Jun 14 17:15:00 UTC 2005
On Tue, Jun 14, 2005 at 04:09:50PM +1000, Andrew Pollock wrote:
> One of our users has reported a problem whereby when he specifically
> mentions interfaces in his dhclient.conf file, and then later runs
> dhclient on a specific interface, dhclient actually tries to send
> requests out all interfaces.
>=20
> The scenario in this case is interface-specific hostnames are required
> to be sent in the DHCP requests.
>=20
> I have confirmed this behavior with 3.0.2.
>=20
> A full log of the correspondence is at http://bugs.debian.org/270890
>=20
> Is this intended behavior, or is it a bug?
It is an intended behaviour. The user (via the configuration file)
is informing the client of an interface it expects to use. I think
it may be possible with the current implementation that interfaces
added from config can be distinguished from interfaces added by
command line, and adjustments made, but this is a change in behaviour
and fairly hairy to boot, so is best dealt with in a feature release.
What's happening is that dhclient only tracks one list of interfaces.
Interfaces added to this list by being mentioned in the config is
not distinguished from interfaces added to the list from the command
line. It's hard to tell what a user would want here anyway, since
they are entering configuration for the interface, and presumably the
interface does indeed exist.
A common workaround is to use different dhclient.conf files for each
interface you wish to configure with separate dhclient daemons. If
somehow you need to only sometimes use separate daemons and sometimes
use one unified daemon, you can use a third config file which merely
includes the other two.
A similar problem exists in that the way dhclient/dhcpd/dhcrelay
relate to these interfaces is decided only at compile time - you
cannot choose to use berkeley sockets, raw interfaces, or etc at
config time.
I hope someday to solve both issues at the same time - by allowing
a set of configuration syntax to relate the way in which the various
daemons interact with the network. This includes segregating yet
another related issue, choosing what interfaces the daemon should
'receive' and 'transmit' upon (a common complaint of dhcrelay when
it shares a broadcast domain with its parent dhcp server).
--=20
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
More information about the dhcp-hackers
mailing list