ntp now takes servers from the dhcp client without asking, and without
being overridable.  It overwrites servers that were rather
deliberately chosen, and there does not seem to be a config option to
tell it not to do that.  The mere existance of a /etc/ntp.conf.dhcp
file that may or may not be stale and out of date after the event of a
unclean shutdown is enough to tell ntp via the init.d/ntp script to
ignore my own config file.

In the presence of (the default!) *.pool.ntp.org, this is also rather
pointless, IMNSHO.

If you must include both this and the (broken; see #399905) restart
upon dhcp obtaining a new lease, please make it so the admin can
disable it by means other than deleting the script, such that they
will be preserved over upgrades?

Tim Connors wrote:

I quote from /usr/share/doc/ntp/README.Debian.gz:

"""
If DHCP is used to configure the host, and the DHCP server sends
information about NTP servers, then this information will be used
automatically.  This is done by making a copy of /etc/ntp.conf at
/etc/ntp.conf.dhcp, replacing the server entries with the information
provided by the DHCP server, and restarting the NTP server.

In order for this to work, the "ntp-servers" option must be mentioned
in the "request" statement in /etc/dhcp3/dhclient.conf.  This is not
the case in a default installation.  A complete configuration might
look like this, for example:

    request subnet-mask, broadcast-address, time-offset, routers,
            domain-name, domain-name-servers, host-name,
            netbios-name-servers, netbios-scope, interface-mtu,
            ntp-servers;

If you don't like using the NTP servers sent by the DHCP server, this
is also the right place to turn off this behavior.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"""

This was as default, and hence was off.  I won't be on this dhcp network
until at least Monday, and shall try it again then with some debug output.
This may well be a dhcp3 bug.  Perhaps new_ntp_servers is being receieved
and passed on even though not requested.

Did you have a chance to test this?  Do you still think this is a bug in
the ntp package?


Kurt

Thanks for reminding me.  I haven't found myself on the same network yet,
but am currently in the vicinity of it.  I'll see what I can do.

This is the last 24 hours for another month that I'll be able to access
this network, and yes, it is happening.  I put:
---
echo ntp remove
set -xv
echo $reason
set
---
and
---
echo ntp add
set -xv
echo $reason
set
---

at the start of the remove and add functions in
/etc/dhcp3/dhclient-enter-hooks.d/ntp and it is quite clearly being called
with $reason=BOUND
(about third time around after a bunch of times when $reason didn't
match).

This is with
request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers,
        netbios-name-servers, netbios-scope, interface-mtu;
in /etc/dhcp3/dhclient.conf

reassign 407336 dhcp3-client
thanks

This looks like a bug in dhcp3 to me, since it's not requested.


Kurt

I can't reproduce this problem. I ran a DHCP server/client pair, and
where the ntp-servers were not requested, none was included in the
information accessible to the hooks.

Try modifying the debug hooks to include new_ntp_servers and
old_ntp_servers in the list of variables they write out, and enable the
debug hooks whilst acquiring a lease.

regards

Andrew

variables.
reason='BOUND'
interface='eth0'
medium=''
alias_ip_address=''
new_ip_address='150.203.92.87'
new_subnet_mask='255.255.255.0'
new_domain_name='anu.edu.au'
new_domain_name_servers='150.203.92.5'
new_routers='150.203.92.1'
new_static_routes=''
old_ip_address='192.231.166.113'
old_subnet_mask='255.255.255.0'
old_domain_name='aao.gov.au'
old_domain_name_servers='192.231.166.63 192.231.167.64 150.203.1.10'
old_routers='192.231.166.3'
old_static_routes=''
new_ntp_servers='150.203.92.5'
old_ntp_servers=''

So it's being received despite not being asked for.  I tried changing the
shebang line of /sbin/dhclient-script to include a -x, but didn't find
anything of use in there.  Where to from here?

Unfortunately, I don't make a transition to this network very often.

Any thoughts on this?


On a differnet network now with a different laptop, and this time I am
trying to not request domain-name-servers, because
1) netenv is taking care of that for me,
and
2) I am intentionally trying to disable one of the domain name servers
that the dhcp server is sending me, because that DNS server is proving to
be very unreliable.

Despite it not appearing in the request line, it is still being sent to
me, and I am ending up with that dodgy DNS server still ending up in
pdnsd's configuration via resolvconf.

My thoughts are that as well as having the ability to request items from
the dhcp server, we should explicitly get the ability to blacklist
unsolicited crap the dhcp server returns back to us.  I don't *want* my
ntp servers or DNS servers to be changed from underneath me.

retitle 407336 dhclient3: adopts dhcp server's settings despite them not being "request"ed
thanks

I have cut down the settings I want to accept from the server to a bare
minimum:
request subnet-mask, broadcast-address, time-offset, routers, interface-mtu, domain-name-servers;

As well as trying to give me ntp servers to use, which prompted this bug,
it is now giving me a domain name search list too, which resolvconf is
appending to my own list.  I'm not on the network now, so can't show the
debug behaviour, but it gives this strange looking lease with wacky expire
dates:

lease {
  interface "bond0";
  fixed-address 192.168.2.4;
  option subnet-mask 255.255.255.0;
  option routers 192.168.2.1;
  option dhcp-lease-time 4294967295;
  option dhcp-message-type 5;
  option domain-name-servers 150.203.92.5;
  option dhcp-server-identifier 192.168.2.1;
  option interface-mtu 1492;
  option domain-name "Belkin";
  renew 1 2076/03/16 05:47:04;
  rebind 1 2127/03/31 14:12:33;
  expire 6 2144/04/04 09:01:11;
}

"Belkin" ended up being appended to the search list, but I presume it came
from a pushed domain-search rather than "domain-name" option from the
server (I assume not everything sent by the server ends up in
/var/lib/dhcp3/dhclient.leases ?).

Since it is evident that dhcp servers are pushing setting not being
requested of them, perhaps it is time for the dhcp client to ignore
anything it didn't request.

So I've picked this bug up again because I'm trying to clean up some of the
open bugs. I still cannot reproduce this in a test environment.

My understanding is that the DHCP lease file is going to contain everything
that is received from the DHCP server.

My current test was to have the DHCP server providing the ntp-servers option
and the DHCP client not requesting it.

When I *was* requesting the option, it appeared in the lease file, when I
*wasn't* it did not.

I also enabled the debug hooks and added the new_ and old_ntp_servers
variables to the list that was spat out, and when I *wasn't* requesting the
option, there these variables contained nothing (as expected).

I'll continue investigating tonight, specifically because your bug has
similarities with #553023 and I'll look into that one as well.

It seems that the AVM Fritzbox has a DHCP server which triggers this
behavior.  Do you want me to create packet captures?