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

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

DHCP Problem

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

Contents

  DHCP Problem Charles Curley <charlescurley@charlescurley.com> - 2023-12-03 20:40 +0100
    Re: DHCP Problem Marco Moock <mm@dorfdsl.de> - 2023-12-03 21:00 +0100
      Re: DHCP Problem Charles Curley <charlescurley@charlescurley.com> - 2023-12-03 22:30 +0100
    Re: DHCP Problem Henning Follmann <hfollmann@itcfollmann.com> - 2023-12-03 22:10 +0100
      Re: DHCP Problem, but where Geert Stappers <stappers@stappers.nl> - 2023-12-03 22:20 +0100
        Re: DHCP Problem, but where jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-03 22:40 +0100
          Re: DHCP Problem, but where Jeffrey Walton <noloader@gmail.com> - 2023-12-04 04:40 +0100
            Re: DHCP Problem, but where Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 04:50 +0100
        Re: DHCP Problem, but where Charles Curley <charlescurley@charlescurley.com> - 2023-12-03 22:40 +0100
    goose DHCP clients to new address   Was: DHCP Problem Geert Stappers <stappers@stappers.nl> - 2023-12-03 22:20 +0100
      Re: goose DHCP clients to new address   Was: DHCP Problem Charles Curley <charlescurley@charlescurley.com> - 2023-12-03 23:00 +0100
        Re: goose DHCP clients to new address Was: DHCP Problem Jeffrey Walton <noloader@gmail.com> - 2023-12-03 23:20 +0100
          Re: goose DHCP clients to new address Was: DHCP Problem Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 00:00 +0100
    Re: DHCP Problem Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 04:50 +0100
    Re: DHCP Problem <tomas@tuxteam.de> - 2023-12-04 06:00 +0100
      Re: DHCP Problem Charles Curley <charlescurley@charlescurley.com> - 2023-12-04 07:10 +0100

#264157 — DHCP Problem

I am installing a new router which seems to work well so far.

I have changed the DHCP server to use the new router's address, and shut
the server down and restarted it. Existing clients insist on using the
old router anyway. Is there any way to goose clients into using the new
one short of manually using the ip route command?


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [next] | [standalone]

#264158

Am 03.12.2023 um 12:30:53 Uhr schrieb Charles Curley:

> I have changed the DHCP server to use the new router's address, and
> shut the server down and restarted it. Existing clients insist on
> using the old router anyway. Is there any way to goose clients into
> using the new one short of manually using the ip route command?

Did you check with a sniffer that the answer from the DHCP includes the
new router address?
As long as the lease time of the old lease the route may stay in the
routing table.

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

#264165

On Sun, 3 Dec 2023 20:56:20 +0100
Marco Moock <mm@dorfdsl.de> wrote:

> Did you check with a sniffer that the answer from the DHCP includes
> the new router address?

Not with a sniffer, but I did check the lease file. Neither the router
address nor the various lease times changed.



-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#264161

> On Dec 3, 2023, at 14:31, Charles Curley <charlescurley@charlescurley.com> wrote:
> 
> I am installing a new router which seems to work well so far.
> 
> I have changed the DHCP server to use the new router's address, and shut
> the server down and restarted it. Existing clients insist on using the
> old router anyway. Is there any way to goose clients into using the new
> one short of manually using the ip route command?
> 
> 

Did you flush the old leases from /var/lib/dhcpd
?
Just changing the config is not enough.

-H

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

#264162 — Re: DHCP Problem, but where

On Sun, Dec 03, 2023 at 04:03:39PM -0500, Henning Follmann wrote:
> > On Dec 3, 2023, at 14:31, Charles Curley wrote:
> > 
> > I am installing a new router which seems to work well so far.
> > 
> > I have changed the DHCP server to use the new router's address, and shut
> > the server down and restarted it. Existing clients insist on using the
> > old router anyway. Is there any way to goose clients into using the new
> > one short of manually using the ip route command?
> > 
> > 
> 
> Did you flush the old leases from /var/lib/dhcpd ?
> Just changing the config is not enough.

That triggered me to ask "Has the DHCP server been restarted?"
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

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

#264166 — Re: DHCP Problem, but where

On 4/12/23 05:18, Geert Stappers wrote:
> That triggered me to ask "Has the DHCP server been restarted?"


The default behaviour of most dhcp clients when they can't connect to a 
dhcp server is to maintain the settings from any previous lease.

A second default behaviour is for clients to not request new dhcp until 
their existing dhcp lease has expired.

To make sure a new dhcp setting is taken by all clients you need to

-  reconfigure your dhcp server

- restart your dhcp server

- check your dhcp server logs for any problems

- restart your dhcp clients

- check your client dhcp logs to see if the new lease info has been taken.

There can be problems where a client with a specific MAC address 
requests a specific ip address based on a previous lease but the server 
is unwilling or unable to allocate that address to that MAC. This can be 
checked in the server and client logs. It may also require flushing the 
server lease tables and client configs so they can both start out 
completely fresh.

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

#264182 — Re: DHCP Problem, but where

On Sun, Dec 3, 2023 at 9:57 PM jeremy ardley <jeremy.ardley@gmail.com> wrote:
>
>
> On 4/12/23 05:18, Geert Stappers wrote:
> > That triggered me to ask "Has the DHCP server been restarted?"
>
>
> The default behaviour of most dhcp clients when they can't connect to a
> dhcp server is to maintain the settings from any previous lease.
>
> A second default behaviour is for clients to not request new dhcp until
> their existing dhcp lease has expired.
>
> To make sure a new dhcp setting is taken by all clients you need to
>
> -  reconfigure your dhcp server
>
> - restart your dhcp server
>
> - check your dhcp server logs for any problems
>
> - restart your dhcp clients
>
> - check your client dhcp logs to see if the new lease info has been taken.
>
> There can be problems where a client with a specific MAC address
> requests a specific ip address based on a previous lease but the server
> is unwilling or unable to allocate that address to that MAC. This can be
> checked in the server and client logs. It may also require flushing the
> server lease tables and client configs so they can both start out
> completely fresh.

The "restart your dhcp clients" may have a sharp edge. Sometimes the
clients have a touch of resiliency or hardening added so they contact
their original dhcp server, and not a [possibly] rogue server setup by
an unknowing developer or attacker. In the past, you used to have to
reboot Microsoft clients to get them to use the new dhcp server. I
don't know Linux behavior.

But if the problem is, dhcp clients are using the old dhcp server or
old dhcp lease info, then I would try to reboot a client if the
service restart did not help.

(I saw a similar attack happen as an undergrad at the University of
Maryland. Someone in the CS department setup a Linux server with
Kerberos running. Workstations got answers from the rogue server and
got [useless] tickets granted, and the [useless] tickets could not be
used for authenticating to other services on the UMBC network. It was
an intermittent problem, and it took a couple of weeks to straighten
it out).

Jeff

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

#264183 — Re: DHCP Problem, but where

On Sun, 3 Dec 2023 22:32:59 -0500
Jeffrey Walton <noloader@gmail.com> wrote:

> The "restart your dhcp clients" may have a sharp edge. Sometimes the
> clients have a touch of resiliency or hardening added so they contact
> their original dhcp server, and not a [possibly] rogue server setup by
> an unknowing developer or attacker. In the past, you used to have to
> reboot Microsoft clients to get them to use the new dhcp server. I
> don't know Linux behavior.
> 
> But if the problem is, dhcp clients are using the old dhcp server or
> old dhcp lease info, then I would try to reboot a client if the
> service restart did not help.

I think the ISC dhclient (which is what I use here) does try to return
to its original server. Rather than reboot anything, I simply stopped
the DHCP server on that machine. Apparently clients then started back at
the beginning. Shortening the lease time accelerates that process.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#264167 — Re: DHCP Problem, but where

On Sun, 3 Dec 2023 22:18:22 +0100
Geert Stappers <stappers@stappers.nl> wrote:

> Has the DHCP server been restarted?

Yes.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#264163 — goose DHCP clients to new address Was: DHCP Problem

On Sun, Dec 03, 2023 at 12:30:53PM -0700, Charles Curley wrote:
> I am installing a new router which seems to work well so far.
 
I assume that the previous router is disconnected from the LAN.


> I have changed the DHCP server to use the new router's address, and shut
> the server down and restarted it. Existing clients insist on using the
> old router anyway. Is there any way to goose clients into using the new
> one short of manually using the ip route command?

The DHCProtocol has "release" for such goosing.
At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0]
The DHCPclient should forget ( "release" ) previous settings.
At DHCPclient do "start DHCP", client should get fresh config,
including the setting for the fresh router.


If that is already done, provide information to enable further help.
Such as name of the DHCP client program  and DHCP lease time.

Oh, DHCP lease time:  What lease time is the DHCP server providing?


Groeten
Geert Stappers

[0] https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_message_types
-- 
Silence is hard to parse

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

#264168 — Re: goose DHCP clients to new address Was: DHCP Problem

On Sun, 3 Dec 2023 22:14:51 +0100
Geert Stappers <stappers@stappers.nl> wrote:

> I assume that the previous router is disconnected from the LAN.

No. Until I solve this problem (and a few others), I will have clients
using the old router.

> The DHCProtocol has "release" for such goosing.
> At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0]
> The DHCPclient should forget ( "release" ) previous settings.
> At DHCPclient do "start DHCP", client should get fresh config,
> including the setting for the fresh router.

I'm not sure how to do this. I did run on a client

dhclient -r
dhclient

I observed no changes.

The -r causes dhclient to release its lease. Invoking dhclient again
should then obtain a new lease.

> 
> 
> If that is already done, provide information to enable further help.
> Such as name of the DHCP client program  and DHCP lease time.

I am using whatever is standard on Debian Bullseye and Bookworm.

root@hawk:/etc# pre dhc
isc-dhcp-client	4.4.1-2.3+deb11u2		amd64
isc-dhcp-common	4.4.1-2.3+deb11u2		amd64
root@hawk:/etc# 

root@tiassa:~# pre dhc
isc-dhcp-client	4.4.3-P1-2		amd64
isc-dhcp-common	4.4.3-P1-2		amd64
root@tiassa:~# 

The client's name is dhclient.


default-lease-time 86400; # 24 hours
max-lease-time 172800;	  # 48 hours

I think for the purposes of experimentation I will shorten those to
half an hour and one hours respectively.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#264171 — Re: goose DHCP clients to new address Was: DHCP Problem

On Sun, Dec 3, 2023 at 4:51 PM Charles Curley
<charlescurley@charlescurley.com> wrote:
>
> On Sun, 3 Dec 2023 22:14:51 +0100
> Geert Stappers <stappers@stappers.nl> wrote:
>
> > I assume that the previous router is disconnected from the LAN.
>
> No. Until I solve this problem (and a few others), I will have clients
> using the old router.
>
> > The DHCProtocol has "release" for such goosing.
> > At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0]
> > The DHCPclient should forget ( "release" ) previous settings.
> > At DHCPclient do "start DHCP", client should get fresh config,
> > including the setting for the fresh router.
>
> I'm not sure how to do this. I did run on a client
>
> dhclient -r
> dhclient
>
> I observed no changes.
>
> The -r causes dhclient to release its lease. Invoking dhclient again
> should then obtain a new lease.

I don't know about Linux clients, but in the past, Windows clients
used to try to connect to the previous DHCP server for its lease info.
If the old DHCP server is still available (on the old router?), then
the client may be getting the lease info from the old server. To avoid
the problem, we disconnected the old server from the network.

You should probably just perform a hard cut-over. Shutdown the old
router, stand up the new router. After the hard cutover, force clients
to renew their leases (or wait until they do it on their own). And if
things go sideways, undo the change.

> > If that is already done, provide information to enable further help.
> > Such as name of the DHCP client program  and DHCP lease time.
>
> I am using whatever is standard on Debian Bullseye and Bookworm.
>
> root@hawk:/etc# pre dhc
> isc-dhcp-client 4.4.1-2.3+deb11u2               amd64
> isc-dhcp-common 4.4.1-2.3+deb11u2               amd64
> root@hawk:/etc#
>
> root@tiassa:~# pre dhc
> isc-dhcp-client 4.4.3-P1-2              amd64
> isc-dhcp-common 4.4.3-P1-2              amd64
> root@tiassa:~#
>
> The client's name is dhclient.
>
> default-lease-time 86400; # 24 hours
> max-lease-time 172800;    # 48 hours
>
> I think for the purposes of experimentation I will shorten those to
> half an hour and one hours respectively.

Jeff

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

#264172 — Re: goose DHCP clients to new address Was: DHCP Problem

On Sun, 3 Dec 2023 17:18:23 -0500
Jeffrey Walton <noloader@gmail.com> wrote:

> I don't know about Linux clients, but in the past, Windows clients
> used to try to connect to the previous DHCP server for its lease info.
> If the old DHCP server is still available (on the old router?), then
> the client may be getting the lease info from the old server. To avoid
> the problem, we disconnected the old server from the network.

I did shut down both the old server and its failover peer. Clients I
haven't mucked with are now asking for leases from the new server.

Dec 03 14:55:48 issola dhcpd[24072]: failover peer failover-partner: I move from startup to communications-interrupted
Dec 03 15:09:46 issola dhcpd[24072]: DHCPREQUEST for 192.168.100.45 from ec:28:d3:7a:6a:76 via enp1s0
Dec 03 15:09:46 issola dhcpd[24072]: DHCPACK on 192.168.100.45 to ec:28:d3:7a:6a:76 via enp1s0
Dec 03 15:40:50 issola dhcpd[24072]: DHCPREQUEST for 192.168.100.45 from ec:28:d3:7a:6a:76 via enp1s0
Dec 03 15:40:50 issola dhcpd[24072]: DHCPACK on 192.168.100.45 to ec:28:d3:7a:6a:76 via enp1s0

But that guy is still pointing toward the old router.

> 
> You should probably just perform a hard cut-over. Shutdown the old
> router, stand up the new router. After the hard cutover, force clients
> to renew their leases (or wait until they do it on their own). And if
> things go sideways, undo the change.

I may yet do that. The change will consist of pulling the Ethernet cable
between the old router and its upstream connection.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#264184

On Sun, 3 Dec 2023 12:30:53 -0700
Charles Curley <charlescurley@charlescurley.com> wrote:

> I am installing a new router which seems to work well so far.
> 
> I have changed the DHCP server to use the new router's address, and
> shut the server down and restarted it. Existing clients insist on
> using the old router anyway. Is there any way to goose clients into
> using the new one short of manually using the ip route command?
> 
> 

OK, stupid mistake of the week.

The frustrating problem was that the clients kept getting the old
router's IP address. This was for the simple reason that I had managed
to not change the value of the "option routers" entry for the subnet.
Doh! I have fixed that. Never be afraid to recheck your own work.

I did shorten the lease times and that has accelerated the changeover.
I didn't need to restart all the client's leases. Two days hence I'll
change them back.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#264186

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

On Sun, Dec 03, 2023 at 12:30:53PM -0700, Charles Curley wrote:
> I am installing a new router which seems to work well so far.
> 
> I have changed the DHCP server to use the new router's address, and shut
> the server down and restarted it. Existing clients insist on using the
> old router anyway. Is there any way to goose clients into using the new
> one short of manually using the ip route command?

Wait a sec: before the clients get an answer from the DHCP server, they
don't have any route (at least not for the network in question), so it
doesn't make sense poking at them with ip route and things. They send their
request to the local network's segment broadcast address.

What's possibly happening is that your old DCHP server is still up and
running and faster than your new one, so its answers come in first.

Cheers
-- 
t

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

#264189

On Mon, 4 Dec 2023 05:55:50 +0100
<tomas@tuxteam.de> wrote:

> Wait a sec: before the clients get an answer from the DHCP server,
> they don't have any route (at least not for the network in question),
> so it doesn't make sense poking at them with ip route and things.
> They send their request to the local network's segment broadcast
> address.

As I understand things, that's true of the first request a client
makes, say, at boot. After that, the client knows which machine it got
its last lease from and can query directly.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [standalone]

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

csiph-web