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.
Have been running 386.1 B4 since it came out on my AX88U with no scripts, QoS, Guest Network, or AIprotection. This morning the router rebooted as I had set it to do with reboot scheduler. I had a look at the logs and found the following 2 errors during reboot. I don't know if they are relevant to anything discussed here.

@RMerlin FYI

May 5 01:05:03 lldpd[971]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted

Jan 11 09:56:13 kernel: *** ERROR: [tdts_shell_ioctl_sig_op_load:95] tdts_core_rule_parsing_trf_load() fail!

@Wadadli

As per @RMerlin 's post here: [Beta 384/NG] Asuswrt-merlin 384.4 Beta is now available | Page 12 | SmallNetBuilder Forums (snbforums.com)

You can just ignore those error's, not of concern.
 
Different SDKs, unrelated.

Thanks - understood that from the outset - saw your Github commit [which led to 4b being released for certain models] had it seems included all supported models including the RT-AX86U ...
pwr-man.JPG

In previous thread had noted the difference between stock power management and your beta4 compile ...
pwr-man2.JPG

In stock CPU states are shown as Disabled or Enabled and can be user set ... but in your b4 compile it seems not.
 
Has anyone tested beta 4 on AC5300? Have an AC5300 as core router, and another for AiMesh node. Also looking for feedback on beta 4 for AC3100..These are my other two AIMesh nodes.

Thanks all!
 
They told me it was to address a bug, but that they would consider reverting it in the future if it creates more issues.
I've not looked at my temperatures so I'm blissfully unaware. What I can say is that my AX88U with AX56U nodes are running very well after 24 hours on Beta 4(b). Many thanks.
 
Do you have AI Protection turned on? I disabled it and after that was able to flash beta 4 on my AC67U.

It was off for one unit, but turning the options on/off and/or withdrawing from TrendMicro didn't do anything, yet. :)
 
Well, its only limited to ac86u. So you should be fine right here.
As I said - I haven't looked so have no idea ;)

Sorry my previous attempt at a bit of humour obviously fell short :)
 
Well, wish I have spare money for a new AX86U
apparently I have not:(
You've chosen to run beta test firmware - you should be aware that this carries risks and if you are concerned it would be advisable to regress to a stable released version with known characteristics.
 
You've chosen to run beta test firmware - you should be aware that this carries risks and if you are concerned it would be advisable to regress to a stable released version with known characteristics.
huh, right at #379 I was running the new 386_41634, which is an official release of stock fw.
It is not a beta and caused issue. Wondering will the actual 386.1 uses same GPL.
 
Since I've moved to beta 1. (And did a factory default)

The schedule are not working anymore. My kids used to be cut out at the exact time I put in. But now internet is available 24/7 what ever I put in.

Anybody else is having issues? I've tried beta 2, 3 and now 4 !

Thank you
Same for me, the only thing I didn't do is format JFFS but I did set defaults.
 
Here are a few observations after running 386.1b4b overnight on my AC86U:
  • The AC86U started issuing the, "protocol 0800 is buggy, dev eth6" log entry. I have Guest Network 1 enabled and set to use 2.4GHz. As Merlin suggested, switching over the Guest Network 2 appears to have eliminated this entry into the log.
  • There is an OVPN Warning in the log about the MTU setting: <ovpn-client1[1781]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1557'>. I don't have any configuration options enabled at either end for link MTU. The client side is an AC86U running 386.1b4b while the server side is an AC86U running 384.19. I guess it goes without saying, but the .ovpn file for the client was generated while the server was running 384.19.
  • There is another OVPN warning about cipher usage: <WARNING: 'cipher' is present in local config but missing in remote config, local='cipher AES-128-CBC'>. However, both the server and the client have exactly the same cipher configuration. I guess there is something new with v2.5.0 vs v2.4.9 with cipher settings. I'm trying to figure it out now, but so far, its not totally clear what I should change on the client or server side.
 
Posting this to find out if anyone else is having the same issue with 386.1 releases that I am.

This has been / still is happening with all Merlin 386.1 alpha's & beta's. I have one client, a W10 PC with an Intel AC7260 wireless adapter, that constantly looses it's 5Ghz wireless connection. It takes a while for the drop to happen after initial PC boot up but after that drops gets closer and closer together. No other clients on RT-AC86U or AIMesh node RC-AC68U drop.

This client is very close to the 86U, 6ft. Once dropped I have to reset the client in the PC via running network diagnostics or manually disable / enable wireless client. I have forgotten wireless network connection several times within PC. I have tried disabling both beamforming's in router, it does not make a difference. This client has always been rock solid prior to this release. I believe there was a new driver version for the 86U that came out with the 386.1 release. I've been hoping that newer releases will fix.

I did do a factory reset after flashing to 386.1 alpha as instructed. The drops have gotten so bad I am now using an Ethernet connection. I read the forum often enough to know no that is not an issue that is being encountered by many.

Any help / suggestions will be appreciated.
update your client's wireless driver(s)?
 
Thanks - understood that from the outset - saw your Github commit [which led to 4b being released for certain models] had it seems included all supported models including the RT-AX86U ...

I simply removed it for all models for uniformity between models, so they all run from the same compiled source code.
 
huh, right at #379 I was running the new 386_41634, which is an official release of stock fw.
It is not a beta and caused issue. Wondering will the actual 386.1 uses same GPL.

You lost me somehow on newest official, Version 3.0.0.4.386.40451 :
 
You lost me somehow on newest official, Version 3.0.0.4.386.40451 :
newest official: 3.0.0.4.386.41634:rolleyes:
ac86u2.png
 
newest official: 3.0.0.4.386.41634:rolleyes:
View attachment 29375

Why did they only post that under Windows 7, 8, 8.1 and NOT 10? The other 2 W10 builds have it (DCH & RS5)?
 
RT-AC68U, updated to beta4. Uptime 1 Day, 23 hours.
Static Leases, VPN Client with selective routing, FlexQos script all working really well.

I did have an initial issue updating to Beta4, but it could have been my fault. I did not get the validation message, but the router rebooted back into beta3. I waited about an hour, and then the router updated successfully.

I will mention that beta3 did increase my cpu temp by 2-3 degrees c.
It held steady at 80-81c, while beta 2 and beta 4 now are at 77-78c. Strange.
 
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