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.
Same issue here too
As workaround I'm using a super simple startup script in order to enable it:

file /jffs/scripts/cpuwait, called by services-start
Code:
#!/bin/sh
pwr config --wait on
Thanks. This has done the trick.
 
Thanks. This has done the trick.

Just for my info.
Is the filename called "services-start" and placed in folder "jffs/scripts"
or is called "cpuwait" and placed in folder "jffs/scripts" (if so, how is it called upon in latter case)?
 
services-start is the file you want. I use init-start with the above code in it, but either should be fine. User WillyTP just calls a custom file from services-start. But you can just put the code from the custom file into services-start or init-start.
Bash:
mastercomputersmith@AC86U:/jffs/scripts# cat init-start
#!/bin/sh
pwr config --wait on
 
Last edited:
services-start is the file you want. I use init-start with the above code in it, but either should be fine. User WillyTP just calls a custom file from services-start. But you can just put the code from the custom file into services-start or init-start.
Bash:
mastercomputersmith@AC86U:/jffs/scripts# cat init-start
#!/bin/sh
pwr config --wait on

And make it executable?
 
Not really much to add, apart from many thanks......

It worked....

beta 3.png


it works.....

beta 4.png


beta 4 installed fine on AX88U over beta 3. Not sure if needed but I disabled the VPN client and then updated to beta 4. Waited a few minutes (made cup of tea) and then turned VPN client with policy routing.

All working, as usual.

The client list gets a little confused as to which wired connection is static or DHCP, picks up manual ok, for some devices. Not an issue really. Altho at least all six of my CCTV cameras have been assigned "static" and not DHCP, so they are right.
Reckon that is an Asus "thing".
 
Last edited:
I've tested the new Beta 4 version. Aiprotection time scheduling works only restricting access to web pages, but it doesn't restrict other services (spotify, for example).
I have noticed the same in this and previous versions of 386.1. Past bedtime, kids are unable to access websites but they're still able to play online games, use Steam (or similar services), etc... making the Time Scheduling feature mostly useless for me. :confused:
 
Just updated my RT-AC86U from 386.1_beta3 to beta4 (no reset) and everything seems fine. The only drawback is the need to manually re-enable cpuwait states, as already mentioned.
 
AX3000 having this log

Jan 9 10:58:37 kernel: potentially unexpected fatal signal 11.
Jan 9 10:58:37 kernel: CPU: 1 PID: 1544 Comm: dcd Tainted: P O 4.1.52 #1
Jan 9 10:58:37 kernel: Hardware name: Generic DT based system
Jan 9 10:58:37 kernel: task: ccf7e000 ti: ccf84000 task.ti: ccf84000
Jan 9 10:58:37 kernel: PC is at 0x2a760
Jan 9 10:58:37 kernel: LR is at 0x2a9e0
Jan 9 10:58:37 kernel: pc : [<0002a760>] lr : [<0002a9e0>] psr: 200b0010
Jan 9 10:58:37 kernel: sp : beeb5988 ip : 000a311c fp : 000825f4
Jan 9 10:58:37 kernel: r10: 00000025 r9 : 00000003 r8 : 00000025
Jan 9 10:58:37 kernel: r7 : b5aff290 r6 : 00000036 r5 : 00000256 r4 : b5aff2f0
Jan 9 10:58:37 kernel: r3 : 00000000 r2 : 00000024 r1 : 0000000b r0 : 00000000
Jan 9 10:58:37 kernel: Flags: nzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Jan 9 10:58:38 kernel: Control: 10c5387d Table: 0cbc004a DAC: 00000015
Jan 9 10:58:38 kernel: CPU: 1 PID: 1544 Comm: dcd Tainted: P O 4.1.52 #1
Jan 9 10:58:38 kernel: Hardware name: Generic DT based system
Jan 9 10:58:38 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Jan 9 10:58:38 kernel: [<c0022c38>] (show_stack) from [<c044e31c>] (dump_stack+0x8c/0xa0)
Jan 9 10:58:38 kernel: [<c044e31c>] (dump_stack) from [<c003aacc>] (get_signal+0x490/0x558)
Jan 9 10:58:38 kernel: [<c003aacc>] (get_signal) from [<c00221d0>] (do_signal+0xc8/0x3ac)
Jan 9 10:58:38 kernel: [<c00221d0>] (do_signal) from [<c0022658>] (do_work_pending+0x94/0xa4)
Jan 9 10:58:38 kernel: [<c0022658>] (do_work_pending) from [<c001f4cc>] (work_pending+0xc/0x20)

stable and responsive with my internet 500/500.
1610188859728.png
 
Last edited:
Thanks Merlin so much - a smooth upgrade from beta3 to beta4, everything works as expected, no errors, AiMesh still works nicely.

PS. Issue of 1GBs speed tests slowing down with TrendMicro enabled (for instance by enabling and disabling AiProtection) on AX88U still remains.
Withdrawal from TrendMicro privacy agreement restores fast speeds.
speed.png
 
Last edited:
Is it possible to run cpu wait command manually via router (AC86U) admin page? Or maybe somehow via WinSCP program? This one I use time to time. I have never created script files myself and even though you guys understand each other with these short explanatory comments, I don't:) Simply have no background.
 
Just updated my RT-AC86U from 386.1_beta3 to beta4 (no reset) and everything seems fine. The only drawback is the need to manually re-enable cpuwait states, as already mentioned.
Time schedule is not still fixed in b4?
 
  • Like
Reactions: Civ
services-start is the file you want. I use init-start with the above code in it, but either should be fine. User WillyTP just calls a custom file from services-start. But you can just put the code from the custom file into services-start or init-start.
Bash:
mastercomputersmith@AC86U:/jffs/scripts# cat init-start
#!/bin/sh
pwr config --wait on
Thanks for the tip, it works!

Time schedule is not still fixed in b4?
Sorry, not using the time schedule feature.
 
I just did a 'dirty' upgrade from beta3 to beta4 and it looks promising :)

(Edit: I reverted the firmware back to beta 3 due to performance issues, see text below original post)

Recently I did a complete reset + configuration when I flashed beta 3, so I didn't see the necessity to do this all over again for beta 4.


DOWNLOAD/UPLOAD speeds in 'Adaptive QoS'
-----------------------------------------------------

When doing a speedtest on www.speedtest.net on my PC I see this:

During download test (100 Mb/s):
1610188856604.png


During upload test (20 Mb/s):
1610189262940.png


This only happens when I have traffic going through my VPN (!)

When I perform a speedtest direct via my ISP (no VPN), then speeds are shown correctly..

In other screens, the speed indications always work fine, it is only in the screen above.

Download test (100 Mb/sec)
1610189750924.png




GUEST WIFI
-------------
I noticed the setting below in previous firmware builds where I set it al 'All'. However I didn't notice this setting in beta 3.

1610189844386.png


After activated the Guest network it works fine now: also the nodes have the Guest Wifi activated. :)


UPDATE
I decided to go back to beta 3 due to performance issues... I have a 100/30 connection and in beta 3 I got these speeds... In beta4 I noticed degraded performance (upload speed in particular) and therefore I reverted the firmware to beta3.

As for beta4: I also tried to load 'factory defaults' and initially download+upload speeds were fine. But when I enabled the Trend Micro related stuff (traffic analyzer statistics), I noticed much lower upload speeds than usual. So I'll skip this one.
 
Last edited:
Hi, just dirty installed b4 over b3 in my x88U main router and aimesh node x56u. My observations :

- There is still some confusion in network map clients list with some clients still being listed that are in fact no longer connected to the network. These are listed with wired interface when they did previously connect wireless. Those 'phantom clients' are correctly missing in the aimesh page clients list.

- It seems like aiprotection does not reflect any event count. This is happening in my machine since last june-july, but I hoped for this to have been fixed with the new GPL based on some comments in other threads.
In any case AIprotection seems to be working even if not counting events since wicar.org malware samples are being stopped correctly. UPDATE: I have also observed degraded performance (internet speed) with AIprotection enabled, as reported by others.

- In Aimesh page, the buttons for bind/unbind and reconnect clients are missing their icons. They were correctly shown before, under b3. UPDATE: The icons appeared magically after reentering the admin GUI.

Other than these the migration went flawlessly. Thanks again Merlin !

Regards
 
Last edited:
On cpuwait / temps - a question that's been bugging me from an earlier thread:


Is there a hog out there that is a bigger cause of these temps? Can't find it yet, but i may be 100% wrong
 
Continuation of the first thread which covered beta 1 through 3.

Beta 4 is now available. Changes since Beta 3:

Code:
6adb157bea asd: disable asd on all models
95025b94e8 Remove Codel scheduler from all kernels
b442b0b5d4 build: move RT-AX86U addvtoken to its own directory
0c12c1a7cf Merge 386_41535 binary blobs for RT-AX86U
f6ef91f31b Merge 386_41535 SDK for RT-AX86U
59789ea24a Updated documentation
db54f3995c build: copy addvtoken to model folder for RT-AX88U
3853b491e8 Merge 386_41535 binary blobs for GT-AC2900
68d1059d39 Merge 386_41535 SDK + binary blobs for RT-AX56U/RT-AX58U
4c7ba10c62 Merge 386_41535 binary blobs for RT-AX88U
133e15c36e Merge 386_41535 binary blobs for RT-AC86U
6bb1ca7420 Merge 386_41535 binary blobs for RT-AC88U/RT-AC3100/RT-AC5300
1f940c33fb Merge 386_41535 binary blobs for RT-AC68U
f32e73d911 Merge with GPL 386_41535
51a23b3b4b webui: do not rely on bridge stats to calculate traffic scale
8b252526f0 rc: do not skip new firmware checks on AX56/AX58 within region CX
cdac832ddc rc: remove outdated source file
9bbb8c59bd libovpn: enable multihome for UDP servers
38d0b385e7 github: enforce the use of an issue template
5a5dfbb287 Merge pull request #671 from JackMerlin/master
801163264e github: create template configuration
f0c34871be github: create bug template
434857ddb5 httpd: cache require.min.js and jquery-ui.js browser-side (ref. #657)
ed9199883f httpd: fix compiler warning in ej_show_sysinfo()
9fa141b22c httpd: re-harmonized with upstream
83cef57b4a httpd: remove duplicate code in httpd.c:main()
ec97c100d2 rc: re-enable cpuwait support on RT-AC86U/GT-AC2900
4548b54d5f webui: re-enable Speedtest webui on RT-AX56U and RT-Ax58U
de99bc07fd rc: limit fq_codel queues to 1000 packets instead of the default 10240.
1092dbfa4d rc: shared: webui: Hardcode fq_codel usage for tQoS/Bandwidth Limiter, remove option to select sfq as a qsched
acdf339dd3 rc: if MTU setting is empty or invalid, use 1500 instead of 576 or 9000
bd4d82908a Bumped version to beta 4

Asuswrt-Merlin 386.1 beta is now available for all supported models (and a few new ones). This marks the switch to the new 386 code base from Asus, which introduces a few changes of its own:

- AiMesh 2.0 (better node management, shared Guest Networks, topology optimizer and more)
- Both AC and AX models are once again based on the same code base
- Speedtest powered by Ookla (note: can be limited by your router's CPU speed)
- Switch to OpenSSL 1.1.1 (so we can now fully move everything to 1.1.1 on our end)
- IPSEC IKEv2 support
- Instant Guard (new simple-to-configure mobile VPN client based on IPSEC)

And numerous under the hood changes, such as better Guest Network handling (the first Guest Network can now be shared with AiMesh nodes) and various other enhancements.

On Asuswrt-Merlin's own end of things, this release mark the addition of two new models:

- RT-AX86U
- Experimental support for the GT-AC2900 (done in collaboration with Asus)

The latter comes with a few caveats:
- The non-ROG webui is used (meaning some ROG-exclusive features are currently NOT supported)
- VPNFusion is not supported (as it's tied to Asus's own closed source OpenVPN implementation)

The non-ROG UI has been implemented by Asus, they also took care of adding GeForceNow QoS support to our code base. This will serve as an experiment to see if other GT models could be added in the future with their collaboration.


Upgrade notes:
- If coming from a previous alpha build, you MUST do a factory default reset after flashing this beta firmware.
- If coming from stock Asus firmware, a factory default reset is recommended, but not mandatory.
- If going back to stock Asus firmware, a factory default reset is STRONGLY recommended.
- If updating your GT-AC2900 from an older 384_xxxx firmware, reformatting your JFFS partition is STRONGLY recommended.
- Direct upgrade from 384.18 or 384.19 should be fine, but be prepared to do a factory default reset if something does not work as expected.


Here are the highlights of changes since 384.19:
  • Merged with beta GPL 386_41535. Since it's a beta GPL, logging activity will be a bit more verbose than normal. Just don't panic at log entries you don't understand, not everything means that your router is not working properly. Most of this is debugging info, NOT error reporting.
  • Added support for the RT-AX86U and the GT-AC2900 (the latter is experimental)
  • Updated components: OpenVPN (2.5.0), OpenSSL (1.1.1h), nano (5.2), curl (7.72.0), zlib (1.2.11), lz4 (1.9.2), e2fsprogs (1.45.6), dropbear (2020.81), miniuppnpd (2.2.0-20201129 snapshot), ipset userspace (7.6, which is compatible with the kernel's v6 protocol).
  • Various changes to OpenVPN to support 2.5.0, remove deprecated features (like the old ciphers setting), tweak the webui, and fix a few issues. Please review the detailed list of changes in the Changelog.
  • Firmware update server is now hardcoded rather than stored in nvram, for security purposes, and check frequency changed from every 48 hours to every 24 hours
  • Added an option to run the Speedtest through a specific OpenVPN client (the webui will automatically detect which client is currently running and add it to the list of available interfaces)
  • fq_codel is no longer supported under Adaptive QoS, due to architectural changes made by Trend Micro, preventing Asuswrt-Merlin's previous patch from injecting fq_codel into rules generated by the Trend Micro engine.
  • Fixed some ISPs that failed to renew DHCP leases when Adaptive QoS was enabled.
  • Removed largely unused and outdated support for the Cloudcheck mobile app (I bet virtually none of you knew it even existed
  • Improvements to the DNSPrivacy preset list implementation, and the addition of AdGuard and CIRA Canadian Shield to the list
  • Increased the number of available mount points for third party web pages from 10 to 20.
  • And a brand new website to better accommodate the list of supported models, and make publishing new releases easier (and more automated) for me. It was completed a few months ago, but was waiting to launch it at the same time as the first 386 beta release).


There are a number of specific areas that will require thorough testing:

  • OpenVPN (note that some issues may be caused by VPN tunnel providers who haven't properly updated their own server. That was the case for PIA for instance which only recently updated their servers to be compatible with 2.5.0 clients.)
  • ipset (the warning about the protocol version is normal, and just a warning telling you that the kernel supports version 6, and your ipset executable supports both version 6 and 7)
  • While testing AiMesh is ok, do note that AiMesh is closed source, and therefore any issue within it are outside of my control. Reproduce the same issue with the stock firmware, and if you do, report it to Asus instead
  • Everything about the RT-AX86U and GT-AC2900
  • Speedtest on the RT-AX56U and RT-AX58U (seems to have performance issues)

Please keep discussions in this thread on this specific beta release. Off-topic posts will be either ignored, moved or deleted depending on my mood at the time.

Downloads are here.
Changelog is here.

Thank you Merlin!

Unfortunately, on RT-AC86U, Traffic Analyzer Statistics, Traffic Monitor and QoS Bandwidth Monitor continue to report completely wrong values. Also Traffic Monitor continues to go out of scale. As I told by my last post, it seems that Asus fixed these problems only for RT-AX86U and not for RT-AC86U. I hope that Asus could fix them soon.

Bye.
 
Last edited:
I will stay on 386.1 beta2 for now until the high CPU temp on AC86U is properly fixed.
 
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