What's new

Release Asuswrt-Merlin 386.1 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I upgraded my RT-AC88U from 384.19 to 386.1 last night. Everything is working fine, with the exception of the traffic analysis. Specifically the last 24, daily and monthly totals are off by a ridiculous amount. I’m talking it says I uploaded 17,179,869,185.07 GB.

The real-time measurement is correct, only the rstats values are sometimes measured incorrectly.

I’ve seen this problem in the past. It happened in 384.14_0 and was fixed in 384.14_2. Was this fix reverted somehow?

See https://www.snbforums.com/threads/r...2-are-now-available.60585/page-15#post-534147 and https://www.snbforums.com/threads/r...2-are-now-available.60585/page-27#post-537590

I don’t have Trend enabled and I haven’t given them permission so there’s nothing to withdraw.
1BF0850B-1440-4DC1-ABCB-E6AA13F03506.png

E21D9849-46EA-446C-9B74-9E5D3F97C4B8.png
 
Hi @all,

did an update from 384.17 (dirty) on AX88U. Planned to jffs format and full factory reset.

Unfortunately I am still waiting for the webUI to respond. Getting the logIn screen and type the creds. After signing in nothing happens. Update started 2h ago.

Should I "restart" the router via power switch or just chill?

Thanks!

Edit: Internet via LAN or WLan was back after 5min. But the router seems to very busy
 
Last edited:
Did a dirty upgrade of my AC86 from 384.19 - 386.1 after removing the USB drives. The only thing I had to do after the router rebooted was get the VPN clients working. Tried just restarting them but that was a no go. Ended up re-uploading the OVPN files. Not totally unanticipated based on all the changes made to various VPN functions.

Router is running warmer as noted by other posters. Currently at 81C.

Running speed tests on the router using spdMerlin v4.1.1 on my is showing my download speeds being 100 Mbps slower than before the upgrade. Actual speed from my ISP is the typical 480 Mbps I normally get and what spdMerlin was showing before. Hopefully when the router settles down after a few hours the speed tests will creep back up.

Thanks Merlin! Job well done.
 
Hi @all,

did an update from 384.17 (dirty) on AX88U. Planned to jffs format and full factory reset.

Unfortunately I am still waiting for the webUI to respond. Getting the logIn screen and type the creds. After signing in nothing happens. Update started 2h ago.

Should I "restart" the router via power switch or just chill?

Thanks!

Edit: Internet via LAN or WLan was back after 5min. But the router seems to very busy

Chill. I have seen reports as high as three hours.
 
Anybody having issues where iPhones just hang and you eventually get a “Safari could not open the page because the server stopped responding” message? Has only happened since 386.1. I’ve tried resetting network settings on the phones and I’ve done a full reset on both my router and node (AX88U and AX58U). When it happens it doesn’t matter what website I try I get the same message.

Seems to happen randomly but often enough to be very annoying. Nothing in the logs when it happens.
 
I upgraded my RT-AC88U from 384.19 to 386.1 last night. Everything is working fine, with the exception of the traffic analysis. Specifically the last 24, daily and monthly totals are off by a ridiculous amount. I’m talking it says I uploaded 17,179,869,185.07 GB.

The real-time measurement is correct, only the rstats values are sometimes measured incorrectly.

I’ve seen this problem in the past. It happened in 384.14_0 and was fixed in 384.14_2. Was this fix reverted somehow?

I checked the source code where it was fixed in the current source code and as far as I can tell the change that fixed the “traffic spikes” from 384.14_2 was reverted in 386.1.

Here’s where it was fixed.

Here’s the current code.

@RMerlin Was this fix accidentally reverted or am I looking at the wrong code? If it was reverted can it be fixed again since the traffic spikes are back.
 
@RMerlin -- Need some help. I was running 384.19 on my RT-AX88U in AP Mode rock solid for months. I upgraded to 386.1 and did a hard/WPS reset, reconfiguring from scratch. I noticed that my hard line kept being reported as "disconnected" from within the GUI. I would lose connectivity as well. If I disconnect/reconnect the ethernet cable, it'll register and work again. I had this issue multiple times.

I flashed back to 384.19, again using a hard/WPS reset to get stability for the family... hoping to try 386.1 later.

I'm experiencing the below "acsd // failed with -22" once a second. At one point, I lost WiFi for about 5 mins from that AP and things came back online again, but these errors are still persisting.

I'll raise my head and say "it's me" but would welcome any assistance. Settings? Try flashing again, then hard reset, configure and then soft reset?


Feb 1 13:34:42 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
Feb 1 13:34:43 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
Feb 1 13:34:44 WLCEVENTD: Auth 7E:24:F9:XX:XX:XX
Feb 1 13:34:44 WLCEVENTD: ReAssoc 7E:24:F9:XX:XX:XX
Feb 1 13:34:44 hostapd: eth7: STA 7e:24:f9:XX:XX:XX IEEE 802.11: associated
Feb 1 13:34:44 kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set
Feb 1 13:34:44 hostapd: eth7: STA 7e:24:f9:XX:XX:XX RADIUS: starting accounting session F9EB2FE89566B5E2
Feb 1 13:34:44 hostapd: eth7: STA 7e:24:f9:XX:XX:XX WPA: pairwise key handshake completed (RSN)
Feb 1 13:34:44 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
Feb 1 13:34:45 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
Feb 1 13:34:46 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
Feb 1 13:34:47 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
Feb 1 13:34:48 acsd: acs_update_oper_mode(290): eth6 read oper_mode failed with -22
 
Last edited:
Is the 'hardline' an Ethernet cable? Test with a different cable, for starters.
 
Hi,

Just updated to 386.1, RT-AC88U as AiMesh router + RT-AC88U as AiMesh node. I have three IPTV set top boxes (Movistar+), one connected to router and two connected to node. The one connected to router is working flawlessly, the other two are not working anymore (working before the upgrade). Those Movistar IPTV stb require IGMP snooping and VLAN Tagging.

I tried to enable emf as recommended here https://www.snbforums.com/threads/enable-igmp-snooping-while-on-ap-mode.43022/ , but it didn't work.

The other two, if connected directly to the router, are working flawlessly.

The other two, if I downgrade the node to 384.19, are working flawlessly.

I am wondering whether IGMP snooping is flawed in 386.1 / AiMesh 2.0.

Right now, the setup that is working for me, AiMesh router is 386.1 + AiMesh node is 384.19.

Another possible bug, when both are 386.1, is that rebooting the node from ssh seems to cause the router to reboot as well. The router doesn't reboot if the AiMesh node is 384.19. I have to test this thoroughly, as only noticed it by accident.

BR
 
Last edited:
AX58U, just completed direct upgrade from 384.19 and it looks good so far.

:)

Edit: Aimesh no longer has an icon next to it, and I think it did before. But that's about the only thing I see that could be even the smallest bit out of place so far

My Aimesh icon was missing for a bit too. Then it reappeared and hasn't gone away since.
 
Hi,

Just updated to 386.1, RT-AC88U as AiMesh router + RT-AC88U as AiMesh node. I have three IPTV set top boxes (Movistar+), one connected to router and two connected to node. The one connected to router is working flawlessly, the other two are not working anymore (working before the upgrade). Those Movistar IPTV stb require IGMP snooping and VLAN Tagging.

I tried to enable emf as recommended here https://www.snbforums.com/threads/enable-igmp-snooping-while-on-ap-mode.43022/ , but it didn't work.

The other two, if connected directly to the router, are working flawlessly.

The other two, if I downgrade the node to 384.19, are working flawlessly.

I am wondering whether IGMP snooping is flawed in 386.1 / AiMesh 2.0.

Right now, the setup that is working for me, AiMesh router is 386.1 + AiMesh node is 384.19.

Another possible bug, when both are 386.1, is that rebooting the node from ssh seems to cause the router to reboot as well. The router doesn't reboot if the AiMesh node is 384.19. I have to test this thoroughly, as only noticed it by accident.

BR

Hi, for what is worth, and in case it may help to determine exactly when this problem happens, I also have movistar IPTV stb connected to an imesh 2.0 node but in my case it is working flawlessly. My server is an AX88U (w/386.1 fw) and the node an AX56U (w/386.1 fw). The backhaul is cabled.
 
Chill. I have seen reports as high as three hours.

I have to ask and i don't mean this in a sarcastic way. Why in the heck would a router take 1,2,3 hours before the GUI would be accessible after a simple firmware flash ? Is this a fluke or something else. If this indeed the way it is then there is something flat out wrong with the software or something. Completely unacceptable in my opinion. Am i missing something here certainly not a issue with the AX58.
 
My take? Asus and RMerlin are giving us 'new' routers with the updated firmware. With new capabilities, more secure code, best/latest optimizations.

Even 'up to three hours' is still reasonable when the dollar cost is 'zero' and we get a much better router in the end?

As we saw with both RMerlin taking an extended break from the 384.xx code branch to the latest 386.1 (since August 14, 2020, when 384.19_0 was released, to be precise), Asus giving access to a public Beta on these very forums and even RMerlin's Beta's going to '5' before he was comfortable to release a final, 386.1 wasn't just a lot of new options, but a lot of work too.

Completely unacceptable? That is for you to decide.

But for me, completely understandable considering how some people treat their routers.

(No, they are not in a 'good/known state' when I first see them).
 
So far so good. Flawless, painless, quick upgrade from B5 via the Webgui, first the AIMESH nodes (2x AC5300's), then the AX88U.

Only odd ball and it's not a Merlin issue as AIMESH is closed source, is this one Nest Thermostat on the other side of the house on 5Ghz. With two Ethernet back haul AC5300's to the left and right of it, about 15/20ft away yet it continously connects to the AX88U on the complete other side of the house, 75/80ft away. Still works, still connects, and even forcing it to bind to any of the AIMESH nodes doesn't change the 3 bars its connected with in the Network Map/View clients.

But random question to every one, and seeing as the three devices are in relatively close proximity. Would adjusting "Tx power adjustment" have any bearing on signal strength?
 
@Jack Yaz's YazDHCP script? :)

(Why aren't you just using @Xentrk's though)?

A factory reset is hardly a multiday project. Take it methodically and thoroughly.
 
Even 'up to three hours' is still reasonable when the dollar cost is 'zero' and we get a much better router in the end?
My router took more than 15 hours to come out of post-upgrade coma and i am not complaining. Most likely because i have left drive with movies connected to the router during upgrade.
 
Upgraded from 386.1_Beta_5 to 386.1 in my AC86U with USB containing scripts(permy signature) mounted. It barely took 1 minute to flash and regain internet connection with all networks working(2.4 GHz, 5 GHz and Guest). Instantly got access to my WebGUI, temperature around 77 °C and all devices are performing as they should, with no complaints from my dear customers(family hahahahahah). So far, so great.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top