What's new

Voxel Custom firmware build for R7800 v. 1.0.2.80SF & v. 1.0.2.80.4SF & v. 1.0.2.80.5SF

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

Just out of curiosity. what does this tell us?
This is standard OpenSSL test. In brief it shows how many encryption operations could be performed during 3 secs. So my test shows that the same CPU i.e. QCA IPQ8065 is able to perform twice more encryption operations during these 3 secs (Voxel vs stock firmware).

Well. Maybe more clear example. I had to seek the very first thread on SNB.

https://www.snbforums.com/threads/custom-firmware-build-for-r7800.36859/post-304066

Pure mathematical benchmark. Calculations of the number Pi and number e. Just for science :)

Stock firmware:
Time to run computation of pi (2400 digits, 10 times): 3.01[secs]
Time to run computation of e (9009 digits): 2.52[secs]


Voxel firmware:
Time to run computation of pi (2400 digits, 10 times): 1.51[secs]
Time to run computation of e (9009 digits): 1.44[secs]


I.e. to calculate the number Pi with my optimization and compiler options your R7800 will spend 1.51 secs. But when you use the stock firmware with their optimization and compiler options the same Pi will be calculated during 3.01 secs.

Voxel.
 
whaat?!! looks like your R7800 is on steroids, or how on earth did you got those numbers, 'cose they are 2x the numbers i get!
I wish I knew :)

I am using Cat 6a cable directly connected to router and we have gigabit (Xfinity) speed.
 
I am using Cat 6a cable directly connected to router and we have gigabit (Xfinity) speed.

Cable and speed of connection does not matter in this test. I think you've executed this test directly on your MacBook instead of R7800...

Please paste full output of this test. From R7800 it should be:

Code:
OpenSSL 1.0.2u  20 Dec 2019
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: arm-openwrt-linux-uclibcgnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=7 -DNDEBUG -DOPENSSL_NO_ERR -DTERMIOS -pipe -mcpu=cortex-a15 -mfpu=neon-vfpv4 -funsafe-math-optimizations -mtune=cortex-a15 -mfloat-abi=softfp -fcommon -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -O3 -fpic -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      52451.40k    61267.24k    63392.96k    62884.86k    63620.88k

Voxel.
 
For info (and logically) on mine it is:
Code:
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      55125.15k    61541.28k    63416.74k    62922.92k    63751.90k
 
GPL source codes of 1.0.2.74 are not published yet, check this link:


latest codes: 1.0.2.68

So changes in 1.0.2.74 could not be processed by me and are not included into my build.

But I am a bit skeptical regarding:



First, as I guess security all the fixes are related to some issues (IMO not so serious) re: access to router GUI via https. At least partially fixed in 80SF (https://github.com/SVoxel/R7800/commit/6079a3e0a7fac3c928a001b984314eb81273fdb7).
There are a lot of much more serious CVEs left in the stock. Briefly I've checked the binary firmware, and e.g. 1.0.2.74 is still using OpenSSL 1.0.2h (May 2016), and not accelerated. There following CVE since this version detected (I exclude platform-specific CVE):

CVE-2016-7052
CVE-2016-7055
CVE-2017-3731
CVE-2017-3735
CVE-2017-3737
CVE-2018-0739
CVE-2018-0737
CVE-2018-0732
CVE-2018-0734
CVE-2018-5407
CVE-2019-1559
CVE-2019-1547
CVE-2019-1563

Version of libjson-c in 1.0.2.74 is 0.12.1. So at least CVE-2020-12762.

Well, there are other old packages.


Fix of corrupted files in AP mode according to NG official announcement above is related to wireless clients. I've faced such corrupted files using wired client. So I am not sure that everything is really fixed.

I do not remember such bug reports re: disappeared devices from attached device list with my latest releases.

Minor bugs... Well. As a rule there could be new bugs after such fixes by NG/DNI.


So, let us wait for GPL.

Voxel.
Thanks for the GPL link. It blows my mind how old some of the packages are included in the official R7800 firmware. The Kerberos 5 package, heimdal-1.5.3.tar is over 7 years old. Nuts, and utterly irresponsible that a piece of 'supported' hardware, even if it is consumer grade, should have 7 year old packages in its firmware. Surprisingly just a couple of CVEs, published over a year ago, but there nonetheless.

This is just one package I picked at random. I suspect you know them all like the back of your hand and are more aware than anyone at the horrors contained within :eek:
And yeah, openssl-1.0.2h is a joke.
A real eye opener. Again, thanks for the link.
 
Last edited:
Cable and speed of connection does not matter in this test. I think you've executed this test directly on your MacBook instead of R7800...

Voxel.
Ha! It seems I did. Sorry for trying to cheat the system :) Like I said, I know just enough to be dangerous!

Here's my results from my 7800 in router mode:
Code:
Doing aes-256 cbc for 3s on 16 size blocks: 9985083 aes-256 cbc's in 2.94s
Doing aes-256 cbc for 3s on 64 size blocks: 2923152 aes-256 cbc's in 2.97s
Doing aes-256 cbc for 3s on 256 size blocks: 740085 aes-256 cbc's in 2.84s
Doing aes-256 cbc for 3s on 1024 size blocks: 189297 aes-256 cbc's in 2.95s
Doing aes-256 cbc for 3s on 8192 size blocks: 23891 aes-256 cbc's in 2.98s

OpenSSL 1.0.2u  20 Dec 2019
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: arm-openwrt-linux-uclibcgnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=7 -DNDEBUG -DOPENSSL_NO_ERR -DTERMIOS -pipe -mcpu=cortex-a15 -mfpu=neon-vfpv4 -funsafe-math-optimizations -mtune=cortex-a15 -mfloat-abi=softfp -fcommon -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -O3 -fpic -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      54340.59k    62990.48k    66711.89k    65708.52k    65676.20k
And here's my 7800 in AP mode:
Code:
Doing aes-256 cbc for 3s on 16 size blocks: 10382885 aes-256 cbc's in 2.89s
Doing aes-256 cbc for 3s on 64 size blocks: 2839317 aes-256 cbc's in 2.88s
Doing aes-256 cbc for 3s on 256 size blocks: 746725 aes-256 cbc's in 2.91s
Doing aes-256 cbc for 3s on 1024 size blocks: 186740 aes-256 cbc's in 2.92s
Doing aes-256 cbc for 3s on 8192 size blocks: 23467 aes-256 cbc's in 2.89s

OpenSSL 1.0.2u  20 Dec 2019
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)
compiler: arm-openwrt-linux-uclibcgnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=7 -DNDEBUG -DOPENSSL_NO_ERR -DTERMIOS -pipe -mcpu=cortex-a15 -mfpu=neon-vfpv4 -funsafe-math-optimizations -mtune=cortex-a15 -mfloat-abi=softfp -fcommon -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -O3 -fpic -ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM

The 'numbers' are in 1000s of bytes per second processed.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      57483.10k    63095.93k    65691.27k    65486.90k    66519.61k

Sorry about the confusion!
 
" Although Windows has a service called Connect Now that instigates this behaviour, "


If its a Windows behavior how is turning off WPS going to stop it?
 
I have a r7800 for several years now running an older firmware version (maybe 2.52), as it seems everytime I want to upgrade there are major issues with all the stock firmware. I want to eek out some more life, but am a total noob with this. I read the readme document and scanned the threads here, but still have a few quick questions:

1) First checking that I am in the right place - this is the thread and latest version of the Voxel? I will be running in AP mode, the 7800 handles all my wifi needs.
2) For installing, do I just point the updater to the new img file and away I go?
3) I have a few simple settings in my current firmware: the wifi names, ip address range, and a static ip for AP mode. Will these be intack after the upgrade, or do I need to run through and set any new menu items?
4) What is this ReadyCloud and Kwilt? Is this something that I need to execute the listed commands to disable them? If so, where/how do I run those commands, I am on Apple.
5) I am a set it and forget it type, once I go Voxel do I need to keep checking for updates, or will it run for months and months.

Thank you everyone!
 
Last edited:
I have a r7800 for several years now running an older firmware version, as it seems everytime I want to upgrade there are major issues with all the stock firmware. I want to eek out some more life, but am a total noob with this. I read the readme document and scanned the threads here, but still have a few quick questions:

1) First checking that I am in the right place - this is the thread and latest version of the Voxel? I will be running in AP mode, the 7800 handles all my wifi needs.
2) For installing, do I just point the updater to the new img file and away I go?
3) I have a few simple settings in my current firmware: the wifi names, ip address range, and a static ip for AP mode. Will these be intack after the upgrade, or do I need to run through and set any new menu items?
4) What is this ReadyCloud and Kwilt? Is this something that I need to execute the listed commands to disable them? If so, where/how do I run those commands, I am on Apple.
5) I am a set it and forget it type, once I go Voxel do I need to keep checking for updates, or will it run for months and months.

Thank you everyone!

Voxel is basically stock with upgraded packages and some bugfixes. You can flash it and it will keep your settings - just upload the Voxel firmware image file. You can even return to stock and your settings will still be there. ReadyCloud and Kiwit do not work in AP mode. You don't have to constantly check for updates. Just set it and let it run. When you feel like it, you can upgrade to latest Voxel. If you want/need more functionality, you can install the kamoj addon
 
I'm having a problem with slow upload speeds on 5GHz with this firmware (.80SF). Download speed seems fine (150 Mbps out of 220 broadband) considering the router is 2 floors down. Upload speed on 2.4GHz is hitting the close to the broadband cap (11 Mbps) but for some reason on 5GHz it's struggling to hit 7 Mbps.

Current 5Ghz advanced settings:
CTS/RTS Threshold: 2347 (default)
Preamble Mode: Automatic (default)
Enable implicit beamforming is on (default)
Enable MU-MINO is off (default is on, tried turning it off hoping to improve the upload speed)

Any suggestions other than trying out different 5GHz channels? Already tried a couple different channels and it didn't seem to help, but I could experiment further.
 
Last edited:
I'm having a problem with slow upload speeds on 5GHz with this firmware (.80SF). Download speed seems fine (150 Mbps out of 220 broadband) considering the router is 2 floors down. Upload speed on 2.4GHz is hitting the close to the broadband cap (11 Mbps) but for some reason on 5GHz it's struggling to hit 7 Mbps.

Current 5Ghz advanced settings:
CTS/RTS Threshold: 2347 (default)
Preamble Mode: Automatic (default)
Enable implicit beamforming is on (default)
Enable MU-MINO is off (default is on, tried turning it off hoping to improve the upload speed)

Any suggestions other than trying out different 5GHz channels? Already tried a couple different channels and it didn't seem to help, but I could experiment further.
I had the same issue. I ended up ditching Voxel and going back to stock 1.0.2.74 and the issue hasn't returned.

I think there's something not quite right with .80SF. It's a shame, it was my first jump into Voxel firmware and was unfortunately somewhat of a disappointment as I had always found stock to be incredibly stable. It has rather put me off if I'm honest. I do value security and perform both firmware and software updates on everything I own regularly, but if the device no longer works as intended then one has to re-evaluate.
 
Just got a R7800 today. Installed latest Voxel. Not able to fix 2.5 at 20mhz and 5g at 40mhz to compare with results i noted down from my asus rt3100 that I unplugged. Am i not able to do that?
 
I just went Voxel! I was on stock .52, and now on Voxel .80SF. I just pointed the updater to the img file, I made no changes to my configuration, everything came over fine (I did do a full powerdown).
I reran my speed tests, everything is in the same range as before on both 2.4 and 5. I have noticed a stronger 5 signal at farther distances. I do not have any issues with 5 upload speed, it comes in at or above (300+) my download speeds using several pc's. I am using the 7800 in AP mode as my only wifi source.
 
Last edited:
My upload speed problems seems to have either been temporary, the result of very specific location (deadspot but only affecting upload?) or interference of some kind. I just did 3 tests and all came close to max ISP bandwidth for down and upload. It did "stutter" on the upload portion of one test, so maybe there's still something going on. I've used a Wi-Fi analyzer app to look at other 5Ghz networks that might be interfering and none are being picked up in that frequency range.
 
Well. You know, I cannot exclude some problems in my version. Including Wi-Fi speed. Of course I do testing and some serious test before I do the release. And only if I see that there is no issues (e.g. with a speed) I release this version.

So I have to pick up the statistics. Currently: two negative feedbacks: from Squuiid and from djphilosophy but according to my log checking there are dozen of thousands of downloads. And this post above says that maybe something was wrong in the testing procedure by user. So... Obvious. I have either get more signals (confirmation of the bugs/issues), or ... (your know: there is a lie and there is statistics :cool: ). Waiting for more reports.

Again: I do not exclude the issues. For example Orbi users signaled an issue with IPv6. I had to change GCC compiuler from 10.2.0 to 9.3.0. Issue was fixed:

https://www.snbforums.com/threads/orbi-rbk50-rbr50-rbs50-ipv6-not-recognized.66058/

Now it is OK. The same could be with R7800. I prefer to use GCC 10.2.0 (most fresh compiler) because of performance. So I kept it for 80SF. Because there were no issues/bug reports.

Voxel.
 
Last edited:
@Voxel Your firmware work is outstanding - and I don’t believe you get enough credit for what you do. I’ll say it 1,000 times - THANK YOU for everything you do! I didn’t notice any changes in stability when you made the GCC change, but the speed was slightly better as you alluded to. Still the same rock solid stability and “forever” up-times. Truly is a set and forget firmware for 90% of users.
 
@Voxel I also want to thank you for your great work, and just gave a donation to show my thanks. I wasn't giving negative feedback on the firmware as a whole, just reporting the upload issue I was experiencing to see if others were experiencing it or if there was a setting I needed to tweak - and testing again just now shows solid upload speed.

Thank you for what you do!
 
@Voxel I also want to thank you for your great work, and just gave a donation to show my thanks. I wasn't giving negative feedback on the firmware as a whole, just reporting the upload issue I was experiencing to see if others were experiencing it or if there was a setting I needed to tweak - and testing again just now shows solid upload speed.

Thank you for what you do!
Thank you. To clarify. Maybe I've used not quite correct words. I mean that any... well how to say... maybe not "negative feedback" but "bug report" or "issue" is important as well. I am in no case something like "Guru" or "Sensei" who does not accept any criticism. Errare humanum est. I also can make bugs. Not very pleasant when it happens but... Professional is not who is free of making bugs (it is impossible) but who is able to fix them as soon as possible.

;)

Voxel.
 

Sign Up For SNBForums Daily Digest

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