Beta Asuswrt-Merlin 3006.102.7 Beta is now available

[Aarlin303]

I get that message every time I install new firmware. Be96u
Same on my old Gt-Axe11000

 

[visortgw]

I noticed something I had not seen before. After the update completed on my BE88U, I received a message instructing me to manually reboot the router. That would be highly inconvenient and potentially problematic if I were performing the upgrade remotely. Requiring physical access after a firmware update defeats the purpose of remote management and could leave the device inaccessible until someone is on-site.

Is this a normal experience, or did something go wrong during the update?

Happens every once in a while when the update doesn't sense completion, but it is rarely necessary. When I see that, I typically log into router via ssh and reboot via amtm -- command is rn (for reboot now).

 

[aex.perez]

Just

I noticed something I had not seen before. After the update completed on my BE88U, I received a message instructing me to manually reboot the router. That would be highly inconvenient and potentially problematic if I were performing the upgrade remotely. Requiring physical access after a firmware update defeats the purpose of remote management and could leave the device inaccessible until someone is on-site.

Is this a normal experience, or did something go wrong during the update?

Been seeing this on the BE96u the last few FW upgrades as well. As my Spider is somewhat hidden, on a cabinet behind some moulding, I pull the power to restart. If doing remotely, it would be a headache.

 

[aex.perez]

Just dirty upgraded to the Beta, was a little slow starting everything back up and getting everything connected (and managed - via IoT apps) but eventually they all did and without assistance. But I will deal with that as my original problem got solved. Now if I enable the Guest Network profile (different SSID & subnet from Main or Custom) via the GUI, some the IoT devices on the Main or Custom profile (that are the same subnet) now successfully are able to renew their IP's. Assumed it was releated to MLO but all the devices connected final on the MLO/WiFi7 SSID WPA2/3 except the printer (expected, will move that to wired as I originally had it, only supports WPA but connects to WPA2 SSID)

Asus had reviewed my config/setup and confirmed I did it correctly, but also admitted they had problems in the FW and dnsmasq for the BE96u. Fortunately Merlins FW release cycle is a little more accelerated. I had tried several prior releases of Merlin and Asus FW, all had the same issue.

Got all three SSID's (and two subnets) running finally! Everything running smoothly so far, been 30 minutes, and bonus I didn't have to manually restart.

 

[Ripshod]

After a little over 24hrs the router rebooted itself - nothing in the logs so I'll be watching.

 

[Ripshod]

As my Spider is somewhat hidden, on a cabinet behind some moulding, I pull the power to restart

Simpler to just ssh in and enter

reboot

Only takes a few seconds.
Safer than just cutting the power.

 

[octopus]

I get this every 3rd second had to remove service-event-end file.

Feb  8 23:06:41 service-event-end: 10004 Start service-event-end running restart autowan
Feb  8 23:06:44 service-event-end: 10058 Start service-event-end running restart autowan
Feb  8 23:06:47 service-event-end: 10080 Start service-event-end running restart autowan
Feb  8 23:06:50 service-event-end: 10103 Start service-event-end running restart autowan
Feb  8 23:06:53 service-event-end: 10131 Start service-event-end running restart autowan
Feb  8 23:06:56 service-event-end: 10150 Start service-event-end running restart autowan
Feb  8 23:06:59 service-event-end: 10173 Start service-event-end running restart autowan
Feb  8 23:07:02 service-event-end: 10206 Start service-event-end running restart autowan
Feb  8 23:07:05 service-event-end: 10225 Start service-event-end running restart autowan
Feb  8 23:07:08 service-event-end: 10251 Start service-event-end running restart autowan
Feb  8 23:07:11 service-event-end: 10277 Start service-event-end running restart autowan
Feb  8 23:07:14 service-event-end: 10296 Start service-event-end running restart autowan
Feb  8 23:07:17 service-event-end: 10319 Start service-event-end running restart autowan

 

[bluepoint]

I noticed something I had not seen before. After the update completed on my BE88U, I received a message instructing me to manually reboot the router. That would be highly inconvenient and potentially problematic if I were performing the upgrade remotely. Requiring physical access after a firmware update defeats the purpose of remote management and could leave the device inaccessible until someone is on-site.

Is this a normal experience, or did something go wrong during the update?

It happens to me almost in every update since I use wireless 5Ghz connection to install. When I see that message to reboot manually, I just ignore it and wait until my connection is establish , 5Ghz connection needs time to establish its connection as the router scans the channels to check for interferences then eventually connection is established. The message will not show in remote connections(VPN) since the router completely reooted before it let you in.

 

[Aarlin303]

It happens to me almost in every update since I use wireless 5Ghz connection to install. When I see that message to reboot manually, I just ignore it and wait until my connection is establish , 5Ghz connection needs time to establish its connection as the router scans the channels to check for interferences then eventually connection is established. The message will not show in remote connections(VPN) since the router completely reooted before it let you in.

That explains why it happens to me

 

[CaptainLockness]

I noticed something I had not seen before. After the update completed on my BE88U, I received a message instructing me to manually reboot the router. That would be highly inconvenient and potentially problematic if I were performing the upgrade remotely. Requiring physical access after a firmware update defeats the purpose of remote management and could leave the device inaccessible until someone is on-site.

Is this a normal experience, or did something go wrong during the update?

i have the same message on my BE88U, also does remote management via ASUS App work on your end when you're on Data? I haven't been able to get it working on my end unless I'm directly connected to the Wi-Fi router itself.

 

[RMerlin]

The "Reboot manually" message gets automatically shown by the browser if after a specific wait time (120-180 secs, it varies by model) the router's web server isn't back online yet. The vast majority of the time you just need to give it another minute for it to finish rebooting and for your client to reestablish its network connection.

 

[ducky124]

Happens every once in a while when the update doesn't sense completion, but it is rarely necessary. When I see that, I typically log into router via ssh and reboot via amtm -- command is rn (for reboot now).

I don't know why I didn't think of using SSH

 

[JB_1366]

I noticed something I had not seen before. After the update completed on my BE88U, I received a message instructing me to manually reboot the router. That would be highly inconvenient and potentially problematic if I were performing the upgrade remotely. Requiring physical access after a firmware update defeats the purpose of remote management and could leave the device inaccessible until someone is on-site.

Is this a normal experience, or did something go wrong during the update?

Ive only ever seen this message when upgrading firmware through 5ghz wireless, i assume it takes time to bring back up wireless radios.When upgrading through ethernet, ive never seen it.

 

[RMerlin]

Dirty upgrade on by BE58_go from alpha 2 to beta1. The two options, "Enable local NTP server" and "Intercept NTP client requests" are available in both Router and WISP modes.

I can not update the "Trend Micro's Signature version" in either mode. I see the following two messages during the attempts before it fails.
Signature checking ...
Signature is updating ...

When I use the OEM firmware, it does update from version 1.100 to 1.149.

Thank you Merlin for all your hard work.

Signature update script was missing for models with the HNS engine. Fixed.

 

[TurnstileBlues]

86U-Pro, dirty flash from the alphas.
No issues at all.

Thank you, again, for the continued development

 

[octopus]

That's because you have Dual WAN set to "Autowan". I already silenced service-start events a few months back, I will also do the same thing for service-event-end. In the meantime, you could go to the Dual WAN page, and manually select the correct WAN port instead of leaving it on Autowan - it will be more optimal anyway.

I already set it to manually wan.

 

[RMerlin]

I get this every 3rd second had to remove service-event-end file.

Feb  8 23:06:41 service-event-end: 10004 Start service-event-end running restart autowan
Feb  8 23:06:44 service-event-end: 10058 Start service-event-end running restart autowan
Feb  8 23:06:47 service-event-end: 10080 Start service-event-end running restart autowan
Feb  8 23:06:50 service-event-end: 10103 Start service-event-end running restart autowan
Feb  8 23:06:53 service-event-end: 10131 Start service-event-end running restart autowan
Feb  8 23:06:56 service-event-end: 10150 Start service-event-end running restart autowan
Feb  8 23:06:59 service-event-end: 10173 Start service-event-end running restart autowan
Feb  8 23:07:02 service-event-end: 10206 Start service-event-end running restart autowan
Feb  8 23:07:05 service-event-end: 10225 Start service-event-end running restart autowan
Feb  8 23:07:08 service-event-end: 10251 Start service-event-end running restart autowan
Feb  8 23:07:11 service-event-end: 10277 Start service-event-end running restart autowan
Feb  8 23:07:14 service-event-end: 10296 Start service-event-end running restart autowan
Feb  8 23:07:17 service-event-end: 10319 Start service-event-end running restart autowan

Edit your service-event-end script and remove the commands that generate these log entries. The watchdog will generate autowan events every few seconds to check if there is any change to your WAN. The firmware itself already skips logging these events to avoid filling up the log, however the log entries you post here are not from the firmware but your script itself.

Otherwise, go to the Dual WAN page and change from AutoWAN to the actual WAN port that you use.

 

[Texasguy]

24+ hours rt-be92u dirty upgrade then factory reset do to access restrictions on two devices one wired, one wireless both IP addresses changed after Web UI reboot. Plus getting system info messages
Feb 9 16:02:52 kernel: CFG80211-ERROR) wl_cfg80211_change_station :
Feb 9 16:02:52 kernel: WLC_SCB_DEAUTHORIZE error (-30)
Even after factory reset

 

[octopus]

Edit your service-event-end script and remove the commands that generate these log entries. The watchdog will generate autowan events every few seconds to check if there is any change to your WAN. The firmware itself already skips logging these events to avoid filling up the log, however the log entries you post here are not from the firmware but your script itself.

Otherwise, go to the Dual WAN page and change from AutoWAN to the actual WAN port that you use.

I have removed everything in service-event-end and put it back again.
I has no more "running restart autowan" and WAN - Dual WAN0=> Basic Config => Primary WAN => 2.5G WAN/LAN-1

 

[Bob575]

Dirty flash of 3006_102.7_beta1 over alpha 2. Everything seems ok, but this morning I get this error message in my logs:

Feb 11 06:20:20 dnsmasq-dhcp[2705]: Working around kernel bug: faulty source address scope for VRF slave br0

Is this just a random glitch, or something that needs attention?