What's new

Voxel Custom firmware build for R7800 v. 1.0.2.94SF

  • 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!

Thanks to @fossil re: WebGUI LG_VERSION.

I had to release SnapShot version. Minimal changes:

V1.0.2.94.1SF
1. proftpd package is upgraded 1.3.7c->1.3.7d.
2. Upgrade WebGUI LG_VERSION

There are some bugs in LG translation used in the stock. So it is better to do not use LG translation updates with my build.

Voxel.
 
Thanks to @fossil re: WebGUI LG_VERSION.

I had to release SnapShot version. Minimal changes:

V1.0.2.94.1SF
1. proftpd package is upgraded 1.3.7c->1.3.7d.
2. Upgrade WebGUI LG_VERSION

There are some bugs in LG translation used in the stock. So it is better to do not use LG translation updates with my build.

Voxel.
Thank you for releasing this snapshot.

Previously once you hit the LG update. There was no way to go back to fw builtin LG version (V1.0.0.361) I tried deleting all LG update files, reverting back to old fw versions upto .68SF & .68, resetting NVRAM var to StringTable_NonEnglish_Ver=V1.0.0.361, resetting router. I think it stores/updates that information (LG update available) permanently somewhere.

net-cgi binary will automatically download the NG LG update once rebooted. It downloads /tmp/fileinfo.txt based on that it downloads NG LG update and untar it to /tmp/multi_lang folder

So if someone has not updated the LG version from UI, based on Voxel's recommendation don't do it. There is no going back.

I updated the fw snapshot ver to .94.1SF. I see you bumped the LG version to V1.0.0.426

Now it is not creating /tmp/have_new_language, /tmp/lang_url and /tmp/lang_version files. It is still downloading /tmp/fileinfo.txt and then download & untar .425 LG table to /tmp/multi_lang folder. Once router is rebooted.

I think only way to stop it from downloading fileinfo.txt and LG update is block these 2 domains:
http.fw.updates1.netgear.com - [TCP port 443 HTTPS]​
updates1.netgear.com - [TCP port 21 FTP]​

I will test it tonight
 
Last edited:
I think only way to stop it from downloading fileinfo.txt and LG update is block these 2 domains:
http.fw.updates1.netgear.com - [TCP port 443 HTTPS]updates1.netgear.com - [TCP port 21 FTP]
As far as I remember these domains are used to download ReadyCLOUD and KWILT. So it is why I did not block them. Some people still prefer to use these coockies from NG.

the same I see you bumped the LG version to V1.0.0.426
It is made from V1.0.0.425 plus my changes. Including some bugs fixing. Not significant but annoying.

So if someone has not updated the LG version from UI, based on Voxel's recommendation don't do it. There is no going back.
I am not sure that it is fatal. For example no any attempts of updates for two of my R7800 but the same /tmp/fileinfo.txt.

Voxel.
 
Languages look like they are saved into /dev/mtd10. It's raw flash with no filesystem. It looks like it has a 2-3 letter language code, a new line, and then a tar file with one file inside, named language_table.tar.gz. My flash has six of these, Eng, SP, PR, FR, GR, and IT.

The language_table.tar.gz file that is inside the tar file in flash has four files inside a directory named multi_lang, which have information for one language.

I'd guess the firmware downloads a new language pack and writes certain languages to flash in /dev/mtd10. That's why a firmware update (/dev/mtd6), wiping UBI (/dev/mtd7), clearing config, etc. doesn't recover the old language. All the languages would take too much flash space.

The file /tmp/lang_file is a copy of the contents of /dev/mtd10, which is coped out of nand by /etc/init.d/boot. It copies the whole partition, instead of just the language used, which adds a few unnecessary seconds to the boot time.
 
I am not sure that it is fatal. For example no any attempts of updates for two of my R7800 but the same /tmp/fileinfo.txt.
My point was if someone did the NG LG update, that information is stored permanently somewhere in flash outside the main fw. That may be one of the reasons NG offers LG table update separate from the main fw update. So if someone has not updated the LG table from NG yet it will not be saved in the flash.

It is made from V1.0.0.425 plus my changes. Including some bugs fixing. Not significant but annoying.
My initial guess was that you only bumped the LG version to stop it from using NG LG version. I did not realize that you merged the NG LG (.425) changes in the 94.1SF Voxel fw snapshot version.

So in 94.1SF snapshot version, it is using the .426 LG updates. Even though it still downloads NG fileinfo.txt and untars the NG LG table to /tmp/multi_lang (for someone who did the NG LG update previously)

As far as I remember these domains are used to download ReadyCLOUD and KWILT. So it is why I did not block them. Some people still prefer to use these coockies from NG.
Thanks for this heads-up.
 
Last edited:
Yes. I never had any issue with regular or snapshot version of Voxel fw. Voxel gave us a favor by releasing .94.1.SF version.

This whole discussion has nothing to do with Voxel fw. It is about Netgear releasing the language updates separately.
Of course! I haven't had an issue in over 2 dozen Voxel releases either. I just wasn't understanding the issue with the language pack.

Thanks for clarifying!
 
This is probably the most interesting point in this release:
1. Toolchain: GCC is upgraded 11.2.0->11.3.0.
It indeed is. I built with gcc 11.3. FW builds perfectly fine, including all pkgs. Flashed the built fw to my R7800.

Host tools: upgrade missing-macros to 11.
I integrated this few releases back. It is a better option than disabling build docs through build arg 'OR' installing extra pkgs for build docs warnings.

I have also integrated ccache-4.6 in the build setup some time back. With well configured and populated ccache build time reduces exponentially for new builds from scratch.
 
Last edited:
Hello guys, do you know how to get back readycloud working? Thank you
 
Hello guys, do you know how to get back readycloud working? Thank you
Since you did not specifically mention what exactly is the issue. (Registration failure issues in the past from some folks were common)

Check the value of these nvram vars from telnet/ssh:
Code:
nvram show | grep readycloud_enable
0 = readycloud disabled
1 = readycloud enabled

nvram show | grep nocloud
1 = readycloud disabled
0 = readycloud enabled

These are few readycloud troubleshooting steps mentioned by Voxel. It is an old post but steps may be helpful:
https://www.snbforums.com/threads/readycloud-on-netgear-r7800.58376/

Factory reset after firmware update helps with readycloud issues as well:
https://www.snbforums.com/threads/r7800-voxel-firmware-64-5g-and-readycloud-issues.55824/
 
Since you did not specifically mention what exactly is the issue. (Registration failure issues in the past from some folks were common)

Check the value of these nvram vars from telnet/ssh:
Code:
nvram show | grep readycloud_enable
0 = readycloud disabled
1 = readycloud enabled

nvram show | grep nocloud
1 = readycloud disabled
0 = readycloud enabled

These are few readycloud troubleshooting steps mentioned by Voxel. It is an old post but steps may be helpful:
https://www.snbforums.com/threads/readycloud-on-netgear-r7800.58376/

Factory reset after firmware update helps with readycloud issues as well:
https://www.snbforums.com/threads/r7800-voxel-firmware-64-5g-and-readycloud-issues.55824/
tx Fossil. i have use your guide and fix that. really appreciated
 
So I updated from .92 to .94.1

I had a customized script /etc/init.d/dnsmasq, so this version replaced it with a standard version. Which broke my DHCP. But I restored my customization and all seems well!
Each time you will update the firmware, all your custom scripts will be wiped out…

Best solution is to use a USB thumb drive and to have in it the script /autorun/scripts/post-mount.sh to call any script putting your customization scripts in place.
In your case either by copying it to /etc/init.d/dnsmasq from a local copy in your thumb drive or using ln -s to make a soft link of it in the /etc/init.d directory.
 

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