What's new

Kamoj Kamoj Addon 5.5 Beta for Netgear R7800/R8900/R9000 with Voxel FW

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

...
Traceroute set to 2.It seems the username and Password is found ok now but the configs are not right

2022-01-03 08:55:39 5739.24 [OpenVPN] Client rc.common 21488: Information: Check that needed data exist in the configuration
2022-01-03 08:55:39 5739.25 [OpenVPN] Client rc.common 21488: Error: This is not a client configuration.
2022-01-03 08:55:39 5739.27 [OpenVPN] Client rc.common 21488: Error: This is no (udp/tcp) protocol defined in the client configuration.
..
Good to see you've update the add-on already!

Working ExpressVPN OpenVPN Client configuration:

If you make these changes to the configs they'll work:

Add these lines to the top of the configuration file:
client
proto udp
data-ciphers AES-256-CBC:AES-256-GCM
remote-cert-tls server

Remove these lines from the configuration file (or put a # at the start of the line e.g.):
remote-random
pull
tls-client
ns-cert-type server
route-method exe
route-delay 2
keysize 256

Once you get it working you can start fine tuning, e.g. changing or removing:
sndbuf 524288
rcvbuf 524288
(The addon has it's own way of setting these parameters in a way efficient for the router!)

PS
This line should be in the configuration file as well - as it was in one file you sent to me:
auth-user-pass
 
Thanks and Well done @kamoj express vpn working. Although vpn tunnel status on gui is red with white cross and the internet light on the router is amber.

Definitely on internet ....checked ip
 

Attachments

  • vpn working.txt
    18.4 KB · Views: 127
All working good now the problem was I had
Both
OpenVPN Client connection (tun21)

OpenVPN Client DNS connection (tun21)

turned on in supervision

Thanks once again @kamoj
 
Using the 5.5b14 update, I like the information, it takes to connect for example wireguard "Information: Wireguard Client TorGuard_Spectrum completed start sequence after 3.11 sec." Everything seems faster as well, OpenVPN and Wireguard connecting.
 
Hi all. First of all i would like to thank for your hard work Voxell and Kamoj. I'm using the latest version of addon on r7800, and I have two questions:
1. In previous versions, after typing in login and password for openvpn they remain there, and don't disappear- now they do and I have to retype them - how to fix it?
2. After changing router password in netgear GUI, every option change in addon ask me for password, but neither new or previous password work. I had to go back to old password. What can I do with that ?

Again thank You for your work.
 
Hi all. First of all i would like to thank for your hard work Voxell and Kamoj. I'm using the latest version of addon on r7800, and I have two questions:
1. In previous versions, after typing in login and password for openvpn they remain there, and don't disappear- now they do and I have to retype them - how to fix it?
2. After changing router password in netgear GUI, every option change in addon ask me for password, but neither new or previous password work. I had to go back to old password. What can I do with that ?

Again thank You for your work.
1. You have to explain in detail what you do step by step, and what is not working, and in which version it was working.
As a beta tester you have to be as helpful as possible.
2. Reload the BASIC page and then read the FAQ.txt
Be safe tester!
 
All working good now the problem was I had
Both
OpenVPN Client connection (tun21)

OpenVPN Client DNS connection (tun21)

turned on in supervision

Thanks once again @kamoj
If you want/need to have supervision to automatically restart broken OpenVPN connection:
- Set the traceroute TTL_max to 2
- Set the ping timeout to 10 seconds or more!
- Set the traceroute timeout to 10 seconds or more!
Then again, switch on:
- OpenVPN Client connection (tun21)
- OpenVPN Client DNS connection (tun21)
(It depends on the lag/latency of your connection and ExpressVPN client.)

If not help, see the Supervision log if restarts are done even when connection is good.
If so, increase the timeouts even more.

Hope to see you report back!
Stay safe!
 
@ Kamoj
The first part of the log is after supervision turned on and the second part after openvpn client turned on

could not see any restarts after 15 mins
 

Attachments

  • supervision.txt
    2.6 KB · Views: 121
@ Kamoj
The first part of the log is after supervision turned on and the second part after openvpn client turned on

could not see any restarts after 15 mins
Great! Thank you for your fast and good support as a beta tester! Very much appreciated!

Something is not good when running the traceroute with ExpressVPN.
Can you try to increase the timeouts until the errors in the supervision disappears completely?
You can also change "Minimum supervision interval" to 10 sec.
 
After Supervision turned back on with these settings
minimum supervision level 10
Ping test 30
traceroute 30
No restarts after 15 mins.
 

Attachments

  • supervision.txt
    2.4 KB · Views: 124
After Supervision turned back on with these settings
minimum supervision level 10
Ping test 30
traceroute 30
No restarts after 15 mins.
Amazing! :cool:
You've nailed it, to work vid ExpressVPN as well.
Well done!!! :)
PS
Did you try any other values that didn't work?
 
I have just noticed something on my R9000 running v5.5b14. When you add a broken WG config and start WG client, the whole router GUI is inaccessible for few seconds. How to reproduce it, just change something to the config like PrivateKey and PublicKey to break this config and connect. This was not the case with v.5.4.
 
Hello,
I installed 5.5b14 on my R9000 the other day. I was not able to to get OpenVPN or WireGuard to connect. I noticed the "MTD System Disk Usage (Used/Total)" showed 90% and it is normally just under 42% - I doubt that had any effect on the add-on but it is the only thing I noticed. My former employer talked this old dog out of retirement so without much time before going to work, I reinstalled 5.4b32 and truncated logs to get some disk room. Yesterday I installed 5.5b14 again and all is well. However I do notice that the "MTD System Disk Usage (Used/Total)" is back up over 42%. Guess I need to look at that when I get more time. But so far, so good and I find the many changes in the 5.5 add-on to be very useful and well thought out. Fantastic Kamoj!

Best wishes,
BL
 
The moment I start having some connectivity issues it is like whole R9000 GUI stops responding for a good few seconds. I had PPPoE outage from ISP today, was observing how WG will go through it. It went fairly well coming back when PPPoE was back - thanks @kamoj. But the issue I am talking about is that the moment PPPoE outage was present, despite GUI being not responsive for good few seconds (although Adguard Home was working), LAN devices have disconnected too. I launched networking settings on my Mac and could clearly see my ethernet connected Mac switching to "disconnected". I don't know if this is @kamoj bug or @Voxel with R9000.

I am sure I must not be the only one noticing this behaviour? My setup is Adguard Home + Aegis on USB + some iptables rules on USB.
 
The moment I start having some connectivity issues it is like whole R9000 GUI stops responding for a good few seconds. I had PPPoE outage from ISP today, was observing how WG will go through it. It went fairly well coming back when PPPoE was back - thanks @kamoj. But the issue I am talking about is that the moment PPPoE outage was present, despite GUI being not responsive for good few seconds (although Adguard Home was working), LAN devices have disconnected too. I launched networking settings on my Mac and could clearly see my ethernet connected Mac switching to "disconnected". I don't know if this is @kamoj bug or @Voxel with R9000.

I am sure I must not be the only one noticing this behaviour? My setup is Adguard Home + Aegis on USB + some iptables rules on USB.
GUI not responding for a few seconds is nothing strange or unusual.

Is it a cyclic status refresh (which form?) that hangs it for a few seconds or what button or form/menu is it starting the few seconds delay.
Can you measure the delay? Is it 1, 2 ,3 ,4 ,5 seconds e.g?
What happens if you don't have the GUI started?
What timeouts etc have you set in Supervision menu?

Maybe you expected too much?
I would be happy if the reconnection was working - as newly designed.

The idea is that it should be working automatically without a GUI,
If not, please post the Supervision, Wireguard, dns, adguard etc logs here so we can help!

Have a nice day!
PS
Your setup is far from what I can test:
- PPPoE
- R9000
- Wireguard
- AdGuard
(I don't use or test any of that, but I do my best to make it work..)

PPS
Have tested the command "traceroute -q1 -m1 -w1 -i wg0 8.8.8.8 38" that is used to check the connection.
On the R7800:
If the connection is down, the traceroute command completely hangs the thread/process and can not even be killed with "kill -9".
So the traceroute command seems to behave badly.
It's kind of same problem as with ExpressVPN that requires "-m2" to work. (A tester reported same behavior with R9000).
Can anyone help? ( @Voxel @HELLO_wORLD @R. Gerrits )
 
Last edited:
@kamoj I am sure it is a good 10-15 seconds delay when GUI is not responding and I saw my Mac Pro losing ethernet connection entirely (similar effect to rebooting the router) but it came back 10 seconds later. So maybe this traceroute commands hangs the entire R9000 which is causing the total connectivity loss with both the GUI and DHCP assignments to devices? As I said it is temporary, I can live with that for sure, especially that it only happens when ISP has some connection issues or WG server. I just report things the way I see them, perhaps it is supposed to work like that. I checked the supervision logs but the reason I did not post them is that I saw nothing concerning.

I have all default supervision logging enabled.

Did you try to break WG config by changing some parameters and hit connect? Did you have the same issue with GUI not responding for good 10-15 seconds? I can reproduce this every single time, maybe someone else can too? As I said this may not be the bug and I can live with that but I would prefer to get confirmation this is the way it behaves for others too and not that only I am affected.
 
Changes in kamoj-addon beta version 2022-01-12 5.5b15
---------------------------------------------------------------
- Supervision: Changed traceroute command to speed up supervision when
using ExpressVPN (@jrbmw) or bad connection (@primitivo),
by setting first ttl to same as max ttl.
- Supervision: Default value changed from 1 to 2 for:
Supervision Menu: Max time-to-live (max number of hops)

@kamoj I am sure it is a good 10-15 seconds delay when GUI is not responding and I saw my Mac Pro losing ethernet connection entirely (similar effect to rebooting the router) but it came back 10 seconds later. So maybe this traceroute commands hangs the entire R9000 which is causing the total connectivity loss with both the GUI and DHCP assignments to devices? As I said it is temporary, I can live with that for sure, especially that it only happens when ISP has some connection issues or WG server. I just report things the way I see them, perhaps it is supposed to work like that. I checked the supervision logs but the reason I did not post them is that I saw nothing concerning.

I have all default supervision logging enabled.

Did you try to break WG config by changing some parameters and hit connect? Did you have the same issue with GUI not responding for good 10-15 seconds? I can reproduce this every single time, maybe someone else can too? As I said this may not be the bug and I can live with that but I would prefer to get confirmation this is the way it behaves for others too and not that only I am affected.
I have little hope this will help you, but I did a fix for you to try.
It's like you engage the auto-pilot (Supervision with restart), and then try to fly manually with the stick anyhow.
I mean it's not normal to supervise the supervision more than it does itself - if you allow it to...

Still I'm not happy with your reluctance to support and share log-files, or even tell which GUI you use when it stop responding.
I'm sure I can see interesting things that you don't understand e.g.
Please be more supportive, and the chance you get help increases a lot.

Wishing you good luck, and thank you for using the add-on anyhow.
 
H Kamoj

R9000 running Voxel V1.0.4.57HF & Kamoj V5.5B.15

There is a problem with the VPN Tunnel Status in Router Information and the OpenVPN/Wireguard clients.


If Router is set to self-bypass VPN then then VPN tunnel status is reported as failed (red shield) in clients and ERROR wg0: No wg0 or tun21: NoTun21 & the ISP allocated IP address. in Router Information

However, the VPN is connected and devices set to use it show the IP address allocated by the VPN

When supervision is set to monitor VPN/DNS it is then repeatedly restarting the lost resources (extract from supervision log) :

^ OpenVPN traceroute all IP A
2022-01-17 12:55:53 487.97 [SUPERVISION] addon_supervision.sh 15184: ERROR: OpenVPN traceroute A to all IPs failed 1.
2022-01-17 12:55:53 487.99 [SUPERVISION] addon_supervision.sh 15184: ========>>>>>>>> RESTART lost resource: openvpn 8 <<<<<<<<========
2022-01-17 12:56:12 506.82 [SUPERVISION] addon_supervision.sh 15184: Cpu load: 5 %. Processes: 69. Threads: 169. iptables: ipv4 rules: 200. ipv6 rules: 0. System Load Average: 0.95 0.67 0.34. brwan: Rx: 30.713 KB/s, Tx: 3.957 KB/s. tun21: Rx: 28.761 KB/s, Tx: 2.508 KB/s.
..........
2022-01-17 12:56:39 534.01 [SUPERVISION] addon_supervision.sh 15184: These is_starting_file tests went wrong:
2022-01-17 12:56:27 521.88 ls -al /tmp/addons/openvpn_is_starting:
2022-01-17 12:56:27 521.90 ps -w /etc/init.d/openvpn-client:
2022-01-17 12:56:39 534.02 [SUPERVISION] addon_supervision.sh 15184: ERROR: OpenVPN traceroute A to all IPs failed 2.
2022-01-17 12:56:39 534.04 [SUPERVISION] addon_supervision.sh 15184: ========>>>>>>>> RESTART lost resource: openvpn 9 <<<<<<<<========
2022-01-17 12:56:48 543.35 [SUPERVISION] addon_supervision.sh 15184: Cpu load: 5 %. Processes: 69. Threads: 169. iptables: ipv4 rules: 251. ipv6 rules: 15. System Load Average: 0.87 0.69 0.37. brwan: Rx: 2.480 KB/s, Tx: 838.0 B/s. tun21: Rx: 1.153 KB/s, Tx: 105.0 B/s.
..........
2022-01-17 12:57:13 568.24 [SUPERVISION] addon_supervision.sh 15184: These is_starting_file tests went wrong:
2022-01-17 12:57:01 556.08 ls -al /tmp/addons/openvpn_is_starting:
2022-01-17 12:57:01 556.10 ps -w /etc/init.d/openvpn-client:
2022-01-17 12:57:13 568.25 [SUPERVISION] addon_supervision.sh 15184: ERROR: OpenVPN traceroute B to all URLs failed. 1
2022-01-17 12:57:13 568.27 [SUPERVISION] addon_supervision.sh 15184: ========>>>>>>>> RESTART lost resource: openvpn 10 <<<<<<<<========
2022-01-17 12:57:18 572.83 [SUPERVISION] addon_supervision.sh 15184: Cpu load: 5 %. Processes: 69. Threads: 185. iptables: ipv4 rules: 54. ipv6 rules: 15. System Load Average: 0.88 0.71 0.38. brwan: Rx: 27.448 KB/s, Tx: 2.750 KB/s. tun21: Rx: 25.426 KB/s, Tx: 1.566 KB/s.


This started with Kamoj V5.5B.12, it was not a problem with V5.4B.35

At the moment I am having to leave VPN/DNS supervision off as I need the Router to bypass the VPN for the Dynamic DNS to work – needed for some devices that are set to bypass the VPN

Have done a complete reinstall (including full erase of all Netgear configuration) in case it was something in my settings before discovering the above.

Apart from that everything runs well with the latest update
 
Thank you for the report.
I'll have a look and make a fast-fix release for you to test.
PS
The 5.4b35 had no working VPN/DNS supervision for clients at all, only for the router itself.
PPS
Have you used the "Settings: DHCP DNS Options: Custom DNS"?
H Kamoj

R9000 running Voxel V1.0.4.57HF & Kamoj V5.5B.15

There is a problem with the VPN Tunnel Status in Router Information and the OpenVPN/Wireguard clients.


If Router is set to self-bypass VPN then then VPN tunnel status is reported as failed (red shield) in clients and ERROR wg0: No wg0 or tun21: NoTun21 & the ISP allocated IP address. in Router Information

However, the VPN is connected and devices set to use it show the IP address allocated by the VPN

When supervision is set to monitor VPN/DNS it is then repeatedly restarting the lost resources (extract from supervision log) :

^ OpenVPN traceroute all IP A
2022-01-17 12:55:53 487.97 [SUPERVISION] addon_supervision.sh 15184: ERROR: OpenVPN traceroute A to all IPs failed 1.
2022-01-17 12:55:53 487.99 [SUPERVISION] addon_supervision.sh 15184: ========>>>>>>>> RESTART lost resource: openvpn 8 <<<<<<<<========
2022-01-17 12:56:12 506.82 [SUPERVISION] addon_supervision.sh 15184: Cpu load: 5 %. Processes: 69. Threads: 169. iptables: ipv4 rules: 200. ipv6 rules: 0. System Load Average: 0.95 0.67 0.34. brwan: Rx: 30.713 KB/s, Tx: 3.957 KB/s. tun21: Rx: 28.761 KB/s, Tx: 2.508 KB/s.
..........
2022-01-17 12:56:39 534.01 [SUPERVISION] addon_supervision.sh 15184: These is_starting_file tests went wrong:
2022-01-17 12:56:27 521.88 ls -al /tmp/addons/openvpn_is_starting:
2022-01-17 12:56:27 521.90 ps -w /etc/init.d/openvpn-client:
2022-01-17 12:56:39 534.02 [SUPERVISION] addon_supervision.sh 15184: ERROR: OpenVPN traceroute A to all IPs failed 2.
2022-01-17 12:56:39 534.04 [SUPERVISION] addon_supervision.sh 15184: ========>>>>>>>> RESTART lost resource: openvpn 9 <<<<<<<<========
2022-01-17 12:56:48 543.35 [SUPERVISION] addon_supervision.sh 15184: Cpu load: 5 %. Processes: 69. Threads: 169. iptables: ipv4 rules: 251. ipv6 rules: 15. System Load Average: 0.87 0.69 0.37. brwan: Rx: 2.480 KB/s, Tx: 838.0 B/s. tun21: Rx: 1.153 KB/s, Tx: 105.0 B/s.
..........
2022-01-17 12:57:13 568.24 [SUPERVISION] addon_supervision.sh 15184: These is_starting_file tests went wrong:
2022-01-17 12:57:01 556.08 ls -al /tmp/addons/openvpn_is_starting:
2022-01-17 12:57:01 556.10 ps -w /etc/init.d/openvpn-client:
2022-01-17 12:57:13 568.25 [SUPERVISION] addon_supervision.sh 15184: ERROR: OpenVPN traceroute B to all URLs failed. 1
2022-01-17 12:57:13 568.27 [SUPERVISION] addon_supervision.sh 15184: ========>>>>>>>> RESTART lost resource: openvpn 10 <<<<<<<<========
2022-01-17 12:57:18 572.83 [SUPERVISION] addon_supervision.sh 15184: Cpu load: 5 %. Processes: 69. Threads: 185. iptables: ipv4 rules: 54. ipv6 rules: 15. System Load Average: 0.88 0.71 0.38. brwan: Rx: 27.448 KB/s, Tx: 2.750 KB/s. tun21: Rx: 25.426 KB/s, Tx: 1.566 KB/s.


This started with Kamoj V5.5B.12, it was not a problem with V5.4B.35

At the moment I am having to leave VPN/DNS supervision off as I need the Router to bypass the VPN for the Dynamic DNS to work – needed for some devices that are set to bypass the VPN

Have done a complete reinstall (including full erase of all Netgear configuration) in case it was something in my settings before discovering the above.

Apart from that everything runs well with the latest update
 
  • Like
Reactions: KW.

Sign Up For SNBForums Daily Digest

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