Release Asuswrt-Merlin 386.1 is now available

[Howard_inGA]

Had loaded A2, but saw this latest final and installed that. I'd hoped it might address this weird glitch that surfaced in this iteration of the software (version 19 and previous remain immune). I installed 386.1.2 over the A2 with a dirty upgrade, since the full reset for this line had already been done.

Here is the writeup:

" Installed A2 from 384.19, after trying the latest stable release (386.1.1) with the same problem making a rollback necessary. In a nutshell, I am unable to access the cable modem url at http://192.168.100.1. The login box appears, as usual. On login, the Router (?) looses WAN?? The router goes into a reset, but the cable modem connection is steady throughout, with no drop in the signal.
The cable router is hard wired to the router, as usual, so no change there. With .19 software, modem access is rock solid as in all other firmware updates. Now, any attempt to access scrambles DHCP assignments, resets the router, and generally just crushes the system. Manual resets of the bridge and main router are the only workable solution...that, and not even trying to sign into my modem.
I followed all protocols for the update, but absolutely nothing seems to help."

I'd add that, otherwise, the 386 line seems really solid in these final releases.

 

[Kees17760]

It was addressed

Not in 386.1_2.
Still running +/- 10 degr. C hotter than 384.19 on my AC2900. When enabling "eee" it's a bit better, but still 5 degr. hotter

 

[ATLga]

Not in 386.1_2.
Still running +/- 10degr. C hotter than 384.19 on my AC2900

It’s addressed

Release - Asuswrt-Merlin 386.1 is now available

upgraded from b5 on ax88. no issues. thanks Merlin!!!

www.snbforums.com

I agree some are still seeing higher temps than they had before, but the original issue was reportedly solved.

 

[Kees17760]

It’s addressed

Release - Asuswrt-Merlin 386.1 is now available

upgraded from b5 on ax88. no issues. thanks Merlin!!!

www.snbforums.com

I agree some are still seeing higher temps than they had before, but the original issue was reportedly solved.

Yes, well let's call it partly addressed.
Some changes have been made to the code base, but as long as some people are still seeing a significant increase in temps, i can hardly call these changes succesfull. I could have enabled "wait_state" and "eee" myself, but it seems there's more to it.

 

[Lee MacMillan]

I sent my AX88U to repair by RMA, I've been using my old AC68U. Man this is one solid router, everything works really well under this release. Sure hope my AX88U comes back in good shape.

And this is why I'm reluctant to replace my AC66U_B1 with an AX model even though I'd like to have something more current. I'll probably do it eventually but I'll be breaking the "if it ain't broke, don't fix it" rule.

 

[barutchiev]

Anyone having issues with Chromecasts disappearing off the network? A few of mine go AWOL off the Google Home app, but are still visible in the network list on the router.

No problems with version 386.1_2.I use third generation Chromecast devices only at 5 GHz.

 

[torjohron]

Another reboot

Some of the log:

Feb 15 18:54:47 crond[1604]: time disparity of 1465249 minutes detected
Feb 15 18:54:59 kernel: wfd_registerdevice Successfully registered dev wds1.0.1 ifidx 1 wfd_idx 1
Feb 15 18:54:59 kernel: Register interface [wds1.0.1] MAC: d4:5d:64:d9:fb:1c
Feb 15 18:54:59 kernel: device wds1.0.1 entered promiscuous mode
Feb 15 18:54:59 kernel: br0: port 8(wds1.0.1) entered listening state
Feb 15 18:54:59 kernel: br0: port 8(wds1.0.1) entered listening state

Feb 15 18:55:52 kernel: wfd_unregisterdevice Successfully unregistered ifidx 1 wfd_idx 1
Feb 15 18:55:52 kernel: DROP IN=eth0 OUT= MAC=d4:5d:64:d9:fb:18:00:6c:bc:b9:10:19:08:00 SRC=86.5.150.185 DST=84.209.52.196 LEN=52 TOS=0x00 PREC=0x00 TTL=113 ID=36572 DF PROTO=TCP SPT=7352 DPT=26101 SEQ=3437510778 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402) MARK=0x8000000
Feb 15 18:55:52 lldpd[1036]: removal request for address of fe80::d65d:64ff:fed9:fb1c%22, but no knowledge of it
Feb 15 18:55:52 wlceventd: wlceventd_proc_event(507): eth6: Disassoc E0:3F:49:94:22:AC, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 15 18:55:52 kernel: br0: port 8(wds1.0.1) entered disabled state
Feb 15 18:55:52 kernel: device wds1.0.1 left promiscuous mode
Feb 15 18:55:52 kernel: br0: port 8(wds1.0.1) entered disabled state

 

[McStoobin]

I am having a heck of a time getting the new 386 codebase to run stable on a 1900P. I have tried both 386.1 and 386.1_2 and had to roll back to 384.19 in each case. The upgrade was done using a factory restore with the M&M procedure. I even tried the WPS NVRAM erase and nuclear reset to no avail.

The issue with 386.1 was that WiFi signal and internet connection would drop randomly for 2-3 minutes at a time -- this behavior started a few hours after the upgrade. With 386.1_2, the WiFi signal never dropped, but the internet connection had the same behavior as before which started to appear 2 days after the upgrade. When 386.1_2 was installed from 384.19, I let the router settle overnight before performing the factory restore with M&M to hopefully rule out any database upgrade issues. I only manually added the DNS settings that I was using on 384.19 and a handful of hosts to the manual DHCP client list which was stable through the weekend until this morning.

The logging settings were set to "default message log level = notice" and "log only messages more urgent than = debug". I couldn't find any error or warning messages in the logs.

I have been using merlin for several years now and never had any issues up until 386. Any recommendations on what I should try?

Thanks in advance for any advice.

 

[Jeffrey Young]

I am having a heck of a time getting the new 386 codebase to run stable on a 1900P. I have tried both 386.1 and 386.1_2 and had to roll back to 384.19 in each case. The upgrade was done using a factory restore with the M&M procedure. I even tried the WPS NVRAM erase and nuclear reset to no avail.

The issue with 386.1 was that WiFi signal and internet connection would drop randomly for 2-3 minutes at a time -- this behavior started a few hours after the upgrade. With 386.1_2, the WiFi signal never dropped, but the internet connection had the same behavior as before which started to appear 2 days after the upgrade. When 386.1_2 was installed from 384.19, I let the router settle overnight before performing the factory restore with M&M to hopefully rule out any database upgrade issues. I only manually added the DNS settings that I was using on 384.19 and a handful of hosts to the manual DHCP client list which was stable through the weekend until this morning.

The logging settings were set to "default message log level = notice" and "log only messages more urgent than = debug". I couldn't find any error or warning messages in the logs.

I have been using merlin for several years now and never had any issues up until 386. Any recommendations on what I should try?

Thanks in advance for any advice.

What do you mean by "factory restore"? You are not restoring from a saved backup file right?

 

[McStoobin]

What do you mean by "factory restore"? You are not restoring from a saved backup file right?

By factory restore I meant using the reset to factory defaults via the gui or via the reset button on the device. For the sake of testing the 386 updates I did not import any backed up settings. Instead I used the M&M procedures and also set DNS and manual DHCP client list by hand.

 

[Atomic7431]

Im still interested in the upnp and what changes it has had in the 386 releases. Upnp isnt working the same for me and im having to go back to 384.18 where it works flawlessly.
I have 3 pcs and 2 ps4 (kids) and on 384.18 i can get all devices to have an open nat connection with upnp no issue, but with 386 i am struggling to get more than 1 device with open nat.
I did mention it earlier in the thread but not really much info was provided.

I have tested this with Black ops cold war/warzone and destiny 2, if we all connect together on 386 branch i cant get open nat, but on 384.18 we all get open nat no issues.

 

[Slawek P]

AC66U_B1, since 384.19 and now 386.1_2 the web interfact to the router runs incredibly slow of often won't resolve. I've rebooted of course and tried from muliple devices, laptop, android 11 phone etc... The router is working, speeds are good and everything as you'd expect expect the web interface is basically unable to be access the majority of the time.

Anyone experienced this? Any solutuons? Thank

Only on Brave browser. Firefox or Chrome run fast.

 

[Slawek P]

Some of us ran into this huge DB during the prior 384.19 upgrades. We removed it without issues b/c it filling up the JFFS. This seems to be a good tip to substantially reduce the long wait times being reported until the GUI responds. I'm surprised no one else picked up on @Maksym posting. For the pros, any thoughts on making this an "if you can" recommended step for those with SSH access to the routers? From the GUI and JFFS format might also do it? Thoughts? Stay safe, stay alive!

Yes I deleted iit n the past and it gets revreated. It took 90 mins once for me nt_center to settle down. I personally do not understand why maintence of relatively small and pointless database takes so long. To me this is Asus non-performing code but @RMerlin finds it acceptable

 

[Slawek P]

IIRC, you need to enable IGMP snooping (Wireless --> Professional). This setting is per band, so set it on both to be safe. Not sure if those devices do both 2.4 and 5.

Yes and IGMP snooping is default setting after factory reset

 

[Slawek P]

My comment was quite a while ago, but I've been wondering off and on about this. I know nothing, really, about these cookies, collectively or individually: what specific trigger is responsible for setting them, what information they contain, how and by what and for what they are used, etc.

There sure are a bunch of them tho; 15 by my count. I am confident all of them are both necessary and innocent.

But the possibility hasn't been ruled out in my mind that, depending on a bunch of other things which I also know nothing about, there could be an explanation lurking in there somewhere as to why some people see fw u/g's succeed only after some number of attempts.

Going back to sleep now.

That is interesting. For me uograde works on second attempt. I will try clearing cookies

 

[jj22038]

I am having a heck of a time getting the new 386 codebase to run stable on a 1900P. I have tried both 386.1 and 386.1_2 and had to roll back to 384.19 in each case. The upgrade was done using a factory restore with the M&M procedure. I even tried the WPS NVRAM erase and nuclear reset to no avail.

The issue with 386.1 was that WiFi signal and internet connection would drop randomly for 2-3 minutes at a time -- this behavior started a few hours after the upgrade. With 386.1_2, the WiFi signal never dropped, but the internet connection had the same behavior as before which started to appear 2 days after the upgrade. When 386.1_2 was installed from 384.19, I let the router settle overnight before performing the factory restore with M&M to hopefully rule out any database upgrade issues. I only manually added the DNS settings that I was using on 384.19 and a handful of hosts to the manual DHCP client list which was stable through the weekend until this morning.

The logging settings were set to "default message log level = notice" and "log only messages more urgent than = debug". I couldn't find any error or warning messages in the logs.

I have been using merlin for several years now and never had any issues up until 386. Any recommendations on what I should try?

Thanks in advance for any advice.

My 1900P and AC68U on 386.1 are rock solid.
I had two problems with going to 386.1b4, both of which can be chalked up to PEBKAC. I recommend the following approach:
1) Read The Fine Manual, and do what it says
2) When that doesn't work, do a "nuclear" reset, and start at (1) again
3) When that doesn't work, wait until the next maintenance window (Saturday morning), and start at (1) again
4) When that doesn't work, realize Merlin's wisdom and stop using unsupported routers

Best wifi I've had in years. Thanks to Merlin, developers, and guinea pigs!

 

[RMerlin]

I installed 386.1.2 over the A2 with a dirty upgrade, since the full reset for this line had already been done.

You need to do a factory default reset after coming off an alpha build. There were various known issues with the alpha builds that will carry over if you don`t do so, such as an incorrect MTU value.

 

[alejandrofm1]

good. With 386.1 and 386.1_2 I have noticed that the traffic monitor now shows all the traffic that goes through the router. previously with 384.19 it only showed internet traffic. but not the Iptv. any more with this? i am using an ax88u

 

[Howard_inGA]

You need to do a factory default reset after coming off an alpha build. There were various known issues with the alpha builds that will carry over if you don`t do so, such as an incorrect MTU value.

Thanks, Merlin. I thought that there were minimal changes in the short lived A2 and the latest final. I'll try it and see if it addresses the problem...

 

[Rebs]

RT-AX88U: This is just an observation on 386.1_2 coming from the 384 codebase.

Relevant pre-upgrade configuration:

• I have a 2.4/5ghz network and then a guest 5 ghz network.
• I don't use the router for DHCP, clients get their IP address from a pi-hole server.
• Guest network *not* allowed access to Intranet
• The guest network was just using static IP addresses for now (based on the current IP scheme for the internal network).

Post upgrade:

• The internal network works fine and appears to be getting IP addy's from the PiHole server (validated the Router doesn't have DHCP enabled)
• Noticed guest network lost Internet connectivity. After disabling/re-enabling the guest radio, etc. I finally change the IP address on clients to be dynamic.
  • The guests started getting 192.x.x.x IP addresses. I'm assuming from the router, but the router has DHCP *disabled* and it's not using the IP address space or subnet I previously used on the router.

I still have more troubleshooting to perform, and I'll probably end up doing a factory reset, but this seems relatively curious.

P.S. I've also noticed a lot of "kernel: protocol 0800 is buggy, dev eth7" messages and I haven't changed the logging level..