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.
Using an AX88U here:

Two days ago I dirty upgraded from 384.19 to b4b and saw a great improvement in both 2.4G WiFi range and stability. 5G WiFi remains the same as far as I can see.

For 10 hours all was generally good, but two things stood out:
Timing of parental controls to a pair of Xbox One either did not work at all, or cut in some erratic time after the cut-off time. Then access would resume for a while. Then drop again, and so on.
IPv6 was erratic. Sometimes dropping pings, sometimes dropping connections.
IPv6 DDNS didn't work most of the time.

I resorted to a complete factory reset, which helped some. Then switched off IPv6, which helped a lot.

b5 dropped a few hours later.

Now upgraded to b5 and IPv6 is significantly more stable. DDNS IPv6 updates are now consistent from within the network (From a Synology NAS, not from the router) which suggests something was interfering with these in b4b, or maybe it was the general flakiness of IPv6 in action within b4b.

I'll report on the parental controls in b5 tomorrow after they have had time to cut in.

B5 seems stable and usable for me so far.
 
Last edited:
I just downloaded 386.1 beta 5 for RT-AX88U but the update keep failing. Is there something wrong with this beta5?
View attachment 29885

Clearly looks like a B4 Problem - may need to upgrade to B4b first - alternatively try multiple attempts. Had to try 3 times in a row before I succeeded to get from B4 to B4b
 
Upgraded RT-AC68U b4 to b5 (and before, all betas in order from 384.19). Have yet to reset or rebuild jffs on my router for many years, rarely would other than for alpha or personal test builds (which I've not run to date).

I post this to maybe help some understand a bit about how to tell when a reset/jffs-rebuild is really necessary. Generally, it's not really that necessary in the vast majority of cases. The only changes I've ever dealt with were /jffs/script or /jffs/configs (and for some, consider /jffs/addons) that are doing things inconsistent with the new firmware (doesn't take a reset or jffs reformat, just script / config fixes). To be sure, if you want to live a reset-free life, make darned sure you have one network that will *always* work, or a cron job that will detect problems and reset things appropriately so you can get in to fix things. Otherwise, you can't assume reset free in all cases (though still relatively rare in my experience of embedded kernel / ROM dev-ing).

A reset is necessary if you need to test your setup process for your router(s) or you know (or believe) state transition between setup steps somehow alters long term operations (again, likely rare, though look below regarding dblog_usb_path -- non-deterministic code can definitely cause problems, though this case is benign for me).

Below is a diff of my nvram showing the nvram delta between beta4 and beta5 on my RT-AC68U with highly modified setup (e.g., multiple tagged and untagged vlan port setups, eatables work, multiple guest wireless, many firewall/nat alterations, Dnsmasq, entware services, pre/post-mount fsck ops, etc.). In the end, nothing earth shattering; no need to reset. An observation on dblog_usb_path provided after the diff.

I save nvram (nvram show | sort > [some_file]) for all versions I use to check between upgrades. To read, here's a legend for those unfamiliar with diff (Mac command used was "diff -y --suppress-common-lines nvram_b4.txt nvram_b5.txt"):
  • a | between entries means it changed
  • a < between entries means it existed only in beta4
  • a > between entries means it exists only in beta5.
Widen your browser window if the following looks a little wonky.

Code:
buildinfo=Fri Jan  8 22:43:29 UTC 2021 merlin@6adb157 | buildinfo=Tue Jan 26 00:28:08 UTC 2021 merlin@3790c8f
cfg_check=9                                           <
cfg_fwstatus=9                                        <
dblog_usb_path=[redacted]                             | dblog_usb_path=[redacted but changed, really should not]
ddns_cache=[redacted]                                 | ddns_cache=[redacted but changed (expected)]
extendno=beta4                                        | extendno=beta5
fwpath=                                               | fwpath=1
                                                      > httpd_handle_request=upgrade.cgi


                                                      > httpd_handle_request_fromapp=0
login_ip=[redacted]                                   <
login_ip_str=[redacted]                               <
login_timestamp=1026542                               <
wan0_expires=[redacted]                               | wan0_expires=[redacted but changed (rarely wouldn't)]
                                                      > wan0_gw_mac=[redacted]
                                                      > webs_state_info_beta=384_10_beta3
webs_state_upgrade=                                   <

-- end diff --

Not much to see here . . . pretty normal.

Regarding dialog_usb_path, the code setting that value is written in a non-deterministic way (first mount wins). If you use more than one partition on your USB drive, beware if you enabled dblog (dblog_enable is non-zero) and expect a stable path. See (https://github.com/RMerl/asuswrt-me...9b8a0/release/src/router/rc/usb.c#L2186-L2195).


--- update: fixed model from RT-AC86U to RC-AC68U (that typo gets me all the time, dangit!).
 
Last edited:
Upgraded AX86U and Ac86U from B4 to B5 and no major issues.

Still looks like the Wireless MAC/Wake ON LAN/DHCP Reservations suffer from custom icons not always being shown at the correct size and enlarged and out of its HTML table. Still keep having to do SHIFT+REFRESH icon to display properly on pages where custom icons appear for devices (other than network map). Think those pages could do with an always refresh tag when entering.
 
@RMerlin what does a679101f9c asd: re-enable on all models do exactly ?
 
Well that was easy sledding. Upgrade from b4 to b5 flawless. Network rock steady. Thanks RMerlin!
 
Eric, I can confirm with what you said about guest network on RT-AX88U. To everyone else my apologies for misleading that guest network is fixed, which is clearly not true at all.
 
On beta5, I have to restart FlexQOS from amtm in order to get the FleQoS web GUI content to update in either tab (classification, FlexQoS). Wasn't an issue with beta4. I *suspect* the disk check script is causing the timeout, but I'm still sleepy.
 
Update went well on both the AX88U and mesh node AX58U. Nothing to report, boring :) .
 
guys I am still having 88c of my AC86U on beta 5.
What temperature you guys have?
Current Temperatures: 46 °C - 48 °C - 60 °C
Clients: 8 - 5 Apple devices, 1 console, 1 Windows notebook, 1 TP-Link Extender
Running Scripts: See my signature
 
My log is full of stuff like this

Jan 26 11:56:28 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=04:d9:f5:fb:db:d8:00:01:5c:a5:00:5f:08:00 SRC=185.193.91.250 DST=my.ip LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=16802 PROTO=TCP SPT=52556 DPT=8489 SEQ=2481059237 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000

Am I under attack? :D

Only from the logging - it's set to Debug by default so you are getting everything. I've changed the Log only messages more urgent than setting to notice much quieter now
 
My log is full of stuff like this

Jan 26 11:56:28 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=04:d9:f5:fb:db:d8:00:01:5c:a5:00:5f:08:00 SRC=185.193.91.250 DST=my.ip LEN=40 TOS=0x00 PREC=0x00 TTL=247 ID=16802 PROTO=TCP SPT=52556 DPT=8489 SEQ=2481059237 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0 MARK=0x8000000

Am I under attack? :D


Unrelated to Beta5... However,
Turn off logging in the firewall section.
1611670203606.png
 
Upgraded 6 AC68Us (1 router, 5 non AIMesh APs) from Merlin 386-1b4 to 386-1b5 using a dirty flash with no appraent issues.

All had been factory reset and NV-RAM reset after the upgrade from 384-19 to 386-1b4.

AC68U "router" is running Diversion, Skynet, and DNScrypt, firewall and AiProtection are on, QOS is off.

Lan from this router is split into two subnets, using an EdgeRouter ER-X, and then to two AC68U APs (daisy-chained,) (for computers) on one subnet and three AC68U APs for (surveillance) on the other subnet.

Ookla speedtest from computers on the subnets showed 86 mbps down and 28 mbps up both before and after the upgrade on a 75/30 fiber connection . Merlin Speedtest on the router showed about the same both before and after upgrade at 86/28.

No updates to Diversion, Skynet, DNScrypt or Entware were needed. Highest temp is 73°C and steady after about 30 minutes.

THANKS Merlin!
 
Make sure you do have the correct model. beta 4b shouldn't have any problem upgrading to beta 5, the issue was only with beta 4.
Both of my ax88u were on beta 4. Tired to upgrade to 5. The Aimesh node(ax88u) took the upgrade. But the main one won’t
 
Upgraded two AC86Us (one in router mode and one in AP mode) from b4b to b5 with no issues during the upgrade. b4b was rock solid for my setup after I tweaked OVPN settings on server and client sides to clean up the OVPN connection handling and then moved my guest network to slot 2 to get rid of the buggy protocol log message. b5 is similarly rock solid. I have not tried to move my guest network back to slot 1. CPU temperature is the same between b4b and b5 - for both firmwares, the main router CPU temperature is 80-81C in a 23C room. This is 4-5C higher than when the router had 384.19 installed.

One interesting tidbit for b5 is that even though my network is not in AiMesh mode, my main router is occasionally leaving a log message about not being able to apply AiMesh updates to two devices on my network, one of which is a laptop while the other is a Kindle Fire. There are several more devices on my network, but no messages for these other devices. A bit odd, but no biggie.
 
@RMerlin what does a679101f9c asd: re-enable on all models do exactly ?

I am not sure if it were in this thread or in the previous beta thread (386.1) that Merlin stated it was the new Asus security daemon and that was all he could say. I take it from that statement, Merlin can not say anything more.
 
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