On 24/10/2018 13:34, john doe wrote: > On 10/24/2018 1:28 PM, tony wrote: >> 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. >> > > By doing: > > $ systemctl stop isc-dhcp-server > rm /var/lib/dhcpd/dhcpd.leases > $ systemctl start isc-dhcp-server > > Make sure that the client is disconnected before doing the above. >
Ew, this time it worked. I wonder why deleting the leases file was better than clearing it out? Ah, well; thank you all for your help. Cheers, Tony