Windows 11: Wi‑Fi connects to SSID but obtains APIPA (169.254.x.x) until adapter restart

Environment

Windows 11 Pro 22H2 on Dell XPS 13 (Intel AX201 Wi‑Fi), home WPA2-PSK network, router: ISP-supplied modem/router with DHCPv4 enabled, IPv6 disabled

Symptoms

Laptop shows Wi‑Fi connected in system tray and to the correct SSID, but no internet access. ipconfig /all reports IPv4 address 169.254.x.x (APIPA). Other devices on same Wi‑Fi have working internet. Internet returns after manually disabling and re-enabling the Wi‑Fi adapter or running 'ipconfig /renew'.

Observations

Event Viewer - System logs contain repeated DHCP client warnings 'DHCP lease could not be obtained' around the time of connection. Windows Network & Internet > Status shows 'No internet, secured'. Router DHCP table does not show a lease for the laptop when in APIPA state. Wired Ethernet on same machine receives DHCP address immediately. When booting the laptop with Wi‑Fi already enabled, DHCP lease is obtained reliably; problem occurs mainly when resuming from sleep or after waking from hotspot use.

Already attempted

Updated Intel Wi‑Fi drivers to latest from Dell support; disabled 'Allow the computer to turn off this device to save power' for the adapter; reset network stack with 'netsh winsock reset' and 'netsh int ip reset'; configured static IPv4 as test (worked) but wanted DHCP; cleared router DHCP lease list and restarted router (temporary fix for other devices). Problem reproduced with another SSID (mobile hotspot) showing same behavior.

Question

What diagnostics and non-destructive configuration changes can I run to determine why Windows 11 is failing to request or accept a DHCP lease on certain Wi‑Fi connects, and how to persistently fix it without forcing a static IP?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Bug or race in the Wi‑Fi driver causing DHCP client to fail to send or receive DHCP packets until adapter reset (driver state machine or offload features). 85%

Power-management features (ARP offload, packet coalescing, WoWLAN) interfering with broadcast DHCP on resume, causing DHCPDISCOVER to be dropped or transmitted on wrong VLAN. 75%

IPv4 DHCP client service timing issue: service not bound to Wi‑Fi adapter quickly enough on resume leading to missed replies with the DHCP server not responding to late requests. 55%

Summary

Symptoms point at a DHCP client handshake failing specifically over the Wi‑Fi interface in certain connection sequences (resumes, switching hotspots). Observations (DHCP client warnings in System log, no entry in router lease table) indicate the DHCPDISCOVER/DHCPREQUEST exchange never completes or the packets are dropped locally. The fact that adapter disable/re-enable or ipconfig /renew fixes it suggests a local state issue (driver, offload/power features, or filtering by third-party networking software) rather than router DHCP server being universally broken.

Suggested Fixes

Diagnostic step 1

Capture network traffic on the laptop while reproducing the issue using Wireshark: filter for bootp or udp port 67/68 to see whether DHCPDISCOVER is transmitted and whether DHCPOFFER arrives. This is reversible and read-only.

Diagnostic step 2

Temporarily disable third-party security/network filtering (antivirus firewall) and retest to rule out packet filtering interference. If disabled, re-enable after test.

Diagnostic step 3

Set Wi‑Fi adapter advanced properties: disable 'Allow computer to turn off this device to save power', disable 'Wake on Magic Packet' and 'ARP offload' options; test after each change to isolate guilty feature. These changes are reversible from Device Manager.