Release Asuswrt-Merlin 386.2 is now available

[hellboy2]

NTP still doesn't work with Asus_Merlin 386.2
It works with Asus 386.41994

My router is RT-AC68U in Repeater mode.

 

[dazedandlost]

Here to report a successful (after more or less the fifth try) dirty u/g from beta_1 to 386.2 a few minutes ago. I have seen no immediate problems.

A couple of observations, fwtmbw, but first, a huge thank you to Merlin and contributors for the firmware.

Sorted by using a different browser!

This (similar but different) happened, again, to me also but this time neither a different browser nor clearing cookies seemed to help.

What happened was that the browser hung indefinitely at the “please wait, Applying Settings...” dialog. So then I changed “Authentication Method” from https to both and tried the u/g again, and after a while got this (apologies if the screenshot is fouled up somehow, I'm not in the habit of doing this and I really don't know how - but I tried.)

Please note that it says the firmware u/g was unsuccessful but the progress bar shows it is upgrading anyway. After the u/g completed, the gui reported the 86u was still on beta_1. So I tried again, this time successfully – both the gui and amtm report the router on 386.2. Obviously, the key factor is the full moon at the same time as the cosmic ray bitflip event.

Btw, I notice that after a forced upgrade, the amtm check for update process shows on first run an “awm” option which gives the download link. Is it in the works to allow a f/w u/g via amtm? Sure would be nice, and maybe bypass the browser problems, if yes.

I would appreciate if someone would share, or point me to the link for, the ju-ju for doing a fw u/g from a terminal. Thanks in advance.

 

[pdc]

Updated the main router just fine, but the AiMesh node now has this log message repeating over and over. Zero search hits on google! Beta1 was just fine in this regard. I rebooted the mesh node, same behavior exists.

Any ideas? This is remote syslog via ui-scribe, AC86 x 2.

Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)

 

[MvW]

Here to report a successful (after more or less the fifth try) dirty u/g from beta_1 to 386.2 a few minutes ago. I have seen no immediate problems.

A couple of observations, fwtmbw, but first, a huge thank you to Merlin and contributors for the firmware.

This (similar but different) happened, again, to me also but this time neither a different browser no clearing cookies seemed to help.

What happened was that the browser hung indefinitely at the “please wait, Applying Settings...” dialog. So then I changed “Authentication Method” from https to both and tried the u/g again, and after a while got this (apologies if the screenshot is fouled up somehow, I'm not in the habit of doing this and I really don't know how - but I tried.)

View attachment 32758

Please note that it says the firmware u/g was unsuccessful but the progress bar shows it is upgrading anyway. After the u/g completed, the gui reported the 86u was still on beta_1. So I tried again, this time successfully – both the gui and amtm report the router on 386.2. Obviously, the key factor is the full moon at the same time as the cosmic ray bitflip event.

Btw, I notice that after a forced upgrade, the amtm check for update process shows on first run an “awm” option which gives the download link. Is it in the works to allow a f/w u/g via amtm? Sure would be nice, and maybe bypass the browser problems, if yes.

I would appreciate if someone would share, or point me to the link for, the ju-ju for doing a fw u/g from a terminal. Thanks in advance.

The progress bar continues, because it's performing a reboot but it has stopped performing an upgrade. Most of the time, in my case at least, it succeeds after giving it another try when it is done rebooting. If it still doesn't work, eject the USB drive, reboot and try again. Does the trick every time (but most of time I'm just too lazy to take out of the thumbdrive as my main router is on a cabinet and a wheelchair or similar aids don't go well to together to take routers of cabinets...)

 

[gattaca]

The progress bar continues, because it's performing a reboot but it has stopped performing an upgrade. Most of the time, in my case at least, it succeeds after giving it another try when it is done rebooting. If it still doesn't work, eject the USB drive, reboot and try again. Does the trick everytime (but most of time I'm just too lazy to take out of the thumbdrive as my main router is on a cabinet and a wheelchair or similar aids don't go wel to together to take routers of cabinets...)

You can usually eject ("Remove") the USB drive (main menu) without actually physically removing it. I think that's an @L&LD "upgrade" note.

 

[MvW]

You can usually eject ("Remove") the USB drive (main menu) without actually physically removing it. I think that's an @L&LD "upgrade" note.

That's good to know, thanks! I thought I knew @L&LD by heart now, but this suggestion I have apperently overseen. However, Eric recommends rebooting before upgrading, which means that the USB drive is auto mounted again. Is that solely for the same purpose, freeing up memory? Should I perform the upgrade before rebooting then? Does unmounting the USB drive and thus stopping all related processes, free up enough memory, to perform the upgrade?

Thanks in advance.

Best regards,
Marco

 

[Makaveli]

That's good to know, thanks! I thought I knew @L&LD by heart now, but this suggestion I have apperently overseen. However, Eric recommends rebooting before upgrading, which means that the USB drive is auto mounted again. Is that solely for the same purpose, freeing up memory? Should I perform the upgrade before rebooting then? Does unmounting the USB drive and thus stopping all related processes, free up enough memory, to perform the upgrade?

Thanks in advance.

Best regards,
Marco

unmounting the drive or unplugging the USB key is standard procedure before doing upgrades if you have issues doing it while plugged in, this hasn't really changed for years now. And yes it free's up resources and memory.

 

[gattaca]

^^^ @dazedandlost See this earlier thread where another person had firmware update troubles -> https://www.snbforums.com/threads/asuswrt-merlin-386-1-is-now-available.69783/page-55#post-663804

 

[MvW]

unmounting the drive or unplugging the USB key is standard procedure before doing upgrades if you have issues doing it while plugged in, this hasn't really changed for years now. And yes it free's up resources and memory.

Fully aware of that, my dearest @Makaveli . If you read carefully that was actually my advice to another user. What has change are my physical capabilities, as I'm disabled now, therefore physically removing the USB-drive has become a real PITA and not without risk. Therefore my question to @gattaca and @L&LD was: can I upgrade by just unmounting my USB drive prior to rebooting (which has also been recommended frequently to free up memory) and just leave the reboot to the upgrade process.

 

[brummygit]

I have 1 client (Honeywell Thermostat) which cannot connect to the ax86u after upgrading to 386_2.

This is what I see in the gui log of the router specific to the Honywell thermostat.
A quick google does not shed light on what this means.

Any assistance would be appreciated.

Apr  3 08:15:31 kernel: CONSOLE: 122906.030 wl1: wlc_txbf_delete_link_serve failed for b8:2c:a0:77:a6:b7
Apr  3 08:16:52 kernel: CONSOLE: 122986.910 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 5
Apr  3 08:16:56 kernel: CONSOLE: 122990.653 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 0
Apr  3 08:16:56 kernel: CONSOLE: 122990.654 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 0
Apr  3 08:16:57 kernel: CONSOLE: 122992.149 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 7
Apr  3 08:17:01 kernel: CONSOLE: 122996.179 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x2 tid 3
Apr  3 08:18:04 kernel: CONSOLE: 123058.271 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 4
Apr  3 08:18:04 kernel: CONSOLE: 123058.275 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 4

*** UPDATE 1 ***
I just found my main tv roku (4k model) is now not seeing the 5ghz wifi from the router either.
Show stopper for me so back to 386.1_2 where every client I have connects as expected.

Might be a long shot, but during the betas I had a similar issue with some of my devices which wouldn't connect to my AX86Us until I turned off universal beamforming.

 

[RMerlin]

yes. I sent an email to the address you posted in the other thread and referenced you.

Ok, thanks.

Just like for the HND platform, they're the ones in a position of eventually fixing this if there really is an issue.

 

[RMerlin]

NTP still doesn't work with Asus_Merlin 386.2
It works with Asus 386.41994

My router is RT-AC68U in Repeater mode.

Check your configuration, NTP worked fine for me when I tested it in repeater mode.

 

[pdc]

Updated the main router just fine, but the AiMesh node now has this log message repeating over and over. Zero search hits on google! Beta1 was just fine in this regard. I rebooted the mesh node, same behavior exists.

Any ideas? This is remote syslog via ui-scribe, AC86 x 2.

Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)
Apr  3 10:20:04 AC86U-OFFICE kernel: blog_request 1502: dev dpsta put_stats           (null)

Just FYI I reverted to beta1 and the messages are gone again. I might have some more time to mess with it tomorrow, might try a reset (it's just an AiMesh node, so I just have to copy my syslog script).

 

[Wishmaster1965]

Dirty flash to my mesh node RT-AC68 done and then then main RT-AC88U router , will monitor over the next few days.

Thanks to @RMerlin

 

[dcsang]

I have 1 client (Honeywell Thermostat) which cannot connect to the ax86u after upgrading to 386_2.

This is what I see in the gui log of the router specific to the Honywell thermostat.
A quick google does not shed light on what this means.

Any assistance would be appreciated.

Apr  3 08:15:31 kernel: CONSOLE: 122906.030 wl1: wlc_txbf_delete_link_serve failed for b8:2c:a0:77:a6:b7
Apr  3 08:16:52 kernel: CONSOLE: 122986.910 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 5
Apr  3 08:16:56 kernel: CONSOLE: 122990.653 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 0
Apr  3 08:16:56 kernel: CONSOLE: 122990.654 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 0
Apr  3 08:16:57 kernel: CONSOLE: 122992.149 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 7
Apr  3 08:17:01 kernel: CONSOLE: 122996.179 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x2 tid 3
Apr  3 08:18:04 kernel: CONSOLE: 123058.271 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 4
Apr  3 08:18:04 kernel: CONSOLE: 123058.275 wl1.0: wlc_send_bar: for b8:2c:a0:77:a6:b7 seq 0x1 tid 4

*** UPDATE 1 ***
I just found my main tv roku (4k model) is now not seeing the 5ghz wifi from the router either.
Show stopper for me so back to 386.1_2 where every client I have connects as expected.

I am also still working out periodic connectivity issues with specific clients and the guest network. I also installed YAZFI and moved my guest to network 3 as recommended.

Try disabling your 5GHz network temporarily to see if your Honeywell Thermostat will reconnect to the 2.4GHz network. The best solution I have found was to reduce the 5GHz TX Power down to Balanced. My Honeywell thermostat and Logitech Hub are now connected more reliably. I thought the thermostat connectivity was resolved with a previous beta but that didn't last.

I prefer being on the latest builds for security reasons, but trying to regain the stability I experienced with 384.19 and previous versions. I've never removed my flash drive for a firmware update, although it makes perfect sense to do so. Perhaps that will be my next step if I experience further issues.

 

[gattaca]

@MvW Affirmative. I follow @L&LD guide / path for fear of the huge rugged bottomless cliffs on either side! After my initial reboot, and waiting 10-15 mins to resettle, I log in, backup the JFFS, and router configs, then I "Remove" the USB drive from the GUI on the first page showing the USB drives. Only then do I upgrade the Merlin firmware. I cannot remember the last time I actually physically removed the USB drives.. (the 384.18/19 SNAFU excepted...).

 

[octopus]

Updated my two routers without any problem. Only thing is still there, "Two domain name in two places"
Uptime: 1 days 9 hour(s) 23 minute(s) 56 seconds

Thank you @RMerlin

 

[Zoomingrocket]

@RMerlin Can't figure this out, AC68U, any version of firmware I try is said to be uncertified and the upgrade fails. Doesn't matter if it's 384.19 or 386.2 it says both are not certified. Which I know is crap but how do I get by it, my other AC68U updated fine but it's a aimesh node, the one I'm trying to upgrade and failing at is wireless router mode. Any ideas besides firmware recovery tool?

Are you sure you downloaded AC68U firmware? I by mistake downloaded AX68U first which is the new router added with 386.2

I have two AC68U, main + aimesh node both dirty upgrade from 386.1 and clean reboots, no funky errors in sys log and all is stable

 

[Deleted member 22229]

Are you sure you downloaded AC68U firmware? I by mistake downloaded AX68U first which is the new router added with 386.2

I would almost bet that's the first thing he checked. Skeal has been around here for some time and knows basic trouble shooting.

 

[Morris]

Here to report a successful (after more or less the fifth try) dirty u/g from beta_1 to 386.2 a few minutes ago. I have seen no immediate problems.

A couple of observations, fwtmbw, but first, a huge thank you to Merlin and contributors for the firmware.

This (similar but different) happened, again, to me also but this time neither a different browser no clearing cookies seemed to help.

What happened was that the browser hung indefinitely at the “please wait, Applying Settings...” dialog. So then I changed “Authentication Method” from https to both and tried the u/g again, and after a while got this (apologies if the screenshot is fouled up somehow, I'm not in the habit of doing this and I really don't know how - but I tried.)

View attachment 32758

Please note that it says the firmware u/g was unsuccessful but the progress bar shows it is upgrading anyway. After the u/g completed, the gui reported the 86u was still on beta_1. So I tried again, this time successfully – both the gui and amtm report the router on 386.2. Obviously, the key factor is the full moon at the same time as the cosmic ray bitflip event.

Btw, I notice that after a forced upgrade, the amtm check for update process shows on first run an “awm” option which gives the download link. Is it in the works to allow a f/w u/g via amtm? Sure would be nice, and maybe bypass the browser problems, if yes.

I would appreciate if someone would share, or point me to the link for, the ju-ju for doing a fw u/g from a terminal. Thanks in advance.

Probably need a resource and the reboot that happened will have freed it up. I agree the messages could be better when the firmware load fails.

Just run it again from the GUI