Release Asuswrt-Merlin 3006.102.7 is now available

[RMerlin]

Now, will Asus do the same?

I already sent them the patch a few weeks ago, so expect it to be applied in a future stock release.

 

[Tim Storey]

Updated to 3006.102.7 from Beta, no problems.

 

[RogerSC]

Updated the RT-BE96U from 3006.102.6 to .7 earlier today, no factory reset. Looking just fine after several hours. My little network of routers are all doing well. Glad to have the bug fixes and updates you've provided, appreciate it.

Thanks!

 

[scootertramp]

Updated my RT-BE88U to 3006.102.7 from 3006.102.6 yesterday morning using the MerlinAU webUI interface
to initiate the upgrade process. So far all looks good.

 

[Ev0]

Very strange as I had issues with my BE92U with 3006.102.6 release and had to set it to reboot once a day, otherwise it would just drop the connection randomly, sometimes several times per day (I would have to toggle the internet connection off / on again in the gui to regain a connection).

3006.102.7 beta 1 has been stable for me, and I have since removed that reboot setting and it's not dropped the connection once.

I will upgrade to beta 2 and see how it goes.

 

[128bit]

a primarily seamless upgrade here, with a wrinkle. performing a rescan of the usb-3 attached ssd, forces a log off when it's ~55-60% complete. after logging back on, the scan appears to have successfully completed and even better, all the files are accessible! still, it's a new behavior!

fwiw, the ssd was detached/removed prior to the upgrade and not reinstalled until the mesh node got upgraded. also, when checked directly on the win 11 os, the 860 evo ssd shows no defects and that mirrors what the fw diagnostic reports. it has been solid for years and most recently on 3006.102.6.

 

[zer0bitz]

Updated yesterday and everything has been running smoothly.

 

[Deleted member 121779]

Ipv6 with controld still drops out after about 2 hours on my AXE16000 , my wan gateway shows blank when this happens . Does anyone have any idea why this happens no what the settings are set to? I have tried controld daemon and manual config as well as every setting possible on my endpoint and router

 

[Bob575]

Smooth, albeit dirty, upgrade to 3006_102.7 Release from alpha 2 on all supported devices. All is well with no known problems.
Many Thanks to @RMerlin and his contributors for their excellent product.

 

[ItspronouncedNuclear]

Dirty flash, 3006_102.6 -> .7, on BE7200/BE88u, smooth running

 

[jerry6]

2 days AX1100Pro running well no problems
Thanks for another easy update

 

[penguin22]

Not sure if this is the right place to continue this topic, though it does seem related with the current GPL, including what is used for this version. I have been having instability with only one of my two nodes (BE86U with issue, BE82U no issue). IoT devices most notably would consistently lose connection, often within a day, sometimes intermittent in either direction. This is fairly consistent across firmware versions, both Merlin or stock.

Yesterday, I saw a post with reported DHCP issue when using wired VLAN, so wondered if the wired VLAN config I use for a single IoT device on the BE86U could be causing the connection drops. I changed the VLAN back to All(Default) / Default and following the change have not had a single device go offline on any node. While this has only been 1 day, 8 hours, 20 minutes; I would have had devices dropping off by now on the latest stock firmware. I have a ticket open with Asus since the GPL is closed and will report to them as well should I find that this is causing the IoT stability issues. My desire is to be able to use the wired VLAN without impacting wireless IoT VLAN, so hoping this helps isolate the issue if it does prove to be the source of the instability.

 

[jksmurf]

I have a ticket open with Asus since the GPL is closed and will report to them as well should I find that this is causing the IoT stability issues. My desire is to be able to use the wired VLAN without impacting wireless IoT VLAN, so hoping this helps isolate the issue if it does prove to be the source of the instability.

Following this with great interest. Have two AiMesh nodes (RT-AX86U Pro’s) which I bought especially for the wired VLAN function, especially with IoT network on GNP; have wired ESP32s on both.

Have a separate thread with disconnect issues but never thought this could be related (wired affecting wireless).

 

[puket]

Good morning guys, I updated the firmware of my GT-BE19000AI to the latest version (3006.102.7) and it works very well except for a problem that I can't solve. When I try to install AdGuard Home I always get this error message: "Error: control/install/configure | checking address 192.168.1.200:3000: listen tcp 192.168.1.200:3000: bind: address already in use | 400". Let me start by saying that I have tried both adding and removing address reservations on the LAN but to no avail, it always gives me this error. Do you know how to kindly resolve it? I watched some videos about the procedure to follow and, even though I followed it correctly, I still have this problem. Could it be due to the firmware? I attach a PDF in which you can better understand the problem.

 

[Frostbite]

Upgraded main router and second router and so far so good.

 

[Poul Bak]

Upgraded main router and second router and so far so good.

That is rather useless unless you mention which routers you have. You could add it to your signature, then it's clear to everyone.

 

[jksmurf]

Not sure if this is the right place to continue this topic, though it does seem related with the current GPL, including what is used for this version. I have been having instability with only one of my two nodes (BE86U with issue, BE82U no issue). IoT devices most notably would consistently lose connection, often within a day, sometimes intermittent in either direction. This is fairly consistent across firmware versions, both Merlin or stock.

Yesterday, I saw a post with reported DHCP issue when using wired VLAN, so wondered if the wired VLAN config I use for a single IoT device on the BE86U could be causing the connection drops. I changed the VLAN back to All(Default) / Default and following the change have not had a single device go offline on any node. While this has only been 1 day, 8 hours, 20 minutes; I would have had devices dropping off by now on the latest stock firmware. I have a ticket open with Asus since the GPL is closed and will report to them as well should I find that this is causing the IoT stability issues. My desire is to be able to use the wired VLAN without impacting wireless IoT VLAN, so hoping this helps isolate the issue if it does prove to be the source of the instability.

The post referred to (thanks to @penguin22) is this one:

Guest network pro vlan with ethernet ports configured to anything than "All(default) - SDN Profile: default" main dhcp problem

This is a general query Is there anybody who succesfully configured a guess vlan setup where one of the ethernet port of the switch is not configured to vlan mode All(defaut). I have made tons of test on RT-AX86U Pro using a configuration like this and at some point, it will make me loose main...

www.snbforums.com

So an update from me on my observation above. In the past after every AiMesh System reboot, I had to go through a series of service restart_wireless (which often did not work) or individual node reboots to get IoT (GNP VLAN) devices that were actually CONNECTED (on first start) to those nodes based on the AiMesh Clientlist and the RSSI checks via ssh, but were not pingable nor accessible via their WebGui.

However after I changed, in the Main Router's LAN/VLAN page, the port from Access/IoTNetwork back to just All-Default (like @penguin22 did), on a System reboot (via the AiMesh menu) the devices on BOTH nodes came up straight away, were pingable and accessible. So I do not know if the issue is the same but @penguin22's observation seems to have merit for the observed behaviour in my (Merlin-only) system. Only sad that I cannot now have the Ethernet IoT devices on the LAN ports of the nodes ...

 

[penguin22]

The post referred to (thanks to @penguin22) is this one:

Guest network pro vlan with ethernet ports configured to anything than "All(default) - SDN Profile: default" main dhcp problem

This is a general query Is there anybody who succesfully configured a guess vlan setup where one of the ethernet port of the switch is not configured to vlan mode All(defaut). I have made tons of test on RT-AX86U Pro using a configuration like this and at some point, it will make me loose main...

www.snbforums.com

So an update from me on my observation above. In the past after every AiMesh System reboot, I had to go through a series of service restart_wireless (which often did not work) or individual node reboots to get IoT (GNP VLAN) devices that were actually CONNECTED (on first start) to those nodes based on the AiMesh Clientlist and the RSSI checks via ssh, but were not pingable nor accessible via their WebGui.

However after I changed, in the Main Router's LAN/VLAN page, the port from Access/IoTNetwork back to just All-Default (like @penguin22 did), on a System reboot (via the AiMesh menu) the devices on BOTH nodes came up straight away, were pingable and accessible. So I do not know if the issue is the same but @penguin22's observation seems to have merit for the observed behaviour in my (Merlin-only) system. Only sad that I cannot now have the Ethernet IoT devices on the LAN ports of the nodes ...

As an update, I am now squarely over 2 days without a single IoT device dropping wireless. I am more confident that wired VLAN configuration is a contributing factor to wireless GNP instability. I am certain that I would have experienced issues by this point, though will continue to monitor. This effectively set up my BE86U node to the same Mesh setup as the other BE82U that hasn't had any issues and doesn't support wired VLAN configurations.

 

[Salsoul]

dirty flash from 3006.102.7 beta 1 with my GT AX6000 got a strange issue happening randomly during the day and these logs appear,. I'm not sure if its the WAN or LAN, anyway to see which port Eth5 is mapped to? I. AS both my WAN port and LAN are set to 2.5gbps full duplex, it happens 2 or 3 times a day since flash, Im really not sure if this was apparent in Beta 1, maybe I just missed it in the logs.

Feb 25 15:39:47 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link DOWN.
Feb 25 15:39:47 kernel: ^[[0;34m[NTC xport] xport_reset: rc = 0; intf = 3 port = 2 spd = 2.5G dup = 1
Feb 25 15:39:47 kernel: ^[[0m
Feb 25 15:39:47 kernel: br0: port 5(eth5) entered disabled state
Feb 25 15:39:52 kernel: ^[[0;34m[NTC xport] xport_init: rc = 0; intf = 3 port = 2 spd = 2.5G dup = 1
Feb 25 15:39:52 kernel: ^[[0m
Feb 25 15:39:52 kernel: eth5 (Int switch port: 6) (Logical Port: 6) (phyId: 13) Link Up at 2500 mbps full duplex
Feb 25 15:39:52 kernel: br0: port 5(eth5) entered blocking state
Feb 25 15:39:52 kernel: br0: port 5(eth5) entered forwarding state

 

[Seth Harman]

As an update, I am now squarely over 2 days without a single IoT device dropping wireless. I am more confident that wired VLAN configuration is a contributing factor to wireless GNP instability. I am certain that I would have experienced issues by this point, though will continue to monitor. This effectively set up my BE86U node to the same Mesh setup as the other BE82U that hasn't had any issues and doesn't support wired VLAN configurations.

There's a few people here, myself included, who've used managed switches to put wired devices in a GNP VLAN because of AiMesh nodes that don't support wired VLAN tagging (only my main router can do that ). I can't speak for those other people but I have not experienced any client dropouts (wired or wireless) like what's being described, so I think that's solid evidence of it being something about the Asus hardware doing the wired tagging and not a result of having wired clients in the VLANs.