I decided on a quiet breezy Sunday morning, to upgrade my routers
firmware. Which required a router reboot.

So it lost all its DHCP tables.

However apart from 10 seconds of internet outage, the rest of the
network carried on nicely (nothing uses the router's wifi, as it's in a
remote space).

I then restarted a piece of kit I am working on, and it popped up in the
first available DHCP slot.

My question is, if that had already been occupied by another piece of
kit, would I have ended up with an IP address clash?

It seems to me that checking for conflicts only happens at lease start
or lease renewal times?

Or does that imply that the router did check the ip address first before
allocating the IP?

--
Canada is all right really, though not for the whole weekend.

"Saki"

The Natural Philosopher wrote:

> I then restarted a piece of kit I am working on, and it popped up in the
> first available DHCP slot.
>
> My question is, if that had already been occupied by another piece of
> kit, would I have ended up with an IP address clash?

Most kit will try a gratuitous ARP for the IP addr it's contemplating
using, which will show up most clashes before they happen, less
sophisticated devices may not bother ...

At Sun, 7 Apr 2024 10:45:39 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

>
>
> I decided on a quiet breezy Sunday morning, to upgrade my routers
> firmware. Which required a router reboot.
>
> So it lost all its DHCP tables.
>
> However apart from 10 seconds of internet outage, the rest of the
> network carried on nicely (nothing uses the router's wifi, as it's in a
> remote space).
>
> I then restarted a piece of kit I am working on, and it popped up in the
> first available DHCP slot.
>
> My question is, if that had already been occupied by another piece of
> kit, would I have ended up with an IP address clash?

This would not happen. I believe that the DHCP server process does something
like an "arp" before it assigns leaases. Also, anything with an "old"
(pre-reboot) lease would eventually ask for a lease renewal sooner or later
(eg when the lease runs out). It would ask for its existing IP address and the
router would likely grant that and create an entry int its lease table.

So, even if the router does not have any persistant lease data (eg saved
across reboots), the data would eventually be re-created is pretty shourt
order. I suspect the lease time for most od these little routersis fairly
should (an hour?), so the problem you fear is a non-problem.

>
> It seems to me that checking for conflicts only happens at lease start
> or lease renewal times?
>
> Or does that imply that the router did check the ip address first before
> allocating the IP?
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 07/04/2024 12:37, Robert Heller wrote:
>> My question is, if that had already been occupied by another piece of
>> kit, would I have ended up with an IP address clash?
> This would not happen. I believe that the DHCP server process does something
> like an "arp" before it assigns leaases.

I think it may in fact do a *ping*. In fact this led me to the
realisation that none of my Raspberry PI PICO W widgets were responding
to pings...another 2 hours of my life working out why...:-)

"To prevent a newly allocated IP address conflicting with existing IP
addresses, the DHCP server sends an ICMP Echo Request packet before
sending a DHCP Offer message. This ICMP packet contains the IP address
to be allocated in both the source and destination IP address fields.
The server can allocate the IP address if it receives no ICMP Echo Reply
packet within the detection period (no client is using this IP address).
If the server receives an ICMP Echo Reply packet within the detection
period, the DHCP server lists this IP address as a conflicting IP
address (as it is in use by another client), and then waits for the next
DHCP Discover message to start the IP address selection process again."

https://support.huawei.com/enterprise/en/doc/EDOC1100126920/5cef90ad/how-a-dhcp-server-allocates-network-parameters-to-new-dhcp-clients

>Also, anything with an "old"
> (pre-reboot) lease would eventually ask for a lease renewal sooner or later
> (eg when the lease runs out). It would ask for its existing IP address and the
> router would likely grant that and create an entry int its lease table.
>
yes.

> So, even if the router does not have any persistant lease data (eg saved
> across reboots), the data would eventually be re-created is pretty shourt
> order. I suspect the lease time for most od these little routersis fairly
> should (an hour?),

24 hours...

> so the problem you fear is a non-problem.

It was a potential problem when my Pi Picos didnt respond to pings

--
Climate Change: Socialism wearing a lab coat.

At Sun, 7 Apr 2024 13:24:28 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:

>
> On 07/04/2024 12:37, Robert Heller wrote:
> >> My question is, if that had already been occupied by another piece of
> >> kit, would I have ended up with an IP address clash?
> > This would not happen. I believe that the DHCP server process does something
> > like an "arp" before it assigns leaases.
>
> I think it may in fact do a *ping*. In fact this led me to the
> realisation that none of my Raspberry PI PICO W widgets were responding
> to pings...another 2 hours of my life working out why...:-)
>
> "To prevent a newly allocated IP address conflicting with existing IP
> addresses, the DHCP server sends an ICMP Echo Request packet before
> sending a DHCP Offer message. This ICMP packet contains the IP address
> to be allocated in both the source and destination IP address fields.
> The server can allocate the IP address if it receives no ICMP Echo Reply
> packet within the detection period (no client is using this IP address).
> If the server receives an ICMP Echo Reply packet within the detection
> period, the DHCP server lists this IP address as a conflicting IP
> address (as it is in use by another client), and then waits for the next
> DHCP Discover message to start the IP address selection process again."
>
> https://support.huawei.com/enterprise/en/doc/EDOC1100126920/5cef90ad/how-a-dhcp-server-allocates-network-parameters-to-new-dhcp-clients
>
> >Also, anything with an "old"
> > (pre-reboot) lease would eventually ask for a lease renewal sooner or later
> > (eg when the lease runs out). It would ask for its existing IP address and the
> > router would likely grant that and create an entry int its lease table.
> >
> yes.
>
> > So, even if the router does not have any persistant lease data (eg saved
> > across reboots), the data would eventually be re-created is pretty shourt
> > order. I suspect the lease time for most od these little routersis fairly
> > should (an hour?),
>
> 24 hours...
>
> > so the problem you fear is a non-problem.
>
> It was a potential problem when my Pi Picos didnt respond to pings

Which is not the *router's* problem, but a mis-configuration problem with the
Pi Picos...
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 07.04.2024 um 10:45 Uhr The Natural Philosopher wrote:

> I decided on a quiet breezy Sunday morning, to upgrade my routers
> firmware. Which required a router reboot.
>
> So it lost all its DHCP tables.

Normal.

> I then restarted a piece of kit I am working on, and it popped up in
> the first available DHCP slot.
>
> My question is, if that had already been occupied by another piece of
> kit, would I have ended up with an IP address clash?

2 parties can do duplicate address detection (DHCP server and the
client). None of them did.

> It seems to me that checking for conflicts only happens at lease
> start or lease renewal times?

When a device requests a lease, the DHCP server should check the address
with an ARP/NDP request.

The client should do that too. For IPv6, this is mandatory.

--
kind regards
Marco

Send spam to 1712479539muell@cartoonies.org

On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:

> On 07/04/2024 12:37, Robert Heller wrote:
>>
>> I believe that the DHCP server process does
>> something like an "arp" before it assigns leaases.
>
> I think it may in fact do a *ping*.

You want it to do an ARP, not a ping. Ping is routable, ARP is not.

On 4/7/24 18:53, Lawrence D'Oliveiro wrote:
> You want it to do an ARP, not a ping. Ping is routable, ARP is not.

What is the down side of ping being routable in the context of
determining if an IP in the directly attached subnet is reachable or not?

The only reason I'd prefer to use ARP over ping (ICMP) is that ping can
easily be filtered and may give a false negative. While ARP more
directly deals with the ARP cache and thus looking at where responses
would show up even if ping is filtered.

N.B. to be able to ping something in the local directly attached subnet,
ARP is going to be used to resolve the IP address to a MAC address.

--
Grant. . . .

On Sun, 7 Apr 2024 19:36:04 -0500, Grant Taylor wrote:

> On 4/7/24 18:53, Lawrence D'Oliveiro wrote:
>
>> You want it to do an ARP, not a ping. Ping is routable, ARP is not.
>
> What is the down side of ping being routable ...

You wouldn’t expect it to be routed. Nevertheless, better to use a
protocol that can never be routed.

On 4/7/24 19:51, Lawrence D'Oliveiro wrote:
> You wouldn’t expect it to be routed.

Expectations have a way of biting.

> Nevertheless, better to use a protocol that can never be routed.

There are ways to route ARP. }:-)

But I agree that ARP is better than ping for this use case.

--
Grant. . . .

On Sun, 7 Apr 2024 20:37:42 -0500, Grant Taylor wrote:

> There are ways to route ARP. }:-)

You are thinking of proxy ARP, perhaps?

On 4/7/24 20:51, Lawrence D'Oliveiro wrote:
> You are thinking of proxy ARP, perhaps?

You might think that, but even proxy ARP is traditional ARP all be it
for remote IPs.

I was thinking more along the lines of bridged routing (brouting) and /
or tunnels.

OpenFlow can really break traditional networking paradigms.

--
Grant. . . .

On Sun, 7 Apr 2024 21:37:39 -0500, Grant Taylor wrote:

> I was thinking more along the lines of bridged routing (brouting) and /
> or tunnels.
>
> OpenFlow can really break traditional networking paradigms.

Tunnels/SDN are irrelevant, because they happen at a lower level that is
transparent to the level we are talking about (virtual layer 2).

Remember, we were talking about DHCP, and ARP operates at the same level.

On 07/04/2024 14:29, Robert Heller wrote:
> At Sun, 7 Apr 2024 13:24:28 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>>
>> On 07/04/2024 12:37, Robert Heller wrote:
>>>> My question is, if that had already been occupied by another piece of
>>>> kit, would I have ended up with an IP address clash?
>>> This would not happen. I believe that the DHCP server process does something
>>> like an "arp" before it assigns leaases.
>>
>> I think it may in fact do a *ping*. In fact this led me to the
>> realisation that none of my Raspberry PI PICO W widgets were responding
>> to pings...another 2 hours of my life working out why...:-)
>>
>> "To prevent a newly allocated IP address conflicting with existing IP
>> addresses, the DHCP server sends an ICMP Echo Request packet before
>> sending a DHCP Offer message. This ICMP packet contains the IP address
>> to be allocated in both the source and destination IP address fields.
>> The server can allocate the IP address if it receives no ICMP Echo Reply
>> packet within the detection period (no client is using this IP address).
>> If the server receives an ICMP Echo Reply packet within the detection
>> period, the DHCP server lists this IP address as a conflicting IP
>> address (as it is in use by another client), and then waits for the next
>> DHCP Discover message to start the IP address selection process again."
>>
>> https://support.huawei.com/enterprise/en/doc/EDOC1100126920/5cef90ad/how-a-dhcp-server-allocates-network-parameters-to-new-dhcp-clients
>>
>> >Also, anything with an "old"
>>> (pre-reboot) lease would eventually ask for a lease renewal sooner or later
>>> (eg when the lease runs out). It would ask for its existing IP address and the
>>> router would likely grant that and create an entry int its lease table.
>>>
>> yes.
>>
>>> So, even if the router does not have any persistant lease data (eg saved
>>> across reboots), the data would eventually be re-created is pretty shourt
>>> order. I suspect the lease time for most od these little routersis fairly
>>> should (an hour?),
>>
>> 24 hours...
>>
>>> so the problem you fear is a non-problem.
>>
>> It was a potential problem when my Pi Picos didnt respond to pings
>
> Which is not the *router's* problem, but a mis-configuration problem with the
> Pi Picos...

No argument there!

>>
>

--
"In our post-modern world, climate science is not powerful because it is
true: it is true because it is powerful."

Lucas Bergkamp

On 08/04/2024 00:53, Lawrence D'Oliveiro wrote:
> On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:
>
>> On 07/04/2024 12:37, Robert Heller wrote:
>>>
>>> I believe that the DHCP server process does
>>> something like an "arp" before it assigns leaases.
>>
>> I think it may in fact do a *ping*.
>
> You want it to do an ARP, not a ping. Ping is routable, ARP is not.
What I want to do is not in question, What is (apparently) generally
accepted practice, is.
--
"In our post-modern world, climate science is not powerful because it is
true: it is true because it is powerful."

Lucas Bergkamp

On 08/04/2024 08:35, The Natural Philosopher wrote:
> On 08/04/2024 00:53, Lawrence D'Oliveiro wrote:
>> On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:
>>
>>> On 07/04/2024 12:37, Robert Heller wrote:
>>>>
>>>> I believe that the DHCP server process does
>>>> something like an "arp" before it assigns leaases.
>>>
>>> I think it may in fact do a *ping*.
>>
>> You want it to do an ARP, not a ping. Ping is routable, ARP is not.
> What I want to do is not in question, What is (apparently) generally
> accepted practice, is.

I found this, which seems relatively authoritative.

"With conflict detection enabled, the DHCP Server will ping the IP
address it wants to grant a lease for to make sure no other computers
are using that IP address. If the ping request receives a reply, the
server will mark the IP as BAD_ADDRESS. If no response is received, the
server will assign the IP address to the requesting client (The DHCP
client probes the IP address by sending gratuitous ARP packets)."

Apparently the use of ping is preferred because a DHCP server *can*
operate across various routed subdomains.

--
No Apple devices were knowingly used in the preparation of this post.

On 2024-04-08 01:53, Lawrence D'Oliveiro wrote:
> On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:
>
>> On 07/04/2024 12:37, Robert Heller wrote:
>>>
>>> I believe that the DHCP server process does
>>> something like an "arp" before it assigns leaases.
>>
>> I think it may in fact do a *ping*.
>
> You want it to do an ARP, not a ping. Ping is routable, ARP is not.

Actually, you want the query to be routed in this scenario. You do not
want any machine in the entire network to have the same IP, no matter
how far it is.

--
Cheers, Carlos.

Lawrence D'Oliveiro wrote:

> The Natural Philosopher wrote:
>
>> I think it may in fact do a *ping*.
>
> You want it to do an ARP, not a ping. Ping is routable, ARP is not.

ping is blockable, ARP is not (if you want a functioning IP stack).

The oddest device I have doesn't actually respond to ARP requests,
instead it continually sends out an ARP reply containing its own MAC and
IP addrs.

On 4/8/24 00:40, Lawrence D'Oliveiro wrote:
> Tunnels/SDN are irrelevant, because they happen at a lower level that
> is transparent to the level we are talking about (virtual layer 2).

Not all tunnels are created equally.

> Remember, we were talking about DHCP, and ARP operates at the same level.

No, DHCP and ARP do not operate on the same layers.

DHCP operates on top of UDP which operates on top of IP.

ARP operates on the same level as and /beside/ IP.

--
Grant. . . .

On 4/8/24 03:19, The Natural Philosopher wrote:
> "With conflict detection enabled, the DHCP Server will ping the IP
> address it wants to grant a lease for to make sure no other computers
> are using that IP address. If the ping request receives a reply, the
> server will mark the IP as BAD_ADDRESS. If no response is received, the
> server will assign the IP address to the requesting client...."

This usually works well enough. But it breaks down when the system
using the IP the DHCP server is ping testing refuses to send echo reply
responses to the ping.

> (The DHCP client probes the IP address by sending gratuitous ARP
> packets)

I wonder if this happens after the client receives the DHCP OFFER from
the server and before the client sends the DHCP REQUEST (for the offered
IP).

> Apparently the use of ping is preferred because a DHCP server can
> operate across various routed subdomains.

That doesn't surprise me. But it does have limitations in some probably
rare cases.

--
Grant. . . .

On 4/8/24 07:47, Carlos E.R. wrote:
> Actually, you want the query to be routed in this scenario. You do not
> want any machine in the entire network to have the same IP, no matter
> how far it is.

Anycast IPs beg to differ with you.

All IPs are locally significant. It's just a question of how local
locally significant actually is.

There is a good chance that the DHCP server's ping will only go to the
subnet containing the IP in question which the DHCP has a route to. It
won't find other instances of the IP where it doesn't have a route to.

--
Grant. . . .

On 4/8/24 09:22, Andy Burns wrote:
> ping is blockable, ARP is not.

ARP is blockable. arptables, ebtables, and even iptables (with the
proper configuration) can block ARP quite easily.

ARP is rarely blocked.

> (if you want a functioning IP stack)

ARP is not required for a functional IP stack. There are multiple types
of networks that don't even support ARP.

IP just needs a way to know what MAC address to send traffic to or what
port to send traffic out.

It's perfectly feasible to configure static ARP entries on systems in a
LAN and disable ARP. The systems will work perfectly fine.

This will likely be familiar to anyone that has needed to de-conflict
IPs remotely across a (layer 2) network.

I've heard tell of people purposefully using conflicting IP addresses on
systems that don't need to communicate with each other as a security
measure (of sorts). (I'm not saying it's a good security measure. It's
more an obfuscation.)

Aside: I suspect static ARP entries and disabling ARP is more secure. }:-)

--
Grant. . . .

On Mon, 8 Apr 2024 09:19:24 +0100, The Natural Philosopher wrote:

> Apparently the use of ping is preferred because a DHCP server *can*
> operate across various routed subdomains.

No it cannot. How is a client supposed to figure out how routing works to
get to the DHCP server, if not from info it gets from the DHCP server?

On Mon, 8 Apr 2024 18:25:07 -0500, Grant Taylor wrote:

> DHCP operates on top of UDP which operates on top of IP.

It works specifically on 169.254 addresses, because those are the only
kind you can use without a proper IP configuration.

> ARP operates on the same level as and /beside/ IP.

They are both non-routable. You might say that DHCP is technically layer
3, but it is restricted to the domain of layer 2.

On Mon, 8 Apr 2024 14:47:58 +0200, Carlos E.R. wrote:

> You do not want any machine in the entire network to have the same IP,
> no matter how far it is.

<https://datatracker.ietf.org/doc/html/rfc1918>