What's new

Beta Asuswrt-Merlin 386.1 Beta (stage 2) 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.
Tried all the above.

Although given the abuse it had it likely was wearing out anyway. For a year it was running a restaurant and took far more abuse they it was meant to so it was likely time for a upgrade and all mess with it given time and who knows maybe it can be brought back to life.
For rescue mode, one thing that I noticed. If you have any other network interface (real or virtual) on, just enabled (My PC has integrated WiFi and a few virtual adapters VMware/HyperV) then the rescue utility won't find the router in rescue mode. I've had to disable each interface, other than the one I'm using for the rescue from control panel (Windows 10) and only then will the utility find the router in rescue mode (having done everything else correctly). Drove me nuts with all the Asus 386 RC10/ AX88U 386 B4, B4b scenarios until I figured it out. Not saying that's your issue but something to consider trying as well.
 
I don't think it is directly from @RMerlin branch, but AiMesh 2.0 and Smart Connect seems to have some problems in routing clients to proper nodes/bands. I have ac-3100 as main and a ac-86u as mesh node. I had Smart Connect enabled since beginning and with old 384 code all my devices were happy.

Since going to beta 5, my kids Chromebook started acting crazy, even though its next to ac3100 it will try to connect to upstairs 86u and says "medium signal strength" and it can't even access internet. Nothing in the logs that I can correlate.

Turning off mesh node gets everything back online. Today I tried turning off the smart connect, and so far things are okay even with mesh node ON.
Thought I was the only one seeing this. Under B4B I had the roaming assistant cofigured to help steer clients around if their rssi got too low. Its as if that's being ignored now in B5. Often going from one side of the house to the other I need to cycle the Wifi conection on the device (off/on) to get it work 100%. I'm not completely sure what's at fault as I can see the roaming, drop, connect in the log and I can still get to the webgui (local LAN) but until I cycle the wifi there is no internet access (WAN), which would imply something else. Doesn't happen consistently, and nothing in the logs so hard to pin down.

This is one of the things I'll be monitoring as I start fresh with B5 this weekend...
 
So, I’ve been running the new Beta 5 for several days now. These are the problems I’m encountering after a full reset/clean install on my AC RT5300:

First serious problem is constant disconnects of my NAS network adapter every hour (or 2 at the most). This runs through the 3200 set as a media bridge connecting through the 5300.

My brand new Acer laptop with an AX wifi adapter has lost 2/3’s of its speed while connected to the 5G wifi (160mbps max). In testing it, I held my Samsung S20 right beside the laptop, and it tested at full speed for my provider (480mbps). 2.4G wifi still runs at normal speeds (85-105mbps) on both devices. The old software allowed the Acer AX wifi to run at full speeds!

My RT3200 will no longer maintain its assigned fixed address of http://192.168.1.169/. My 5300 won’t maintain its address of http://192.168.1.1/, and somehow assigns the 3200 that address? So, sign in at the .1 address (should be the 5300) logs into the GUI for the 3200?? If it works right and signs into the 5300, after a few minutes the 5300 is logged out and the sign in screen shows for the 3200. The DHCP pool addresses start at .2 and up.


None of these problems are there while using the 384.19 software, so I’m at a loss as to causes.

I intend rolling back to the old software until some of this is able to be hashed out. I have logs from all this saved, just in case there were questions. I am at a complete loss!
 
@Howard_inGA what firmware is your RT-AC3200 on?

Can you give us more specifics about your network setup?

This doesn't sound similar to any network I've seen Beta 5 installed on. Is it possible it is a configuration error somewhere along the way?
 
@Howard_inGA what firmware is your RT-AC3200 on?

Can you give us more specifics about your network setup?

This doesn't sound similar to any network I've seen Beta 5 installed on. Is it possible it is a configuration error somewhere along the way?
RT-AC3200_384.13_10 is the current (and last?) firmware from Merlin. It ONLY serves as a media bridge. All DHCP and internet access flows through the 5300. As indicated, I did a factory wipe. Then, did a page by page restore of all setup info. Nothing material changed in config from 384.19.

I really don't understand what could be happening, but I took every precaution to ensure a clean install and rebuild. All the pages LOOKED ok, and same as before. I even tried shutting down all Guest networks, but to no avail.
 
A page by page restore isn't too specific. But on the face of it, you shouldn't be having these problems either. More details would help though.

How did you set up the amtm drive, for example?

See the suggestions in the link below and maybe you can spot where you deviated a little or a lot.

Update/Reset Mini Guide
 
A page by page restore isn't too specific. But on the face of it, you shouldn't be having these problems either. More details would help though.

How did you set up the amtm drive, for example?

See the suggestions in the link below and maybe you can spot where you deviated a little or a lot.

Update/Reset Mini Guide
I don't run scripts, and had NO USB devices attached during the whole evolution. I did put a usb 2.0 device (corsair thumbdrive) in as a Traffic history location storage site after returning to .19. It was never installed in the Beta 5 trial.
I did utilize the procedures outlined in the Mini Guide and by Merlin to do the process...
One more piece of info that just occurred to me. I have implemented ipv6 addressing in both .19 and the beta, including the proper address sites. So, no difference there, but I cannot discern if it is germane?
 
Last edited:
I see this cosmetic issue in Advanced_Wireless_Content.asp, once I select 5GHz in the top drop down. Selecting 5GHz has top section with all regular options, and bottom section, which I could not understand. None of the drop downs in that section have any values.

Looking at source Advanced_Wireless_Content.asp source it is not from beta 5 code, but I am just now noticing it. This was not visible until I had Smart Connect ON, once it turned off, it gives option to select the band.



1611952222288.png
 
I tried Beta5 and had the same issue I had with the any of the AiMesh 2.0 firmware..... roam assist does not work. Clients just stick to the main router even with rssi -86. With 384.19 roam assist works great. So, on a positive note it looks like my days of updating firmware on my Asus routers is over and I can find something else to occupy my time. :)
 
I use an OOMA as well and noticed that it causes issues (mostly interference when making OOMA calls) a while ago. I bought a modem with two LAN ports (ARRIS CM8200A) and connected the router on port 1 and the OOMA phone system on port 2. Works like a charm.
Ooma user as well, although I've never noticed any issues. What issues are you and GHog referring to? When you say interference when making calls, do you mean wifi interference? Just curious if I should be looking out for something as I've always had my Ooma box connected directly to the Asus.
 
Update: Smart Connect, still not as smart as it should be in 2021. :)
Smart Connect is only as smart as the dumb clients. I have 2 devices that don't behave - a HK Invoke and my Surface Pro 4. They like to stay on the 2.4GHz even though their signals meet SC thresholds. And you can tell that SC is doing something because the Wireless log 'Connected' is never more than my dwell time. And even though they bounce between 2.4 and 5, SC does what its supposed to... devices never lose their IP address and network traffic is never interrupted (or the error corrections is high up in the protocol stack)

(Screenshot is an example -I don't have any clients misbehaving right now)
1611966296613.png


When they do a power cycle or some other task that causes them to start their normal Network connection routine (airplane mode on Surface) fixes them for a while.

(Smart Connect) Can't fix stupid (STAs).
 
AKA Dumb Connect.
 
Hello everybody.
I've done a dirty upgrade from 384.19 to 386.1b5 on my RT-AC86U.

I have the following issues (no time now to make a clean install):

  1. CPU Temp jumped from 78°C to 89°C. CPU Wait is enabled. However, as it seems, high temp issue is still present.
  2. This kind of error message in the system log:
    Code:
    [0;33;41mBLOG ERROR blog_request :blog_key corruption when adding flow net_p=ffffffc0074472e8  dir=1 old_key=0xfffffffe new_key=0x20001584[0m
  3. The following error in the system log with Guest WiFi 1 enabled
    Code:
    kernel: protocol 0800 is buggy, dev eth6
Thanks
 
Did a dirty update on my RT-AC86U from 384.19 to 386.1 beta5. The only thing I had to do is move the guest network to the second guest network to get rid of '0800 buggy network' messages in the log. Everything else seems to be ok, Open VPN clients, OpenVPN server, DDNS, let's encrypt, DoT, Static IP's, DNS Filter. CPU temp fluctuates between 72 and 80 degrees Celsius.
 
Last edited:
Luckily I didn’t waste time on upgrading my 5300 yet. To many issues here. I am grateful though for you guys testing the waters, but temps still raising by 10dgr. and these disconnects, ir seems to me we are far away from a stable branch.
 
With this latest 386.1b5, on RT-AC86U, looks like some people are still having high temps (like me) while others not.
What is the revision / Boot loader of your RT-AC86U?

Mine is Rev 1.5, of 2018. - Bootloader (CFE) 1.0.0.8
Even tough CPU Model seems to be the same among all AC86U (BCM490x - Cortex A53 ARMv8 revision 0) I noticed that Bootloader (CFE) is different among releases.
I have another AC86U (on which I cannot test betas) with Bootloader (CFE) 1.0.1.0
 
beta 5 installed on ac66u b1. once installed restore to factory settings from the graphical user interface. configuration from 0. everything works correctly except the 5ghz WiFi shutdown programming that does not allow the configuration tested in Chrome and Egde

1612011044950.png


I edit to include a photo that was not at home before
 
Last edited:
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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