Release Asuswrt-Merlin 3004.388.6 is now available

[jeepr]

continuous loss of connection
what do these failures mean?
Jan 24 10:51:29 dnsmasq-dhcp[13479]: DHCPACK(br0) 192.168.50.33 10:d5:61:41:7f:f1 wlan0
Jan 24 10:51:29 dnsmasq-dhcp[13479]: DHCPREQUEST(br0) 192.168.50.33 10:d5:61:41:7f:f1
Jan 24 10:51:29 dnsmasq-dhcp[13479]: DHCPACK(br0) 192.168.50.33 10:d5:61:41:7f:f1 wlan0
Jan 24 10:53:06 ovpn-client1[991]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Jan 24 10:53:06 ovpn-client1[991]: VERIFY OK: depth=1, O=NordVPN, CN=NordVPN CA9
Jan 24 10:53:06 ovpn-client1[991]: VERIFY KU OK
Jan 24 10:53:06 ovpn-client1[991]: Validating certificate extended key usage
Jan 24 10:53:06 ovpn-client1[991]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan 24 10:53:06 ovpn-client1[991]: VERIFY EKU OK
Jan 24 10:53:06 ovpn-client1[991]: VERIFY X509NAME OK: CN=ca1648.nordvpn.com
Jan 24 10:53:06 ovpn-client1[991]: VERIFY OK: depth=0, CN=ca1648.nordvpn.com
Jan 24 10:53:06 ovpn-client1[991]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bits RSA, signature: RSA-SHA512, peer temporary key: 253 bits X25519
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xe832 (36/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xe832 (36/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xe832 (36/160)
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xe932 (40/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xe932 (40/160)
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xea32 (44/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xea32 (44/160)
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xeb32 (48/160)
Jan 24 11:05:43 dnsmasq-dhcp[13479]: DHCPREQUEST(br0) 192.168.50.185 00:09:b0:15:fc:53
Jan 24 11:05:43 dnsmasq-dhcp[13479]: DHCPACK(br0) 192.168.50.185 00:09:b0:15:fc:53 Onkyo-TX-NR686-EB754A

 

[ColinTaylor]

what do these failures mean?

They're all normal messages seen when the router boots up. They do not indicate a problem.

 

[jeepr]

They're all normal messages seen when the router boots up. They do not indicate a problem.

router was supposedly in a steady state
if that is a result of booting up
then the router is rebooting on its own
and
that's a problem

 

[ColinTaylor]

router was supposedly in a steady state
if that is a result of booting up
then the router is rebooting on its own
and
that's a problem

Without seeing the complete syslog we can't comment.

 

[jeepr]

Without seeing the complete syslog we can't comment.

 

[ColinTaylor]

@jeepr There's nothing particularly obvious in the logs. There may have been some VPN events around 08:10 and 08:58 in the morning. Overnight an Ethernet device connected to eth1 was flapping, but that might just be its normal standby behaviour. You'll probably need to change "Log only messages more urgent than" to "all" to get more useful information.

Is this something that's only started happening after installing this release? If not then it would be best to open a separate thread.

 

[MDM]

continuous loss of connection
what do these failures mean?
Jan 24 10:51:29 dnsmasq-dhcp[13479]: DHCPACK(br0) 192.168.50.33 10:d5:61:41:7f:f1 wlan0
Jan 24 10:51:29 dnsmasq-dhcp[13479]: DHCPREQUEST(br0) 192.168.50.33 10:d5:61:41:7f:f1
Jan 24 10:51:29 dnsmasq-dhcp[13479]: DHCPACK(br0) 192.168.50.33 10:d5:61:41:7f:f1 wlan0
Jan 24 10:53:06 ovpn-client1[991]: VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Jan 24 10:53:06 ovpn-client1[991]: VERIFY OK: depth=1, O=NordVPN, CN=NordVPN CA9
Jan 24 10:53:06 ovpn-client1[991]: VERIFY KU OK
Jan 24 10:53:06 ovpn-client1[991]: Validating certificate extended key usage
Jan 24 10:53:06 ovpn-client1[991]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jan 24 10:53:06 ovpn-client1[991]: VERIFY EKU OK
Jan 24 10:53:06 ovpn-client1[991]: VERIFY X509NAME OK: CN=ca1648.nordvpn.com
Jan 24 10:53:06 ovpn-client1[991]: VERIFY OK: depth=0, CN=ca1648.nordvpn.com
Jan 24 10:53:06 ovpn-client1[991]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bits RSA, signature: RSA-SHA512, peer temporary key: 253 bits X25519
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xe832 (36/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xe832 (36/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xe832 (36/160)
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xe932 (40/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xe932 (40/160)
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xea32 (44/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xea32 (44/160)
Jan 24 11:05:11 acsd: acs_candidate_score_intf(1112): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Jan 24 11:05:11 acsd: acs_candidate_score_bgnoise(1577): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Jan 24 11:05:11 acsd: acs_candidate_score_txop(1835): eth7: txop check failed for chanspec: 0xeb32 (48/160)
Jan 24 11:05:43 dnsmasq-dhcp[13479]: DHCPREQUEST(br0) 192.168.50.185 00:09:b0:15:fc:53
Jan 24 11:05:43 dnsmasq-dhcp[13479]: DHCPACK(br0) 192.168.50.185 00:09:b0:15:fc:53 Onkyo-TX-NR686-EB754A

I only see here a potential problem with 160MHz (Auto channel?) not sticking and dropping? If issue only on WiFI...

Thanks for the reply.

Are you saying I need to edit a config file or something to fix this? I am not an advanced user and have no idea how to do this. I have never edited or changed anything beyond whatever settings are visible in the router UI.

I guess I need to do a factory reset, which is too much bother, or wait for a future software version. 388.5 is working fine so I’ll stick to that for now.

All later FW will have same or newer GPL, with all the new changes ASUS made.
So do not hope for that.

 

[ColinTaylor]

I have never edited or changed anything beyond whatever settings are visible in the router UI.

Then it's unlikely to be the same problem. For that file to have been created you would have had to SSH into the router and install some addon scripts from the command line.

 

[gk802]

I had a similar problem during the beta, and again this morning when I tried to upgrade from 3004.388.5 to .6 - nothing seemed to be working, and (the clue was) nothing seemed to be able to resolve DNS addresses. Once I realized that hint, I went to the system log and found that DNSMASQ startup was failing with a bad line in the /etc/dnsmasq.conf file.

For me, the bad line was dns-forward-max=500 which I had added via /jffs/configs/dnsmasq.conf.add. It turns out that this latest release has added the dns-forward-max=1500 directive - dnsmasq won't accept duplicate entries (you have to edit these with /jffs/scripts/dnsmasq.postconf if you want to change an existing directive). Once I commented out my (newly duplicated) entry, I was able to upgrade to 3004.388.6 without problem.

Important note - it is surprising how many things in the router code depend on DNS running properly. Some are obvious: anything that needs to resolve an external name to work, e.g., DDNS, VPN connections, etc. Some less obvious - for example, ALL of my AIMesh nodes failed to reconnect when dnsmasq wasn't running properly. Also, I was unable to SSH into the router while DNSMASQ wasn't running (I had to downgrade to .5 so that I could comment out the offending entry in /jffs/configs/dnsmasq.conf)

So...check your system logs for a failed dnsmasq startup (or any other errors that aren't there when you boot up the 3004.388.5 release).

I saw a similar problem with the minidlna.conf file. The system-generated default version had a "log_dir=" line in it that was not there in the previous release. I had been redirecting the log file with a "pc_append" command in minidlna.postconf and that resulted in the conf file having two log_dir= lines. In the case of minidlna, the duplicated log_dir= line did not cause an issue, but I have since gone back into each of my postconf files to include a pc_delete option before the pc_append to make sure duplicate lines are not generated in the conf files.

 

[jeepr]

@jeepr There's nothing particularly obvious in the logs. There may have been some VPN events around 08:10 and 08:58 in the morning. Overnight an Ethernet device connected to eth1 was flapping, but that might just be its normal standby behaviour. You'll probably need to change "Log only messages more urgent than" to "all" to get more useful information.

Is this something that's only started happening after installing this release? If not then it would be best to open a separate thread.

yes

 

[jeepr]

yes

happening on ethernet connection

 

[ColinTaylor]

happening on ethernet connection

All ethernet connections or just one?

Reboot the router and post the new log if the problem reoccurs.

 

[128bit]

perhaps it's me but after reading so many reviews over the years, i often find that i'm confused on whether to upgrade or stay the course. has anyone thought about a rating system, 1-10 e.g., that summarizes the consensus view to upgrade?

before anyone starts throwing stones, i enquire because some may not realize the true size of this audience; and when i say true size, i'm referring to folks like me who viewed for years before taking the dive and opening an account. this site likely has a profoundly positive effect on asustek sales that may not be readily apparent. i'm still a believer even after one very unpleasant experience where i had to wait for the next release to be whole again.

 

[jeepr]

All ethernet connections or just one?

Reboot the router and post the new log if the problem reoccurs.

Did a hard reboot- turn off, remove power - just got disconnected on wifi
could not log in to router via wifi for a minute
here’s the log

 

[ColinTaylor]

Did a hard reboot- turn off, remove power - just got disconnected on wifi
could not log in to router via wifi for a minute
here’s the log

All ethernet connections or just one? I can see your VPN client reset briefly at 20:42 and you have a Shield routed through that. Otherwise I can't see any indication of any other disconnections at that time.

Maybe try turning off both of your VPN clients for a while and seeing if that makes a difference.

 

[aru]

I often rely on AI to quickly analyze potential issues in system logs. You can also give it a try.

The AI's response is as follows:

First log analysis:

1. Duplicate blog errors may affect business logic

2. Multiple VPN connections exist, need to check for authorization

3. Large WiFi device connections, may cause IP exhaustion

4. Unstable WiFi connections, likely signal or configuration issues

5. ACSD detected channel problems, need to adjust WiFi channels

6. Kernel FCACHE errors affect system performance

7. Suggest checking WiFi config, adjusting channels, inspecting VPN connections, checking IP pool, inspecting blog program, continuous monitoring of system

Second log analysis:

1. Device 60:01:94:df:8a:d1 obtained fixed IP

2. Device 24:62:ab:1a:85:49 trying to obtain dynamic IP

3. Duplicate DHCP requests exist in both

4. Duplicate requests may increase network overhead, affect performance

5. Excessive duplication may exhaust DHCP resources

6. Suggest optimizing DHCP client implementations to avoid duplicates

7. Can consider using DHCP Snooping etc to restrict

8. Expanding DHCP range may help alleviate issues

9. Logs themselves have no fatal issues, but duplicate requests are worth noting

In summary, the main issues are in WiFi connection quality, VPN connection monitoring, IP management, blog logic, DHCP optimization etc. Need to check configurations, tune programs, expand appropriately, and monitor continuously, to ensure stable system operation.

 

[SomeWhereOverTheRainBow]

I often rely on AI to quickly analyze potential issues in system logs. You can also give it a try.

View attachment 55938

The AI's response is as follows:

First log analysis:

1. Duplicate blog errors may affect business logic

2. Multiple VPN connections exist, need to check for authorization

3. Large WiFi device connections, may cause IP exhaustion

4. Unstable WiFi connections, likely signal or configuration issues

5. ACSD detected channel problems, need to adjust WiFi channels

6. Kernel FCACHE errors affect system performance

7. Suggest checking WiFi config, adjusting channels, inspecting VPN connections, checking IP pool, inspecting blog program, continuous monitoring of system

Second log analysis:

1. Device 60:01:94:df:8a:d1 obtained fixed IP

2. Device 24:62:ab:1a:85:49 trying to obtain dynamic IP

3. Duplicate DHCP requests exist in both

4. Duplicate requests may increase network overhead, affect performance

5. Excessive duplication may exhaust DHCP resources

6. Suggest optimizing DHCP client implementations to avoid duplicates

7. Can consider using DHCP Snooping etc to restrict

8. Expanding DHCP range may help alleviate issues

9. Logs themselves have no fatal issues, but duplicate requests are worth noting

In summary, the main issues are in WiFi connection quality, VPN connection monitoring, IP management, blog logic, DHCP optimization etc. Need to check configurations, tune programs, expand appropriately, and monitor continuously, to ensure stable system operation.

Welcome to free troubleshooting 101. Often those who work for IT companies now call their IT support who read steps like these for hours out of troubleshooting manuals. Similarly, this does not provide much more help.

 

[John Adler]

My router is working rock solid since the upgrade...

 

[laracroftonline]

Almost 5 days up without issues, so rock solid for me

 

[pavlfz]

Dirty upgrade from 388.5 on ax86u pro and five days without any issue for me! . Everything is working like a charm. Thanks very much Merlin