Release Asuswrt-Merlin 3004.388.8_2 is now available

[Funnyland123]

Hello, I have this firmware with my AX86U:

3004.388.8_1-g908dbf3334

Can someone tell me whether everything that is written in the system log is correct or whether something is wrong?


Jul 30 18:39:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f835300>^[[0m
Jul 30 18:39:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f835300> JOIN blog<0xffffffc02f892000>^[[0m
Jul 30 18:40:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f8417c0>^[[0m
Jul 30 18:40:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8417c0> JOIN blog<0xffffffc02f892000>^[[0m
Jul 30 18:40:42 dnsmasq-dhcp[9225]: DHCPREQUEST(br0) 192.168.50.130 e0:09:bf:6e:11:2b
Jul 30 18:40:42 dnsmasq-dhcp[9225]: DHCPACK(br0) 192.168.50.130 e0:09:bf:6e:11:2b WVCA63XE1EPSKQMQ
Jul 30 18:40:42 dnsmasq-dhcp[9225]: DHCPREQUEST(br0) 192.168.50.247 e0:09:bf:71:22:3f
Jul 30 18:40:42 dnsmasq-dhcp[9225]: DHCPACK(br0) 192.168.50.247 e0:09:bf:71:22:3f WVCA6GAWHZ0GNSFQ
Jul 30 18:41:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f842e40>^[[0m
Jul 30 18:41:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f842e40> JOIN blog<0xffffffc02f892000>^[[0m
Jul 30 18:42:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f841300>^[[0m
Jul 30 18:42:26 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f841300> JOIN blog<0xffffffc02f8417c0>^[[0m
Jul 30 18:43:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f835300>^[[0m
Jul 30 18:43:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f835300> JOIN blog<0xffffffc02f892000>^[[0m
Jul 30 18:44:23 dnsmasq-dhcp[9225]: DHCPDISCOVER(br0) 2c:f4:32:c2:49:34
Jul 30 18:44:23 dnsmasq-dhcp[9225]: DHCPOFFER(br0) 192.168.50.126 2c:f4:32:c2:49:34
Jul 30 18:44:25 dnsmasq-dhcp[9225]: DHCPREQUEST(br0) 192.168.50.126 2c:f4:32:c2:49:34
Jul 30 18:44:25 dnsmasq-dhcp[9225]: DHCPACK(br0) 192.168.50.126 2c:f4:32:c2:49:34 ESP_C24934
Jul 30 18:44:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f8764c0>^[[0m
Jul 30 18:44:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8764c0> JOIN blog<0xffffffc02f892000>^[[0m
Jul 30 18:45:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f8297c0>^[[0m
Jul 30 18:45:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8297c0> JOIN blog<0xffffffc02f85b7c0>^[[0m
Jul 30 18:46:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f8964c0>^[[0m
Jul 30 18:46:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8964c0> JOIN blog<0xffffffc02f85b7c0>^[[0m
Jul 30 18:47:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f8764c0>^[[0m
Jul 30 18:47:27 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8764c0> JOIN blog<0xffffffc02f842e40>^[[0m
Jul 30 18:47:55 dnsmasq-dhcp[9225]: DHCPDISCOVER(br0) 2c:f4:32:c2:a0:9e
Jul 30 18:47:55 dnsmasq-dhcp[9225]: DHCPOFFER(br0) 192.168.50.185 2c:f4:32:c2:a0:9e
Jul 30 18:48:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f828000>^[[0m
Jul 30 18:48:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f828000> JOIN blog<0xffffffc02f842e40>^[[0m
Jul 30 18:49:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f896e40>^[[0m
Jul 30 18:49:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f896e40> JOIN blog<0xffffffc02f842e40>^[[0m
Jul 30 18:50:26 dnsmasq-dhcp[9225]: DHCPDISCOVER(br0) 2c:f4:32:c2:49:34
Jul 30 18:50:26 dnsmasq-dhcp[9225]: DHCPOFFER(br0) 192.168.50.126 2c:f4:32:c2:49:34
Jul 30 18:50:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f8964c0>^[[0m
Jul 30 18:50:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f8964c0> JOIN blog<0xffffffc02f8417c0>^[[0m
Jul 30 18:50:28 dnsmasq-dhcp[9225]: DHCPREQUEST(br0) 192.168.50.126 2c:f4:32:c2:49:34
Jul 30 18:50:28 dnsmasq-dhcp[9225]: DHCPACK(br0) 192.168.50.126 2c:f4:32:c2:49:34 ESP_C24934
Jul 30 18:51:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f842e40>^[[0m
Jul 30 18:51:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f842e40> JOIN blog<0xffffffc02f84d300>^[[0m
Jul 30 18:52:16 dnsmasq-dhcp[9225]: DHCPDISCOVER(br0) 2c:f4:32:c2:a0:9e
Jul 30 18:52:16 dnsmasq-dhcp[9225]: DHCPOFFER(br0) 192.168.50.185 2c:f4:32:c2:a0:9e
Jul 30 18:52:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f84a4c0> JOIN blog<0xffffffc02f895300>^[[0m
Jul 30 18:52:28 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f895300> JOIN blog<0xffffffc02f84d300>^[[0m

 

[RMerlin]

Could that be the failure reason?

Yes. As indicated in the changelog, the killswitch will activate even if the user manually stops/disable the client. You have to disable the killswitch if you don't want it active.

 

[thatdoodle]

Hello,

I have found an issue where I am unable to completely disable the http webgui. If port is set to 80, webgui is not available over http but "netstat -tulpn" shows httpd bound to port 80. This prevents nginx from binding to port 80 and starting.

I have changed the port for http access in the webgui to an arbitrary port to free up 80 for nginx. However the webgui is now accessible via this port over a normal http connection instead of being restricted to https as the dropdown suggests.

 

[Aiadi]

Connection to a commercial wireguard as a client for the first time followed by setting VPN director to pass all IPs through that VPN results in a complete loss of internet access until the router is rebooted when everything starts to work properly following the reboot. Never had this issue with previous versions at all. Has anyone else noticed the same issue?

 

[eibgrad]

Hello,

I have found an issue where I am unable to completely disable the http webgui. If port is set to 80, webgui is not available over http but "netstat -tulpn" shows httpd bound to port 80. This prevents nginx from binding to port 80 and starting.

I have changed the port for http access in the webgui to an arbitrary port to free up 80 for nginx. However the webgui is now accessible via this port over a normal http connection instead of being restricted to https as the dropdown suggests.

@RMerlin

I can verify this too. Just tested it. Anything other than the default port 80 will result in binding the httpd server w/ http and that new port on the LAN side. I can't even fathom a good reason why that might be. Just seems to be a bug.

All I can recommend for the OP at the moment is blocking access to that port w/ the firewall using a firewall-start script.

iptables -I INPUT -i br+ -p tcp --dport $(nvram get http_lanport) -j REJECT

The following link illustrates how to create a firewall-start script.

Routing guest 1 clients thru vpn client tunnel while access intranet set to disable

Trying to route some devices on guest 1 thru vpn client, seems to work ok if i enable the acess intranet option, but obviously that defeats the purpose of trying to isolate guest 1 from lan. When i disable intranet acess, guest 1 drops the vpn tunnel. I tried adding 192.168.101.0/24 which is my...

www.snbforums.com

 

[RMerlin]

can verify this too. Just tested it. Anything other than the default port 80 will result in binding the httpd server w/ http and that new port on the LAN side. I can't even fathom a good reason why that might be. Just seems to be a bug.

This is by design, AFAIK. So error pages like Parental Blocking, Internet Down error page and so on can be displayed. It`s always been like that.

EDIT: also probably used by Let's Encrypt for validation purposes if you're not using Asus DDNS (which can do DNS-based validation).

 

[David Williams]

I upgraded to 3004.388.8 on my Asus RT-AX86U and since then I am not able to connect to my mesh devices to upgrade them. They are showing up on the network and clients are connecting to them but when I go to Administrator/Firmware Upgrade and click on the Manual Firmware update upload link it comes up on both mesh nodes with:

Hmmm… can't reach this page​

Here is a screenshot from the AIMesh screen:

As you can see, both are wired with great connection quality. I'm pretty sure this worked before upgrading to 388.8. I have rebooted the nodes and the main AX86U without success. The nodes are AC3100 and AC88U. Is anyone else seeing this? Any suggestions?

 

[eibgrad]

This is by design, AFAIK. So error pages like Parental Blocking, Internet Down error page and so on can be displayed. It`s always been like that.

EDIT: also probably used by Let's Encrypt for validation purposes if you're not using Asus DDNS (which can do DNS-based validation).

I could understand that rationale if http was always accessible. But it's NOT. When HTTPS is required on the LAN side, http is denied, so long as the default http port is 80. It only becomes available over http if you change port 80 to something else (e.g., 9999)! So something doesn't add up here. It still seems like a bug.

 

[dbell]

I upgraded to 3004.388.8 on my Asus RT-AX86U and since then I am not able to connect to my mesh devices to upgrade them. They are showing up on the network and clients are connecting to them but when I go to Administrator/Firmware Upgrade and click on the Manual Firmware update upload link it comes up on both mesh nodes with:

Hmmm… can't reach this page​

Here is a screenshot from the AIMesh screen:

View attachment 60659
As you can see, both are wired with great connection quality. I'm pretty sure this worked before upgrading to 388.8. I have rebooted the nodes and the main AX86U without success. The nodes are AC3100 and AC88U. Is anyone else seeing this? Any suggestions?

What is the URL of your router and then what is the url of the popup window when you try to upload to a node ? During the beta (IIRC-might have been alpha) I did see an issue where the node URL was not being constructed properly but it was ok since the actual release. I run a couple of AC5300 nodes; are your AC nodes running a pre-release or the 3004.386.14 release ?

 

[Aiadi]

Another very strange occurance today with a clean install of this version and that has never happened to me in the past is that the whole network went into a complete meltdown and ground to a halt with my Unifi Access Point reporting that two clients were assigned the same IP address by a rogue DHCP server! GT-AX6000 repoot was required before things started to work normall again.

 

[jass]

I upgraded to 3004.388.8 on my Asus RT-AX86U and since then I am not able to connect to my mesh devices to upgrade them. They are showing up on the network and clients are connecting to them but when I go to Administrator/Firmware Upgrade and click on the Manual Firmware update upload link it comes up on both mesh nodes with:

Hmmm… can't reach this page​

Here is a screenshot from the AIMesh screen:

View attachment 60659
As you can see, both are wired with great connection quality. I'm pretty sure this worked before upgrading to 388.8. I have rebooted the nodes and the main AX86U without success. The nodes are AC3100 and AC88U. Is anyone else seeing this? Any suggestions?

I've experienced the same with a couple of ac88 on 386.13, not being able to log on too the nodes. Everything else seemed to work fine.

Just restart the nodes by pulling the power cord made everything work again for me.

I also think it's recomended to upgrade the nodes before upgrading the router/main node

 

[David Williams]

What is the URL of your router and then what is the url of the popup window when you try to upload to a node ? During the beta (IIRC-might have been alpha) I did see an issue where the node URL was not being constructed properly but it was ok since the actual release. I run a couple of AC5300 nodes; are your AC nodes running a pre-release or the 3004.386.14 release ?

The URL of the router is http://172.16.1.1 the URL's of the nodes are http://172.16.1.85/AiMesh_Node_FirmwareUpgrade.asp and http://172.16.1.15/AiMesh_Node_FirmwareUpgrade.asp. The nodes are running 3004.386.13 which I believe was the last non-beta release before 3000.386.14 was released.

 

[David Williams]

I've experienced the same with a couple of ac88 on 386.13, not being able to log on too the nodes. Everything else seemed to work fine.

Just restart the nodes by pulling the power cord made everything work again for me.

I also think it's recomended to upgrade the nodes before upgrading the router/main node

I'll try the power plug. I know I have rebooted them a couple of times. If the nodes are on a completely different code base, ie 3004.386.13 why would you need to upgrade them before upgrading the main router which is on 3004.388.8 builds. I thought that the two code based were completely separate from each other?

 

[David Williams]

I'll try the power plug. I know I have rebooted them a couple of times. If the nodes are on a completely different code base, ie 3004.386.13 why would you need to upgrade them before upgrading the main router which is on 3004.388.8 builds. I thought that the two code based were completely separate from each other?

I tried the power plug disconnect without success. If I try to SSH into the nodes that works fine so I know the IP addresses are correct.

 

[dbell]

The URL of the router is http://172.16.1.1 the URL's of the nodes are http://172.16.1.85/AiMesh_Node_FirmwareUpgrade.asp and http://172.16.1.15/AiMesh_Node_FirmwareUpgrade.asp. The nodes are running 3004.386.13 which I believe was the last non-beta release before 3000.386.14 was released.

They seem fine.
I access my router over https:// but then had to use http:// for the nodes when I had my issue, but as I said the regular https:// links worked again after the release update.
What happens if you just enter the node URL directly in browser rather than clicking Upload button ? You should get login page and then a full page version of the upload UI.
Also try clearing browser cache and cookies.

 

[David Williams]

They seem fine.
I access my router over https:// but then had to use http:// for the nodes when I had my issue, but as I said the regular https:// links worked again after the release update.
What happens if you just enter the node URL directly in browser rather than clicking Upload button ? You should get login page and then a full page version of the upload UI.
Also try clearing browser cache and cookies.

Clearing cache and cookies worked. Thank you for your help.

 

[thatdoodle]

I could understand that rationale if http was always accessible. But it's NOT. When HTTPS is required on the LAN side, http is denied, so long as the default http port is 80. It only becomes available over http if you change port 80 to something else (e.g., 9999)! So something doesn't add up here. It still seems like a bug.

Thanks for the line in the previous post, can confirm http access is now blocked after re-running the firewall-start script.

I agree this seems like a bug. I'm sure I was able to run nginx freely in the past after setting webui access to https only without requiring further configuration. Will have to roll back and check.

 

[RMerlin]

Version 3004.388.8_2 is now available.

3004.388.8_2 (31-July-2024)
  - UPDATED: OpenVPN to 2.6.12.
  - CHANGED: Support importing WiregUard config files that
             contain multiple AllowedIPs, Address or DNS
              declarations.
  - FIXED: OpenVPN client routing not working properly when
           configuring Internet redirection to "All" or "None".
  - FIXED: New firmware check button missing for the RT-AX58U.
  - FIXED: Generated web certificate wasn't using the FQDN
           for Namecheap DDNS users.

 

[MDM]

Minor update - All good!

 

[128bit]

dirty upgrade from v...388.8 which worked fine for my somewhat simple configuration. 8_2 just got installed. the mesh is still meshing and i'm connected to a nord tunnel. that said, i have not enabled any vpn director client to actually use the tunnel but don't anticipate a problem.

many thanks to our marvelous wizard - it's magical how he's able to do so very much!