Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201544 > unrolled thread

strange DHCP behaviour

Back to article view | Back to linux.debian.user

Contents

  strange DHCP behaviour Tony van der Hoff <tony@vanderhoff.org> - 2018-10-23 16:20 +0200
    Re: strange DHCP behaviour Roberto C. Sánchez <roberto@debian.org> - 2018-10-23 16:30 +0200
      Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-23 18:10 +0200
    Re: strange DHCP behaviour Martin <keine-eile@online.de> - 2018-10-23 17:20 +0200
      Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-23 18:00 +0200
      Re: strange DHCP behaviour john doe <johndoe65534@mail.com> - 2018-10-23 18:40 +0200
        Re: strange DHCP behaviour john doe <johndoe65534@mail.com> - 2018-10-23 19:50 +0200
          Re: strange DHCP behaviour john doe <johndoe65534@mail.com> - 2018-10-23 20:10 +0200
            Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-24 10:40 +0200
        Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-23 19:50 +0200
    Re: strange DHCP behaviour mick crane <mick.crane@gmail.com> - 2018-10-23 21:10 +0200
      Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-24 10:50 +0200
        Re: strange DHCP behaviour mick crane <mick.crane@gmail.com> - 2018-10-24 12:20 +0200
          Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-24 12:40 +0200
            Re: strange DHCP behaviour mick crane <mick.crane@gmail.com> - 2018-10-24 13:00 +0200
              Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-24 13:20 +0200
    Re: strange DHCP behaviour deloptes <deloptes@gmail.com> - 2018-10-23 22:00 +0200
      Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-24 11:00 +0200
    Re: strange DHCP behaviour Reco <recoverym4n@enotuniq.net> - 2018-10-24 08:30 +0200
      Re: strange DHCP behaviour tony <lists@vanderhoff.org> - 2018-10-24 13:30 +0200
        Re: strange DHCP behaviour john doe <johndoe65534@mail.com> - 2018-10-24 13:40 +0200
          Re: strange DHCP behaviour [SOLVED] tony <lists@vanderhoff.org> - 2018-10-24 14:40 +0200
            Re: strange DHCP behaviour [SOLVED] <tomas@tuxteam.de> - 2018-10-24 14:50 +0200
              Re: strange DHCP behaviour [SOLVED] tony <lists@vanderhoff.org> - 2018-10-25 14:50 +0200
            Re: strange DHCP behaviour [SOLVED] Michael Stone <mstone@debian.org> - 2018-10-24 17:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#201585

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.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#201587 — Re: strange DHCP behaviour [SOLVED]

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

[toc] | [prev] | [next] | [standalone]

#201588 — Re: strange DHCP behaviour [SOLVED]

[Multipart message — attachments visible in raw view] — view raw

On Wed, Oct 24, 2018 at 02:35:37PM +0200, tony wrote:

[...]

> Ew, this time it worked. I wonder why deleting the leases file was
> better than clearing it out?

Some things you gotta delete *twice*.

(Sigh. I guess everyone here knows _that_ feeling... :)

Glad you found it
-- t

[toc] | [prev] | [next] | [standalone]

#201621 — Re: strange DHCP behaviour [SOLVED]

On 24/10/2018 14:41, tomas@tuxteam.de wrote:
> On Wed, Oct 24, 2018 at 02:35:37PM +0200, tony wrote:
> 
> [...]
> 
>> Ew, this time it worked. I wonder why deleting the leases file was
>> better than clearing it out?
> 
> Some things you gotta delete *twice*.
> 
> (Sigh. I guess everyone here knows _that_ feeling... :)
> 
> Glad you found it
> -- t
> 

I submitted my problem to the isc-dhcp mail list, but while waiting for
their reply, I deleted the leases file. They came back with some useful
advice, which I wish I had taken. I admitted to them what I had done.

I think it would be useful ro repeat their caution:

-------------------------------------------------------------------
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.

-------------------------------------------------------------------

Ouch!

The correct solution (according to the experts) is:

-------------------------------------------------------------------
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.
-------------------------------------------------------------------

Cheers, tony

[toc] | [prev] | [next] | [standalone]

#201593 — Re: strange DHCP behaviour [SOLVED]

On Wed, Oct 24, 2018 at 02:35:37PM +0200, tony wrote:
>Ew, this time it worked. I wonder why deleting the leases file was
>better than clearing it out?

Hard to say at this point, but are you sure you cleared every instance 
in the leases file? (Entries often appear more than once.)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web