Strange DHCP behaviour

[tony]

Hi,
I'm running a DHCP server (4.3) under Debian Stretch to serve a small
local domain. It behaves well for most clients, but I have a laptop
(also Debian Stretch) for which I wish to assign a fixed address. My
server configuration is this (tony-lt being the laptop):
------------------------------------------------------------------
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# option definitions common to all supported networks...
#option domain-name "example.org";
option domain-name "chalet.vanderhoff.org";
#option domain-name-servers ns1.example.org, ns2.example.org;
option domain-name-servers 192.168.1.1;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

subnet 192.168.1.0 netmask 255.255.255.0
{
        range 192.168.1.200 192.168.1.254;
        option routers 192.168.1.10;
}

host tony-lt
{
        hardware ethernet 0c:60:76:6c:e6:6f;
        fixed-address 192.168.1.199;
}
------------------------------------------------------------------

Despite this configuration I have failed to get that address for the
laptop; it seems to be stuck on 192.168.1.254, currently. It may have
legitimately had that address in the past.

I have stopped and cleared the client via 'dhclient -r', deleted the
files in /var/lib/dhclient, before restarting it with 'dhclient -v, It
immediately requests ..254

I'm seeing this in the server log:
------------------------------------------------------------------
Oct 24 12:52:04 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
from 0c:60:76:6c:e6:6f (tony-lt) via eth0
Oct 24 12:52:04 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
0c:60:76:6c:e6:6f via eth0
Oct 24 12:52:24 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.244
from f4:81:39:82:53:c4 via eth0
Oct 24 12:52:24 router-pi dhcpd[1068]: DHCPACK on 192.168.1.244 to
f4:81:39:82:53:c4 via eth0
Oct 24 12:52:32 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
from 0c:60:76:6c:e6:6f via eth0
Oct 24 12:52:32 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
0c:60:76:6c:e6:6f (tony-lt) via eth0
Oct 24 12:52:41 router-pi dhcpd[1068]: reuse_lease: lease age 9 (secs)
under 25% threshold, reply with unaltered, existing lease for 192.168.1.254
Oct 24 12:52:41 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
from 0c:60:76:6c:e6:6f (tony-lt) via eth0
Oct 24 12:52:41 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
0c:60:76:6c:e6:6f (tony-lt) via eth0
------------------------------------------------------------------

Apart from the rather frequent lease request, which I suspect is due to
NetworkManager on this laptop, what is the 'reuse-lease' comment?

Has anyone any suggestions on how to fix this, please?

Cheers, Tony

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Wed, Oct 24, 2018 at 7:15 AM tony <[hidden email]> wrote:

Hi,
I'm running a DHCP server (4.3) under Debian Stretch to serve a small
local domain. It behaves well for most clients, but I have a laptop
(also Debian Stretch) for which I wish to assign a fixed address. My
server configuration is this (tony-lt being the laptop):
------------------------------------------------------------------
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# option definitions common to all supported networks...
#option domain-name "example.org";
option domain-name "chalet.vanderhoff.org";
#option domain-name-servers ns1.example.org, ns2.example.org;
option domain-name-servers 192.168.1.1;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

#subnet 10.152.187.0 netmask 255.255.255.0 {
#}

# This is a very basic subnet declaration.

subnet 192.168.1.0 netmask 255.255.255.0
{
        range 192.168.1.200 192.168.1.254;
        option routers 192.168.1.10;
}

host tony-lt
{
        hardware ethernet 0c:60:76:6c:e6:6f;
        fixed-address 192.168.1.199;
}
------------------------------------------------------------------

Despite this configuration I have failed to get that address for the
laptop; it seems to be stuck on 192.168.1.254, currently. It may have
legitimately had that address in the past.

I have stopped and cleared the client via 'dhclient -r', deleted the
files in /var/lib/dhclient, before restarting it with 'dhclient -v, It
immediately requests ..254

I'm seeing this in the server log:
------------------------------------------------------------------
Oct 24 12:52:04 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
from 0c:60:76:6c:e6:6f (tony-lt) via eth0
Oct 24 12:52:04 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
0c:60:76:6c:e6:6f via eth0
Oct 24 12:52:24 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.244
from f4:81:39:82:53:c4 via eth0
Oct 24 12:52:24 router-pi dhcpd[1068]: DHCPACK on 192.168.1.244 to
f4:81:39:82:53:c4 via eth0
Oct 24 12:52:32 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
from 0c:60:76:6c:e6:6f via eth0
Oct 24 12:52:32 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
0c:60:76:6c:e6:6f (tony-lt) via eth0
Oct 24 12:52:41 router-pi dhcpd[1068]: reuse_lease: lease age 9 (secs)
under 25% threshold, reply with unaltered, existing lease for 192.168.1.254
Oct 24 12:52:41 router-pi dhcpd[1068]: DHCPREQUEST for 192.168.1.254
from 0c:60:76:6c:e6:6f (tony-lt) via eth0
Oct 24 12:52:41 router-pi dhcpd[1068]: DHCPACK on 192.168.1.254 to
0c:60:76:6c:e6:6f (tony-lt) via eth0
------------------------------------------------------------------

Apart from the rather frequent lease request, which I suspect is due to
NetworkManager on this laptop, what is the 'reuse-lease' comment?

Has anyone any suggestions on how to fix this, please?

Cheers, Tony

In this situation I typically create a 'fake' host reservation for the old IP with a dummy MAC address, which forces the DHCP server to refuse to give out that address.  Once the laptop gets the right IP, then the fake entry can be removed.

-- 

Bob Harold

 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

tony <[hidden email]> wrote:

> Despite this configuration I have failed to get that address for the
> laptop; it seems to be stuck on 192.168.1.254, currently. It may have
> legitimately had that address in the past.

The client is obviously retaining state of the address it once had, and is requesting that address. As the address is available for teh client, it is given it. Some ways to fix it :

Remove the address from the range(s) allowed in the server config. Next time the client requests the address, it will be refused (DHCP-Nack message), the client will then be given it's fixed address.

Split out the address to separate range (in a separate pool) and add "deny booting" to the range. As above, on the next renew the client will be refused.

Add "deny known clients" to the range. The host statement makes the laptop a known client, and so the deny known clients statement will mean that the client is not allowed an address from the range. So as above, next time the client sends a request, it will be refused.
Note that this would affect other hosts with a host statement.

Similar to above, define a class that matches the client and add "deny members of <name of class>" to the range.

Stop the server and edit the leases file. Find the last lease entry for the host and edit it - change the hardware and/or Client-ID fields so that the lease now belongs to a different client. Then start the server again. Next time the client sends a request, it will be denied as the server now thinks that the address belongs to a different client.
The lease will eventually time out and go into the pot to be re-used. It won't be reused until every address in the range(s) has already been used at least once - "never used before" addresses are used before any previously used address is re-used for a different client.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[tony]

On 24/10/2018 21:22, Simon Hobson wrote:

> tony <[hidden email]> wrote:
>
>> Despite this configuration I have failed to get that address for the
>> laptop; it seems to be stuck on 192.168.1.254, currently. It may have
>> legitimately had that address in the past.
>
> The client is obviously retaining state of the address it once had, and is requesting that address. As the address is available for teh client, it is given it. Some ways to fix it :
>
> Remove the address from the range(s) allowed in the server config. Next time the client requests the address, it will be refused (DHCP-Nack message), the client will then be given it's fixed address.
>
> Split out the address to separate range (in a separate pool) and add "deny booting" to the range. As above, on the next renew the client will be refused.
>
> Add "deny known clients" to the range. The host statement makes the laptop a known client, and so the deny known clients statement will mean that the client is not allowed an address from the range. So as above, next time the client sends a request, it will be refused.
> Note that this would affect other hosts with a host statement.
>
> Similar to above, define a class that matches the client and add "deny members of <name of class>" to the range.
>
> Stop the server and edit the leases file. Find the last lease entry for the host and edit it - change the hardware and/or Client-ID fields so that the lease now belongs to a different client. Then start the server again. Next time the client sends a request, it will be denied as the server now thinks that the address belongs to a different client.
> The lease will eventually time out and go into the pot to be re-used. It won't be reused until every address in the range(s) has already been used at least once - "never used before" addresses are used before any previously used address is re-used for a different client.
>

Thanks Simon, and Bob, for your very helpful replies.

Whilst waiting for a response to my cry for help, I continued fiddling,
and deleted the leases file. That seemed to fix thye problem.

Your fix would have been more elegant, maybe I should have waited ...

Thanks, anyway.

Cheers, tony.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

tony <[hidden email]> wrote:

> Whilst waiting for a response to my cry for help, I continued fiddling,
> and deleted the leases file. That seemed to fix thye problem.

For the benefit of others finding this thread ...
In general it is a very bad idea deleting the leases file. In your case, not a problem as you have a small network and still at the testing stage.

But in general, with an active network, you have blown away the record of all the "promises" the server has made to clients. There will be clients with active leases, but the server will have no record of them. At the very best, this can result in churn when clients come back (eg a device that's been switched off is turned on) and their address has been leased to another device - so they get a new address. But what is likely to happen is new clients come along and get offered an address that's already in use - what happens then depends on a number of factors.

If the device already using the address responds to pings, then the server may detect it with it's "ping before offer" function. The address will then be marked as abandoned - and not used again unless you completely run out of free addresses. This results in increased address churn "forever" as part of your pool is never used unless you clean it up (or they get recovered if you run out of addresses which shouldn't happen in a well provisioned network).

If the device doesn't respond to a ping, then the server will offer the address to the client. The client *should* detect that it's already in use and reject the offer - but the server will not stop offering the address to clients, resulting in a lot of "offer-reject" exchanges. If the client is poorly implemented and just accepts the address then you now have two devices using the same address and neither will work properly/at all. Users may or may not (depending on the implementation) get a warning about the duplicate address.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users