What's new

Kamoj Kamoj Add-on 5.1 Beta testing poll

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

Do you want to beta test Kamoj add-on v5.1b1?

  • No, I don't trust 3rd party software

    Votes: 0 0.0%
  • No, I don't use the Voxel firmware

    Votes: 0 0.0%
  • No, I don't like your add-on

    Votes: 0 0.0%

  • Total voters
    207
Changes in kamoj-addon beta version 5.3b8
-------------------------------------------------
- Wireguard Client: Added Install from GUI for R7800
- net-wall Firewall: Changed for "Aegis" from @HELLO_wORLD
- net-wall Firewall: Re-added support for /root/firewall-start.sh (@HELLO_wORLD)
(But, please don't put any scripts in /root, it's bad practice)
- FAQ.txt updated
 
From the FAQ:

Q: Which is faster of the Wireguard and OpenVPN Clients?
A: Depends on the router:
R7800: OpenVPN Client max is about 120 Mbps
R9000: OpenVPN Client max is about 130 Mbps
R7800: Wireguard-go client max is about 70 Mbps
R9000: Wireguard Client max is about 230+ ? Mbps
Thanks for the info!
Interesting BTW - didn't know that R9000 is that slow with OpenVPN client.
Was testing RT-AC86U and getting 200-210 Mbps most of the time with OpenVPN client.
 
Thank you @kamoj :)

Great integration between tools crafted in this community is wonderful.

Changes in kamoj-addon beta version 5.3b8
-------------------------------------------------
- Wireguard Client: Added Install from GUI for R7800
- net-wall Firewall: Changed for "Aegis" from @HELLO_wORLD
- net-wall Firewall: Re-added support for /root/firewall-start.sh (@HELLO_wORLD)
(But, please don't put any scripts in /root, it's bad practice)
- FAQ.txt updated
 
I am not well versed with the technical aspects of the add-on (5.3b6) but I can say it is working well for me, with one exception. I still lose internet access on devices that are in the OpenVPN bypass list (even with the VPN connected) - that is, unless I also have the killswitch disabled for bypassed devices. Or is that how it is supposed to work?

By the way, I am using Aegis and appreciate all the effort to make it run well with the Kamoj add-on.

Thanks,
BL
 
Thank you so much for this wonderful addon, I used it for 2 days now, it's a charm on my R9000.

But I have only 1 issue, I can't backup the config of my adguard on usb drive, I lost all my config after update to 5.3B8.
 
Last edited:
Thank you for your support!
I have tested and can not repeat your issue.
Maybe you can tell point by point and using adequate terms/names on functions etc,
so I don't misunderstand you.
Try without Aegis.
Suggest you update to latest version to keep Aegis compatibility.

I am not well versed with the technical aspects of the add-on (5.3b6) but I can say it is working well for me, with one exception. I still lose internet access on devices that are in the OpenVPN bypass list (even with the VPN connected) - that is, unless I also have the killswitch disabled for bypassed devices. Or is that how it is supposed to work?

By the way, I am using Aegis and appreciate all the effort to make it run well with the Kamoj add-on.

Thanks,
BL
 
Thank you for the feedback!:)

About the AdGuard it's very strange of two reasons:
You shouldn't lose config when you update the add-on. I have tested that.
The function buttons for backup and restore of config works for me.

Have you checked on the USB device that there is no backup?
Have you read the FAQ.txt ? There you can read about how the backup functions.
Did you install/uninstall something else as well?

Happy for any more details to solve your issue.

Thank you so much for this wonderful addon, I used it for 2 days now, it's a charm on my R9000.

But I have only 1 issue, I can't backup the config of my adguard on usb drive, I lost all my config after update to 5.3B8.
 
I am not well versed with the technical aspects of the add-on (5.3b6) but I can say it is working well for me, with one exception. I still lose internet access on devices that are in the OpenVPN bypass list (even with the VPN connected) - that is, unless I also have the killswitch disabled for bypassed devices. Or is that how it is supposed to work?
Yes that is exactly how it should work.

Killswitch = block all traffic that is not going to the tunnel.
Traffic from a device using VPN bypass is not going to the tunnel, so it is blocked by Killswitch.
Enabling the option "No Killswitch for Bypass devices" makes an exception so that those devices are allowed to send traffic outside the tunnel.

(now I cannot think why anyone would want to use VPN bypass + Killswitch and have the router block the bypassed devices.
So perhaps the "No Killswitch for Bypass devices" should be enabled by default.)
 
Thanks for the replies to my question on the bypass.. I have some physical problems with typing and sometimes my comments aren't clear because I have to stop and eventually just hit "send".

Anyway I did install Kamoj 5.3b8 and ran it with and without Aegis. I get the same result. With the settings below, my devices that bypass the VPN can connect to the internet:

OpenVPN Client - General settings
"checked" - Killswitch On
"checked" - No Killswitch for Bypass devices
"checked" - Turbo On
Start delay 0 seconds

If I un-check "No Killswitch for Bypass devices" as shown below, then those same devices will lose internet connection even though the VPN is still connected:

OpenVPN Client - General settings

"checked" - Killswitch On
"NOT checked" - No Killswitch for Bypass devices
"checked" - Turbo On
Start delay 0 seconds

I apologize if I don't understand how this is supposed to work. I mention the issue because (as I recall) in earlier Kamoj versions I would have internet access for bypassed devices whether or not the Killswitch was checked. It would seem to me that the Killswitch should only stop internet access if the VPN is not connected, and that it wouldn't even be needed for devices that bypass the VNP (unless required for Aegis or better DNS/ip leak protection of VPN devices?).

If there is indeed something to change or correct, I would be happy to supply log info if it is helpful...

Thanks again,
BL
 
  • Like
Reactions: KW.
Yes that is exactly how it should work.

Killswitch = block all traffic that is not going to the tunnel.
Traffic from a device using VPN bypass is not going to the tunnel, so it is blocked by Killswitch.
Enabling the option "No Killswitch for Bypass devices" makes an exception so that those devices are allowed to send traffic outside the tunnel.

(now I cannot think why anyone would want to use VPN bypass + Killswitch and have the router block the bypassed devices.
So perhaps the "No Killswitch for Bypass devices" should be enabled by default.)

Hello,

Yes, if the "No Killswitch for Bypassed devices" option is working as intended, then that makes sense to me too.

Thanks,
BL
 
Remark on the Bandwidth Usage part of the addon:
I recently noticed that my work laptop only showed a few MB usage, which is kind of strange it being contantly connected to a corporate VPN.
Also checking directly in iptables chain RRDIPT it showed zero for the IP of that laptop.
And doing a tcpdump host 192.168.1.90 -vv -n -i br0 showed also zero traffic.

And then I remembered some other thread I read on traffic monitoring, that required hardware acceleration to be disabled.

So I did a /etc/init.d/qca-nss-ecm stop, to disable the NSS accelerator -> immediately the counters of my work laptop in iptables started increasing again. And also tcpdump again shows the traffic.

Conclusion: if you want accurate Bandwidth usage, you need to disable NSS.

The question is, how effective is the NSS? (i.e. with NSS disabled, does my network get slower? or wouldn't I notice it with my 250/25 connection).

Why for instance a download on my NAS from bittorrent or usenet doesn't seem to get accelerated (it does get measured by iptables), while an IPSEC VPN connection does get accelerated (it doesn't get measured by iptables).

(And now that I think of it, this might also explain my bad experience with trying to measure bandwidth with iptables in the past. -> there I used wget to download something from a http(s) site -> probably that also got accelerated.)

And I also noticed a bug:
Trying to start NSS again with /etc/init.d/qca-nss-ecm start doesn't work.
It tries to insert kernel module ecm, which it cannot find.

It tries to do insmod ecm blocksite_enable=$blocksite, which fails.
However insmod /lib/modules/3.4.103/ecm.ko blocksite_enable=$blocksite does work.

EDIT: changing it into /sbin/insmod ecm blocksite_enable=$blocksite
also works (i.e. it only happens for people with entware and a changed PATH)
So also my other questions below are no longer valid .

So question: how come that it apparently does work during boot? Or do all the kernel modules automatically get loaded already and is the insmod not needed during boot, but only during a manual (re)start?

(I'm wondering, this seemingly "wrong" kernel module search-path, would this also explain the iptables -S errors, where it cannot find the ipt-modules that are being used in various rules ???
Something to look at some other time...)
 
Last edited:
You are really fantastic!:D I was on to that but never found out why!!!
Really fantastic!:cool:

I was doing experiments with this before.
The way I started/stopped the NSS was (same for ipv6):

Code:
      if [ "$nss_ipv4_disable" = "on" ]; then
         echo 1 > /sys/kernel/debug/ecm/ecm_nss_ipv4/stop
      else
         echo 0 > /sys/kernel/debug/ecm/ecm_nss_ipv4/stop
      fi
I removed that option from the add-on GUI, but the code is still there, for experiment to continue later.

I also read some article once stating that the NSS should be transparent in iptables statistics. Wrong apparently.
Or is it a side-effect of the infamous DNI firewall?
There are some hairy bugs somewhere around here...:eek:

See also my "AP-mode_data_corruption_wan_fix" in kamoj.sh. It tries to correct the other infamous AP mode data corruption errors ...
But no one has reported to have tested it - yet...

So how do we go forward with this? ;)

And to everyone: Sorry:oops: for the Bandwidth Usage meter for R7800 can not be trusted!:(
For the R9000 it might still work as expected?!

Again, I fantastic digging by you. All respect!

Remark on the Bandwidth Usage part of the addon:
I recently noticed that my work laptop only showed a few MB usage, which is kind of strange it being contantly connected to a corporate VPN.
Also checking directly in iptables chain RRDIPT it showed zero for the IP of that laptop.
And doing a tcpdump host 192.168.1.90 -vv -n -i br0 showed also zero traffic.

And then I remembered some other thread I read on traffic monitoring, that required hardware acceleration to be disabled.

So I did a /etc/init.d/qca-nss-ecm stop, to disable the NSS accelerator -> immediately the counters of my work laptop in iptables started increasing again. And also tcpdump again shows the traffic.

Conclusion: if you want accurate Bandwidth usage, you need to disable NSS.

The question is, how effective is the NSS? (i.e. with NSS disabled, does my network get slower? or wouldn't I notice it with my 250/25 connection).

Why for instance a download on my NAS from bittorrent or usenet doesn't seem to get accelerated (it does get measured by iptables), while an IPSEC VPN connection does get accelerated (it doesn't get measured by iptables).

(And now that I think of it, this might also explain my bad experience with trying to measure bandwidth with iptables in the past. -> there I used wget to download something from a http(s) site -> probably that also got accelerated.)

And I also noticed a bug:
Trying to start NSS again with /etc/init.d/qca-nss-ecm start doesn't work.
It tries to insert kernel module ecm, which it cannot find.

It tries to do insmod ecm blocksite_enable=$blocksite, which fails.
However insmod /lib/modules/3.4.103/ecm.ko blocksite_enable=$blocksite does work.

So question: how come that it apparently does work during boot? Or do all the kernel modules automatically get loaded already and is the insmod not needed during boot, but only during a manual (re)start?

(I'm wondering, this seemingly "wrong" kernel module search-path, would this also explain the iptables -S errors, where it cannot find the ipt-modules that are being used in various rules ???
Something to look at some other time...)
 
I can't download any files from ge.tt? No matter do I use computer or mobile phone, nothing just happen. Can you put these to somewhere else too?
 
Sorry, I'm too busy to arrange for that now.
Please try to use a VPN or proxy.
Or maybe someone else here in the forum can help you!:D
 
  • Like
Reactions: KW.
today I tried out WireGuard-go on my R7800. A few observations:

An earlier fix regarding VPN bypassing on WireGuard that I suggested to @kamoj apparently doesn't work. :(
(guess we don't have ppl using WG with VPN Bypass.)

Code:
  if [ -z "$WAN_GWAY" ]; then WAN_GWAY="$(ip route | awk '/via/ && /dev "$WAN_IF"/ && !/default/"'{print $3}')";fi

Here the awk command is in single quotes, so it never expands the variable "$WAN_IF"
This line does work:
Code:
  if [ -z "$WAN_GWAY" ]; then WAN_GWAY="$(ip route | awk "/via/ && /dev $WAN_IF/ && !/default/"'{print $3}')";fi

Another thing I noticed:
With OpenVPN, I can click the green box (with the white check mark) to stop OpenVPN and then click the red box to start it again.
With WireGuard however, this doesn't reliably work...
(When it doesn't work, then starting via the green "start Wireguard Client with this" does work. But for stopping, I need to use etc/init.d/wg-client stop.)

And last thing: the killswitch for WireGuard also doesn't work.
Code:
root@R7800:~$ /tmp/wireguard/firewall-start-wireguard_killswitch.sh
iptables v1.8.4 (legacy): mark: bad integer value for option "--mark", or out of range.

Try `iptables -h' or 'iptables --help' for more information.
(would't it be simpler just call the same kill-switch script as for OpenVPN? (including to exclude bypassed devices from killswitch)
 
also stopping wireguard doesn't properly cleanup its routes.

stopping it shows:
Code:
2020-06-09 23:57:55 [OpenVPN] WireGuard Client 32144: 4345.91:Information: Stop: Delete wireguard routing
Error: either "to" is duplicate, or "13.95.xxx.xxx" is a garbage.
and then this route still remains in my routing tables:
13.95.xxx.xxx via 94.213.xxx.xxx dev brwan

Perhaps tomorrow I'll take a look if I can improve the WG init-script

EDIT: already had a quick peek -> the issue is that I have configured additional static routes via Advanced Setup -> Static Routes.

If I remove my static routes, then the init-script does successfully cleanup on shutdown.
 
Last edited:
Running 5.3b5 on my R7800 and I'm finding that when using my OpenVPN setup it works well for almost all services but a few IoT, I am not able to leverage the bypass options like others have stated, I would love to test the newest beta to see if I can make it work with my ovpn file.

Thank you,
 

Latest threads

Sign Up For SNBForums Daily Digest

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