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!

So I think I found the answer via the Cloudflare community forum:
"It’s traffic on port 443, but I don’t think it’s https traffic, it’s VPN traffic. You can run any service on any port at least theoretically but with our standard service Cloudflare only proxies http/s and websocket traffic. Proxying alternative protocols and ports is only available with our Spectrum product today."
This is an answer from 2018 however, I'll keep looking for a workaround somehow.

For now it means I need to make a decision: cloudflare or openvpn. Or is there a third option I haven't thought of?
 
I noticed an few issues with the supervision mechanism:

- I enabled DNS supervision and selected dnsmasq + adguard.
But in supervision logging I only see:
Code:
2022-07-13 19:32:01 1222.64 [SUPERVISION] addon_supervision.sh 13243: dnsmasq_is_running: Ok
2022-07-13 19:32:01 1222.72 [SUPERVISION] addon_supervision.sh 13243: openvpn_is_running: Ok
2022-07-13 19:32:01 1223.22 [SUPERVISION] addon_supervision.sh 13243: SUCCESS: Ping IP OK

Also if I do "killall AdGuardHome" then supervision newer restarts AGH.

- This morning I had an issue that AGH was not responding -> this would not be detected by simply checking if the process is still running.

Only way to detect this, is by actually trying to ping some URLs or do some nslookups.

But the supervision.log seems to suggest that supervision is only pinging IPs and not pinging URLs.
I only see: SUCCESS: Ping IP OK and no SUCCESS: Ping URL OK. Or is that only a naming thing, and does the ping module do both?

Aside that issue, even if it does ping an URL, then the router would directly use the DNS servers in /etc/resolv.conf, so it will not detect issues with AGH. But only upstream DNS (if you have configured AGH with the same servers as resolv.conf(


So I was thinking of some potential solution to improve AGH supervision.
My idea: add to lines to /tmp/addons/firewall-start-adguardhome.sh
Code:
iptables -w -t nat -A OUTPUT -p udp -d 1.2.3.4 --dport 53 -j DNAT --to 192.168.1.1:5300
iptables -w -t nat -A OUTPUT -p tcp -d 1.2.3.4 --dport 53 -j DNAT --to 192.168.1.1:5300

and then do something like:
nslookup cloudflare.com 1.2.3.4
(or some of the other common URLs that you already use for URL testing)

I.e. tell nslookup to use the bogus IP 1.2.3.4 to resolve an URL. and then have that iptables rule force that lookup to go via AGH.
If that lookup would fail, then it could mean that AGH is hanging.


The result however:
- without the iptables rule the nslookup command waits a few seconds (logical as 1.2.3.4 isn't reachable) but then eventually does give back a result.
checking with tcpdump, it seems that after the timeout of the specified server, nslookup falls back to the default system resolvers.
(so if the traffic is redirected to AGH and AGH would be hanging, then nslookup would still give back a result, only much slower -> difficult to reliably use this check.)

- if I add the iptables rule, then the nslookup command immediately gives a result.
so that seemed to be working.

- next idea, to work around the detection issue with the first point: add a bogus DNS entry to AGH (via DNS rewrite rule")
And then do nslookup bogus.dns.name 1.2.3.4 -> if nslookup falls back to resolv.conf than that would give an getaddrinfo failed message.
And if AGH is working, then it should return the ip-address that was configured in the DNS rewrite rule.
But this also didn't work.

It turns out that without iptables rule, there is a timeout, followed by a fallback to resolv.conf. And with the iptables rule, there is NO timeout, but it directly uses resolv.conf. I do see that the nat rule is hit. But traffic never seems to reach AGH.
So a mystery that I need to dive deeper into.

tbc
 
Hi, thank you for the report and continued support and investigation!

I'll fix the easy part and wait for you to come up with something more improvements.
The supervision roughly works like this:
- Check that DNS is up and running, and restart if not
- Check that VPN is up and running, and restart if not
- Check that ping to IP is working, if not and selected, restart netwall
- Check that traceroute to IP through VPN is working, and restart if not
- Check that traceroute to URL through VPN is working, and restart if not
- Check that ping to URL is working, and restart DNS if not
- Check that ping to URL is working, if not and selected, restart net-lan
- Check that ping to IP is working, if not and selected,
Check that ping to dhcp gateway IP is working, if not and selected, reboot router
Check that ping to IP is working, if not and selected, reboot router

Best Regards,
kamoj
I noticed an few issues with the supervision mechanism:

- I enabled DNS supervision and selected dnsmasq + adguard.
But in supervision logging I only see:
Code:
2022-07-13 19:32:01 1222.64 [SUPERVISION] addon_supervision.sh 13243: dnsmasq_is_running: Ok
2022-07-13 19:32:01 1222.72 [SUPERVISION] addon_supervision.sh 13243: openvpn_is_running: Ok
2022-07-13 19:32:01 1223.22 [SUPERVISION] addon_supervision.sh 13243: SUCCESS: Ping IP OK

Also if I do "killall AdGuardHome" then supervision newer restarts AGH.

- This morning I had an issue that AGH was not responding -> this would not be detected by simply checking if the process is still running.

Only way to detect this, is by actually trying to ping some URLs or do some nslookups.

But the supervision.log seems to suggest that supervision is only pinging IPs and not pinging URLs.
I only see: SUCCESS: Ping IP OK and no SUCCESS: Ping URL OK. Or is that only a naming thing, and does the ping module do both?

Aside that issue, even if it does ping an URL, then the router would directly use the DNS servers in /etc/resolv.conf, so it will not detect issues with AGH. But only upstream DNS (if you have configured AGH with the same servers as resolv.conf(


So I was thinking of some potential solution to improve AGH supervision.
My idea: add to lines to /tmp/addons/firewall-start-adguardhome.sh
Code:
iptables -w -t nat -A OUTPUT -p udp -d 1.2.3.4 --dport 53 -j DNAT --to 192.168.1.1:5300
iptables -w -t nat -A OUTPUT -p tcp -d 1.2.3.4 --dport 53 -j DNAT --to 192.168.1.1:5300

and then do something like:
nslookup cloudflare.com 1.2.3.4
(or some of the other common URLs that you already use for URL testing)

I.e. tell nslookup to use the bogus IP 1.2.3.4 to resolve an URL. and then have that iptables rule force that lookup to go via AGH.
If that lookup would fail, then it could mean that AGH is hanging.


The result however:
- without the iptables rule the nslookup command waits a few seconds (logical as 1.2.3.4 isn't reachable) but then eventually does give back a result.
checking with tcpdump, it seems that after the timeout of the specified server, nslookup falls back to the default system resolvers.
(so if the traffic is redirected to AGH and AGH would be hanging, then nslookup would still give back a result, only much slower -> difficult to reliably use this check.)

- if I add the iptables rule, then the nslookup command immediately gives a result.
so that seemed to be working.

- next idea, to work around the detection issue with the first point: add a bogus DNS entry to AGH (via DNS rewrite rule")
And then do nslookup bogus.dns.name 1.2.3.4 -> if nslookup falls back to resolv.conf than that would give an getaddrinfo failed message.
And if AGH is working, then it should return the ip-address that was configured in the DNS rewrite rule.
But this also didn't work.

It turns out that without iptables rule, there is a timeout, followed by a fallback to resolv.conf. And with the iptables rule, there is NO timeout, but it directly uses resolv.conf. I do see that the nat rule is hit. But traffic never seems to reach AGH.
So a mystery that I need to dive deeper into.

tbc
 
Changes in kamoj-addon beta version 2022-07-14 5.5b26
---------------------------------------------------------------
- Updated: System Information: flash info. Show device with ubi info (ubi0/ubi1).
Thank you @nsx for providing the R9000, enabling me to find this information
needed for plexmediaserver mtd partition.
- Fixed supervision of AdGuardHome, that neither detected error or started/restarted service. (@R. Gerrits)
- Router Information: Moved "Add-on entries" to "Router Configuration Information"
- Enhanced Device Name detection
- Added: Supervision: LOGGING SELECTION: cpu load + some basic iptables/network info
(Was always "on" before, so now possible to switch on/off)
- Added: Supervision: Alternative time settings (used when ntp is not working)
(IPs/URLs of time providers)
- Separated time providers to own list of URLs/IPs.
(Used when ntp time is not obtained at boot).
- Removed slow/not working and not p.c. IPs/URLs from supervision
It is recommended to let the add-on use it's own ip/name addresses.
To do so:
Execute these commands from router command line once.
nvram unset kamoj_ping_www;nvram unset kamoj_ping_ip;nvram commit;reboot
- Minor editorials/optimizations/refactoring
 
I recently updated to voxel 1.0.2.95SF which seems stable for me, however, I am unable to find the the latest kamoj-addon file for download. Can someone share a link or post the file (w/ .md5)
 
I have dnscrypt-2 enabled, but I don't want to use the available servers, I want to use nextdns's server with my own ID when I create an account? According to the instructions of the nextdns page, I have to insert the Stamp line to use my ID. So how do I insert the Stamp line?
R7800-dns1.jpg

dnscrypt-proxy-20.jpg
 
Just installed 5.5b26 on my R9000 with Router Firmware Version (Voxel) V1.0.4.60HF
Before upgrading to the b26, I was on b21, I did do the:

Code:
nvram show | awk -F= '/^kamoj/ {print $1}' | xargs -n1 nvram unset
nvram commit

and

Code:
/bin/opkg remove kamoj-addon
reboot

After the reboot, I was connecting to the first VPN on my OpenVPN list?? but Kamoj add on was gone from the interface? I thought that was weird, so I just installed b26, and upon reboot, AGH was off which is expected, but I was connected to a VPN on the OpenVPN config list, I dont know if its because configuration was saved on my USB drive, which does save some IP tables and AGH configuration, just wanted to point it out.
 
Voxel FW connects to vpn with a non specific configuration if found on USB.
Both Voxel and addon use USB settings if found.
Don't understand what you mean about AGH though.
 
Voxel FW connects to vpn with a non specific configuration if found on USB.
Both Voxel and addon use USB settings if found.
Don't understand what you mean about AGH though.
Yes you are right, I totally forgot about this, I must have an .ovpn file on the USB I forgot about, and it must of auto connected, I assumed it was in the NVRAM. I thought maybe my saved AGH configuration file might of done this, but its the .ovpn file I still have on there :) Sorry for the confusion! Glad though you got an R9000 to test :)
 
Hello, If I understand correctly, to have the latest version you have to be a "beta tester".
To be a beta tester you must have Kamoj's private email but we don't can't find it in his profile.
By following the "readme.txt", we install the 2019 version.
On the voxel site no ipk file is listed.
And how do you get the latest version?
Please can someone help me out as I'm a bit lost here!
Aperobik
 
Hello, If I understand correctly, to have the latest version you have to be a "beta tester".
To be a beta tester you must have Kamoj's private email but we don't can't find it in his profile.
By following the "readme.txt", we install the 2019 version.
On the voxel site no ipk file is listed.
And how do you get the latest version?
Please can someone help me out as I'm a bit lost here!
Aperobik
I remember Kamoj said in one of his earlier threads, that if you want to become a beta tester you need to send him a private message through this forum :)
 
I remember Kamoj said in one of his earlier threads, that if you want to become a beta tester you need to send him a private message through this forum :)
Thank you for answering me.
Indeed, it puts this message during each release.
Now how to get his email?
I searched his profile but couldn't find anything.
 
I make beta versions of the next kamoj add-on.

The 5.5 beta has a lot more functions than the 5.0 beta and 5.4 betas.
The objective is to in the near future make an official release!

But first I need some voluntary testers to find serious bugs.
I can e.g. not test R9000 or Wireguard, so those testers are most wanted,
but anyone is welcome to test 5.5 beta.

To be a beta tester of this hobby project includes that you must be active;
as tester reporting success/error, and in the SNB forum.
Are you willing to give feedback, and contribute to the community?

In the SNB forum, please be polite and press "Like" on the postings you like.
,

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 and your router(s).


Examples of things you can tell me:
Report your experience directly to me, or in the forum, so that we together can
find bugs and introduce new functions.

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!

This is a continuation of:
https://www.snbforums.com/threads/kamoj-add-on-beta-testing-ii.72238/
https://www.snbforums.com/threads/kamoj-add-on-beta-testing.67375/
https://www.snbforums.com/threads/kamoj-add-on-v5-for-netgear-r7800-x4s-and-r9000-x10.60590/
Hello Kamoj,
Could you send me your private email so that I can test the new release?
 
hello kamoj and all,
it works, but i encountered a problem when i changed the lan network (ie 10.0.0.0/24 to 192.168.10.0/24), the router blocks internet connections (wan).
Coming back with the original network no problem.
For configuration, I enabled Adguard, Aegis, Netdata and set up iptables rules for nat dns to Adguard.
 

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