Menu
What's new
By:
Filters Better Search

Stubby-Installer-Asuswrt-Merlin

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

One more thing for the devs. Stubby creates the folder /opt/var/log if not found. However, the /log folder is created by default when installing Entware.
When uninstalling Stubby it states:
Code: 
Directory /opt/var/log found. Skipping deletion of directory as it may be used by other applications
You can manually delete /opt/var/log if not used by other applications
This is confusing and would break Diversion if deleted as it directs the dnsmasq.log* files to that location.
And again, the /log folder is part of Entware. Why even trying to delete it while Entware is installed?
 
I'm losing my internet connection several times a day.
I give the reboot command on stubby and the link goes online again.
Would the problem be in Stubby or Asuswrt?

Code: 
Feb  8 07:11:05 WLCEVENTD: wl0.1: Disassoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 WLCEVENTD: wl0.1: Assoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.34 68:c6:3a:a3:45:1a ESP_A3451A
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.9 30:9c:23:df:4e:4b
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.9 30:9c:23:df:4e:4b Ryzen
Feb  8 07:41:54 WLCEVENTD: eth5: Assoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 84:8e:0c:bf:e9:e4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:49:18 dropbear[9550]: Child connection from 192.168.10.9:63058
Feb  8 07:49:18 dropbear[9550]: Password auth succeeded for 'admin' from 192.168.10.9:63058
Feb  8 06:49:34 S61stubby: restart Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb  8 06:49:35 admin: Started stubby from .
 
thelonelycoder said:
One more thing for the devs. Stubby creates the folder /opt/var/log if not found. However, the /log folder is created by default when installing Entware.
When uninstalling Stubby it states:
Code: 
Directory /opt/var/log found. Skipping deletion of directory as it may be used by other applications
You can manually delete /opt/var/log if not used by other applications
This is confusing and would break Diversion if deleted as it directs the dnsmasq.log* files to that location.
And again, the /log folder is part of Entware. Why even trying to delete it while Entware is installed?
Click to expand...
Thanks for the heads up. I'll look into it in just a bit.

I probably added the check for the log file in an attempt to catch a situation where the log folder did not exist for some reason. But since entware is creating the log folder, removing the code to create the folder if it does not exists makes sense.

Looks like the check for removal can be removed and the message deleted.

Thanks for catching the messaging, etc..

EDIT: install_stubby.sh updated.
 
Last edited:
PoloNes said:
I'm losing my internet connection several times a day.
I give the reboot command on stubby and the link goes online again.
Would the problem be in Stubby or Asuswrt?

Code: 
Feb  8 07:11:05 WLCEVENTD: wl0.1: Disassoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 WLCEVENTD: wl0.1: Assoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.34 68:c6:3a:a3:45:1a ESP_A3451A
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.9 30:9c:23:df:4e:4b
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.9 30:9c:23:df:4e:4b Ryzen
Feb  8 07:41:54 WLCEVENTD: eth5: Assoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 84:8e:0c:bf:e9:e4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:49:18 dropbear[9550]: Child connection from 192.168.10.9:63058
Feb  8 07:49:18 dropbear[9550]: Password auth succeeded for 'admin' from 192.168.10.9:63058
Feb  8 06:49:34 S61stubby: restart Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb  8 06:49:35 admin: Started stubby from .
Click to expand...
I'm not sure from the log files messages.

You may want to uninstall Stubby and see if the outages still occur to determine if Stubby has a role in the issue. Or, when you do loose connection, run some of the debugging commands on the README.md page.
 
PoloNes said:
I'm losing my internet connection several times a day.
I give the reboot command on stubby and the link goes online again.
Would the problem be in Stubby or Asuswrt?

Code: 
Feb  8 07:11:05 WLCEVENTD: wl0.1: Disassoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 WLCEVENTD: wl0.1: Assoc 68:C6:3A:A3:45:1A
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.34 68:c6:3a:a3:45:1a
Feb  8 07:11:07 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.34 68:c6:3a:a3:45:1a ESP_A3451A
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:11:18 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.9 30:9c:23:df:4e:4b
Feb  8 07:28:08 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.9 30:9c:23:df:4e:4b Ryzen
Feb  8 07:41:54 WLCEVENTD: eth5: Assoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:54 WLCEVENTD: eth6: Disassoc 84:8E:0C:BF:E9:E4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPDISCOVER(br0) 84:8e:0c:bf:e9:e4
Feb  8 07:41:55 dnsmasq-dhcp[767]: DHCPOFFER(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb  8 07:41:56 dnsmasq-dhcp[767]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadMini
Feb  8 07:49:18 dropbear[9550]: Child connection from 192.168.10.9:63058
Feb  8 07:49:18 dropbear[9550]: Password auth succeeded for 'admin' from 192.168.10.9:63058
Feb  8 06:49:34 S61stubby: restart Stubby DNS over TLS /opt/etc/init.d/S61stubby
Feb  8 06:49:35 admin: Started stubby from .
Click to expand...
You may not be loosing the connection but Network Monitoring thinks you have lost connection. I have turned off Network Monitoring completely. You might set it to ping a known ip address such as a DNS server if you are on 384.9.

Sent from my SM-T380 using Tapatalk
 
thelonelycoder said:
Files in /jffs/scripts need a shebang and have the executable bit set. Those in /jffs/configs don't need those.
Both need to be saved with Unix type End of line (EOL).
Click to expand...
Thanks for this reply, I'll remember it presented this way. I run Linux as my main computer desktop and have used it for years, very comfortable with the CLI. I've just never been able to get a handle on scripting, so I appreciate what all of you script gurus offer. When I add or alter scripts in router, I use nano so EOL is correct and running chmod is second nature. Now that I understand the differences in locations of jffs files, that is a tremendous help to me.
 
Take what you have there and put it into a file called "nat-start" make sure to make it executable, and run dos2inix on it as well. That will work.
 
Xentrk said:
I'm not sure from the log files messages.

You may want to uninstall Stubby and see if the outages still occur to determine if Stubby has a role in the issue. Or, when you do loose connection, run some of the debugging commands on the README.md page.
Click to expand...

Following your advice I decided to do a clean installation of asuswrt-merlin.
The problem continues, the problem was not Stubby.

Feb 8 14:47:58 WLCEVENTD: eth5: Assoc F0:DB:F8:96:8E:23
Feb 8 14:47:59 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.79 f0:db:f8:96:8e:23
Feb 8 14:47:59 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.79 f0:db:f8:96:8e:23 iPhone
Feb 8 14:48:03 WLCEVENTD: eth5: Assoc 64:20:0C:59:DA:04
Feb 8 14:48:04 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.13 64:20:0c:59:da:04
Feb 8 14:48:04 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.13 64:20:0c:59:da:04 iPad
Feb 8 14:48:14 WLCEVENTD: eth6: Assoc D8:8F:76:42:7D:B7
Feb 8 14:48:14 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.21 d8:8f:76:42:7d:b7
Feb 8 14:48:14 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.21 d8:8f:76:42:7d:b7 iPhone
Feb 8 14:48:16 crond[776]: time disparity of 402463 minutes detected
Feb 8 14:49:05 WLCEVENTD: eth5: Assoc 84:8E:0C:BF:E9:E4
Feb 8 14:49:05 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb 8 14:49:05 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadmini
Feb 8 14:50:00 rc_service: service 2328:notify_rc restart_letsencrypt
Feb 8 14:50:09 WLCEVENTD: eth5: Disassoc 64:31:50:D1:FA:BE
Feb 8 14:56:53 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 14:56:57 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 14:56:57 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 14:56:57 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 14:56:57 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 14:56:57 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 14:57:40 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Feb 8 14:58:59 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 14:59:03 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 14:59:03 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 14:59:03 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 14:59:03 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 14:59:03 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 14:59:44 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 14:59:48 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 14:59:48 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 14:59:48 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 14:59:48 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 14:59:48 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:08:38 WLCEVENTD: eth6: Disassoc D8:8F:76:42:7D:B7
Feb 8 15:08:38 WLCEVENTD: eth6: Assoc D8:8F:76:42:7D:B7
Feb 8 15:08:38 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.21 d8:8f:76:42:7d:b7
Feb 8 15:08:38 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.21 d8:8f:76:42:7d:b7 iPhone
Feb 8 15:16:07 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 15:16:11 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 15:16:11 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 15:16:11 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:16:11 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:16:11 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:16:48 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 15:16:52 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 15:16:52 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 15:16:52 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:16:52 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:16:52 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:20:30 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 15:20:34 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 15:20:34 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 15:20:34 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:20:34 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:20:34 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:20:58 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 15:21:02 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 15:21:02 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 15:21:02 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:21:02 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:21:02 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:22:34 WLCEVENTD: eth6: Assoc 84:8E:0C:BF:E9:E4
Feb 8 15:22:34 WLCEVENTD: eth5: Disassoc 84:8E:0C:BF:E9:E4
Feb 8 15:22:34 WLCEVENTD: eth5: Disassoc 84:8E:0C:BF:E9:E4
Feb 8 15:22:35 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) 84:8e:0c:bf:e9:e4
Feb 8 15:22:35 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb 8 15:22:36 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb 8 15:22:36 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadmini
Feb 8 15:29:49 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb 8 15:29:49 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadmini
Feb 8 15:29:50 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.33 84:8e:0c:bf:e9:e4
Feb 8 15:29:50 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.33 84:8e:0c:bf:e9:e4 iPadmini
Feb 8 15:31:55 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 15:31:59 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 15:31:59 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 15:31:59 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:31:59 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:31:59 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:33:01 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb 8 15:33:04 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Feb 8 15:33:04 dnsmasq-dhcp[1909]: DHCPDISCOVER(br0) ec:fa:bc:8a:31:94
Feb 8 15:33:04 dnsmasq-dhcp[1909]: DHCPOFFER(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:33:04 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.100 ec:fa:bc:8a:31:94
Feb 8 15:33:04 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.100 ec:fa:bc:8a:31:94 ESP_8A3194
Feb 8 15:34:40 dnsmasq-dhcp[1909]: DHCPREQUEST(br0) 192.168.10.9 30:9c:23:df:4e:4b
Feb 8 15:34:40 dnsmasq-dhcp[1909]: DHCPACK(br0) 192.168.10.9 30:9c:23:df:4e:4b Ryzen
Click to expand...

bbunge said:
You may not be loosing the connection but Network Monitoring thinks you have lost connection. I have turned off Network Monitoring completely. You might set it to ping a known ip address such as a DNS server if you are on 384.9.

Sent from my SM-T380 using Tapatalk
Click to expand...

You are right, not really the loss of connection to the internet.
This problem of fimware drops the link and I stay for some time without connection.
I did a factory reset on the router.
I do not know how to solve this problem or what is causing the same.

Code: 
Feb  8 15:33:01 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb  8 15:33:04 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
 
PoloNes said:
I do not know how to solve this problem or what is causing the same.

Code: 
Feb  8 15:33:01 WLCEVENTD: wl0.1: Disassoc EC:FA:BC:8A:31:94
Feb  8 15:33:04 WLCEVENTD: wl0.1: Assoc EC:FA:BC:8A:31:94
Click to expand...
These are devices on your network going to sleep or waking up or calling home with data for the mothership. Might be harmless, might be a serious privacy / security breach. You should investigate first to make sure your networks is secure. Here is my take on it from the 384.9 release thread.
https://www.snbforums.com/threads/r...-9-is-now-available.54843/page-13#post-464560

If you want to play ostrich with your head in the sand, here is the way to clear them, but I strongly recommend to NOT do that.
https://www.snbforums.com/threads/r...-9-is-now-available.54843/page-14#post-464799

If you think this is not serious, please, please read this:
https://techcrunch.com/2019/02/06/iphone-session-replay-screenshots/
 
Last edited:
Butterfly Bones said:
If you want to play ostrich with your head in the sand, here is the way to clear them, but I strongly recommend to NOT do that.
https://www.snbforums.com/threads/r...-9-is-now-available.54843/page-14#post-464799
Click to expand...
That's a little harsh. You're assuming someone has the knowledge, time, and patience to go from "some device is waking up periodically and accessing the network" to "this specific program/device/whatever is accessing this specific IP and maybe passing along data you don't want to share". There's a LOT of steps in there and most people don't have enough of at least one of knowledge, time, or patience to track that down. Many of us install things like Skynet and Diversion expressly so we don't have to become experts in tracking down this stuff. I rely on people who know better to figure out what needs to be blocked.
 
Ralphort said:
Is this (below) the right way to put this nat-start script?

9ewxnHQ.png
Click to expand...
That will work. But what @thelonelycoder recommends as best practice, which I agree with, is to not include the lines in nat-start. Instead, call another script, just like is being done with IPSET_Netflix.sh. So, create a script called Redirect_DNS.sh and place the code there. Add the mandatory she-bang and make it executable. Then, add the lines sh /jffs/scripts/Redirect_DNS.sh to nat-start.sh.

I am doing some more analysis on this since the topic came up. I currently have duplicate entries

Code: 
# iptables -nvL PREROUTING -t nat --line
Chain PREROUTING (policy ACCEPT 2934 packets, 196K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     1934  105K VSERVER    all  --  *      *       0.0.0.0/0            180.183.200.186
2        0     0 VSERVER    all  --  *      *       0.0.0.0/0            169.254.81.53
3      406 27661 DNAT       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:my.ro.ip.ad
4        0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:my.ro.ip.ad
5        0     0 DNAT       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:my.ro.ip.ad
6        0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:my.ro.ip.ad

This can be avoided by adding the -D lines to the script (see example below):

/jffs/scripts/Redirect_DNS.sh
Code: 
#!/bin/sh
iptables -t nat -D PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" > /dev/null 2>&1
iptables -t nat -D PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" > /dev/null 2>&1

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

I'll update the README.md to include the -D lines.

EDIT: README.md updated to reflect above recommendation. For now, I left the location to call the script as firewall-start. I asked @Adamm and @Jack Yaz to chime in on the best script to invoke the rules from e.g. firewall-start vs. nat-start.
 
Last edited:
Xentrk said:
I am doing some more analysis on this since the topic came up. I currently have duplicate entries

Code: 
# iptables -nvL PREROUTING -t nat --line
Chain PREROUTING (policy ACCEPT 2934 packets, 196K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     1934  105K VSERVER    all  --  *      *       0.0.0.0/0            180.183.200.186
2        0     0 VSERVER    all  --  *      *       0.0.0.0/0            169.254.81.53
3      406 27661 DNAT       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:my.ro.ip.ad
4        0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:my.ro.ip.ad
5        0     0 DNAT       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:my.ro.ip.ad
6        0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:my.ro.ip.ad

This can be avoided by adding the -D lines to the script (see example below):

Code: 
iptables -t nat -D PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" > /dev/null 2>&1
iptables -t nat -D PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" > /dev/null 2>&1

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

I'll update the README.md to include the -D lines.
Click to expand...
Good catch @Xentrk !!
 
Code: 
Xentrk said: ↑
That will work. But what @thelonelycoder recommends as best practice, which I agree with, is to not include the lines in nat-start. Instead, call another script, just like is being done with IPSET_Netflix.sh. So, create a script called Redirect_DNS.sh and place the code there. Add the mandatory she-bang and make it executable. Then, add the lines sh /jffs/scripts/Redirect_DNS.sh to nat-start.sh.
Great idea, fixed on mine now.
 
cmkelley said:
That's a little harsh. You're assuming someone has the knowledge, time, and patience to go from "some device is waking up periodically and accessing the network" to "this specific program/device/whatever is accessing this specific IP and maybe passing along data you don't want to share". There's a LOT of steps in there and most people don't have enough of at least one of knowledge, time, or patience to track that down. Many of us install things like Skynet and Diversion expressly so we don't have to become experts in tracking down this stuff. I rely on people who know better to figure out what needs to be blocked.
Click to expand...
Ok, yeah maybe just a little. My reaction is to those who thing the Assoc (MAC) / Disassoc (MAC) is a bug to be squashed or just want it to go away without knowing what it is just because it is new in the syslog.

I tracked it down knowing what a MAC address is (hoping those running Merlin know too), reading the syslog, then looking at the DHCP Leases tab next to the General log (syslog), then searching Skynet for the IP of my network Associated MAC) address. For me, just knowing it was a Kindle and Google Home Mini gave me some idea, and alleviated the concern that something had penetrated past Skynet and AI Protection.
 
Xentrk said:
That will work. But what @thelonelycoder recommends as best practice, which I agree with, is to not include the lines in nat-start. Instead, call another script, just like is being done with IPSET_Netflix.sh. So, create a script called Redirect_DNS.sh and place the code there. Add the mandatory she-bang and make it executable. Then, add the lines sh /jffs/scripts/Redirect_DNS.sh to nat-start.sh.

I am doing some more analysis on this since the topic came up. I currently have duplicate entries

Code: 
# iptables -nvL PREROUTING -t nat --line
Chain PREROUTING (policy ACCEPT 2934 packets, 196K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     1934  105K VSERVER    all  --  *      *       0.0.0.0/0            180.183.200.186
2        0     0 VSERVER    all  --  *      *       0.0.0.0/0            169.254.81.53
3      406 27661 DNAT       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:my.ro.ip.ad
4        0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:my.ro.ip.ad
5        0     0 DNAT       udp  --  br0    *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 to:my.ro.ip.ad
6        0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 to:my.ro.ip.ad

This can be avoided by adding the -D lines to the script (see example below):

Code: 
iptables -t nat -D PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" > /dev/null 2>&1
iptables -t nat -D PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" > /dev/null 2>&1

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

I'll update the README.md to include the -D lines.

EDIT: README.md updated to reflect above recommendation. For now, I left the location to call the script as firewall-start. I asked @Adamm and @Jack Yaz to chime in on the best script to invoke the rules from e.g. firewall-start vs. nat-start.
Click to expand...
I just incorporated those suggestions into my scripts, thank you and thelonelycoder for all the information!
 
Butterfly Bones said:
Ok, yeah maybe just a little. My reaction is to those who thing the Assoc (MAC) / Disassoc (MAC) is a bug to be squashed or just want it to go away without knowing what it is just because it is new in the syslog.

I tracked it down knowing what a MAC address is (hoping those running Merlin know too), reading the syslog, then looking at the DHCP Leases tab next to the General log (syslog), then searching Skynet for the IP of my network Associated MAC) address. For me, just knowing it was a Kindle and Google Home Mini gave me some idea, and alleviated the concern that something had penetrated past Skynet and AI Protection.
Click to expand...
Herein lies the major pitfall of syslogd. Everything goes into the system log, so if something is flooding it, even legitimately, it becomes very difficult to notice anything that's out of the ordinary. Installing and setting up syslog-ng is a pain, but now the only thing I'm actively using sed to find and delete are the dcd crashes. I'd push those off into a crashes file if I could understand the syslog-ng documentation. 100's of pages of babble and useless "examples". I'm inclined to believe that's by design so you'll purchase the "pro" version and pay for support. I'm fairly certain multi-line-prefix and multi-line-suffix are they key, but damned if I can find an understandable explanation.
 
I've pushed v1.0.6

This update gives you a new option during the install process to automatically handle forcing clients DNS requests through Stubby.
 
Adamm said:
I've pushed v1.0.6

This update gives you a new option during the install process to automatically handle forcing clients DNS requests through Stubby.
Click to expand...
Would this precisely be the same functionality as Merlin GUI DNS-based Filtering in Global Filter Mode "Router"?
 
This is outstanding!! Thank you @Adamm !!;):)
 
You must log in or register to reply here.

Similar threads

RMerlin
Release Asuswrt-Merlin 3006.102.1 is now available for Wifi 7 devices
4 5 6
Replies
106
Views
16K
jksmurf
J
RMerlin
ANNOUNCEMENT: Asuswrt-Merlin support underway for 3 Wifi 7 routers
5 6 7
Replies
130
Views
26K
scasapending
S
DMcD-EMS-USMC
  • Locked
3006.102 alpha 2 Build(s) Now Available
Replies
2
Views
1K
octopus
octopus
octopus
  • Locked
[ 3006.102 alpha Build(s) ] Testing available build(s)
2 3
Replies
59
Views
11K
octopus
octopus
RMerlin
  • Locked
Beta Asuswrt-Merlin 3006.102.1 Beta is now available for WIfi 7 devices
3 4 5
Replies
97
Views
14K
RMerlin
RMerlin
Similar threads
Thread starter Title Forum Replies Date
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 23
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1
F Several Questions Re:Asuswrt-Merlin Feature Implementation Asuswrt-Merlin 2
Yota How to enable port randomization in Asuswrt-Merlin? Asuswrt-Merlin 4
RMerlin Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices Asuswrt-Merlin 70
J Does Asuswrt-Merlin support AiMesh over Wifi? Asuswrt-Merlin 4
Siff Printing from Guest Network (ASUSWRT-Merlin 3004.388.8_2) Asuswrt-Merlin 5
Siff Setting dnsmasq on Asuswrt-Merlin Asuswrt-Merlin 8
Rob Bowlby fwupdate.asuswrt-merlin.net - diversion.ch Down? Asuswrt-Merlin 7
R Wireguard on Asuswrt-Merlin Asuswrt-Merlin 11

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Members online

Total: 716 (members: 20, guests: 696)
Top