Re: strange DHCP behaviour
On 24/10/2018 08:19, Reco wrote:
> Hi.
>
> On Tue, Oct 23, 2018 at 03:56:34PM +0200, Tony van der Hoff wrote:
>> The DHCP server is another Stretch system, with the stanzas
>> host tony-lt {
>> hardware ethernet 0c:60:76:6c:e6:6f;
>> fixed-address 192.168.1.199;
>> }
>> 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;
>> }
>>
>> That MAC is correct for the laptop.
>>
>
>> Finally, the server shows:
>> Oct 23 14:23:38 routerpi dhcpd[1068]: DHCPREQUEST for 192.168.1.253 from
>> 0c:60:76:6c:e6:6f (tony-lt) via eth0
>> Oct 23 14:23:38 routerpi dhcpd[1068]: DHCPACK on 192.168.1.253 to
>> 0c:60:76:6c:e6:6f (tony-lt) via eth0
>> Oct 23 14:23:53 routerpi dhcpd[1068]: reuse_lease: lease age 15 (secs)
>> under 25% threshold, reply with unaltered, existing lease for 192.168.1.253
>> Oct 23 14:23:53 routerpi dhcpd[1068]: DHCPREQUEST for 192.168.1.253 from
>> 0c:60:76:6c:e6:6f (tony-lt) via eth0
>> Oct 23 14:23:53 routerpi dhcpd[1068]: DHCPACK on 192.168.1.253 to
>> 0c:60:76:6c:e6:6f (tony-lt) via eth0
>>
>> So, my question: why is the server handing out .253, when it is
>> configured to provide .199?
>
> Because client specifically asks for .253 address:
>
>> Oct 23 14:23:38 routerpi dhcpd[1068]: DHCPREQUEST for 192.168.1.253 from
>> 0c:60:76:6c:e6:6f (tony-lt) via eth0
>
Agree fully.
> And, to quote dhcpd.conf:
>
> There may be a host declaration matching the client’s identification. If
> that host declaration contains a fixed-address declaration that lists an
> IP address that is valid for the network segment to which the client is
> connected. In this case, the DHCP server will never do dynamic address
> allocation. In this case, the client is required to take the address
> specified in the host declaration. If the client sends a DHCPREQUEST for
> some other address, the server will respond with a DHCPNAK.
>
Yes, agree again.
> When the DHCP server allocates a new address for a client (remember,
> this only happens if the client has sent a DHCPDISCOVER), it first looks
> to see if the client already has a valid lease on an IP address, or if
> there is an old IP address the client had before that hasn’t yet been
> reassigned. In that case, the server will take that address and check it
> to see if the client is still permitted to use it. If the client is no
> longer permitted to use it, the lease is freed if the server thought it
> was still in use - the fact that the client has sent a DHCPDISCOVER
> proves to the server that the client is no longer using the lease.
>>
> You assume that a 'host' entry overrides any previous IP assignment.
> It's not.
>
No, When a client issues a DHCPREQUEST which the server doesn't like,
the server should issue a DHCPNAK, to which the client will respond with
a DHCPDISCOVER. The server is not sending the NAK. This, I believe to be
the crux of the matter. The 'host' assignment should cause the server to
send a DHCPNAK.
>
>> What is this 'reuse-lease' all about?
>
> Your DHCP client renews the leased IP although the lease time is not
> expired. Not relevant to this problem.
>>
>> I've tried 'dhclient -r wlan 0; dhclient -v wlan0' on the laptop, to no
>> avail.
>
> I'd be really surprised if it did change something. Your DHCP server has
> a problem, client does not.
>
I agree again, but when one gets desperate, one starts to grasp at straws.
>
>> Any suggestions, please?
>
> Clear your DHCP lease file on DHCP server. Bounce the thing. Check
> again.
>
Yes, I've done that. No change I'm afraid.
Cheers, Tony
Reply to: