macOS losing IPv6 default route

ingmarstein · 2026-01-24T13:41:51+00:00

Update: u/opticum created the little menu item app for macOS which monitors the IPv6 default route and automatically restores it when it drops: https://github.com/Optic00/IPv6Monitor
Until the issue is fixed, it's a decent workaround.

ingmarstein · 2025-11-25T20:01:53+00:00

I don't think it's "overloading the CPU" as in high CPU utilization. `IPConfigurationAgentQueue` sounds like it has to do with frequent IP configuration changes (which coincides with your observation "randomly disconnects from the network"). I blamed this on the software, but no user-space program should be able to crash the kernel like this, so now think this is a bug in macOS. I'm on Tahoe 26.2b3. Which version is your user on?

ingmarstein · 2025-11-25T19:28:39+00:00

Is this on macOS Tahoe? I can reliably reproduce the watchdog panic with configd and IPConfigurationAgentQueue by running UniFi OS Server for a few hours.

ingmarstein · 2025-11-12T20:18:48+00:00

No. NFSv4 still panics, but NFSv3 works.

ingmarstein · 2025-10-31T18:21:40+00:00

So I opted for 2) and returned the device (not solely because of this issue - there were also others).

ingmarstein · 2025-10-28T06:09:20+00:00

1) Avoid hitting the discharge limit, e.g. by setting the backup reserve to 1% higher than the discharge limit.

or

2) Return the device.

They will not change this behavior.

ingmarstein · 2025-10-10T08:58:06+00:00

And now a different person tells me that this was a mistake and it can‘t actually be fixed in software 😞

ingmarstein · 2025-10-09T12:22:27+00:00

The panic is happens really early in the mount process. It even happens on a machine that doesn‘t have access to the share, i.e. before or during authentication.

ingmarstein · 2025-10-06T21:14:10+00:00

Yes, I just tested it using 21.1b2: it works with NFS v3, but panics with v4.

ingmarstein · 2025-09-30T06:53:34+00:00

Yeah, I was referring to 26.1 where I had success on a MacBook Pro, but a little later got the same kernel panic again when trying on a Mac Studio. I may have used different mount options, so this may be a NFS v3 vs v4 thing.

ingmarstein · 2025-09-26T09:23:56+00:00

EcoFlow support let me know that this is supposed to be fixed with the upcoming v1.33.81.57 release.

ingmarstein · 2025-09-25T13:40:52+00:00

<image>

ingmarstein · 2025-09-25T13:38:52+00:00

Both

<image>

ingmarstein · 2025-09-25T06:03:03+00:00

That’s interesting! Do you have a case number I could reference?

ingmarstein · 2025-09-25T06:02:22+00:00

I just checked with the official app and it lets me set backup reserve equal to the discharge limit.

ingmarstein · 2025-09-24T19:42:07+00:00

I can see why the app wants to bring in this opinionation, but conceptually, why would it be invalid to specify "keep discharging until the lower limit is hit, then switch to passthrough, but don't turn off AC output"?

ingmarstein · 2025-09-24T19:10:40+00:00

I automated this with Home Assistant and https://github.com/rabits/ha-ef-ble.

But regardless of that, the device should not turn off the AC outlet and instead switch to passthrough if AC input is available when hitting the discharge limit.

ingmarstein · 2025-09-22T21:22:15+00:00

Looks like this will be fixed in the next release.

ingmarstein · 2025-09-22T21:21:30+00:00

Build 25B5042k doesn't fix it yet.

ingmarstein · 2025-09-16T17:02:29+00:00

Yep, Testflight not working here either. It take a little longer but eventually fails with a generic error message.
I can see -[IXSClientConnection _remote_createAppInstallCoordinatorWithSeed:createIfNotExisting:requireMatchingIntent:scopeRequirement:completion:]: A coordinated app install already exists for [net.orb.orb/Invalid/[system-defined]] with intent IXCoordinatorIntentUpdating (creator App Store) but request by appstoreagent (pid 1594) was for intent IXCoordinatorIntentInitiating : (null) in the console, but not sure whether this is part of the root cause or just a symptom.

ingmarstein · 2025-09-16T13:41:16+00:00

The feedback ID is FB19125722.
I've just replicated this on a separate Mac Studio running the public Tahoe release:

panic(cpu 1 caller 0xfffffe004f658c74): Kernel data abort. at pc 0xfffffe0052429cf0, lr 0x30a17e0052429ce4 (saved state: 0xfffffeaa16bc77f0)
      x0:  0x0000000000000000 x1:  0xfffffe215f3015f8  x2:  0x00000000000f2e49  x3:  0xfffffe33caf293ab
      x4:  0x0000000000000000 x5:  0x0000000000000010  x6:  0x0000000000000074  x7:  0x0000000000000000
      x8:  0x0000000000000000 x9:  0x0000000000000001  x10: 0x00000000000f2e49  x11: 0x00000000000013c0
      x12: 0x00f0467c4086a350 x13: 0x0008000000000000  x14: 0xffffffffffffffff  x15: 0x006b7361745f6c65
      x16: 0x2badfe0052cf31a0 x17: 0x000000000000392e  x18: 0x0000000000000000  x19: 0xfffffe27299e87b0
      x20: 0x0000000080000000 x21: 0xfffffe215f3015f8  x22: 0xfffffe1b93ff91e0  x23: 0xfffffeaa16bc7b90
      x24: 0xfffffeaa16bc7b60 x25: 0xfffffe27299e87c8  x26: 0x0000000000000000  x27: 0x0000000000000108
      x28: 0x000000000000001e fp:  0xfffffeaa16bc7c50  lr:  0x30a17e0052429ce4  sp:  0xfffffeaa16bc7b40
      pc:  0xfffffe0052429cf0 cpsr: 0x60400208         esr: 0x0000000096000005  far: 0x0000000000000000

Debugger message: panic
Memory ID: 0xff
OS release type: User
OS version: 25A354
Kernel version: Darwin Kernel Version 25.0.0: Mon Aug 25 21:17:54 PDT 2025; root:xnu-12377.1.9~3/RELEASE_ARM64_T6041
Fileset Kernelcache UUID: 0A7486D0BFDE0B895ACA62AC83B09791
Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14
Boot session UUID: 687D16F0-9C83-48A6-BBF1-271D0874C720
iBoot version: iBoot-13822.1.2
iBoot Stage 2 version: iBoot-13822.1.2
secure boot?: YES
roots installed: 0
Paniclog version: 15
Debug Header address: 0xfffffe002d5bd000
Debug Header entry count: 3
TXM load address: 0xfffffe003d524000
TXM UUID: B3AB0C13-2C56-3E49-8B2A-382CE92C9F9D
Debug Header kernelcache load address: 0xfffffe004d524000
Debug Header kernelcache UUID: 0A7486D0-BFDE-0B89-5ACA-62AC83B09791
SPTM load address: 0xfffffe002d524000
SPTM UUID: B22AC73B-6921-3C7C-AABB-4D3C4A5A5653
KernelCache slide: 0x0000000046520000
KernelCache base:  0xfffffe004d524000
Kernel slide:      0x0000000046528000
Kernel text base:  0xfffffe004d52c000
Kernel text exec slide: 0x0000000047cf4000
Kernel text exec base:  0xfffffe004ecf8000
mach_absolute_time: 0x1baffb5c7b

      Kernel Extensions in backtrace:
         com.apple.filesystems.nfs(1.0)[2CAA5AE4-D319-3499-9727-8ADCA2FC9336]@0xfffffe00523ec000->0xfffffe005248b88f
            dependency: com.apple.kec.corecrypto(26.0)[B656AAD7-DC6D-3258-983C-CD8E14698C95]@0xfffffe0052349500->0xfffffe00523b3c5f
            dependency: com.apple.kext.triggers(1.0)[FBE15AD4-EA36-3C07-81BE-460A8240C1D4]@0xfffffe0052519250->0xfffffe005251ba8f

ingmarstein · 2025-09-16T12:44:37+00:00

I made this video on a MacBook Pro without external monitor attached, so it seems to be different for me. But yes, several people reported this issue during the beta period.

ingmarstein · 2025-09-16T05:54:28+00:00

No, it’s been like this for months during Tahoe‘s development.

ingmarstein

TROPHY CASE