We need your assistance as we are currently facing an issue without a workaround for users on macOS 15.4 and 15.5.
FeedbackID: FB17547675
The problem has been observed on macOS versions 15.4 and 15.5. Apple has acknowledged this issue and confirmed that it is fixed in the macOS 15.6 beta. Although we tried to reproduce the issue in our environment, it did not occur, even on macOS 15.5. Therefore, we cannot verify if the fix in macOS 15.6 beta resolves the problem.
We are actively working to identify an appropriate workaround for users on macOS 15.5. Some users have reported a failure to obtain an IP address over Wi-Fi, possibly due to a DHCP failure.
As a temporary solution, we added logic to restart Wi-Fi programmatically when either an APIPA address (169.254.x.x) or no IPv4 address is detected on the active interface. However, restarting Wi-Fi does not always resolve the issue, and the device may still fail to obtain an IP address over Wi-Fi or Ethernet.
Could you advise if there is a reliable method to detect DHCP failure and recover the device from this state? Also, any idea, how we can reproduce this scenario in our machine?
Below is the failure.
default 2025-06-27 10:07:57.055003 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:07:57.055269 -0700 configd DHCP en0: status = 'no server'
default 2025-06-27 10:08:23.336215 -0700 airportd WiFiUsageBssSession:: ChannelAfterRoam=0; ChannelAtJoin=36; FaultReasonApsdTimedOut=0; FaultReasonArpFailureCount=0; FaultReasonBrokenBackhaulLinkFailed=0; FaultReasonDhcpFailure=0;
default 2025-06-27 10:08:23.367852 -0700 configd DHCP en0: status = 'media inactive'
default 2025-06-27 10:08:23.367909 -0700 configd DHCP en0: INACTIVE
default 2025-06-27 10:08:23.988565 -0700 configd DHCP en0: status = 'media inactive'
default 2025-06-27 10:08:23.988703 -0700 configd DHCP en0: INACTIVE
info 2025-06-27 10:08:23.988852 -0700 configd DHCPv6 en0: Inactive
default 2025-06-27 10:08:35.656415 -0700 configd DHCP en0: status = 'network changed'
default 2025-06-27 10:08:35.656817 -0700 configd DHCP en0: INIT
default 2025-06-27 10:08:35.656821 -0700 configd DHCP en0: supplying device type 'Mac'
info 2025-06-27 10:08:35.656934 -0700 configd DHCP en0: busy
default 2025-06-27 10:08:35.657351 -0700 configd DHCP en0: INIT waiting at 0 for 1.358613
info 2025-06-27 10:08:35.657404 -0700 configd DHCPv6 en0: Inactive
default 2025-06-27 10:08:37.019229 -0700 configd DHCP en0: INIT waiting at 1.36206 for 2.113913
default 2025-06-27 10:08:39.136955 -0700 configd DHCP en0: INIT waiting at 3.47937 for 4.462224
default 2025-06-27 10:08:43.602229 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:08:43.603143 -0700 configd DHCP en0: INIT waiting at 7.94533 for 8.128784
default 2025-06-27 10:08:51.735532 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:08:51.735846 -0700 configd DHCP en0: INIT waiting at 16.0786 for 8.749985
default 2025-06-27 10:09:00.488315 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:09:00.488550 -0700 configd DHCP en0: INIT waiting at 24.8313 for 8.496864
default 2025-06-27 10:09:08.988284 -0700 configd DHCP en0: ARP router: No leases to query for
default 2025-06-27 10:09:08.988310 -0700 configd DHCP en0: reported address acquisition failure symptom
default 2025-06-27 10:09:08.988579 -0700 configd DHCP en0: INIT waiting at 33.3312 for 8.300735
default 2025-06-27 10:09:17.294478 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:17.294485 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:17.295454 -0700 configd DHCP en0: INIT waiting at 41.6373 for 8.798768
default 2025-06-27 10:09:26.096673 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:26.096688 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:26.097553 -0700 configd DHCP en0: INIT waiting at 50.4394 for 8.807943
default 2025-06-27 10:09:34.909050 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:34.909054 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:34.909375 -0700 configd DHCP en0: INIT waiting at 59.2517 for 8.877971
default 2025-06-27 10:09:43.792458 -0700 configd DHCP en0: ARP router: No leases to query for
info 2025-06-27 10:09:43.792464 -0700 configd DHCP en0: symptom failure already reported
default 2025-06-27 10:09:43.793641 -0700 configd DHCP en0: status = 'no server'
info 2025-06-27 10:09:43.794145 -0700 configd DHCP en0: not busy
DNS failure
resolver #1
flags :
reach : 0x00000000 (Not Reachable)
resolver #2
domain : local
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300200
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300400
resolver #5
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300600
resolver #6
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300800
resolver #7
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 301000
Route table
Destination Gateway Flags Netif Expire
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#14 UCS en0 !
169.254.160.160/32 link#14 UCS en0 !
224.0.0/4 link#14 UmCS en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0
255.255.255.255/32 link#14 UCS en0 !
This issue is being triggered by the presence of your transparent proxy, right?
For those following along at home, macOS 15.x, x < 6, have an issue where a transparent proxy causes DHCP to fail when you disconnect and reconnect an interface (r. 150505789).
Could you advise if there is a reliable method to detect DHCP failure and recover the device from this state?
I don’t see any way to make that work.
The fix for this bug is to correctly clean up an internal kernel resource during the interface tear down process. Without that, this resource is left dangling and causes ongoing problems. Turning the interface off and on again won’t clear the problem. The only way to clear it prior to this fix is to restart the Mac.
Also, any idea, how we can reproduce this scenario in our machine?
My understanding is that it reproduces pretty reliably with a transparent proxy:
-
Set up a Mac on Ethernet with a transparent proxy.
-
Disconnect the Ethernet.
-
Reconnect it.
I’ve seen this reported by a number of transparent proxy developers. For example, the developer on this thread can reliably reproduce it.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"