Connected link but no DHCP IPv4 lease · Linux Fix Lab

Symptoms & scope

A cable has carrier or Wi-Fi authenticates, but no expected IPv4 address appears.
Activation reaches ip-config and then fails, or only a link-local address remains.

Relevant environment

NetworkManager profiles intended to use IPv4 DHCP; IPv6-only and intentionally static networks require different expectations.

Recognizable messages (synthetic examples)

NetworkManager[650]: device (enp3s0): state change: ip-config -> failed (reason 'ip-config-unavailable', managed-type: 'full')

On a DHCP profile inspect offers and address-conflict events; this reason can also occur for static configuration failure.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

The DHCP server, relay, VLAN, exhausted pool or filtering may prevent a usable offer or acknowledgment from reaching the client.
A wrong profile method or an IPv4 address conflict can also prevent IP configuration; ip-config-unavailable is not uniquely a DHCP timeout.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace IFACE with the affected interface. Read active address, routes and received DHCP options without renewing or reconnecting.

nmcli -f GENERAL,IP4,DHCP4 device show IFACE

Interpret the result: A missing DHCP4 lease on an auto profile supports failed acquisition. A valid lease but absent default route points to route/profile policy; missing DNS alone is a separate problem.

Check 2

Read the activation sequence with journal privileges if needed; locate the interface and the events immediately before ip-config failure.

journalctl -b -u NetworkManager --no-pager -n 300

Interpret the result: No offer, lease expiration or server rejection directs DHCP checks. An already-in-use address warning instead requires resolving the address conflict; successful Wi-Fi association does not prove DHCP reachability.

Evidence-guided next steps

Correct the intended address method

If this network is documented to use DHCP but the saved profile has the wrong IPv4 method or stale manual settings, save the current configuration and set that profile to automatic address acquisition. Reconnect only the affected profile and inspect the new lease.

Precautions: Use a local console or checkpoint if this is your remote-access link. Do not invent a static address or gateway simply to bypass DHCP.

Recovery / rollback: Restore the saved method, addresses, routes and DNS, then reactivate the prior profile locally if the comparison loses access.

Did this solution help you?

Share this solution #

Repair the confirmed DHCP path

If multiple clients on the same intended VLAN lack offers, inspect the DHCP server’s scope, lease capacity and relay/switch assignment with its administrator. If only this client fails, compare its profile and the server’s lease/reservation record before changing client identity.

Precautions: Scope and switch edits affect other users; retain the previous configuration and make the smallest supported correction. Avoid indiscriminate firewall shutdown or DHCP-client replacement.

Recovery / rollback: Revert the server, VLAN or reservation change if other clients regress; restore the client profile and retry acquisition through the original working network.