What's new

Voxel Custom firmware build for R7800 v. 1.0.2.79SF

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

There is (at least) 3 places where "apmode" is handled erroneously:
One place in /etc/init.d/opmode
and 2 places in /etc/init.d/qca-nss-ecm.

Here is the code so you can test/see yourself:
Code:
sed -i 's/apmode|extmode)/extmode)/' /etc/init.d/opmode
sed -i 's#support_bridge \&\& {#support_bridge \&\& [ "$(/bin/nvram get i_opmode)" != "apmode" ] \&\& \{#g' /etc/init.d/qca-nss-ecm
Reboot after change!

To restore original faulty stock code:
Code:
\cp -p /rom/etc/init.d/opmode /etc/init.d/opmode
\cp -p /rom/etc/init.d/qca-nss-ecm /etc/init.d/qca-nss-ecm
Hope that clears things up for you!

@kamoj can I ask what it is you did to attempt to fix? Technically?
Thanks for your efforts on this.
 
@Voxel

Just upgraded from 78SF to 79SF.

Install went smooth.

Shields Up tests pass.

Still running with TM disabled. Don't have the guts to turn it back on. My isp doesn't throttle me so TM is of no practical use to me.

A very satisfied Voxel firmware user since 62SF.

Thank you!
 
@Voxel

Shields Up tests pass.

Can someone explain to me the significance of passing the Shields Up! test?

On previous FWs and on different modems and routers I have run the test and failed it because of one or two ports being closed instead of stealthed. I always got the impression that, on its own, that did not bring with it any serious security implications. With the exception of a determined hacker being aware that those ports are there.

Having run it now I passed both the common and the all service port scan tests and all ports are stealthed, but I have not made any changes to the network settings in the R7800 or had anything change in the devices or home network topology. So I don’t really understand why those ports are now stealth as opposed to closed?

I’m not particularly concerned either way but it would be interesting to know if anyone has an idea about this.
 
Can someone explain to me the significance of passing the Shields Up! test?

On previous FWs and on different modems and routers I have run the test and failed it because of one or two ports being closed instead of stealthed. I always got the impression that, on its own, that did not bring with it any serious security implications. With the exception of a determined hacker being aware that those ports are there.

Having run it now I passed both the common and the all service port scan tests and all ports are stealthed, but I have not made any changes to the network settings in the R7800 or had anything change in the devices or home network topology. So I don’t really understand why those ports are now stealth as opposed to closed?

I’m not particularly concerned either way but it would be interesting to know if anyone has an idea about this.

Stealth means you're invisible to the bad guys. Closed tells the bad guys you exist although the port is closed. The bad guys may keep attacking until they find an open port.

More info here:
https://www.grc.com/su/portstatusinfo.htm
 
Stealth means your invisible to the bad guys. Closed tells the bad guys you exist although the port is closed. The bad guys may keep attacking until they find an open port.

More info here:
https://www.grc.com/su/portstatusinfo.htm
Yeah I get what the two statuses are, my question was more about what role firmware plays in this. Because between firmwares the two ports that were closed have now gone to stealth even though I haven’t changed anything and I don’t understand how that has happened.
 
I got a quick question, I recently got another R7800 to use as a bridge. It is losing connection after about 2 days of running as expected. The bridge R7800 is also running on 1.0.2.79SF, does anyone else experience such issues when using bridge mode?

When the bridge is disconnected there is no way to reach the management dashboard for Netgear, the IP assigned to the bridge no longer works, and there is no way to reach the bridge even with a wired connection to my laptop.
 
I don't know if this is a bug or not, but I've noticed that disabling QoS does not stay off after a reboot.
Every time the router gets rebooted, QoS is enabled again.

I don't know if this is intentional or not, but I thought it would remember the choice and keep it disabled after a reboot if the user selected it to be disabled.
 
Last edited:
Try this:
Code:
nvram set qos_endis_on=0
nvram commit
chmod -x /sbin/dni_qos
chmod -x /sbin/qos.sh
reboot

I don't know if this is a bug or not, but I've noticed that disabling QoS does not stay on a reboot.
Everyone the router gets rebooted, QoS is enabled again.

I don't know if this is intentional or not, but I thought it would remember the choice and keep it disabled after a reboot if the user selected it to be disabled.
 
I'd use the R7800 as AP.

Voxel.
So I've managed to flash Voxel 79SF, took me a few times to do the incremental updates from NG stock all the way up to a FW where it would recognise Voxel FW. Flash process was slick and easy.

Just a question on now running the R7800 in AP mode: Is it better to use the AP mode option in GUI, or manual workaround (static IP, disable DHCP, disable NAT). I have read somewhere that R7800 throughput is greatly reduced when using R7800 in AP mode, as hardware acceleration is disabled? Also I used the WAN port for linking to main router, but this created problems and random resets. Changing connection between router from wan to lan seemed to fix it. Did some research and found posts that say using wan to link AP is perfectly fine, other posts say to only use lan. What is the truth?

Otherwise thanks so much for work on this FW, the wireless reach on my R7800 is quite nice now.
 
Last edited:
Probably a bug, but you never know: Netgear has a tendency to let the router run things like aws, traffic control, so...

Thanks, that worked.
Do you know if it's meant to save the preference as standard or is this a bug?
 
I got a quick question, I recently got another R7800 to use as a bridge. It is losing connection after about 2 days of running as expected. The bridge R7800 is also running on 1.0.2.79SF, does anyone else experience such issues when using bridge mode?

When the bridge is disconnected there is no way to reach the management dashboard for Netgear, the IP assigned to the bridge no longer works, and there is no way to reach the bridge even with a wired connection to my laptop.

I turned off HT160 on both the bridge and main router and the issue seems to be gone, it seems HT160 is not stable for the bridge connection. It must be off on the main router too not just the bridge. It's a shame seems now there are more 160Mhz clients available but they are not fully compatible with WiFi 5 160Mhz like the AX201 which I could not get 1733 Mbps working.
 
When rebooting my R7800, Dynamic QoS stays turned off. It has also stayed turned off over FW flashes and all settings have stayed the same.
It maybe because you've been upgrading from previous firmwares.

I've gone from stock Netgear to Voxel's 1.0.2.79SF.

Mine wasn't saving it at each reboot. I had to go back and turn it off.
I rebooted a number of times testing out other things such as OpenVPN client and AdGuard Home and each time it turned itself back on at reboot.
 
Hello Voxel and All, i have an issue with Guest wifi. if i untick " Allow guests to see each other and access my local network " Guests can connect to it but without internet access. i have to tick it to gave access to internet. do anyone know why? using .79 + Kamoj addon 5.3 beta
Just also tested this. -> it seems that the issue is DNS related. because browsing to http://1.1.1.1 via the guest-wifi does work.

I'm guessing you are also using AdGuardHome with the Kamoj addon?
Because if I disable AdGuardHome, then DNS via guest-wifi starts working again.

Not sure yet how the guest-wifi isolation thing exactly works and if it is fixable.
 
  • Like
Reactions: KW.
found the issue in the ebtables rules -> these allow only a handful of ports from the guest-wifi to the router itself. and the port 5300 that AdGuardHome is listening on, is not one of them.

workaround is to execute these 2 commands:
Code:
ebtables -I INPUT -p IPv4 --ip-proto udp --ip-dport 5300 -j ACCEPT
ebtables -I INPUT -p IPv4 --ip-proto tcp --ip-dport 5300 -j ACCEPT

I didn't look yet where these ebtables rules are generated to begin with.
So I also don't know how often the router is flushing/rebuilding the ebtables.
(did see that net-wall restart does not affect ebtables)

also a slight bug in the firmware: Netgear only allows udp_53 from guest-wifi. But DNS in some cases can also use tcp_53.
So when running guest-wifi in isolation, without AdGuardHome, then also this rule would be required:
Code:
ebtables -I INPUT -p IPv4 --ip-proto tcp --ip-dport 53 -j ACCEPT
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top