There are none, have never been and will never be (that’s a fairly safe claim for ipq806x, given the slightly different direction ipq95xx has taken this most likely also applies to ipq807x/ ipq50xx/ ipq60xx).
1 Like
Yes I read the ipq95xx moved away from using NSS cores but is using CPU logic and kernel fastpath which sound promising but as Harley riders say " There is no substitute for cubic inches" just a beefy CPU and you are fine 
The Arm A5X series is energy efficient but the IPC is anaemic
Indeed, that was also my solution (x86_64) - albeit triggered for different reasons (the fabric frequency scaling induced instability in early 2021(?) forced me to search for an alternative to ipq8065). But I’m not looking back, plenty of raw power (enough to do sqm+cake for my ftth connection, large adblock lists, sure, bring it on), not fighting against buggy offloading implementations, booooring in the best sense of the word, it just works, all the time.
2 Likes
A couple of years later I found it in a drawer and decided to spend some time on it again
Here is the result
TLDR: If Lan ports are dead and factory uboot does not support USB (which it does not, code is commented out), you can recover via serial connection + some patience.
1 Like
I am suddenly seeing the network crashing at boot in my "dumb AP" R7800.
Using the up-to-date main/master build r32883-16239e90ad.
Week-ago build r32783-cf84e8ee86 boots ok.
Strange, as I can't easily identify many possible culprit commits from the OpenWrt commit log since the working build. Even the same kernel version, I think.
I have already removed pretty much all services, disabled wifi etc., but still the crash is coming from the basic networking.
Somehow it looks like the switch is not initialising and declaring the interfaces.
According to system log, procd says that network crashes.
root@router78:~# logread | tail -n 20
Sun Feb 1 11:40:13 2026 user.notice : Added device handler type: tunnel
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: vrf
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: bonding
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: 8021ad
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: 8021q
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: macvlan
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: veth
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: bridge
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: Network device
Sun Feb 1 11:40:18 2026 user.notice : Added device handler type: tunnel
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: vrf
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: bonding
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: 8021ad
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: 8021q
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: macvlan
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: veth
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: bridge
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: Network device
Sun Feb 1 11:40:23 2026 user.notice : Added device handler type: tunnel
Sun Feb 1 11:40:23 2026 daemon.info procd: Instance network::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
root@router78:~# ifconfig
eth0 Link encap:Ethernet HWaddr DC:EF:09:EF:F3:E5
inet6 addr: fe80::deef:9ff:feef:f3e5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1502 Metric:1
RX packets:204 errors:0 dropped:0 overruns:0 frame:0
TX packets:204 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12556 (12.2 KiB) TX bytes:12556 (12.2 KiB)
Interrupt:32
Anybody else seeing anything strange with R7800 or other ipq806x devices?
There have been commits about DSA making it possible to add the wan port to the br-lan bridge.
About the ethernet conduits and the dual cpu ports.
I am travelling so cannot look it up
But that was a few weeks ago
But maybe related?
This time not related to DSA. I figured it out:
The change to netifd logging exposes a crash reaction to certain malformatted uci options in network config.
- The commit https://github.com/openwrt/openwrt/commit/168d5affc3bd1aa07ce0b36ed417e6e4fa6f4a20 from PR https://github.com/openwrt/openwrt/pull/19737 changes the network (netifd) init script regarding logging.
- My dumb AP config had a malformatted line in lan interface config:
option ip6ifaceid='::78'(there is extra '=', should be just space).
That combination kills the network bring-up.
Things get fixed by either
- removing the logging options change line
procd_append_param command -l ${netifd_loglevel}from/etc/init.d/network, or - removing the faulty
=from/etc/config/network.
So, the network init script change seems to expose some underlying problem related to logging in netifd (and related). Trying to log that error apparently causes netifd to crash.
4 Likes
Good find 
I debugged this further, and the reason seems to be the new validate section that is always run before netifd is launched. The validate function is not guaranteed to return a value.
Commit 168d5af added the possibility to configure netifd logging level. The option is read from /etc/config/network and validated. Supposedly the validation sets 2 as default.
However, if there is a syntax error in the uci file, the validate returns an empty value (instead of '2' that is supposed to be the default from validation), which empty is then passed unchecked for "-l" netifd param. That causes the netifd launch to fail due to the missing numeric parameter after '-l".
As a fix, I authored a PR to add a fallback value 2 to the variable, so that there will always be a proper value after the '-l' option.
The adding of the logging parameter was fundamentally ok, but it just exposed the fragility of the validate functionality, which apparently can a bit unexpectedly return also an empty value in some cases. Which then needs a further safeguard to prevent unnecessary softbricks (as small syntax errors in the network config file are not that rare).
5 Likes