NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
BUG: KERNEL CRASH in 9.13.1.2, Orbi 970
After being up about 28 hours, one of my 970 satellites did a restart. The bug log reports that the reason was a kernel crash.
It was at about 1:30 AM local time, so little or no action going o...
I assume you have 970 Orbi series? Try these steps and wait to see if it fixes the crashes:
- 9.13.2.1 is the latest version - https://www.netgear.com/support/download/?model=RBE973S&_ga=2.38375275.974127454.1697786862-475167439.1689166105 Update manually or via the router admin web page (Advanced Tab -> Administration-> Firmware Update
- On the router admin web page, Advanced tab, Administration -> Logs: In the section "Include in Logs, turn everything OFF. At the top, click the Clear Log button.
Then let it run and see if the panics continue. If they do, open a support ticket - get the ticket number and post it here, I'll also send that to our engineering contact who may have some ideas.
Yes, I have 970. My support ticket is 49350608
This firmware zip contains the old firmware; they packaged it wrong.
Yeah, they were running beta firmware. Netgear finally published it into production on Oct 31st 2025 but mistakenly packaged the wrong version. It's really frustrating because the community Mods keep locking down the threads when people bring up the issue.
I also asked ChatGPT with a stacktrace attached, and here's what it said:
That’s a real kernel panic dump — and it gives a lot of clues about what went wrong inside your Orbi 970.
Let’s break it down clearly 👇
---
🧠 Plain-English Summary
Your Orbi 970 crashed because a system process (d2d) tried to write to a null pointer (address 00000000) — meaning it attempted to access memory that doesn’t exist.
This caused the Linux kernel to panic and halt to prevent further damage.
So in short:
> A software component in the router firmware hit a programming bug — likely a memory management or networking issue — causing a system crash.
---
⚙️ Technical Details
From the dump:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Process d2d (pid: 5457)
PC is at skb_queue_tail+0x1c/0x48
Crash function: skb_queue_tail() — this is a Linux kernel function that handles network socket buffers.
Caller: unix_dgram_sendmsg() → part of the inter-process communication (IPC) system using UNIX domain sockets.
Process: d2d — this is almost certainly “Device-to-Device” communication service used by Orbi mesh nodes to talk to each other.
Fault: Null pointer dereference → means some buffer or pointer wasn’t properly initialized or got freed prematurely.
So the D2D (mesh communication) process tried to queue a network packet into a null socket buffer.
That’s a firmware bug, not a hardware failure.
---
🔄 Likely Cause
This is almost always due to:
A firmware bug in the D2D or NSS (Qualcomm networking subsystem) code.
Could be triggered by mesh sync, Wi-Fi backhaul instability, or a corrupted configuration.
The “Tainted: P” line (Tainted: P) means it’s using proprietary Qualcomm/Netgear kernel modules, so standard Linux debugging is limited.
