What's new

Custom firmware build for R9000

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

Not of course. As I said I used GPL sources of 1.0.1.36 for R9000. Not anything from R7800. I do not use binaries from one router to use with other router. Only source codes. And BTW binaries are rather incompatible (R9000 vs R7800).

In Feb 2017 the sources of 1.0.1.36 (R9000) were OK for building workable FW for R9000. No cut off yet.

Voxel.

Hi again,

I was not asking about if you are using binaries from R7800, but was asking about source code from R7800 and you compiled for R9000. But now I realised my question was based on my bad quick look at your R7800 repo.

If possible can I get hold of the sources from Feb 2017 (R9000) which you mentioned? Like some link to them etc?

Thanks in advance
 
but was asking about source code from R7800 and you compiled for R9000
Such part as some software packages are the same for R7800/R9000. I.e. OpenSSL/OpenVPN/Samba etc. At least one of my goal is to unify them. Kernel/drivers are different.

If possible can I get hold of the sources from Feb 2017 (R9000) which you mentioned? Like some link to them etc?
OK. Link is in your P.M. I stress: this archive was legally downloaded from official NG site. You may compare downloading from NG site the "cut off" version 1.0.1.36 (to see what packages were removed).

Voxel.
 
Such part as some software packages are the same for R7800/R9000. I.e. OpenSSL/OpenVPN/Samba etc. At least one of my goal is to unify them. Kernel/drivers are different.


OK. Link is in your P.M. I stress: this archive was legally downloaded from official NG site. You may compare downloading from NG site the "cut off" version 1.0.1.36 (to see what packages were removed).

Voxel.

Thanks a lot.
 
You can look in the logfile to see what goes wrong.
Code:
cat /var/log/openvpn-client.log

Also if you install the Kamoj-add-on you can get some information.
 
Hoping I'm not asking something that's already been covered, but I'm not seeing anything about it in the last two months:

I see that the latest Voxel firmware has Stubby as an add-on baked in. When I look at the DNS Privacy Project site, it shows that Stubby has configuration files for Quad9 and Cloudflare DNS. What is the easiest way to enable secure DNS with Cloudflare on the R9000. The only options I'm seeing are to Telnet into the router and enable Stubby... how does one configure it then?

(I haven't enabled it yet as I'm not sure of what the consequences are yet...)
 
Hoping I'm not asking something that's already been covered, but I'm not seeing anything about it in the last two months:

I see that the latest Voxel firmware has Stubby as an add-on baked in. When I look at the DNS Privacy Project site, it shows that Stubby has configuration files for Quad9 and Cloudflare DNS. What is the easiest way to enable secure DNS with Cloudflare on the R9000. The only options I'm seeing are to Telnet into the router and enable Stubby... how does one configure it then?

(I haven't enabled it yet as I'm not sure of what the consequences are yet...)
Latest firmware (14HF, 14HF-HW) really includes Stubby. To enable is with Cloudflare it is enough to run from telnet:

Code:
nvram set stubby=1
nvram commit

And reboot your router. This setting should be kept after next flashing too.

Voxel.
 
Latest firmware (14HF, 14HF-HW) really includes Stubby. To enable is with Cloudflare it is enough to run from telnet:

Code:
nvram set stubby=1
nvram commit

And reboot your router. This setting should be kept after next flashing too.

Voxel.
Just to clarify - how will it know I want Cloudflare? Is there a configuration in the GUI or will it see I've chosen 1.1.1.1 and 1.0.0.1?
 
It does show Cloudflare, but is there a way to confirm that all DNS traffic is now running over TLS?
Theoretically there are several reliable ways to check it. And all of them require some special action.

1. Use some kind of sniffer to check this traffic. E.g. installing sniffer program from Entware.
2. Trying to unload cryptodev module from telnet/ssh console if HW version is used. After this OpenSSL should fail (and stubby too).
3. Prepare special version of OpenSSL with debug printouts.
4. Checking stubby's and its dependence's source codes.

Or just trust to its developers.

Well, try to check stubby's log after some time. For my R9000 it contains two records:

Code:
Fri Oct 19 07:20:28 UTC 2018
[07:20:29.108183] STUBBY: Read config from file /etc/stubby/stubby.yml
STUBBY: 1.1.1.1                                  : Upstream   : !Backing off TLS on this upstream    - Will retry again in 2s at Fri Oct 19 23:38:40 2018

For R7800 (it is connected to other ISP) there are about 35 such records (failed/restored TLS).

Voxel.
 
Another way of at least verifying that DNS requests are handled by Stubby:
You can stop Stubby and verify that you can't connect any longer:
Code:
/etc/init.d/stubby stop
then start it again and verify that all connections are working again:
Code:
/etc/init.d/stubby start

It does show Cloudflare, but is there a way to confirm that all DNS traffic is now running over TLS?
 
Another way of at least verifying that DNS requests are handled by Stubby:
You can stop Stubby and verify that you can't connect any longer:
Not quite so. Stopping stubby means just starting plain DNS resolver.

Voxel.
 
Also I want to add my experience of Stubby on R7800 (sorry if I'm off topic):
I enabled all the default servers in the config, both ip4 and ip6, and I got enormous delays/timeouts.
So I decide to stay with DNSCrypt. Both v1 and v2 are running very much better than Stubby - for me.
Just my opinon. I'm trying all three by the moment to implement in my kamoj add-on.
 
Also I want to add my experience of Stubby on R7800 (sorry if I'm off topic):
I enabled all the default servers in the config, both ip4 and ip6, and I got enormous delays/timeouts.
So I decide to stay with DNSCrypt. Both v1 and v2 are running very much better than Stubby - for me.
Just my opinon. I'm trying all three by the moment to implement in my kamoj add-on.
Kamoj, I do not see any off topic.

Well, I can compare three ISP. For first (R9000) stubby is working well (Cloudflare).

Second is R7800 (other ISP). And BTW stubby chooses another Cloudflare server. Not so good, but acceptable speed of resolving. It produces many records in the log file such as:

Code:
. . .
[12:30:36.107735] STUBBY: 2606:4700:4700::1111                     : Upstream   : No valid upstreams for TLS... promoting this backed-off upstream for re-try...
[12:30:36.108047] STUBBY: 2606:4700:4700::1111                     : Upstream   : !Backing off TLS on this upstream    - Will retry again in 2s at Sun Oct 28 12:30:38 2018
. . .

Third is ASUS router, tried it with stubby from Entware (third ISP). I just cannot use stubby there. Too long response or no response at all. But dnscrypt v1 is working w/o problems.

So. Let's leave while dnscrypt in the next release. People can make their choice.

P.S.
It is better to use dig from Entware to check the speed of stubby or dnscrypt. E,g, (stubby)

Code:
dig -p 64153 @127.0.0.1 www.snbforums.com

(avoiding cached requests of course).

Voxel.
 
At the expense of sounding thick, if I wanted to use cloudfare dns on my router do I just enter the dns values (1.1.1.1 and 1.0.0.1) and reboot?
I currently have PIA dns values on my router but I find that response times can be slow at times.
Thanks
If you need to secure your DNS requests to Cloudflare (DNS-overTLS) you should follow the procedure:

https://www.snbforums.com/threads/custom-firmware-build-for-r9000.40125/page-12#post-440226

if not secure then just as you said, 1.1.1.1 and 1.0.0.1 (Cloudflare).

(For version 1.0.4.14HF(-HW)).

Voxel.
 
@Voxel

So I can see that everything is working well on 1.0.4.14HF-HW however there are two features that have disappeared but were in the Netgear firmware 1.0.4.12.

  1. The ability to select the second VHT80 channel for the 5ghz band under "Wireless Setup" is missing. While I'm not sure if this creates any issues, I would think it could cause a problem with any HT160 clients trying to connect?
  2. The "Enable Smart Roaming" feature which is under "Advanced Wireless Setup" directly under "Enable HT-160" is gone.
Are you planning on placing these back into the firmware? Is v14 based on v12?
 
@Voxel

So I can see that everything is working well on 1.0.4.14HF-HW however there are two features that have disappeared but were in the Netgear firmware 1.0.4.12.

  1. The ability to select the second VHT80 channel for the 5ghz band under "Wireless Setup" is missing. While I'm not sure if this creates any issues, I would think it could cause a problem with any HT160 clients trying to connect?
  2. The "Enable Smart Roaming" feature which is under "Advanced Wireless Setup" directly under "Enable HT-160" is gone.
Are you planning on placing these back into the firmware? Is v14 based on v12?

NG 1.0.4.12 is very unstable (permanent dropping Wi-Fi and WAN). And users of 1.0.4.12 report significant problems with this version. So they even have to disable these options to improve Wi-Fi stability, e.g.

https://community.netgear.com/t5/Ni...15-20-MINS/m-p/1646350/highlight/true#M106437

So these features are available in my 1.0.4.13HF-HW (changes from 1.0.4.12 were included) but I had to perform a partial rolling back in 1.0.4.14HF-HW, see this thread, changes log:

https://www.snbforums.com/threads/c...4-13hf-hw-and-1-0-4-14hf-1-0-4-14hf-hw.49096/

You may play with .13HF-HW if you wish to get these features. But there is an issue with Wi-Fi stability.

When NG resolves these issues they could be added.

Voxel.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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