Kamoj Kamoj Add-on Beta testing

[kamoj]

I make beta versions of the next kamoj add-on.

The beta has a lot more functions than the official 5.0 beta,
but is also more tested and with fewer known bugs.

N.B: Voxel firmware is a pre-requisite, not an option!

If you want to test betas you must apply by sending me a PM (Private Message)
after reading and accepting this, and tell me something about yourself:

To be a beta tester of this hobby project includes that you must be active,
and report your experience to me or the community, so that we together can
find bugs and introduce new functions.

Can you tell me something more about yourself and your router? e.g.:

What router do you have?

What is your level of router/networking knowledge?
How you got to know about the addon-on?

How long have you used Voxel firmware?
What are your expectations?
In what way do think can you help in the beta program?

Wishing you a good experience of the add-on!

 

[kamoj]

Changes in kamoj-addon beta version 5.4b7
--------------------------------------------------
- Removed automatic setting of dmesg time stamps (To align with Aegis)
- Advanced: Kamoj Menu: Settings: Added "Set time stamps on dmesg logs"
N.B.: Don't check this one if you want Aegis logs to work >10000 seconds
- OpenVPN Client: AzireVPN: Added: Spain-Madrid.
- Restart Supervision: Changed timeouts.
Delayed start 31 seconds to not start simultaneously with other cron jobs.
ping failure detection changed.
Added possibility to change ping failure timeout (default 1 sec) with nvram variable, e.g.:
nvram set kamoj_restart_ping_timeout=2 && nvram commit
- Router Information: Changed number of ping for DNS/Internet test from 1 to 3.
Added possibility to change ping failure timeout (default 3 sec) with nvram variable, e.g.:
nvram set kamoj_restart_ping_timeout=2 && nvram commit
- net-wan: added restart of Wireguard client if needed
- Advanced: Administration: Logs: Enlarged default log window size for R7800.
- Advanced: Administration: Logs: Enabled these log alternatives for R7800:
+ Automatic Internet connection reset
+ ReadySHARE Mobile Connect

 

[KW.]

From my heart to all Voxel netgears owners: Send a PM to @kamoj and beg to be deemed worthy You will have another router with his addon and a level of control that is fantastic. All you have to do is read his FAQ and Readme. All written with great respect for people like me that came here without knowing anything about routers. Then with Kamoj addon your home network is yours do decide just with the click of your mouse.

I just love it.

 

[Voxel]

The beta has a lot more functions than the official 5.0 beta

I would change the word 'beta' to 'release'. Just IMO.

Any 'beta' assumes something not-tested. So as a rule people prefer to avoid any betas. If you test it, if it works and it should work for otherts. - it is the 'release'. I keep my own 'betas' not visible for users of Voxel FW. Just for my own internal testing, benchmarks, etc. On the fly. Inside me. But it is not your case.

IMO you do not release not tested versions of your software product. So: I'd suggest you to release your 'releases' but not 'betas'. Change the meaning. Just IMO. Respect your work .

Voxel.

 

[kamoj]

I'll think about it. All that you say is always sensible.
My problem is that I try to support a router (R8900/R9000) that I can not test.
Another thing is that there are so many options now in the add-on, so it's impossible to test all combinations.
But again, I think you are right.
Thank you for the advice.

I would change the word 'beta' to 'release'. Just IMO.

Any 'beta' assumes something not-tested. So as a rule people prefer to avoid any betas. If you test it, if it works and it should work for otherts. - it is the 'release'. I keep my own 'betas' not visible for users of Voxel FW. Just for my own internal testing, benchmarks, etc. On the fly. Inside me. But it is not your case.

IMO you do not release not tested versions of your software product. So: I'd suggest you to release your 'releases' but not 'betas'. Change the meaning. Just IMO. Respect your work .

Voxel.

 

[Voxel]

My problem is that I try to support a router (R8900/R9000) that I can not test.

I can provide you the permanent access to my R9000 by SSH (reverse SSH tunneling). Is it enough? You can reboot, play with, etc. The only limitation for you: it should be workable (i.e. accessible by SSH from my LAN) for such times as 00:00, 01:00, 02:00, 03:00 - 23:00. Plus/minus 2 mins. It performs some temperature measurement hourly (cron) with publishing the results to my own server. So I'd prefer it should work these times... Not obligatory of course. But preferable.

Voxel.

 

[kamoj]

Why don't you sleep at this hour?
With ssh I can't use the GUI... All my add-ons involve GUI.

I can provide you the permanent access to my R9000 by SSH (reverse SSH tunneling). Is it enough? You can reboot, play with, etc. The only limitation for you: it should be workable (i.e. accessible by SSH from my LAN) for such times as 00:00, 01:00, 02:00, 03:00 - 23:00. Plus/minus 2 mins. It performs some temperature measurement hourly (cron) with publishing the results to my own server. So I'd prefer it should work these times... Not obligatory of course. But preferable.

Voxel.

 

[Panner]

Kamoj

In your 5.4b7 changes you have

Added possibility to change ping failure timeout (default 1 sec) with nvram variable, e.g.:
nvram set kamoj_restart_ping_timeout=2 && nvram commit
- Router Information: Changed number of ping for DNS/Internet test from 1 to 3.
Added possibility to change ping failure timeout (default 3 sec) with nvram variable, e.g.:
nvram set kamoj_restart_ping_timeout=2 && nvram commit

Is this a duplication with different defaults or should one relate to the failure time before stopping and the other to the pause before restarting?

Many thanks for your efforts

 

[kamoj]

Different defaults. Same parameter due to lazy programmer.
Router Information is just information.
Normal user doesn't need to change these, but e.g. user with very slow internet may need to
increase the value.
There is no pause before restarting, but since many ip-addresses are tried before failing,
a restart due to failed VPN may take e.g. 3 minutes.

Kamoj

In your 5.4b7 changes you have

Added possibility to change ping failure timeout (default 1 sec) with nvram variable, e.g.:
nvram set kamoj_restart_ping_timeout=2 && nvram commit
- Router Information: Changed number of ping for DNS/Internet test from 1 to 3.
Added possibility to change ping failure timeout (default 3 sec) with nvram variable, e.g.:
nvram set kamoj_restart_ping_timeout=2 && nvram commit

Is this a duplication with different defaults or should one relate to the failure time before stopping and the other to the pause before restarting?

Many thanks for your efforts

 

[R. Gerrits]

With ssh I can't use the GUI... All my add-ons involve GUI.

You could tunnel the GUI over ssh.

 

[kamoj]

Ok, I beieve you, but it's out of my limited knowledge.
Maybe you or Voxel can do it, but not me.
I'm sorry.

You could tunnel the GUI over ssh.

 

[blueliner]

Installed Kamoj 5.4b7 and adjusted the restart ping timeout (I figured that have to be one of those users "with a very slow internet!). Everything seems to be running well.

Thanks,
BL

 

[kamoj]

Thank you too, I'm happy my setting for "you" worked.
It's very good for me to get feedback!

Installed Kamoj 5.4b7 and adjusted the restart ping timeout (I figured that have to be one of those users "with a very slow internet!). Everything seems to be running well.

Thanks,
BL

 

[foo man]

R9000 running Komoj v5.4b6 with Voxel v1.0.4.45.2HF and Aegis v1.3.1.......Happy to report no issues with my setup. Everything is running very well.

Same here ... R9000 with all the trimmings!

 

[Panner]

R9000 running Komoj v5.4b7 with Voxel v1.0.4.45.2HF currently without Adguard or any DNS Filter/Encryption. Surfshark VPN and some VPN bypassing. Together with R7800 in AP mode running Komoj v5.4b6 with Voxel V1.0.2.80.5SF.

Apart from an occasional VPN Inactivity timeout (--ping-restart) it is running well

 

[kamoj]

Thank you for reporting! This what I expect from beta testing.
It's "interesting" about your VPN Inactivity timeout.
Can you please provide information about how often it happens?
When did it start happening? Have you tried older Voxel FW and Add-ons?
I'm currently investigating these kind of timeouts for both OpenVPN and Wireguard.
I've some reports it's happening exactly every 3 hours.

R9000 running Komoj v5.4b7 with Voxel v1.0.4.45.2HF currently without Adguard or any DNS Filter/Encryption. Surfshark VPN and some VPN bypassing. Together with R7800 in AP mode running Komoj v5.4b6 with Voxel V1.0.2.80.5SF.

Apart from an occasional VPN Inactivity timeout (--ping-restart) it is running well

 

[ern]

Previously reported high CPU usage with AdGuard

Now woking well with the following changes to default settings
In upstream DNS server addresses I removed the last 2 server address entries
Then I switched from parallel requests to load balancing (this was the main culprit for high CPU usage)

Just for info I use Seb Sauvage and AdGuard DNS filter DNS block lists

 

[Panner]

Thank you for reporting! This what I expect from beta testing.
It's "interesting" about your VPN Inactivity timeout.
Can you please provide information about how often it happens?
When did it start happening? Have you tried older Voxel FW and Add-ons?
I'm currently investigating these kind of timeouts for both OpenVPN and Wireguard.
I've some reports it's happening exactly every 3 hours.

The problem started after installing the R9000 (early September) and setting up Surfshark on it. I had previously been using Surfshark for a couple of months on my R7800 as the main router.

Has happened with all versions of Voxel (from v1.0.4.43 to 1.0.4.45.2 (apart from 1.0.4.45.1 which I did not install) and your addons from 5.3b30 to 5.4b7 (apart from 5.4b4 which I did not install). I usually update the addon within a day of updates being released.

ISP is a mobile (cell) provider (since just before installing the R9000) and the download/upload speed is usually 15 to 25mb for both (usually better via VPN than not). However at certain times of the day (usually evenings) this drops substantially.

Initially seemed OK then kept dropping the connection briefly. Varied from 1 or 2 times per day up to 7 to 10 times. There does not appear to be any set pattern or regular interval. However, I will try and monitor it and let you know if a pattern appears. Initially thought it was a problem with Surfshark settings so changed the config file to tie in with the push settings received. The following settings were added or changed in the config to try to improve things.

#ping 60
#ping-restart 180
#ping-timer-rem
keepalive 60 360
connect-retry 1
cipher AES-256-GCM

There appeared to be a reduction in number of restarts following these changes as most days it is only 1 or 2. However that may be coincidental

Killswitch is on, no killswitch for Bypass, Restart at connection failure and Turbo are on

Further info:

The push settings received on starting VPN are:
Thu Nov 5 07:06:17 2020 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 162.252.172.57,dhcp-option DNS 149.154.159.92,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,block-outside-dns,route-gateway 10.8.8.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.8.8 255.255.255.0,peer-id 6,cipher AES-256-GCM'
Thu Nov 5 07:06:17 2020 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:7: block-outside-dns (2.4.9)

The following is an extract from current session log sowing 2 restarts since the current session started (on 2020-11-04 at 06:01:31)

“Wed Nov 4 22:00:35 2020 [uk-lon-v032.prod.surfshark.com] Inactivity timeout (--ping-restart), restarting
Wed Nov 4 22:00:35 2020 SIGUSR1[soft,ping-restart] received, process restarting
Wed Nov 4 22:00:35 2020 Restart pause, 1 second(s) (note - changed from 5 seconds to reduce down time)
-
Thu Nov 5 07:00:42 2020 TLS: tls_process: killed expiring key
Thu Nov 5 07:00:43 2020 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA
Thu Nov 5 07:00:43 2020 VERIFY KU OK
Thu Nov 5 07:00:43 2020 Validating certificate extended key usage
Thu Nov 5 07:00:43 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Nov 5 07:00:43 2020 VERIFY EKU OK
Thu Nov 5 07:00:43 2020 VERIFY OK: depth=0, CN=uk-lon-v032.prod.surfshark.com
Thu Nov 5 07:00:43 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Nov 5 07:00:43 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Nov 5 07:00:43 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Nov 5 07:06:15 2020 [uk-lon-v032.prod.surfshark.com] Inactivity timeout (--ping-restart), restarting
Thu Nov 5 07:06:15 2020 SIGUSR1[soft,ping-restart] received, process restarting
Thu Nov 5 07:06:15 2020 Restart pause, 1 second(s)”

I hope that helps
If you need anything further (eg full session log or other logs) I can provide them. I do not currently save logs so information is currently only available from the last reboot.

PS I am hoping Surfshark start to support wireguard on the router, at present they only have wireguard on their apps for PC/Android etc.

 

[kamoj]

Excellent!
I'll keep these logs and valuable information.

You can also try to add this to your OpenVPN Client config:
reneg-sec 3600

You have a good point in trying to reduce down time.
So in next release I'll tune the restart supervision to be faster as well.

Thank you again @Panner for your reports!!!

The problem started after installing the R9000 (early September) and setting up Surfshark on it. I had previously been using Surfshark for a couple of months on my R7800 as the main router.

Has happened with all versions of Voxel (from v1.0.4.43 to 1.0.4.45.2 (apart from 1.0.4.45.1 which I did not install) and your addons from 5.3b30 to 5.4b7 (apart from 5.4b4 which I did not install). I usually update the addon within a day of updates being released.

ISP is a mobile (cell) provider (since just before installing the R9000) and the download/upload speed is usually 15 to 25mb for both (usually better via VPN than not). However at certain times of the day (usually evenings) this drops substantially.

Initially seemed OK then kept dropping the connection briefly. Varied from 1 or 2 times per day up to 7 to 10 times. There does not appear to be any set pattern or regular interval. However, I will try and monitor it and let you know if a pattern appears. Initially thought it was a problem with Surfshark settings so changed the config file to tie in with the push settings received. The following settings were added or changed in the config to try to improve things.

#ping 60
#ping-restart 180
#ping-timer-rem
keepalive 60 360
connect-retry 1
cipher AES-256-GCM

There appeared to be a reduction in number of restarts following these changes as most days it is only 1 or 2. However that may be coincidental

Killswitch is on, no killswitch for Bypass, Restart at connection failure and Turbo are on

Further info:

The push settings received on starting VPN are:
Thu Nov 5 07:06:17 2020 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 162.252.172.57,dhcp-option DNS 149.154.159.92,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,block-outside-dns,route-gateway 10.8.8.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.8.8 255.255.255.0,peer-id 6,cipher AES-256-GCM'
Thu Nov 5 07:06:17 2020 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:7: block-outside-dns (2.4.9)

The following is an extract from current session log sowing 2 restarts since the current session started (on 2020-11-04 at 06:01:31)

“Wed Nov 4 22:00:35 2020 [uk-lon-v032.prod.surfshark.com] Inactivity timeout (--ping-restart), restarting
Wed Nov 4 22:00:35 2020 SIGUSR1[soft,ping-restart] received, process restarting
Wed Nov 4 22:00:35 2020 Restart pause, 1 second(s) (note - changed from 5 seconds to reduce down time)
-
Thu Nov 5 07:00:42 2020 TLS: tls_process: killed expiring key
Thu Nov 5 07:00:43 2020 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA
Thu Nov 5 07:00:43 2020 VERIFY KU OK
Thu Nov 5 07:00:43 2020 Validating certificate extended key usage
Thu Nov 5 07:00:43 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Nov 5 07:00:43 2020 VERIFY EKU OK
Thu Nov 5 07:00:43 2020 VERIFY OK: depth=0, CN=uk-lon-v032.prod.surfshark.com
Thu Nov 5 07:00:43 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Nov 5 07:00:43 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Nov 5 07:00:43 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Nov 5 07:06:15 2020 [uk-lon-v032.prod.surfshark.com] Inactivity timeout (--ping-restart), restarting
Thu Nov 5 07:06:15 2020 SIGUSR1[soft,ping-restart] received, process restarting
Thu Nov 5 07:06:15 2020 Restart pause, 1 second(s)”

I hope that helps
If you need anything further (eg full session log or other logs) I can provide them. I do not currently save logs so information is currently only available from the last reboot.

PS I am hoping Surfshark start to support wireguard on the router, at present they only have wireguard on their apps for PC/Android etc.

 

[Panner]

Excellent!
I'll keep these logs and valuable information.

You can also try to add this to your OpenVPN Client config:
reneg-sec 3600

You have a good point in trying to reduce down time.
So in next release I'll tune the restart supervision to be faster as well.

Thank you again @Panner for your reports!!!

Thanks Kamoj

Have amended reneg-sec from 0 to 3600

Will see what happens and let you know if it makes a difference