Beta Asuswrt-Merlin 3004.388.4 beta is now available

[maghuro]

Also noticed the same behaviour since alpha 388.4 alpha1 even if ddns_updated was set at 1.
I disabled custom ddns for now and changed to single server entry with no issues.

Single entry?

 

[shabbs]

I humbly apologize to @shabbs but I couldn't wait for his Let's GO!!!
12+hrs No Issues with router/lan/wan upgrading from alpha to beta.
My only upgrade issue is making sure I do not upload the rog version

LOL! I got caught off-guard with the Beta 1 drop. Pulled the trigger last night.

Upgraded all gear, recycles all done and so far all good here across the board. DDNS, VPN Director, DNS Director, IOT/Nest/TP-Link/Devices all happy, IPTV all good.

Speed test checks out as expected:

So far, so good...

As always, many thanks to @RMerlin and team. Great work!

Let's GO!

 

[spykos]

Single entry?

I changed from Custom in GUI to FREEDNS.AFRAID.ORG until custom issue is fixed.

 

[Striker317]

Upgraded my GT-AX6000 from 388.2_2 to 3004.388.4 beta1 and noticed that my ddns-start script now gets called non-stop, several times a minute. Definitely was not the case with 388.2_2. Everything else looks good.

I am seeing the same thing...

In my logs... (since install 6 hours ago, I'm getting this every 30 seconds)
This setup has worked well for many years...

Jul 28 07:31:08 watchdog: start ddns.
Jul 28 07:31:08 ddns: update CUSTOM , wan_unit 0
Jul 28 07:31:08 ddns: Clear ddns cache.
Jul 28 07:31:08 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:31:08 ddns: Completed custom ddns update
Jul 28 07:31:38 watchdog: start ddns.
Jul 28 07:31:38 ddns: update CUSTOM , wan_unit 0
Jul 28 07:31:38 ddns: Clear ddns cache.
Jul 28 07:31:38 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:31:38 ddns: Completed custom ddns update
Jul 28 07:32:08 watchdog: start ddns.
Jul 28 07:32:08 ddns: update CUSTOM , wan_unit 0
Jul 28 07:32:08 ddns: Clear ddns cache.
Jul 28 07:32:08 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:32:08 ddns: Completed custom ddns update
Jul 28 07:32:38 watchdog: start ddns.
Jul 28 07:32:38 ddns: update CUSTOM , wan_unit 0
Jul 28 07:32:38 ddns: Clear ddns cache.
Jul 28 07:32:38 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:32:38 ddns: Completed custom ddns update
Jul 28 07:33:08 watchdog: start ddns.
Jul 28 07:33:08 ddns: update CUSTOM , wan_unit 0
Jul 28 07:33:08 ddns: Clear ddns cache.
Jul 28 07:33:08 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:33:08 ddns: Completed custom ddns update
Jul 28 07:33:38 watchdog: start ddns.
Jul 28 07:33:38 ddns: update CUSTOM , wan_unit 0
Jul 28 07:33:38 ddns: Clear ddns cache.
Jul 28 07:33:38 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:33:38 ddns: Completed custom ddns update
Jul 28 07:34:08 watchdog: start ddns.
Jul 28 07:34:08 ddns: update CUSTOM , wan_unit 0
Jul 28 07:34:08 ddns: Clear ddns cache.
Jul 28 07:34:08 custom_script: Running /jffs/scripts/ddns-start (args: 142.188.123.xxx)
Jul 28 07:34:08 ddns: Completed custom ddns update



Here is my ddns-start file
#!/bin/sh
# Update the following variables:
# For more than one host, use space to separate hosts
HOSTS="home"
#HOSTS="hostname1 hostname2"
DOMAIN=customdomain.ca
PASSWORD=password

DNSOMATICUSERNAME=username
DNSOMATICPASSWORD=password
DNSOMATICHOSTNAME=all.dnsomatic.com

# Should be no need to modify anything beyond this point
IP=$1
STATUS=0
for HOSTNAME in $HOSTS; do
/usr/sbin/wget --no-check-certificate -qO - "https://dynamicdns.park-your-domain...NAME&domain=$DOMAIN&password=$PASSWORD&ip=$IP"
if [ $? -ne 0 ]; then
STATUS=1
fi
done

#/usr/sbin/curl -k -u "$DNSOMATICUSERNAME:$DNSOMATICPASSWORD" "https://updates.dnsomatic.com/nic/u...ME&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG&myip=" > /dev/null

if [ $STATUS -eq 0 ]; then
/sbin/ddns_custom_updated 1
else
/sbin/ddns_custom_updated 0
fi

 

[Quadcore]

I tried this firmware with my GT-AX6000, at the moment I have no particular problems. Speedtests aren't too bad.
Only the Log keeps displaying the following lines - strangely also the Alpha version displayed these lines at the beginning, but after a few minutes the problem has been solved.

Jul 28 14:38:20 rc_service: watchdog 2632:notify_rc stop_aae
Jul 28 14:38:20 rc_service: watchdog 2632:notify_rc start_mastiff
Jul 28 14:38:20 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 14:38:21 Mastiff: init

 

[Nagy Imre]

Jul 28 17:09:55 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:09:55 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:09:55 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:09:55 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:09:56 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:09:56 Mastiff: init
Jul 28 17:10:26 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:10:26 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:10:26 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:10:26 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:10:27 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:10:27 Mastiff: init
Jul 28 17:10:57 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:10:57 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:10:57 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:10:57 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:10:58 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:10:58 Mastiff: init
Jul 28 17:11:28 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:11:28 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:11:28 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:11:28 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:11:29 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:11:29 Mastiff: init
Jul 28 17:11:59 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:11:59 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:11:59 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:11:59 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:12:00 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:12:00 Mastiff: init
Jul 28 17:12:30 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:12:30 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:12:30 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:12:30 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:12:31 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:12:31 Mastiff: init
Jul 28 17:13:01 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:13:01 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:13:01 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:13:01 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:13:02 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:13:02 Mastiff: init
Jul 28 17:13:32 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:13:32 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:13:32 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:13:32 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:13:33 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:13:33 Mastiff: init
Jul 28 17:14:03 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:14:03 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:14:03 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:14:03 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:14:04 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:14:04 Mastiff: init
Jul 28 17:14:34 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:14:34 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:14:34 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:14:34 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:14:35 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:14:35 Mastiff: init
Jul 28 17:15:05 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:15:05 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:15:05 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:15:05 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:15:06 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:15:06 Mastiff: init
Jul 28 17:15:36 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:15:36 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:15:36 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:15:36 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:15:37 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:15:37 Mastiff: init
Jul 28 17:16:07 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:16:07 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:16:07 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:16:07 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:16:08 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:16:08 Mastiff: init
Jul 28 17:16:38 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:16:38 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:16:38 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:16:38 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:16:39 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:16:39 Mastiff: init
Jul 28 17:17:09 rc_service: watchdog 2947:notify_rc stop_aae
Jul 28 17:17:09 rc_service: watchdog 2947:notify_rc start_mastiff
Jul 28 17:17:09 rc_service: waitting "stop_aae" via watchdog ...
Jul 28 17:17:09 custom_script: Running /jffs/scripts/service-event-end (args: stop aae)
Jul 28 17:17:10 custom_script: Running /jffs/scripts/service-event-end (args: start mastiff)
Jul 28 17:17:10 Mastiff: init

I'm having this log entry spamming every minute or so.

what is the reason? how can i turn it off? @RMerlin THX

 

[karateca]

hi, i try this firmware but just haved 3 hours up, them stop to work, show the log, thx for the hard work. I have a aimesh with ax82u (stock firmware). Before was the ax11000 with the last stock firmware.

Jul 28 17:09:39 wlceventd: wlceventd_proc_event(685): eth7: Auth 46:5C:07:32:56:78, status: Successful (0), rssi:0
Jul 28 17:09:39 wlceventd: wlceventd_proc_event(722): eth7: Assoc 46:5C:07:32:56:78, status: Successful (0), rssi:-65
Jul 28 17:09:39 hostapd: eth7: STA 46:5c:07:32:56:78 IEEE 802.11: associated
Jul 28 17:09:39 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Jul 28 17:09:41 pppd[1424]: No response to 10 echo-requests
Jul 28 17:09:41 pppd[1424]: Serial link appears to be disconnected.
Jul 28 17:09:41 pppd[1424]: Connect time 205.3 minutes.
Jul 28 17:09:41 pppd[1424]: Sent 2219833875 bytes, received 4070006578 bytes.
Jul 28 17:09:41 lldpd[1327]: removal request for address of 87.235.0.10%27, but no knowledge of it
Jul 28 17:09:41 dnsmasq[1796]: read /etc/hosts - 22 names
Jul 28 17:09:41 dnsmasq[1796]: using nameserver 4.2.2.6#53
Jul 28 17:09:41 dnsmasq[1796]: using nameserver 66.28.0.45#53
Jul 28 17:09:41 dnsmasq[1796]: using nameserver 4.2.2.6#53
Jul 28 17:09:41 dnsmasq[1796]: using nameserver 66.28.0.45#53
Jul 28 17:09:43 hostapd: eth7: STA 46:5c:07:32:56:78 IEEE 802.11: disassociated
Jul 28 17:09:43 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind 46:5C:07:32:56:78, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-66
Jul 28 17:09:44 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind 46:5C:07:32:56:78, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 28 17:09:44 hostapd: eth7: STA 46:5c:07:32:56:78 IEEE 802.11: disassociated
Jul 28 17:09:44 WAN(0)_Connection: Fail to connect with some issues.
Jul 28 17:09:44 wlceventd: wlceventd_proc_event(685): eth6: Auth 36:A8:7C:BC:EC:1F, status: Successful (0), rssi:0
Jul 28 17:09:44 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: associated
Jul 28 17:09:44 wlceventd: wlceventd_proc_event(722): eth6: Assoc 36:A8:7C:BC:EC:1F, status: Successful (0), rssi:-60
Jul 28 17:09:44 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Jul 28 17:09:46 wlceventd: wlceventd_proc_event(685): eth6: Auth 00:7C:2D:27:FF:69, status: Successful (0), rssi:0
Jul 28 17:09:46 wlceventd: wlceventd_proc_event(722): eth6: Assoc 00:7C:2D:27:FF:69, status: Successful (0), rssi:-71
Jul 28 17:09:46 hostapd: eth6: STA 00:7c:2d:27:ff:69 IEEE 802.11: associated
Jul 28 17:09:46 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Jul 28 17:09:47 pppd[1424]: Connection terminated.
Jul 28 17:09:47 pppd[1424]: Sent PADT
Jul 28 17:09:47 pppd[1424]: Modem hangup
Jul 28 17:09:48 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: disassociated
Jul 28 17:09:48 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 36:A8:7C:BC:EC:1F, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-57
Jul 28 17:09:48 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 36:A8:7C:BC:EC:1F, status: 0, reason: Previous authentication no longer valid (2), rssi:-57
Jul 28 17:09:49 wlceventd: wlceventd_proc_event(685): eth7: Auth 46:5C:07:32:56:78, status: Successful (0), rssi:0
Jul 28 17:09:49 wlceventd: wlceventd_proc_event(722): eth7: Assoc 46:5C:07:32:56:78, status: Successful (0), rssi:-69
Jul 28 17:09:49 hostapd: eth7: STA 46:5c:07:32:56:78 IEEE 802.11: associated
Jul 28 17:09:49 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Jul 28 17:09:50 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 00:7C:2D:27:FF:69, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-71
Jul 28 17:09:50 hostapd: eth6: STA 00:7c:2d:27:ff:69 IEEE 802.11: disassociated
Jul 28 17:09:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 00:7C:2D:27:FF:69, status: 0, reason: Previous authentication no longer valid (2), rssi:-71
Jul 28 17:09:53 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind 46:5C:07:32:56:78, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-69
Jul 28 17:09:53 hostapd: eth7: STA 46:5c:07:32:56:78 IEEE 802.11: disassociated
Jul 28 17:09:53 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind 46:5C:07:32:56:78, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Jul 28 17:09:53 hostapd: eth7: STA 46:5c:07:32:56:78 IEEE 802.11: disassociated
Jul 28 17:09:53 dnsmasq-dhcp[1796]: DHCPREQUEST(br0) 192.168.0.218 36:a8:7c:bc:ec:1f
Jul 28 17:09:53 dnsmasq-dhcp[1796]: DHCPACK(br0) 192.168.0.218 36:a8:7c:bc:ec:1f
Jul 28 17:10:02 wlceventd: wlceventd_proc_event(685): eth6: Auth 00:7C:2D:27:FF:69, status: Successful (0), rssi:0
Jul 28 17:10:02 wlceventd: wlceventd_proc_event(722): eth6: Assoc 00:7C:2D:27:FF:69, status: Successful (0), rssi:-70
Jul 28 17:10:02 hostapd: eth6: STA 00:7c:2d:27:ff:69 IEEE 802.11: associated
Jul 28 17:10:02 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Jul 28 17:10:06 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 00:7C:2D:27:FF:69, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-66
Jul 28 17:10:06 hostapd: eth6: STA 00:7c:2d:27:ff:69 IEEE 802.11: disassociated
Jul 28 17:10:07 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 00:7C:2D:27:FF:69, status: 0, reason: Previous authentication no longer valid (2), rssi:-66
Jul 28 17:10:09 wlceventd: wlceventd_proc_event(685): eth6: Auth 36:A8:7C:BC:EC:1F, status: Successful (0), rssi:0
Jul 28 17:10:09 wlceventd: wlceventd_proc_event(695): eth6: ReAssoc 36:A8:7C:BC:EC:1F, status: Successful (0), rssi:-55
Jul 28 17:10:09 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: associated
Jul 28 17:10:09 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Jul 28 17:10:13 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 36:A8:7C:BC:EC:1F, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-50
Jul 28 17:10:13 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: disassociated
Jul 28 17:10:13 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 36:A8:7C:BC:EC:1F, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-50
Jul 28 17:10:13 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: disassociated
Jul 28 17:10:13 wlceventd: wlceventd_proc_event(662): eth6: Disassoc 36:A8:7C:BC:EC:1F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 28 17:10:13 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: disassociated
Jul 28 17:10:13 wlceventd: wlceventd_proc_event(662): eth6: Disassoc 36:A8:7C:BC:EC:1F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 28 17:10:13 hostapd: eth6: STA 36:a8:7c:bc:ec:1f IEEE 802.11: disassociated
Jul 28 17:10:13 roamast: [EXAP]Deauth old sta in 0 0: 36:A8:7C:BC:EC:1F
Jul 28 17:10:13 roamast: eth6: disconnect weak signal strength station [36:a8:7c:bc:ec:1f]
Jul 28 17:10:13 roamast: eth6: remove client [36:a8:7c:bc:ec:1f] from monitor list
Jul 28 17:10:14 dnsmasq-dhcp[1796]: DHCPREQUEST(br0) 192.168.0.218 36:a8:7c:bc:ec:1f
Jul 28 17:10:14 dnsmasq-dhcp[1796]: DHCPACK(br0) 192.168.0.218 36:a8:7c:bc:ec:1f
Jul 28 17:10:32 pppd[1424]: Timeout waiting for PADO packets

 

[RMerlin]

Thanks for the help and explanation.
nvram var has the value of 1, which is correct.

Regarding debug mode, I've reviewed the logs line by line and everything is correct. It returns a 200 OK https response, with no error attached.
It also compares my IP with the IP on that cloudflare hosted domain, and it sees that they both are the same.
Then, the nvram var is correctly populated with 1. Process completed, everything went fine, and then, after 30 seconds, ddns watchdog is called again.

@RMerlin I just sent you a pm (for the sake of private log content) with a pastebin link with the unfiltered logs. For me, everything's ok.

Not sure how that could be happening then. I'll have to review the watchdog code another time to see if I missed anything, maybe something else is clearing the variable, forcing the watchdog to re-run it again.

 

[RMerlin]

hi, i try this firmware but just haved 3 hours up, them stop to work, show the log, thx for the hard work.

Your PPPoE connection went down, and the router wasn't getting any reply from the ISP when trying to reconnect. Check your modem and your ISP.

 

[garysteel]

Installed on main xt12, all ok, then updated my other xt12 hard wired to main for backhaul but had problem with other devices connecting through this xt12… in the end reinstalled 388.2.2 on this xt12 and all worked again with devices via this connection…not sure if i missed a step setting this xt12 mode or something else but need to experiment but not while wife working!!thanks for updates ..

 

[maghuro]

Not sure how that could be happening then. I'll have to review the watchdog code another time to see if I missed anything, maybe something else is clearing the variable, forcing the watchdog to re-run it again.

I made a script to get the variable every 2 seconds. It is always populated with value "1", it never gets empty.
But yes, despite watchdog code hasn't been changed, probably is something related to it

 

[RMerlin]

But yes, despite watchdog code hasn't been changed, probably is something related to it

Asus made a few changes to it, but it's mostly related to IPv6 and Dual WAN support.

I've just configured a custom DDNS on a GT-AX6000, and so far I can't reproduce the issue. My custom DDNS updated itself 4 minutes ago, and hasn't been run again since.

Are you using any custom scripts? Dual WAN? IPv6?

 

[maghuro]

Asus made a few changes to it, but it's mostly related to IPv6 and Dual WAN support.

I've just configured a custom DDNS on a GT-AX6000, and so far I can't reproduce the issue. My custom DDNS updated itself 4 minutes ago, and hasn't been run again since.

Are you using any custom scripts? Dual WAN? IPv6?

Absolutely nothing. Both ipv6 and dual wan disabled.

I'm indeed using some custom scripts, but none of them related with ddns...

 

[RMerlin]

Absolutely nothing. Both ipv6 and dual wan disabled.

I'm indeed using some custom scripts, but none of them related with ddns...

I might have a lead.

What does this return?

nvram get ddns_last_wan_unit

If it's not 0, can you set it to 0, and see if the DDNS updates stop?

nvram set ddns_last_wan_unit=0

 

[maghuro]

I might have a lead.

What does this return?

nvram get ddns_last_wan_unit

If it's not 0, can you set it to 0, and see if the DDNS updates stop?

nvram set ddns_last_wan_unit=0

Found the culprit!! Good job.
It returns -1, and after set it to 0 it stops spamming.

What is that var related?

 

[RMerlin]

Found the culprit!! Good job.
It returns -1, and after set it to 0 it stops spamming.

What is that var related?

Asus dual WAN support in place for DDNS. The watchdog keeps track of which WAN unit was last updated. So if your router were to failover from unit 0 to unit 1, then it would trigger a DDNS update to get the current WAN IP updated from that second WAN interface.

The problem with custom DDNS mode is that this variable was never set, so the watchdog thought the current WAN interface had never been updated.

 

[maghuro]

Asus dual WAN support in place for DDNS. The watchdog keeps track of which WAN unit was last updated. So if your router were to failover from unit 0 to unit 1, then it would trigger a DDNS update to get the current WAN IP updated from that second WAN interface.

The problem with custom DDNS mode is that this variable was never set, so the watchdog thought the current WAN interface had never been updated.

Thanks for your patience and clarification.

Is a fix possible from your side (not closed source?) or it has to be made upstream?

 

[RMerlin]

Is a fix possible from your side (not closed source?) or it has to be made upstream?

Yes, it's just a matter of updating the ddns_custom_updated applet so it will also set that additional nvram.

rc: set ddns WAN unit variable on successful custom DDNS update · RMerl/asuswrt-merlin.ng@3a9f7a5

Prevents the watchdog from re-running the update, thinking it was never run on the current WAN unit.

github.com

 

[karateca]

Your PPPoE connection went down, and the router wasn't getting any reply from the ISP when trying to reconnect. Check your modem and your ISP.

its not isp cuz with stock firmware never go down, was the router up more then 30 days and was cuz i restard. I read this in other thread (

• It is extremely buggy firmware where mere changing and applying a setting renders whole UI unresponsive and internet goes down. Only comes online if router is rebooted.)

https://www.snbforums.com/threads/honest-review-of-asus-wrt-5-0-3-0-0-6-branch.86112/

 

[MDM]

its not isp cuz with stock firmware never go down, was the router up more then 30 days and was cuz i restard. I read this in other thread (

• It is extremely buggy firmware where mere changing and applying a setting renders whole UI unresponsive and internet goes down. Only comes online if router is rebooted.)

https://www.snbforums.com/threads/honest-review-of-asus-wrt-5-0-3-0-0-6-branch.86112/

Unplugg/plug/rebooted ISP router...?