DHCP broken when device wakeup

Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup.

From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase.

It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER?

Default     0x0                  0      0    kernel: bpf26 attached to en0 by configd:331
2026-03-25 14:06:33.625851+0100 0x31dea    
Default     0x0                  0      0    kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331

System log and packet capture attach, please check.

Answered by DTS Engineer in 882231022

Is any of your code involved here?

Reading your description it doesn’t look like that’s the case, in which case the best place for this report is Feedback Assistant. See Bug Reporting: How and Why? for lots of hints and tips on how to file a bug.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

2026-03-25 14:06:25.160810+0100 0x31ca3    Default     0x0                  331    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] DHCP en0: not supplying hostname
2026-03-25 14:06:25.160949+0100 0x31ca3    Info        0x0                  331    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] DHCP en0: busy
2026-03-25 14:06:25.162815+0100 0x31ca3    Info        0x0                  331    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] [en0] Transmit 300 byte packet xid 0xd1259f67 to 255.255.255.255 [scope=0]
2026-03-25 14:06:25.165760+0100 0x31ca3    Default     0x0                  0      0    kernel: bpf26 attached to en0 by configd:331
2026-03-25 14:06:25.165867+0100 0x31ca3    Default     0x0                  0      0    kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331
2026-03-25 14:06:25.166000+0100 0x31ca3    Default     0x0                  331    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] DHCP en0: INIT waiting at 0 for 1.680206
2026-03-25 14:06:26.849893+0100 0x31e79    Info        0x0                  331    0    configd: (IPConfiguration) [com.apple.IPConfiguration:Server] [en0] Transmit 300 byte packet xid 0xd1259f67 to 255.255.255.255 [scope=0]
2026-03-25 14:06:26.853357+0100 0x31e79    Default     0x0                  0      0    kernel: bpf26 attached to en0 by configd:331
2026-03-25 14:06:26.853489+0100 0x31e79    Default     0x0                  0      0    kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331

No sure how to attach full system log here since it is large. Please let me know how to share the full system log if you need

Is any of your code involved here?

Reading your description it doesn’t look like that’s the case, in which case the best place for this report is Feedback Assistant. See Bug Reporting: How and Why? for lots of hints and tips on how to file a bug.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

FB number FB22371512

@DTS Engineer any update on this?

any update on this?

I don’t think so, but you can check for yourself in Feedback Assistant.

Earlier I wrote:

Is any of your code involved here?

Was I right in assuming that this isn’t the case?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

We saw this issue more with Content Filter and Transparent proxy network extension running on the device.

We saw this issue more with Content Filter and Transparent proxy network extension running on the device.

OK. But that doesn’t actually answer my question: Is any of your code involved here? That is, are you the developer of these content filter and transparent proxy providers? Or are you trying to use providers created by a different developer?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, our app was built on top of transparent proxy provider, we bypass DHCP from provider to make sure it communicates directly with its ultimate destination. However issue still been reported from customers when Transparent proxy extension running.

our app was built on top of transparent proxy provider

OK.

However issue still been reported from customers

Are you able to reproduce this yourself?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

No, I am not able to reproduce it, few customers reported it after deployed our app. I shared few system diagnose logs in the FB ticket.

I am not able to reproduce it

Hmmm, that makes things tricky. My experience is that investigations like this go a lot quicker when the product developer is able to reproduce the problem. I recommend that you work with the affected customers to see if there’s anything unique about their environment than triggers the issue. You can approach this problem from both ends:

  • Try to add stuff that they have to your environment.
  • Try to remove stuf that you don’t have from their environment.

I also recommend that you ask affected customers to retest with the latest seed of the macOS 26.5 beta. While I don’t have a specific bug fix I can point to, it’s a good idea in general.

I shared few system diagnose logs in the FB ticket.

Thanks.

I took a look at the sysdiagnose log and searched for the kernel: bpf26 attached to en0 by configd:331 message you mentioned. One thing that leapt out was this:

type: default
time: 2026-03-19 14:02:46.031151 -0500
process: kernel
message: bpf2 attached to en0 by UXXSssssssCccccc:1870

where UXXSssssssCccccc looks like it’s one of your processes. Critically, it’s certainly not configd, which is the process I’d expect to be using BPF for the purposes of doing DHCP.

Any idea what your software is doing with BPF?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

My process just do a traceroute with it. It might be wrong that the issue is because of bpf. Would you please review the logs to find the cause? I've upload one more logs set user reported in FB ticket FB22371512, user disabled our process in this case. This is what I see from logs:

343	Server	default	2026-07-24 15:10:34.104403 +0200	configd	DHCP en0: supplying hostname 'DHRMAC-JK2093KWWG'
343	Server	info	2026-07-24 15:10:34.105551 +0200	configd	DHCP en0: busy
343	Server	default	2026-07-24 15:10:34.106436 +0200	configd	DHCP en0: INIT waiting at 0 for 1.680259
343	Server	debug	2026-07-24 15:10:34.106440 +0200	configd	timer(dhcp-en0): 1.680259s
343	Server	default	2026-07-24 15:10:35.792320 +0200	configd	DHCP en0: INIT waiting at 1.68739 for 2.509179
343	Server	debug	2026-07-24 15:10:35.792326 +0200	configd	timer(dhcp-en0): 2.509179s
343	Server	default	2026-07-24 15:10:38.305397 +0200	configd	DHCP en0: INIT waiting at 4.20068 for 4.320592
343	Server	debug	2026-07-24 15:10:38.305404 +0200	configd	timer(dhcp-en0): 4.320592s
343	Server	default	2026-07-24 15:10:42.631076 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	default	2026-07-24 15:10:42.631675 +0200	configd	DHCP en0: INIT waiting at 8.52669 for 8.665435
343	Server	debug	2026-07-24 15:10:42.631683 +0200	configd	timer(dhcp-en0): 8.665435s
343	Server	default	2026-07-24 15:10:51.299364 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	default	2026-07-24 15:10:51.300082 +0200	configd	DHCP en0: INIT waiting at 17.195 for 8.653475
343	Server	debug	2026-07-24 15:10:51.300091 +0200	configd	timer(dhcp-en0): 8.653475s
343	Server	default	2026-07-24 15:10:59.956526 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	default	2026-07-24 15:10:59.956902 +0200	configd	DHCP en0: INIT waiting at 25.8521 for 8.930954
343	Server	debug	2026-07-24 15:10:59.956918 +0200	configd	timer(dhcp-en0): 8.930954s
343	Server	default	2026-07-24 15:11:08.889971 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	info	2026-07-24 15:11:08.889977 +0200	configd	DHCP en0: symptom failure already reported
343	Server	default	2026-07-24 15:11:08.890506 +0200	configd	DHCP en0: INIT waiting at 34.7856 for 8.724616
343	Server	debug	2026-07-24 15:11:08.890512 +0200	configd	timer(dhcp-en0): 8.724616s
343	Server	default	2026-07-24 15:11:17.615712 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	info	2026-07-24 15:11:17.615715 +0200	configd	DHCP en0: symptom failure already reported
343	Server	default	2026-07-24 15:11:17.615991 +0200	configd	DHCP en0: INIT waiting at 43.5113 for 8.059119
343	Server	debug	2026-07-24 15:11:17.615993 +0200	configd	timer(dhcp-en0): 8.059119s
343	Server	default	2026-07-24 15:11:25.677364 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	info	2026-07-24 15:11:25.677371 +0200	configd	DHCP en0: symptom failure already reported
343	Server	default	2026-07-24 15:11:25.677917 +0200	configd	DHCP en0: INIT waiting at 51.5729 for 8.870844
343	Server	debug	2026-07-24 15:11:25.677925 +0200	configd	timer(dhcp-en0): 8.870844s
343	Server	default	2026-07-24 15:11:34.553883 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	info	2026-07-24 15:11:34.553889 +0200	configd	DHCP en0: symptom failure already reported
343	Server	default	2026-07-24 15:11:34.554632 +0200	configd	DHCP en0: INIT waiting at 60.4494 for 8.519308
343	Server	debug	2026-07-24 15:11:34.554641 +0200	configd	timer(dhcp-en0): 8.519308s
343	Server	default	2026-07-24 15:11:43.079022 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	info	2026-07-24 15:11:43.079029 +0200	configd	DHCP en0: symptom failure already reported
343	Server	default	2026-07-24 15:11:43.079597 +0200	configd	DHCP en0: status = 'no server'
343	Server	info	2026-07-24 15:11:43.079763 +0200	configd	DHCP en0: not busy
343	Server	debug	2026-07-24 15:11:43.079787 +0200	configd	timer(dhcp-en0): 60s
343	Server	default	2026-07-24 15:12:43.084856 +0200	configd	DHCP en0: INIT
343	Server	default	2026-07-24 15:12:43.084872 +0200	configd	DHCP en0: supplying hostname 'DHRMAC-JK2093KWWG'
343	Server	info	2026-07-24 15:12:43.085153 +0200	configd	DHCP en0: busy
343	Server	default	2026-07-24 15:12:43.086070 +0200	configd	DHCP en0: INIT waiting at 0 for 1.896141
343	Server	debug	2026-07-24 15:12:43.086075 +0200	configd	timer(dhcp-en0): 1.896141s
343	Server	default	2026-07-24 15:12:44.984467 +0200	configd	DHCP en0: INIT waiting at 1.89894 for 2.535925
343	Server	debug	2026-07-24 15:12:44.984474 +0200	configd	timer(dhcp-en0): 2.535925s
343	Server	default	2026-07-24 15:12:47.526541 +0200	configd	DHCP en0: INIT waiting at 4.4406 for 4.008277
343	Server	debug	2026-07-24 15:12:47.526550 +0200	configd	timer(dhcp-en0): 4.008277s
343	Server	default	2026-07-24 15:12:51.535454 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	default	2026-07-24 15:12:51.536183 +0200	configd	DHCP en0: INIT waiting at 8.45058 for 8.822682
343	Server	debug	2026-07-24 15:12:51.536211 +0200	configd	timer(dhcp-en0): 8.822682s
343	Server	default	2026-07-24 15:13:00.363960 +0200	configd	DHCP en0: ARP router: No leases to query for
343	Server	default	2026-07-24 15:13:00.364665 +0200	configd	DHCP en0: INIT waiting at 17.2791 for 8.050677
343	Server	debug	2026-07-24 15:13:00.364672 +0200	configd	timer(dhcp-en0): 8.050677s
My process just do a traceroute with it.

Is that traceroute critical to your product’s functionality? If not, I think it would make sense for you to disable it. That would leave your product not touching BPF at all, and if you continue to see BPF problems then you know that it’s not your fault (-:


Oh, and just FYI, you don’t need to use BPF to implement traceroute on Apple platforms. Rather:

  • Send the UDP datagrams with the standard BSD Sockets API.
  • Collect the ICMP responses via an ICMP socket (IPPROTO_ICMP or IPPROTO_ICMPV6).

We have (very old, sadly) sample code for the latter in the Documentation archive.

However, I’m not recommending that you make this change as part of this debugging effort. Rather, I think it’d be easier to just disable your traceroute functionality. You can then use the results of that test to see if it makes sense to invest in writing this new code.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The traceroute was already disabled in previous logs I provided(latest logs in FB22371512), would you please check why DHCP still failing?

latest logs in FB22371512

So you’re talking about sysdiagnose_2026.07.24_15-10-27 0200_macOS_Mac_25F80.tar.gz, right?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes. And I uploaded one more log set "sysdiagnose_2026.08.03_16-47-30 0200_macOS_Mac_25F84" And this is what I see

335	Server	default	2026-08-03 16:49:26.889242 +0200	configd	DHCP en0: INIT waiting at 1.6588 for 2.429348
335	Server	default	2026-08-03 16:49:29.324229 +0200	configd	DHCP en0: INIT waiting at 4.09379 for 4.791609
335	Server	default	2026-08-03 16:49:34.119935 +0200	configd	DHCP en0: ARP router: No leases to query for
335	Server	default	2026-08-03 16:49:34.120446 +0200	configd	DHCP en0: INIT waiting at 8.88999 for 8.801197
335	Server	default	2026-08-03 16:49:42.926731 +0200	configd	DHCP en0: ARP router: No leases to query for
335	Server	default	2026-08-03 16:49:42.927369 +0200	configd	DHCP en0: INIT waiting at 17.6967 for 8.366917
335	Server	default	2026-08-03 16:49:51.298625 +0200	configd	DHCP en0: ARP router: No leases to query for
335	Server	default	2026-08-03 16:49:51.299031 +0200	configd	DHCP en0: INIT waiting at 26.0684 for 8.280975
335	Server	default	2026-08-03 16:49:59.581970 +0200	configd	DHCP en0: ARP router: No leases to query for
335	Server	info	2026-08-03 16:49:59.581976 +0200	configd	DHCP en0: symptom failure already reported
335	Server	default	2026-08-03 16:49:59.582550 +0200	configd	DHCP en0: INIT waiting at 34.3517 for 8.768247
335	Server	default	2026-08-03 16:50:08.355863 +0200	configd	DHCP en0: ARP router: No leases to query for
335	Server	info	2026-08-03 16:50:08.355868 +0200	configd	DHCP en0: symptom failure already reported
335	Server	default	2026-08-03 16:50:08.356420 +0200	configd	DHCP en0: INIT waiting at 43.1254 for 8.073674

And I uploaded one more log set "sysdiagnose_2026.08.03_16-47-30 0200_macOS_Mac_25F84"

To which bug?

I thought we were talking about FB22371512, and the latest uploads on that are:

  • sysdiagnose_2026.07.24_15-10-27 0200_macOS_Mac_25F80.tar.gz
  • 06396046 - 480230.pcap.zip

Also, in these upload pairs I see both a sysdiagnose log and a corresponding packet trace. Which device took the packet trace? The Mac having the problem? Or was it taken from the perspective of the network?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

This is only bug we are talking which is DHCP is failing here and FB22371512. I uploaded both sysdiagnose log and corresponding packet trace so that you can see DHCP process is broken from packet trace, and correlate to system log to analyze why DHCP broken. Issue is on macOS so all logs are collected from Mac device.

Hi, any update on this?

DHCP broken when device wakeup
 
 
Q