Custom firmware build for R9000

[farenheit]

[email protected]:/$
[email protected]:/$ cat /var/log/openvpn-client.log
Sun Sep 30 11:41:25 UTC 2018 Voxel: OpenVPNclient stop run: ip route del:
default via 82.13.58.1 dev brwan
82.13.58.0/24 dev brwan  proto kernel  scope link  src 82.13.58.7
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
239.0.0.0/8 dev br0  scope link
[email protected]:/$
[email protected]:/$

 

[farenheit]

Working now. Strange.

 === LOGIN ===============================
  Please enter your password,It's the same
  with DUT login password
 ------------------------------------------
telnet password:

=== IMPORTANT ============================
 Use 'passwd' to set your login password
 this will disable telnet and enable SSH
------------------------------------------


BusyBox v1.4.2 (2018-08-21 12:14:06 UTC) Built-in shell (ash)
Enter 'help' for a list of built-in commands.


  __        __   _                            _
  \ \      / /__| | ___ ___  _ __ ___   ___  | |_ ___
   \ \ /\ / / _ \ |/ __/ _ \| '_ ` _ \ / _ \ | __/ _ \
    \ V  V /  __/ | (_| (_) | | | | | |  __/ | || (_) |
     \_/\_/ \___|_|\___\___/|_| |_| |_|\___|  \__\___/

   _   _ _       _     _   _                    _    _
  | \ | (_) __ _| |__ | |_| |__   __ ___      _| | _| |
  |  \| | |/ _` | '_ \| __| '_ \ / _` \ \ /\ / / |/ / |
  | |\  | | (_| | | | | |_| | | | (_| |\ V  V /|   <|_|
  |_| \_|_|\__, |_| |_|\__|_| |_|\__,_| \_/\_/ |_|\_(_)
           |___/

[email protected]:/$
[email protected]:/$ cat /var/log/openvpn-client.log
Sun Sep 30 15:43:13 2018 OpenVPN 2.4.6 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZ
O] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sun Sep 30 15:43:13 2018 library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.10
Sun Sep 30 15:43:13 2018 NOTE: the current --script-security setting may allow t
his configuration to call user-defined scripts
Sun Sep 30 15:43:13 2018 nice -20 succeeded
Sun Sep 30 15:43:13 2018 TCP/UDP: Preserving recently used remote address: [AF_I
NET]31.24.226.239:1198
Sun Sep 30 15:43:13 2018 UDP link local: (not bound)
Sun Sep 30 15:43:13 2018 UDP link remote: [AF_INET]31.24.226.239:1198
Sun Sep 30 15:43:13 2018 [15380ba1fde2f524d18a98033da09d10] Peer Connection Init
iated with [AF_INET]31.24.226.239:1198
Sun Sep 30 15:43:20 2018 auth-token received, disabling auth-nocache for the aut
hentication token
Sun Sep 30 15:43:20 2018 TUN/TAP device tun0 opened
Sun Sep 30 15:43:20 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Sep 30 15:43:20 2018 /sbin/ifconfig tun0 10.18.10.6 pointopoint 10.18.10.5 m
tu 1500
Sun Sep 30 15:43:20 2018 /etc/openvpn/ovpnclient-up.sh tun0 1500 1558 10.18.10.6
 10.18.10.5 init
Sun Sep 30 15:43:20 2018 Initialization Sequence Completed
[email protected]:/$
[email protected]:/$

 

[ejschenck]

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...)

 

[Voxel]

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:

nvram set stubby=1
nvram commit

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

Voxel.

 

[ejschenck]

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

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?

 

[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?

There is /etc/stubby/stubby.yml. You may check it. Cloudflare by default.

Other way is just to enter by your browser to e.g.

https://www.perfect-privacy.com/dns-leaktest/

You should see Cloudflare server as a DNS.

Voxel.

 

[ejschenck]

You should see Cloudflare server as a DNS.

It does show Cloudflare, but is there a way to confirm that all DNS traffic is now running over TLS?

 

[Voxel]

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:

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.

 

[kamoj]

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:

/etc/init.d/stubby stop

then start it again and verify that all connections are working again:

/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?

 

[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:

Not quite so. Stopping stubby means just starting plain DNS resolver.

Voxel.

 

[kamoj]

OK, thank you for correcting me.
Is it ok to kill the stubby then?

Not quite so. Stopping stubby means just starting plain DNS resolver.

Voxel.

 

[kamoj]

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.

 

[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.

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:

. . .
[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)

dig -p 64153 @127.0.0.1 www.snbforums.com

(avoiding cached requests of course).

Voxel.

 

[farenheit]

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

 

[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.

 

[ejschenck]

@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]

@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.

 

[ejschenck]

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.

Thanks for letting me know that... it explains a lot of the issues I was having with the WiFi kicking out.

Your latest firmware is working fine, but I noticed with Stubby running my DNS lookups were pretty slow - which I'm assuming is due to encryption? I went from anywhere of 2-16ms for a lookup to 60-70ms.

Today, for some reason, Facebook and Instagram weren't loading at all until I turned Stubby off then everything was fine. Do you have any ideas as to what this could be?

 

[kamoj]

I have same problems with Stubby in my R7800.
I changed to DNSCrypt Proxy 2.
https://www.snbforums.com/threads/dnscrypt-proxy-version-2-and-stubby-add-ons-for-r7800-r9000.48445/
All problems gone!

Thanks for letting me know that... it explains a lot of the issues I was having with the WiFi kicking out.

Your latest firmware is working fine, but I noticed with Stubby running my DNS lookups were pretty slow - which I'm assuming is due to encryption? I went from anywhere of 2-16ms for a lookup to 60-70ms.

Today, for some reason, Facebook and Instagram weren't loading at all until I turned Stubby off then everything was fine. Do you have any ideas as to what this could be?

 

[farenheit]

Hi
firstly apologies for going off topic, but i was hoping someone could help me get my VPN running again.
I can get it running with PIA however im having trouble with itv hub which seems to be picking up PIA's IP.
I also have a premium Windscribe account which id like to try however i cannot get it to work?
I have 4 files, auth.txt, ta.key, ca.crt and an .ovpn file.
This is the content of the ovpn file:

client
dev tun
proto udp
remote wf-uk.windscribe.com 443
nobind
auth-user-pass
resolv-retry infinite
auth SHA512
cipher AES-256-CBC
comp-lzo
verb 2
auth-user-pass /etc/openvpn/config/client/auth.txt
ca /etc/openvpn/config/client/ca.crt
mute-replay-warnings
remote-cert-tls server
persist-key
persist-tun
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
MIIF3DCCA8SgAwIBAgIJAMsOivWTmu9fMA0GCSqGSIb3DQEBCwUAMHsxCzAJBgNV
...removed...==
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
5801926a57ac2ce27e3dfd1dd6ef8204
...removed...
-----END OpenVPN Static key V1-----
</tls-auth>

I've noticed the key file information is missing, could this be the issue?