Build for Netgear R7800

You really want to provide more details what exactly doesn't work for you. A screenshot may be worth a thousand words.

1 Like

owrt2410-r28430-e4d840b312-20250204 should be equivalent to the 24.10.0 release being currently compiled in the buildbot.

1 Like

I compiled 24.10.0 and it runs fine upgraded from RC7

Only problem I also had on RC5 and following is with setting up a DumbAP, other users also have reported this same problem.

I did a quick test, my router was on its own subnet 192.168.5.0/24 and I now have made it a Dumb AP, deleted everything from the wan and added the wan port to br-lan set the IP address in the main lan and added gateway and dns:

config device
   option name 'br-lan'
   option type 'bridge'
   list ports 'lan1'
   list ports 'lan2'
   list ports 'lan3'
   list ports 'lan4'
   list ports 'wan'
   option ip6assign '64'
   option ip6hint '5'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr '192.168.0.5'
    option netmask '255.255.255.0'
    option ip6assign '63'
   option gateway '192.168.0.1'
   list dns '192.168.0.1'

Rebooted the router and my workstation which is on LAN port 3 had internet. The WAN port still had the cable to the main router.

So far so good

What is not working is that from the LAN ports I cannot connect/ping the router at 192.168.0.5, but I can from the WAN port????

Not sure what to make of this, this started with the move to DSA maybe related to the fact that this router has two CPU ports for the switch?

1 Like

I have not used my R7800 as dumb AP, nor have I tried to bridge the wan port into lan. So, not much experience from me regarding your specific challenge.

(There is nothing special in my build regarding network hardware definitions, so this is likely not related to my build itself.)

No not related to your build it could be a DSA bug?

2 Likes

Not related to this build, it happens with official snapshot builds too. I'm also seeing the same issue with R7800 as a dumb AP with wan port assigned to br-lan bridge.

3 Likes

Hi there, i updated the router with the latest firmware version but I had a problem installing the ath10 driver to replace the default ath10-ct one.
Usually what I did was:

  1. opkg remove kmod-ath10k-ct; opkg remove ath10k-firmware-qca9984-ct
  2. opkg install /tmp/ath10k-mainline-[file from hnyman repository].ipk
  3. opkg install /tmp/ath10k-firmware-[file from official repository].ipk (file from https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/)
  4. reboot

The problem is in point 3: in the official repository there are now .apk files (instead of .ipk), and these packages are not installable with the opkg command (but with the apk command, not available in current firmware).
So i used this command:
3. opkg install ath10k-firmware-qca9984
(which automatically downloaded the package from the official repositories).

Wi-fi is working, but i don't know it it's correct.

If you install the master build, the files are in any case in the .apk format (even if I would have forgotten to change the suffix in the build artifact rename command). I will need to check the naming.

In 24.10 build they are naturally really .ipk

I installed "stable openwrt-24.10" (with ipk files), but blob files from "https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/" are in apk format.

Is it ok to simply install with command "opkg install ath10k-firmware-qca9984" or should i get latest blob in ipk format from another source?

Well, the 24.10 downloads are separate from the main/master downloads.

If you installed my 24.10 build, the official downloads are in https://downloads.openwrt.org/releases/24.10-SNAPSHOT/ in .ipk format.

but my build includes those correct files in the download directory of each build. You should use them.

:thinking:
Your build includes only one of the two packages i replace ("ath10k-mainline-owrt2410-r28430-e4d840b312-20250204-2041.ipk" that replaces "kmod-ath10k-ct").
But it doesn't includes the second package replacement ("ath10k-firmware-qca9984-ct"). I usually got it from https://downloads.openwrt.org,

So for 24.10 release i should take it from https://downloads.openwrt.org/releases/24.10-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/base/ (and NOT from https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/ ).

I don't understand how that package differs from the one installed by a simple "opkg install ath10k-firmware-qca9984" command.
But it's not important, to be sure I'll take it from https://downloads.openwrt.org

Thank you

It is not included in the my build's download dir, as installing the kmod will pull the wifi firmware blob from the official download site. (There is no difference in the binary firmware.)

1 Like

really hope this issue gets fixed as the r7800 is a great dumb AP device. ( fixing is out of your hands I think?)

1 Like

Not sure it's worth ever going to v24 when v23.05.5 has been running rock stable for me as a dumb AP, using the mainline firmware and drivers though, not CT. I only reboot mine when there's a v23 update.
Not sure what I'll replace it with when the hardware dies, I've had it for 6-7 years now and I feel no need for faster wifi.

After years of using R7800 with your build I switched to x86 build on N100 minipc and just wanted to say thanks for all your work. Especially having to hunt tens of packages that were conveniently already included with your image was a right PITA.

2 Likes

Just for anyone encountering the same issue:
trying to flash the stable 23.05 from here, flashed successfully but upon visiting the router site a LuCI error appears:

Unable to render any theme header template, last error was: Unable to compile 'themes/null/header' as Lua template:

This happened both when flashing sysupgrade or factory.img.
I found this thread: Strange issue with image builder luci theme fails to load properly

Adding a new line on the luci config file also fixed this for me.

The reason was likely an accidental character included in the embedded default luci config file of the 2025-02-04 build, an orphaned 'c' at the last line. Removing that 'c' would have likely fixed things, too.

I made a new build owrt2305-r24177-b0834b0265-20250424 with the corrected LuCI config file. But if you already have fixed things, there is likely no real need to sysupgrade inside 23.05 to the newest 23.05 build, as there are not mouch other real changes.