OpenWrt Support for Armor G5 (NBG7815)

I've noticed there is a problem with the "bridge offloading" implementation it is causing excessive cpu usage in some circumstances.

Disable birdge offloading and try it again.

uci set ecm.@general[0].enable_bridge_filtering='0'
uci commit
service qca-nss-ecm restart; sleep 5
service network restart

Is this related to the nss build or also the standard one?

nss build related

1 Like

I'd like to switch to OpenWRT on this router but I'm kinda lost between the different branches, could someone kindly compare performances (PPPoE, WiFi), issues, stability and features of the available branches? Is the installation procedure the same? Can I switch from one branch to another?
(I’m referring to official RC3, psychowood, Asvio and NSS builds)

Sorry for the noob question, but I’m still a novice and I'm trying as hard as I can to avoid bricking it :slight_smile:

Hi there,
the nss build works great for me, it was unstable at first and crashing, but i got 1-2d+ uptime, i had to restart to test some stuff and i will try to keep it up for a week after which i will update the second router as well. Speeds are excelent (918mbps with iperf3 over wifi close to the router, aprox 1m), i did not manage to test the 10G port for this build.

One issue i have is that it has a partition that is unused which i would love for that to be used as well, the 2.8G one.

Command (m for help): p

Disk /dev/mmcblk0: 3.53 GiB, 3791650816 bytes, 7405568 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98101B32-BBE2-4BF2-A06E-2BB33D000C20

Device            Start     End Sectors  Size Type
/dev/mmcblk0p1       34   16417   16384    8M unknown
/dev/mmcblk0p2    16418   18465    2048    1M unknown
/dev/mmcblk0p3    18466   30753   12288    6M unknown
/dev/mmcblk0p4    30754  153633  122880   60M unknown
/dev/mmcblk0p5   153634  161825    8192    4M unknown
/dev/mmcblk0p6   161826  163873    2048    1M unknown
/dev/mmcblk0p7   163874  176161   12288    6M unknown
/dev/mmcblk0p8   176162  299041  122880   60M unknown
/dev/mmcblk0p9   299042  307233    8192    4M unknown
/dev/mmcblk0p10  307234 1355809 1048576  512M unknown
/dev/mmcblk0p11 1355810 7122977 5767168  2.8G unknown

I'm on the same boat with QNAP QHora-301W with /dev/mmcblk0p9 2.05GiB.
I never intend to use the original crap firmware.
Running myself compiled NSS build with VPN, VLAN and tons of other customizations it is rock solid.

Has anyone tried the 160 mhz channel? I tested it in many snapshot versions but it couldn't get it to work. It is said that IPQ807x works on 36 and 100 mhz channels. Working examples are available for DL-WRX36. Why doesn't it work on NBG7815?

Look at the extroot instructions, I don't have it enabled right now but was previously working.

@asvio in your build I noticed that there are 4 missing thermals (broken images) pointing to some generic cooling_device0 to cooling_device3, not sure where they come from.

On this point, would it be possible to add the fan as a cooling device to be monitored? Even if it is just a generic on/off sensor.

Hello, take a look on this post :

expectially the point 6. That's what I've done on mine (the same mmcblk after all, maintaining the 2Gb+ as /tmp for future use)

All needed are included in the latest @asvio 's nss build

At the end you have 500Mb+ space... IMHO more that you can use for general purpose !

This is a problem with the luci-statistic package that tries to read the temperature of thermal devices linked to the passive cooling defined for the CPU (cooling_device0) and for the Wi-Fi chipset (cooling_device1-3)
These cooling_devices do not provide a temperature value so there is nothing to read and the graph remains blank.

Passive cooling in this case refers to cooling mechanisms due to component inactivity (frequency reduction, voltage reduction...)

The same thing happens with the ipq806x routers.

I hope the explanation is not too confusing and that I am not wrong (which is very likely).

Have you an idea of what each thermal_zones are linked for ?
In deduction I found that zone12 is for the cpu I think, but the others... They are so many :scream:

Zone12 is for 10g port
Zone1 nss0
Zone2 nss1
Zone0 nsscluster
Zone5 cpu0
Zone6 cpu1
Zone9 cpucluster

In my build there is zone13 that is the board sensor temp wich is the same than sensor tmp103...

I don't remember the other zone.

Thx for the detail. 10g port is heating more than the cpu ^^ damned :slight_smile:

Thank you for your work, I'm still running your build with pleasure, I've just a device who won't connect wifi (a Galaxy Tab A7) with Handshake error, the device is not here actualy so I test more in detail later.

Is any people knowing the other zones detail ? Just for a correct naming of sensors's datas

1 Like

You can do it by yourself

BusyBox v1.36.1 (2023-09-24 10:47:14 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 OpenWrt SNAPSHOT, r24069+53-954142f477
root@NBG7815:~# cat /sys/class/thermal/thermal_zone*/type
root@NBG7815:~# cat /sys/class/thermal/thermal_zone2/type
root@NBG7815:~# cat /sys/class/thermal/thermal_zone3/type


I did some testing, I have two NBG7815 and a 10Gb network backbone on an XS1930-10. I'm using the asvio build "OpenWRT-nbg7815-r24056+8-86dadeba48 - sysupgrade Pre-release" on both.
When I did tests with iperf it doesn't matter if on 10Gb or 2.5Gb port max transfer is 1.80 Gbits/sec.
I tried all configurations with Packet Steering, or software offload and no change.
Do you have any ideas what else I can try? Because at the moment with the current heating of the 10Gb port and the fact that the transfers are the same on 2.5gb it isn't worth for me to use the 10Gb port.
(BTW, On main NBG7815 I use this 10Gb port as WAN and LAN, WAN is on tagged VLAN and LAN is untagged)

1 Like

1,8 Gb is the max you can get with this router on OpenWrt without NSS at this moment.
I do a new release base on 23.05.0. It doesn't has extroot but all other stuff prerelease has.
This is the choise for safety. It supose to be more stable than prerelease base on main branch.
NSS version needs more developement on wlan side (this is my opinion) but If performace in 10gb and/or 2,5gb it a must to have, the only way at this moment is flashing the NSS version.
NSS version needs to desable packet stearing and software offloading before you flash, but if you pass the firstboot problem and reboot, it works well (for my use it works without problem, and i have multiples vlan and 2 or more ssid per radio 0 and radio 1. I don't use ipv6).

1 Like

There is a problem connecting clients to an OWE encrypted SSID (opportunistic wireless encryption) on the IPQ8074. I tried with 2 clients (iPhone 12 Pro and Samsung Galaxy S21 5G). Both could not connect to the OWE Access Point set up on the Armor G5. Both clients successfully connected to the OWE SSID set up on a R7800 and Archer C2600 (IPQ806x) running OpenWrt 22.03.5. I will update the R7800 to 23.05.0 to see if OWE still works.

Did somebody else found this issue before?

On R7800 upgraded to 23.05.0 OWE does also not work anymore. Logread tells:

Sun Oct 22 10:07:45 2023 hostapd: phy0-ap0: STA 78:64:c0:d8:f1:b8 IEEE 802.11: authenticated

Sun Oct 22 10:07:45 2023 kernel: [ 1735.798093] ath10k_pci 0000:01:00.0: mac flush vdev 1 drop 0 queues 0x2 ar->paused: 0x0 arvif->paused: 0x0

Solution to the OWE issue found. OWE works after removing wpad-basic-mbedtls and installing wpad-basic-wolfssl or wpad-openssl instead. Reboot required. So far I tested only on the R7800 with 23.05.0 but I assume its the same on the G5.


I didn't upgrade my routers for a few month now because they were running stable and I had less time/desire to mess around.

I've adjusted my builds to fit latest changes. But recent commits changed sth. regarding MAC's. So I figured out that after this commit: kernel: backport nvmem v6.6 fixes and v6.7 changes MAC addresses going crazy:

[    4.171248] GMAC2(ffffff8003ffxxxx) Invalid MAC@ - using 82:3f:e0:52:de:8b
[    4.174842] GMAC3(ffffff8003c8xxxx) Invalid MAC@ - using 16:86:7f:39:0c:1d
[    4.181661] GMAC4(ffffff8003ffxxxx) Invalid MAC@ - using 1e:b9:7f:62:e1:3d
[    4.188461] GMAC5(ffffff8003d7xxxx) Invalid MAC@ - using f2:f6:f7:59:51:28
[    4.395754] GMAC6(ffffff8004d9xxxx) Invalid MAC@ - using 86:a2:36:58:1e:65

MAC's are changing every (re-)boot. The messages above are not present before this patch. Does anyone have the same issue? I know we have issues regarding Wireless MAC changing every reboot for this device. But this is different. It is affecting all MAC's now. -.- If I would guess it is related to 816-v6.7-0004-Revert-nvmem-add-new-config-option.patch. I didn't check so far just deleting this specific patch and I still didn't cross check with other IPQ807x devices also.