Kamoj Kamoj Add-on Beta testing

[R. Gerrits]

Today I noticed an issue with the VPN Bypassing.
I was downloading a new game to my playstation and wondered why it went so slow -> then I noticed it is was download via my VPN connection, instead of directly from internet.

I checked ip rule show -> all the vpn bypassing rules were there.
Next I checked ip route show table novpn -> this was missing the default route to internet.

root@R7800:~$ ip route show table novpn
10.0.0.0/8 via 192.168.1.5 dev br0  metric 10 
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1 
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1 
239.0.0.0/8 dev br0  scope link

I fixed it by running /usr/bin/addon_bypassvpnip.sh force -> after this the default route to internet was back:
(and my download was faster again)

root@R7800:~$ ip route show table novpn
default via 94.213.xxx.1 dev brwan 
10.0.0.0/8 via 192.168.1.5 dev br0  metric 10 
94.213.xxx.0/23 dev brwan  proto kernel  scope link  src 94.213.xxx.xxx 
172.83.xxx.xxx via 94.213.xxx.1 dev brwan 
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1 
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1 
239.0.0.0/8 dev br0  scope link

I don't know what caused it.
I can only see that this afternoon my VPN connection restarted and and at that point the main routing table had both the internet and vpn routes:

2021-02-01 14:06:54; 489950.15; [OpenVPN]; [rc.common 25566 Information: ip route after starting OpenVPN]; 
2021-02-01 14:06:54; 489950.16; [OpenVPN]; [rc.common 25566 
0.0.0.0/1 via 172.21.xxx.1 dev tun21 
default via 94.213.xxx.1 dev brwan 
10.0.0.0/8 via 192.168.1.5 dev br0 metric 10 
94.213.xxx.0/23 dev brwan proto kernel scope link src 94.213.xxx.xxx 
128.0.0.0/1 via 172.21.xxx.1 dev tun21 
172.21.xxx.0/23 dev tun21 proto kernel scope link src 172.21.xxx.xxx
172.83.xxx.xxx via 94.213.xxx.1 dev brwan 
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1 
192.168.2.0/24 dev tun0 proto kernel scope link src 192.168.2.1 
239.0.0.0/8 dev br0 scope link ];

My suspicion: after the restart of VPN, the addon_bypassvpnip.sh script should have been called to recreate the novpn routing table.
and for some reason this didn't happen.
I don't exactly know what logic you are normally using to trigger addon_bypassvpnip.sh, but I'd say it would be better that the start function in /etc/init.d/openvpn-client should have something like "IF VPNbypassing = enabled THEN /usr/bin/addon_bypassvpnip.sh force"

And I'd place this just before the net-wall restart command.

(This might cause the net-wall to be restarted twice. once from addon_bypassvpnip.sh (only if killswitch is enabled) and once from the openvpn-client script. So it could use some improvement.)
(And I'm not sure if the "force" parameter is required.)

 

[kamoj]

Thank you for the qualified "guesses".
If it happen again, can you please provide me with the OpenVPN Client log-file?
Please.
Meanwhile I trust you 100% and will see if your suggested solution is needed "more often"/always...
Thank you friend!

Today I noticed an issue with the VPN Bypassing.
I was downloading a new game to my playstation and wondered why it went so slow -> then I noticed it is was download via my VPN connection, instead of directly from internet.

I checked ip rule show -> all the vpn bypassing rules were there.
Next I checked ip route show table novpn -> this was missing the default route to internet.

root@R7800:~$ ip route show table novpn
10.0.0.0/8 via 192.168.1.5 dev br0  metric 10
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

I fixed it by running /usr/bin/addon_bypassvpnip.sh force -> after this the default route to internet was back:
(and my download was faster again)

root@R7800:~$ ip route show table novpn
default via 94.213.xxx.1 dev brwan
10.0.0.0/8 via 192.168.1.5 dev br0  metric 10
94.213.xxx.0/23 dev brwan  proto kernel  scope link  src 94.213.xxx.xxx
172.83.xxx.xxx via 94.213.xxx.1 dev brwan
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

I don't know what caused it.
I can only see that this afternoon my VPN connection restarted and and at that point the main routing table had both the internet and vpn routes:

2021-02-01 14:06:54; 489950.15; [OpenVPN]; [rc.common 25566 Information: ip route after starting OpenVPN];
2021-02-01 14:06:54; 489950.16; [OpenVPN]; [rc.common 25566
0.0.0.0/1 via 172.21.xxx.1 dev tun21
default via 94.213.xxx.1 dev brwan
10.0.0.0/8 via 192.168.1.5 dev br0 metric 10
94.213.xxx.0/23 dev brwan proto kernel scope link src 94.213.xxx.xxx
128.0.0.0/1 via 172.21.xxx.1 dev tun21
172.21.xxx.0/23 dev tun21 proto kernel scope link src 172.21.xxx.xxx
172.83.xxx.xxx via 94.213.xxx.1 dev brwan
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev tun0 proto kernel scope link src 192.168.2.1
239.0.0.0/8 dev br0 scope link ];

My suspicion: after the restart of VPN, the addon_bypassvpnip.sh script should have been called to recreate the novpn routing table.
and for some reason this didn't happen.
I don't exactly know what logic you are normally using to trigger addon_bypassvpnip.sh, but I'd say it would be better that the start function in /etc/init.d/openvpn-client should have something like "IF VPNbypassing = enabled THEN /usr/bin/addon_bypassvpnip.sh force"

And I'd place this just before the net-wall restart command.

(This might cause the net-wall to be restarted twice. once from addon_bypassvpnip.sh (only if killswitch is enabled) and once from the openvpn-client script. So it could use some improvement.)
(And I'm not sure if the "force" parameter is required.)

 

[kamoj]

Changes in kamoj-addon beta version 5.4b18
--------------------------------------------------
- DNSPrivacy/Ad-Blocking: DNSCrypt: Updated to conform to v2.0.45+
N.B.: If you have modified own dnscrypt-proxy-2.toml configuration file,
it must be changed as described in: https://github.com/DNSCrypt/dnscrypt-proxy/releases
- DNSPrivacy/Ad-Blocking: DNS Filter/Encryption: Changed layout a little bit
- VPN Bypassing: Updated "ip rule show" to also include "ip route show table novpn"
- VPN Bypassing: Added fix for issue observed by @blueliner and @R. Gerrits, causing VPN bypassed
devices to still connect through the VPN tunnel. I could not produce exactly the same issue,
but a similar one, when the router has no internet connection after boot and VPN is started.
This fix will cause a 1-2 seconds slower VPN start, but I see no other draw-backs.
- OpenVPN Client: Make the status "shield" colored red when no internet connection - even if VPN is up.
- OpenVPN Client: Moved some logging to fetch correct "process name" and PID.
Cleaned up the logging.
- Wireguard Client: Make the status "shield" colored red when no internet connection - even if VPN is up.
- AdGuard Home: Updated default "AdGuardHome.yaml"
- Settings: Route To Other Net (E.g. Modem in NAT Off/Bridge Mode): Function enabled again.
(@HELLO_wORLD) (@BritinMA)
- Restart supervision: Added some new reboot code. Now to work when using VPN. (@blueliner)
Reboot will happen when all ping fails except to wan_dhcp_gateway.

PS
Please AdGuard Home users: There is a new version worth to try: v0.105.0-beta.3:
DNSPrivacy/Ad-Blocking: Adguard Home: Check "Use BETA version" box, and then press "Download Latest Version".

 

[Gallo]

Diligence is your most astounding virtue, Thanks

 

[kamoj]

Thank you, but you are much too polite!

Diligence is your most astounding virtue, Thanks

 

[Paul Connolly]

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

thanks kamoj i love the addon my r9000 would be a very expensive door stop without you and voxel

 

[foo man]

thanks kamoj i love the addon my r9000 would be a very expensive door stop without you and voxel

As another R9000 owner: I concur.

 

[blueliner]

Hello,

Back home! It sounds like the Voxel 1.0.4.46 and Kamoj 5.4b16 ran OK on the router. Port 53 udp is still open. Perhaps the recent backup router config I used was corrupt even though the size looked OK??? I installed 1.0.4.46 and 5.4b16 with the original "baseline" backup instead.

My wife uses the R9000 network more than I and mentioned that whenever devices loose the internet, the internet connection indicator on the "Basic - Home" page will show no internet, but the Kamoj OpenVPN status symbol will most always be green. The Kamoj Router Information page may or may not show lookup/ping success at the time, but the Kamoj Supervision log will always show a ping/lookup failure occurred at some point.

Successful ping/lookup may start again but the "Basic-Home" connection indicator will still show no internet connection. At that point restarting the VPN (even though it shows Green/Connected) will solve the problem and internet connection comes back online.

The other thing noticed yesterday is that UPnP does not show any ports forwarded. Usually we don't have anything that would need it. However yesterday a torrent downloader and Resilio Sync were used (and haven't been before on that network) and ports didn't show open with UpNP enabled. Mentioning it because of the earlier problem with port 53. I don't typically have UPnP enabled and don't really know if this is an issue. I will start another thread to see if someone can clue me in on how it is working on their R9000.

It looks like 5.4b18 may address the VPN connection/restart issue and I will give it a try!

Thanks,
BL

 

[blueliner]

Today I noticed an issue with the VPN Bypassing.
I was downloading a new game to my playstation and wondered why it went so slow -> then I noticed it is was download via my VPN connection, instead of directly from internet.

I checked ip rule show -> all the vpn bypassing rules were there.
Next I checked ip route show table novpn -> this was missing the default route to internet.

root@R7800:~$ ip route show table novpn
10.0.0.0/8 via 192.168.1.5 dev br0  metric 10
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

I fixed it by running /usr/bin/addon_bypassvpnip.sh force -> after this the default route to internet was back:
(and my download was faster again)

root@R7800:~$ ip route show table novpn
default via 94.213.xxx.1 dev brwan
10.0.0.0/8 via 192.168.1.5 dev br0  metric 10
94.213.xxx.0/23 dev brwan  proto kernel  scope link  src 94.213.xxx.xxx
172.83.xxx.xxx via 94.213.xxx.1 dev brwan
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
239.0.0.0/8 dev br0  scope link

I don't know what caused it.
I can only see that this afternoon my VPN connection restarted and and at that point the main routing table had both the internet and vpn routes:

2021-02-01 14:06:54; 489950.15; [OpenVPN]; [rc.common 25566 Information: ip route after starting OpenVPN];
2021-02-01 14:06:54; 489950.16; [OpenVPN]; [rc.common 25566
0.0.0.0/1 via 172.21.xxx.1 dev tun21
default via 94.213.xxx.1 dev brwan
10.0.0.0/8 via 192.168.1.5 dev br0 metric 10
94.213.xxx.0/23 dev brwan proto kernel scope link src 94.213.xxx.xxx
128.0.0.0/1 via 172.21.xxx.1 dev tun21
172.21.xxx.0/23 dev tun21 proto kernel scope link src 172.21.xxx.xxx
172.83.xxx.xxx via 94.213.xxx.1 dev brwan
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev tun0 proto kernel scope link src 192.168.2.1
239.0.0.0/8 dev br0 scope link ];

My suspicion: after the restart of VPN, the addon_bypassvpnip.sh script should have been called to recreate the novpn routing table.
and for some reason this didn't happen.
I don't exactly know what logic you are normally using to trigger addon_bypassvpnip.sh, but I'd say it would be better that the start function in /etc/init.d/openvpn-client should have something like "IF VPNbypassing = enabled THEN /usr/bin/addon_bypassvpnip.sh force"

And I'd place this just before the net-wall restart command.

(This might cause the net-wall to be restarted twice. once from addon_bypassvpnip.sh (only if killswitch is enabled) and once from the openvpn-client script. So it could use some improvement.)
(And I'm not sure if the "force" parameter is required.)

I've seen the same behavior a couple times on my R9000. Going to give 5.4b18 a try and see how the changes work out!

BL

 

[R. Gerrits]

Changes in kamoj-addon beta version 5.4b18
--------------------------------------------------
- VPN Bypassing: Added fix for issue observed by @blueliner and @R. Gerrits, causing VPN bypassed
devices to still connect through the VPN tunnel. I could not produce exactly the same issue,
but a similar one, when the router has no internet connection after boot and VPN is started.
This fix will cause a 1-2 seconds slower VPN start, but I see no other draw-backs.

I see you added:
if [ "$(nvram get kamoj_bypassed_devices_pass_killswitch_ovpn_disable)" != "1" ]; then
/usr/bin/addon_bypassvpnip.sh force no_netwall_restart
fi

This means that the fix currently only works for people that also enabled "No Killswitch for Bypass devices"
I think a better solution would be to use:
if [ "$(nvram get kamoj_all_bypassing_off)" != "1" ]; then
/usr/bin/addon_bypassvpnip.sh force no_netwall_restart
fi
This way it will always run when VPN bypassing is enabled.

(And I see /etc/init.d/wg-client would need a similar change.)

Changes in kamoj-addon beta version 5.4b18
--------------------------------------------------
- Settings: Route To Other Net (E.g. Modem in NAT Off/Bridge Mode): Function enabled again.
(@HELLO_wORLD) (@BritinMA)

This function currently does not work from devices that are on VPN bypass list.
(adding the additional ipaddress to the wan interface only adds the corresponding route to table main, and not to table novpn.)

Solution would be to arrange that firewall-start-route_to_other_net.sh will change from:

#!/bin/sh
ip addr add 192.168.100.2/24 dev brwan 2>/dev/null
iptables -t nat -I POSTROUTING -o brwan -d 192.168.100.1/24 -j SNAT --to 192.168.100.2

to

#!/bin/sh
ip addr add 192.168.100.2/24 dev brwan 2>/dev/null
iptables -t nat -I POSTROUTING -o brwan -d 192.168.100.1/24 -j SNAT --to 192.168.100.2
if [ "$(nvram get kamoj_all_bypassing_off)" != "1" ]; then
     ip route add table novpn 192.168.100.0/24 dev brwan  proto kernel  scope link  src 192.168.100.2
fi

OR

#!/bin/sh
ip addr add 192.168.100.2/24 dev brwan 2>/dev/null
iptables -t nat -I POSTROUTING -o brwan -d 192.168.100.1/24 -j SNAT --to 192.168.100.2
if [ "$(nvram get kamoj_all_bypassing_off)" != "1" ]; then
     /usr/bin/addon_bypassvpnip.sh force no_netwall_restart
fi

 

[kamoj]

You are always a source of fantastic information and support!
Thank you sir!
Short comments:
1. I never could understand the problem so I tried something to get forward.
I'm sure you are right in your observation and recommendation!
2. I'm aware of that and if you try to activate it, you'll get a pop-up saying you have to off the VPN.
(Do you know how to reverse (delete) the routing? I couldn't figure out how to do, so the pop-up says
it'll be enable until reboot. ;-) I know you know, you are so skilled and clever! )

Again, thank you for being so supportive to me and the community - a true source of "make it work".
Cudos Mr R!

I see you added:
if [ "$(nvram get kamoj_bypassed_devices_pass_killswitch_ovpn_disable)" != "1" ]; then
/usr/bin/addon_bypassvpnip.sh force no_netwall_restart
fi

This means that the fix currently only works for people that also enabled "No Killswitch for Bypass devices"
I think a better solution would be to use:
if [ "$(nvram get kamoj_all_bypassing_off)" != "1" ]; then
/usr/bin/addon_bypassvpnip.sh force no_netwall_restart
fi
This way it will always run when VPN bypassing is enabled.

(And I see /etc/init.d/wg-client would need a similar change.)



This function currently does not work from devices that are on VPN bypass list.
(adding the additional ipaddress to the wan interface only adds the corresponding route to table main, and not to table novpn.)

Solution would be to arrange that firewall-start-route_to_other_net.sh will change from:

#!/bin/sh
ip addr add 192.168.100.2/24 dev brwan 2>/dev/null
iptables -t nat -I POSTROUTING -o brwan -d 192.168.100.1/24 -j SNAT --to 192.168.100.2

to

#!/bin/sh
ip addr add 192.168.100.2/24 dev brwan 2>/dev/null
iptables -t nat -I POSTROUTING -o brwan -d 192.168.100.1/24 -j SNAT --to 192.168.100.2
if [ "$(nvram get kamoj_all_bypassing_off)" != "1" ]; then
     ip route add table novpn 192.168.100.0/24 dev brwan  proto kernel  scope link  src 192.168.100.2
fi

OR

#!/bin/sh
ip addr add 192.168.100.2/24 dev brwan 2>/dev/null
iptables -t nat -I POSTROUTING -o brwan -d 192.168.100.1/24 -j SNAT --to 192.168.100.2
if [ "$(nvram get kamoj_all_bypassing_off)" != "1" ]; then
     /usr/bin/addon_bypassvpnip.sh force no_netwall_restart
fi

 

[R. Gerrits]

(Do you know how to reverse (delete) the routing? I couldn't figure out how to do, so the pop-up says
it'll be enable until reboot. ;-) I know you know, you are so skilled and clever! )

to remove it, do ip addr del 192.168.100.2/24 dev brwan
(if the added IP was 192.168.100.1)
And remove the iptables rule.

I'm aware of that and if you try to activate it, you'll get a pop-up saying you have to off the VPN.

It does work when VPN is enabled. It only doesn't work in all cases on VPN bypassed devices.
(But if first the "Route To Other Net" is enabled, and later the VPN is started or restarted (and "No Killswitch for Bypass devices" is enabled) then it does also work on VPN bypassed devices.

 

[blueliner]

Hello,

I had some time to recreate the DNS port 53 being closed on my R9000 but I am not sure what to make of it. All works fine on Voxel 1.0.4.46 and 1.0.4.47 without Aegis or Kamoj Add-on installed. Here is what I tried:

1. First try. Installing and starting Aegis with only default blocklists - router DNS worked. Installing Kamoj 5.4b18 - router DNS works. Starting Kamoj DNSCrypt - router DNS works. Stopping DNSCrypt and modifying DNSCrypt server list, then restarting DNSCrypt - port 53 closes.
2. Reset router and reinstall firmware. Second try. All OK. Installed pre-modified dnscrypt-proxy-2.toml file (set up the same as my other two DNSCrypt v2.0.45 instances on Raspberry Pi's). Then I installed and started Aegis (without Add-on installed) - port 53 closes. This seems odd to me but I am sure I hadn't yet installed 5.4b18????
3. Third try. Reset router and reinstall firmware. Install and start Aegis....all is OK. Later I reinstalled 5.4b18 and installed a set of cloaking rules and modified the server list. Started DNSCrypt and sure enough, no port 53.
4. I made several other similar attempts and got the same results. I even tried erasing the Kamoj settings from nvram and unplugging the usb drive that mounts as /opt. The only thing consistent is any modification to the DNSCrypt files leads to port 53 closing once DNSCrypt is running (barring that one time it happened with Aegis running and I thought the Add-on was not yet installed)

Each time I lose port 53, I have to do a router reset and reinstall the firmware to get an open port again. Just doing one or the other will not fix it. And for some reason it only works if I reset via the reset button versus the console. I don't get it but every time I modify the dnscrypt-proxy-2.toml file I lose port 53. I am confused by all of this. On my other machines with the same version of DNSCrypt, I was able to modify files, add whitelists/blacklist/cloaking rules without a hitch. On the R9000 I am normally just using a whitelist...

Any thoughts or suggestions? I still don't know if this is a firmware issue, an add-on issue, an Aegis issue (I have not tried without Aegis but plan to when I can). Or maybe its just another in my long list of ME issues! I don't see anything out of the ordinary in any of the logs but would be happy to supply them, if I know what to send. Knowing me, I've probably just messed up or missed the obvious. I think I will just run without DNSCrypt on the router for now...the natives are getting restless while I have been fiddling with the router the past couple of days!

Thanks ,
BL

 

[kamoj]

1). How do you stop and start DNSCrypt?
2). Be aware that DNSCrypt is crazy picky about "spacing" - you must start each used line at exact correct position,
e.g. you can not start a line with a space or tab to format the text. Look in the log and see if that helps you.
3). Does it work if you use the add-on interface to change your preferred servers?

I had some time to recreate the DNS port 53 being closed on my R9000 but I am not sure what to make of it. All works fine on Voxel 1.0.4.46 and 1.0.4.47 without Aegis or Kamoj Add-on installed. Here is what I tried:
..
Stopping DNSCrypt and modifying DNSCrypt server list, then restarting DNSCrypt - port 53 closes.
..

 

[R. Gerrits]

I wonder, if port 53 no longer responds, is then dnsmasq still running??

ps |grep dnsmasq

Because if I recall correctly, with DNScrypt, it is still dnsmasq that should accept the dns traffic, and forward it to DNScrypt.
Perhaps also look at /var/log/dnsmasq.log ?

And how did you test that port 53 is closed? (or is that an assumption based on the fact that nslookups no longer work?)

 

[kamoj]

Changes in kamoj-addon beta version 5.4b19
--------------------------------------------------
- Updated to match Voxel's latest FW for R7800 (1.0.2.82.1SF) and R9000 (1.0.4.48HF)
- Settings: Route To Other Net (E.g. Modem in NAT Off/Bridge Mode):
Implemented (@R. Gerrits) improvements to get it working when VPN tunnel is used.
It doesn't work for my configuration/computer, but please try it and report back!
- OpenVPN Client: Changed "Connection Status" to "VPN tunnel Status"
- Wireguard Client: Changed "Connection Status" to "VPN tunnel Status"
- net-wall updated to add ip6 support (@HELLO_wORLD)
- net-wall updated with better error handling and logging
- OpenVPN Server: Adapted Voxel's latest changes
- OpenVPN Client: Allowed to run together with OpenVPN Server (@Voxel)
- DNSPrivacy/Ad-Blocking: Stubby: Differentiated logging level by Extended Logging option
- Minor changes

 

[blueliner]

1). How do you stop and start DNSCrypt?
2). Be aware that DNSCrypt is crazy picky about "spacing" - you must start each used line at exact correct position,
e.g. you can not start a line with a space or tab to format the text. Look in the log and see if that helps you.
3). Does it work if you use the add-on interface to change your preferred servers?

Hello,

Thanks for mentioning this.

I start/stop DNSCrypt from the Add-on radio buttons..

At first I tried copying over the toml file I use in my PiHoles (like I normally would do after a firmware update). I will double check my changes again. I also tried to change the server list in the toml file but got the same result. I normally don't use the server option of the Add-on (except to check that my custom server list loaded after upgrading the add-on). I did try it the last time but only after port 53 had closed.

I will start fresh and try it from the list!

Thank you,
BL

 

[blueliner]

I wonder, if port 53 no longer responds, is then dnsmasq still running??

ps |grep dnsmasq

Because if I recall correctly, with DNScrypt, it is still dnsmasq that should accept the dns traffic, and forward it to DNScrypt.
Perhaps also look at /var/log/dnsmasq.log ?

And how did you test that port 53 is closed? (or is that an assumption based on the fact that nslookups no longer work?)

R. Gerrits,

I was checking port 53 using nmap from another device. It would be open and dns calls to the router worked up until the time I would modify the dnscrypt config. That being said....Thank you for the advice as it lead me to the problem! It appears to have been related to dnsmasq as you suggested.

ps | grep showed it was running but the log was full of start/stops. I restarted dnsmasq and it gave an error for line 1 of the config file (and port remained closed). I didn't see anything wrong in dnsmasq.conf but the dnsmasq-resolv.conf file showed a leading space and "garbage" in the first line for some reason. I fixed that, rebooted and all is well!

R Gerrits and Kamoj, I am not well versed in the workings of computers and network devices. I very much appreciate the help and especially the details of how to check / change things!

Best wishes,
BL

 

[kamoj]

Changes in kamoj-addon beta version 5.4b20
--------------------------------------------------
- Settings: Added "Disable NSS Network SubSystem Acceleration" (R7800 only)
- System Information: Show if "NSS Network SubSystem Acceleration" is on or off (R7800 only)

 

[sppmaster]

Changes in kamoj-addon beta version 5.4b20
--------------------------------------------------
- Settings: Added "Disable NSS Network SubSystem Acceleration" (R7800 only)
- System Information: Show if "NSS Network SubSystem Acceleration" is on or off (R7800 only)

Why would anyone need to disable NSS Acceleration, I'm curious.