Custom firmware build for R9000

[kamoj]

Hi Voxel
I have tried every combination to get my VPN working but i have had no luck whatsoever.
I cannot connect with it enabled. I have all certificates in openvpn-client directory in root of usb containing 4 files:
auth.txt, ca.rsa.2048.crt, crl.rsa.2048.pem and manchester.ovpn.
I have followed the guide here:
https://www.myopenrouter.com/article/how-set-openvpn-client-netgear-r900...
Please advise?

Check the openvpn-client log file by logging in to the router with telnet or ssh, and then using the command:
cat /var/log/openvpn-client.log

 

[kamoj]

How would I log in via telnet?

- Install the telnet program on your computer.
For Windows 10, do like this:
Hold down the Windows Key, then press “R“.
The Run dialog box appears. In the Open: window, type:
pkgmgr /iu:”TelnetClient”
Click OK.

- Enable Telnet access to the router:
Login to the router page, http://routerlogin.net/debug.htm
Check the box for: Enable Telnet

- Login to the router:
Open a command prompt (Windows 10):
The Run dialog box appears. In the Open: window, type:
cmd
Click OK.
In the opened DOS-command window, type:
telnet routerlogin.net
(The password is the same as from the normal router login page)

Also how do I delete all the openvpn files on the router to start again? (Just to be sure!)

Place/Create a file named "disable" in the USB directory: /openvpn-client/
Remove the USB-device and insert it again after some time (or reboot and insert the USB-device).
To install openvpn-client, again just remove/rename the disable file.

 

[kamoj]

The log looks good!
Check your ip at eg: https://checkmyip.com/

This is the log:

root@R9000:/$
root@R9000:/$ cat /var/log/openvpn-client.log
Tue May  1 02:00:06 2018 OpenVPN 2.4.6 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZ
.
.
Tue May  1 02:00:08 2018 Initialization Sequence Completed
root@R9000:/$
root@R9000:/$

How do i edit the router date/time?

Set time example:
date -s "080122492017" && date
gives: Tue Aug 1 22:49:00 GMT 2017

PS
To make the openvpn-client wait for time sync you can add to "/etc/init.d/openvpn-client" the following line, after "START=99":

while [ ! -e /tmp/ntp_updated ] && [ $(grep -c "\[Time synchronized with NTP server]" /var/log/log-message) -lt 1 ]; do sleep 1; done

 

[kamoj]

*edit* the date and time on the actual router under ntp settings is correct so cant understand why the log above has Tue May 1???

It takes some time (4-14 seconds for me) to get time synced after boot, and the openvpn-client is started before that.

 

[kamoj]

I cant check ip or anything as i cannot connect to the internet
Also your last post regarding date/time went way over my head
Not sure what i am suppose to do, if log looks good why can i not access the internet?
Do i need to change my DNS settings?

Keep DNS the same as working before you add vpn.

To see if the openvpn-client is running:

ps -w | grep -v grep | grep vpn

PS
(The date string is not so complicated if you look closer...
"080122492017" is "month day hours minutes year")

 

[kamoj]

Do i enter this at the Telnet prompt?

After you have logged in, "yes". (Then it's not a telnet prompt, rather a prompt from an operating system shell ...)

Where do i enter this and is this really necessary?

No, that date/time from last year was just an example. You actually asked how to do!

To not clutter this topic/thread you may want to start a new topic about your problem.

 

[Voxel]

I cant check ip or anything as i cannot connect to the internet
Also your last post regarding date/time went way over my head
Not sure what i am suppose to do, if log looks good why can i not access the internet?
Do i need to change my DNS settings?

For me it is really looks as a problem in DNS because of log is OK. Just try to run from telnet or from your Windows client's command prompt (Run->cmd), i.e. from Windows PC attached to router the following command:

ping 8.8.8.8

If it is OK then problem is really DNS. So (temporary) try to use Google DNS in your settings of router (8.8.8.8 and 8.8.4.4).

Problem with proper time setting could be because of the same DNS, router fails to resolve NTP server addresses.

If it helps, consider to use dnscrypt-proxy for security (as a next step).

Voxel.

 

[Voxel]

What I failed to mention is that I have the dnscrypt file on the root of the usb.
I wonder if that’s causing the problem??

No. It is not copied automatically from USB.

Your dnscrypt.conf will work if you have it in /etc directory. To stop its using it is enough to remove this conf and reboot your router (from telnet console):

rm -f /etc/dnscrypt.conf
reboot

Voxel.

 

[kamoj]

Ok I removed the dnscrypt.conf and tried again.
This is the outcome:

root@R9000:/$
root@R9000:/$ ps -w | grep -v grep | grep vpn
10002 root       1960 S   /usr/sbin/openvpn --fast-io --sndbuf 393216 --rcvbuf 3
93216 --tun-mtu 1500 --mssfix 1460 --writepid /var/r
12318 root       1960 S   /usr/sbin/openvpn --fast-io --sndbuf 393216 --rcvbuf 3
93216 --tun-mtu 1500 --mssfix 1460 --writepid /var/r
root@R9000:/$
root@R9000:/$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

it just sits on the ping.
I'm out of ideas

Thank you for good co-operation and feedback!

One problem is that you are running 2 clients at the same time...
I have seen this many times. I reported it to Voxel long time ago. ;-)

It's a "feature" that may happen if you have the USB with /openvpn-client/ connected to the router.

Remove the USB or rename the openvpn-client directory on the USB.

 

[Voxel]

One problem is that you are running 2 clients at the same time...
I have seen this many times. I reported it to Voxel long time ago. ;-)

Yeah... Thanks for reminding. This patch (two clients) was included into firmware for R7800, but was not into firmware for R9000. OK, I've added it in my 2do for R9000. So in the next release.

Voxel.

 

[Dodge DeBoulet]

Voxel, did your 1.0.4.44 release include updated Atheros drivers? I was having a problem connecting a new device (a Lenovo Tab 4 10" Plus) to the 5GHz network with the previous version, but after installing your latest the problem has disappeared.

 

[Voxel]

Voxel, did your 1.0.4.44 release include updated Atheros drivers? I was having a problem connecting a new device (a Lenovo Tab 4 10" Plus) to the 5GHz network with the previous version, but after installing your latest the problem has disappeared.

Yes, they were upgraded. User xnsys from official NG forum contacted me with request to use some special beta version in my build (it is more stable in W-Fi connection according to his tests).

https://community.netgear.com/t5/Ni...fi-dropouts/m-p/1594907/highlight/true#M97111

Voxel.

 

[BUFFBOY]

thanks for this, any other improvements ?

 

[Voxel]

thanks for this, any other improvements ?

Coming soon.

https://github.com/SVoxel/R9000/commits/master

Voxel.

 

[BUFFBOY]

Hey thanks.
Btw FYI the R7800 device name bug still there, can't see the names. Just ip is shown.

Thanks

 

[Voxel]

Btw FYI the R7800 device name bug still there, can't see the names. Just ip is shown.

Hmm... Are you sure? I can see all device names. Starting from Windows names and up to AppleWatch, Linux, Android phone, iPhones etc. I know the problem of R7800. It is reproducible, the only IP. But I do not see any problems with R9000.

Voxel.

 

[dafergu2]

Others have mentioned, and I've seen it on other NG forum posts, that their wifi radios will randomly reset. I've been having this problem and it is really making me question the quality of the R9000. I almost seem to have gotten better wifi coverage (both distance from router and speed) and stability from my original R7000 (the original nighthawk) that I replaced. The R7000 just couldn't handle the gigabit WAN speed I have now.

To attempt to fix or debug the issue, I installed DD-WRT but had to revert due to Bonjour/mdnsresponder not working well with Airprint. I then installed the latest Voxel firmware (thanks Voxel, it looks pretty good so far). My question is, what's the best way to go about debugging wifi radio issues? I'm somewhat familiar with Linux and kernel debugging, but was hoping for a good place to start.

I'm really hoping this issue gets fixed as I really don't have to replace this router as I just purchased it in April.

Thanks for all of your work Voxel! It makes me want to dig in and help out with the dev work. Do you have a running task/bug list somewhere?

 

[Voxel]

My question is, what's the best way to go about debugging wifi radio issues? I'm somewhat familiar with Linux and kernel debugging, but was hoping for a good place to start.

It is interesting. Yes, I was informed about radio issues:

User xnsys from official NG forum

But I've tested R9000 during 52 hours with 1.0.4.4HF-HW and there were no Wi-Fi dropouts. I cannot check longer, you know, my wife pushes me to set up Wi-Fi off scheduling during night. She want to sleep when no any radios around. Girls... So these 52 hours were as an exception but really there were no dropouts. Also later I started very very long backups over Wi-Fi to USB attached to R9000 by samba. 14 hours or so. They were completed. Do you have dropouts with 1.0.4.4? And BTW do you have the problem with attached device names?

My opinion is that R9000 is very stable and I really do not have any problems with it (my build of course). No replacement.

Do you have a running task/bug list somewhere?

I wrote somewhere that I do not maintain bug list of NG anymore. Well, here:

https://www.snbforums.com/threads/c...-0-2-53sf-kf-updated.46941/page-2#post-411973

And I try to avoid inclusion of new bugs from NG. My bugs I usually correct. Adding into my 2do list.

Voxel.

 

[BUFFBOY]

Hmm... Are you sure? I can see all device names. Starting from Windows names and up to AppleWatch, Linux, Android phone, iPhones etc. I know the problem of R7800. It is reproducible, the only IP. But I do not see any problems with R9000.

Voxel.

Only happening for the R7800.

 

[dafergu2]

It is interesting. Yes, I was informed about radio issues:



But I've tested R9000 during 52 hours with 1.0.4.4HF-HW and there were no Wi-Fi dropouts. I cannot check longer, you know, my wife pushes me to set up Wi-Fi off scheduling during night. She want to sleep when no any radios around. Girls... So these 52 hours were as an exception but really there were no dropouts. Also later I started very very long backups over Wi-Fi to USB attached to R9000 by samba. 14 hours or so. They were completed. Do you have dropouts with 1.0.4.4? And BTW do you have the problem with attached device names?

I've had some problems with attached device names but I think that is due to the devices themselves not reporting things properly.

The drop outs I've seen were on the latest stock firmware and it seemed to occur at a pretty decent distant from the router (2 floors difference) and when the family is all on their devices from that room. It may have to do with load.

I'm also using the same SSID for both 2.4 and 5 ghz, so that could be part of the issue as well. But when I open up the status window, I can tell the radios have actually went down and restarted. It's strange. I never had this issue at all with the R7000. It was pretty rock solid, even from a much greater distance.