Abandoned DHCP transaction...

[Don Y]

Why might a client abandon a DHCP transaction it had initiated
(i.e., fail to issue a REQUEST to the OFFER)?

I can see ignoring offers from some servers in the presence
of many. But, can\'t see how the client can safely abandon
\"all\" offers and hope for something \"better\" (whatever that
means)

[This, of course, assuming the service is correctly configured]

 

[Dave Platt]

In article <u8q9oh$3tn07$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

Why might a client abandon a DHCP transaction it had initiated
(i.e., fail to issue a REQUEST to the OFFER)?

I can see ignoring offers from some servers in the presence
of many. But, can\'t see how the client can safely abandon
\"all\" offers and hope for something \"better\" (whatever that
means)

A client might have a preferred (or required) network range programmed
in, for some reason. That would be a client-specific issue or
setting and you\'d have to check the client.

There may be some (poorly-programmed?) clients which have some
hard-coded limitations... such as, their code might only work on /24
networks, or on 192.168.x.y networks, or on networks where the router
is at .0 or .254. They\'d have to compare the conditions of the offer
with what their own network stack is capable of handling correctly.

Or, the code might just be broken. The client DHCP client might be
crashing or restarting after each offer.

Or, the hardware might be broken - the client might not actually be
seeing the offers (broken wire in the Ethernet cable?).

Or, there could be systematic problems on the network. In some
infrastructures, there are multiple Class C (or other) networks
interconnected by routers, and a single centralized DHCP server.
In these networks, the routers have to act as \"DHCP agents\",
forwarding the DHCP requests from the clients to the DHCP server,
and (crucially) forwarding the offers and accepts/denies back to
the client. A borked DHCP server, or a borked DHCP-agent router
could be losing the offers and replies, so the client might never
see them.

Or, the server could be misconfigured, and the client is detecting
that the offers are invalid for some reason. The client is supposed
to send a DHCPDecline in this case and start over, in cases like this.
Perhaps the server is including an option in the offer that the client
can\'t handle?

Figuring it out would probably require looking at the logs for the
client, server, any agent routers, and a Wireshark capture of the
DHCP packets.

 

[Don Y]

On 7/13/2023 7:28 PM, Dave Platt wrote:

In article <u8q9oh$3tn07$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:

Why might a client abandon a DHCP transaction it had initiated
(i.e., fail to issue a REQUEST to the OFFER)?

I can see ignoring offers from some servers in the presence
of many. But, can\'t see how the client can safely abandon
\"all\" offers and hope for something \"better\" (whatever that
means)

A client might have a preferred (or required) network range programmed
in, for some reason. That would be a client-specific issue or
setting and you\'d have to check the client.

Yes, but that would mean the client could *never* start (on this
subnet).

There may be some (poorly-programmed?) clients which have some
hard-coded limitations... such as, their code might only work on /24
networks, or on 192.168.x.y networks, or on networks where the router
is at .0 or .254. They\'d have to compare the conditions of the offer
with what their own network stack is capable of handling correctly.

That\'s possible. I see other folks complaining of similar problems.
I was trying to imagine why a client might be *designed* that way.
E.g., \"Let\'s wait for a better OFFER... (which may never come!)\"

Or, the code might just be broken. The client DHCP client might be
crashing or restarting after each offer.

Hmmm... I could look at the intervals between ADVERTISE to see if
they are periodic or backing off, etc.

Or, the hardware might be broken - the client might not actually be
seeing the offers (broken wire in the Ethernet cable?).

Wouldn\'t fit with the \"other folks seeing this problem\".

Or, there could be systematic problems on the network. In some
infrastructures, there are multiple Class C (or other) networks
interconnected by routers, and a single centralized DHCP server.
In these networks, the routers have to act as \"DHCP agents\",
forwarding the DHCP requests from the clients to the DHCP server,
and (crucially) forwarding the offers and accepts/denies back to
the client. A borked DHCP server, or a borked DHCP-agent router
could be losing the offers and replies, so the client might never
see them.

I can\'t speak for the \"other folks\" but I\'ve made sure I have
an isolated, low traffic segment so the client has no \"excuses\".

Or, the server could be misconfigured, and the client is detecting
that the offers are invalid for some reason. The client is supposed
to send a DHCPDecline in this case and start over, in cases like this.
Perhaps the server is including an option in the offer that the client
can\'t handle?

No DECLINEs. It\'s as if the client just \"tries again\" (hoping for
a different result?)

Figuring it out would probably require looking at the logs for the
client, server, any agent routers, and a Wireshark capture of the
DHCP packets.

I\'ve been watching the DHCPd logs hoping the .debug level would
shed \"appropriate\" light on the problem. Time to step down a
level... :<

Thanks!