Beta Asuswrt-Merlin 386.1 Beta is now available

[LimJK]

@LimJK @Slawek P
If anyone wants to point me in the direction of where the built-in speedtest binary lives in 386 I can make a version of spdmerlin to use that instead of the version I downloaded from Ookla, to see if it performs any better?

Jack,
Thanks for all your scripts . Coding is beyond me, a retired user, so I have no idea where to point you to.

 

[bluepoint]

I have the same issue with Let's Encrypt Certificate:
View attachment 28263
PS: I do not have this issue with earlier Merlin 386.1_Alphas and Stock RC-B9 9.0.0.4_386_41157-gd618756

Yes, there must be some kind of problem with LE's certificates but mine is slightly different problem as yours as I have *not* yet formatted the jffs partition and factory defaulted after A4 to B1 upgrade, Letsencrypt won't start. Used own certificate for now until I have time.

Dec  5 17:55:00 rc_service: service 26470:notify_rc restart_letsencrypt
Dec  5 17:55:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:00:00 rc_service: service 26984:notify_rc restart_letsencrypt
Dec  5 18:00:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:05:00 rc_service: service 27709:notify_rc restart_letsencrypt
Dec  5 18:05:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:10:00 rc_service: service 28222:notify_rc restart_letsencrypt
Dec  5 18:10:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:15:00 rc_service: service 28732:notify_rc restart_letsencrypt
Dec  5 18:15:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:20:00 rc_service: service 29246:notify_rc restart_letsencrypt
Dec  5 18:20:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:25:00 rc_service: service 29761:notify_rc restart_letsencrypt
Dec  5 18:25:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)
Dec  5 18:30:00 rc_service: service 30275:notify_rc restart_letsencrypt
Dec  5 18:30:00 custom_script: Running /jffs/scripts/service-event (args: restart letsencrypt)

 

[JWoo]

It could be a hardware issue but my RT-AX58U started to crash/reboot when quickly changing sections in the webUI also(started with Alpha 4 for me being I didn't really play with Alpha 3 too much). If I go to a section and stay there to change settings, etc, it doesn't crash/reboot but if I go section by section quickly to verify settings, it will crash eventually,

That is EXACTLY the scenario that I have found as well. It does not happen with 384.17. But with the new Asus GUI in the Alpha and Beta 386 builds it happens. It happened to me the 1st time when I was verifying settings. I agree with you that it could be HW, but more than likely it is a SW bug because it goes away by reverting the SW.

 

[pfuller88]

I have a RT-5300AC and RT-AC68U. Factory reset both from 384-19 to 386 beta 1. Removed USB and clean start on both. Several issues required me to revert back to 384-19...

1) I could not Aimesh the routers, tried 4 or 5 times - 5300AC could not find AC68U. When I revered back to 384, 5300AC found the AC68U node right away and connected no problem.
2) the Network Map "view client" list was only showing a subset of connected clients - it seemed to only show clients that had a static IP assigned; no wifi clients were listed. It would also go blank, no clients listed, for a second then populate back to the subset.
3) the port forwarding or DHCP did not seem to be working, not sure which. I could not reach some of my servers on LAN or via the Wan. I tried adding some IPs to the static IP list and I was then able to connect.
3) there were wifi drop outs on some devices, i.e. I have a bose home speaker, kept dropping wifi connection after 15 20 minutes.

Back to 284-19 which works well. I'll keep watching for the changes and the stable build.

A great fan of all the work done here, much appreciated.

Best Regards,
Peter

 

[Mutzli]

I have a RT-5300AC and RT-AC68U. Factory reset both from 384-19 to 386 beta 1. Removed USB and clean start on both. Several issues required me to revert back to 384-19...

1) I could not Aimesh the routers, tried 4 or 5 times - 5300AC could not find AC68U. When I revered back to 384, 5300AC found the AC68U node right away and connected no problem.
2) the Network Map "view client" list was only showing a subset of connected clients - it seemed to only show clients that had a static IP assigned; no wifi clients were listed. It would also go blank, no clients listed, for a second then populate back to the subset.
3) the port forwarding or DHCP did not seem to be working, not sure which. I could not reach some of my servers on LAN or via the Wan. I tried adding some IPs to the static IP list and I was then able to connect.
3) there were wifi drop outs on some devices, i.e. I have a bose home speaker, kept dropping wifi connection after 15 20 minutes.

Back to 284-19 which works well. I'll keep watching for the changes and the stable build.

A great fan of all the work done here, much appreciated.

Best Regards,
Peter

Is your AI-Mesh connection wired or wireless? Some users reported earlier that they had to setup AI-Mesh wired and once that was working, they were able to connect wireless.

 

[davelian]

@RMerlin is that ok if i upload router setting after a factory default reset ? I used alpha 4 in previous version. AC68U

 

[Mutzli]

@RMerlin is that ok if i upload router setting after a factory default reset ? I used alpha 4 in previous version. AC68U

No, you would load the old NVRAM values right back onto the new firmware. See also this post.

 

[octopus]

Just WPS reset and configure again and seem working fine. My vpn clients working now client1 and 3.
Haven't yet connected my Aimesh node(s)

RPDB Rules
0: from all lookup local
10001: from all to 213.136.63.73 lookup main
10101: from 192.168.12.153 lookup ovpnc1
10102: from 192.168.12.111 lookup ovpnc1
10103: from 192.168.12.157 lookup ovpnc1
10104: from 192.168.12.216 lookup ovpnc1
10401: from all to 213.136.63.73 lookup main
10501: from 192.168.12.116 lookup ovpnc3
32766: from all lookup main
32767: from all lookup default

Table ovpnc1
default via 10.128.0.1 dev tun11
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.2.157
10.129.0.0/22 dev tun13 proto kernel scope link src 10.129.1.206 <<<=== Just curious why this is here?
Table ovpnc2
Table ovpnc3
default via 10.129.0.1 dev tun13
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.2.157 <<<=== Just curious why this is here?
10.129.0.0/22 dev tun13 proto kernel scope link src 10.129.1.206
Table ovpnc4
Table ovpnc5

Table main
default via 15x.174.xxx.x dev eth0

Seems this testing string can't distinguish between tun11 and tun13

echo -e "\n\t"RPDB Rules;ip rule;echo;for I in 1 2 3 4 5;do echo -e "\t"Table ovpnc$I;ip route show table 11$I | grep -E "^0\.|^128.|^default|^prohibit|tun1";done;echo -e "\n\t"Table main;ip route show table 254 | grep -E "^0\.|^128.|^default"

octopus@RT-AX86U-EA08:/tmp/home/root# routes
Table 254
default via 15x.174.xxx.x dev eth0
Table 111
default via 10.128.0.1 dev tun11
Table 112
Table 113
default via 10.129.0.1 dev tun13
Table 114
Table 115

Also getting this in log:

2020-12-06 15:28:12 net_route_v4_best_gw query: dst 0.0.0.0
2020-12-06 15:28:12 sitnl_route_save: rtnl: can't get ifname for index 0: No such device or address (errno=6)
2020-12-06 15:28:12 TUN/TAP device tun11 opened
2020-12-06 15:28:12 TUN/TAP TX queue length set to 1000
2020-12-06 15:28:12 net_iface_mtu_set: mtu 1500 for tun11
2020-12-06 15:28:12 net_iface_up: set tun11 up
2020-12-06 15:28:12 net_addr_v4_add: 10.128.2.157/22 dev tun11
2020-12-06 15:28:12 ovpn-up 1 client tun11 1500 1553 10.128.2.157 255.255.252.0 init
2020-12-06 15:28:14 NOTE: unable to redirect IPv4 default gateway -- Cannot read current default gateway from system
2020-12-06 15:28:14 Initialization Sequence Completed

Thank you @RMerlin

 

[dave14305]

@LimJK @Slawek P
If anyone wants to point me in the direction of where the built-in speedtest binary lives in 386 I can make a version of spdmerlin to use that instead of the version I downloaded from Ookla, to see if it performs any better?

Should be /usr/sbin/ookla. You can test by downloading from https://github.com/RMerl/asuswrt-me...elease/src/router/ookla_speedtest/OOKLA-36521

 

[Aerandir14]

@LimJK @Slawek P
If anyone wants to point me in the direction of where the built-in speedtest binary lives in 386 I can make a version of spdmerlin to use that instead of the version I downloaded from Ookla, to see if it performs any better?

Not sure it would make a difference though.

I just compared spdMerlin, Asus's speedtest and Speedtest on my Desktop (Intel AX200) with my AX86U and a 1Gbps internet connection and here are the results:

Spoiler

However, this morning, I succeeded to get 950Mbps+ download speed with the Asus's speedtest...

 

[rlj2]

@LimJK @Slawek P
If anyone wants to point me in the direction of where the built-in speedtest binary lives in 386 I can make a version of spdmerlin to use that instead of the version I downloaded from Ookla, to see if it performs any better?

/usr/sbin/ookla

command:
ookla -c http://www.speedtest.net/api/embed/vz0azjarf5enop8a/config -f jsonl

 

[RamGuy]

Are there any changes for Full-Cone NAT support? Any reason to avoid upgrading or any additional hardware getting support for Full-Cone NAT?

 

[Jack Yaz]

Should be /usr/sbin/ookla. You can test by downloading from https://github.com/RMerl/asuswrt-me...elease/src/router/ookla_speedtest/OOKLA-36521

inspecting the files, there are different options available to the one downloaded as speedtest-cli

 

[Jack Yaz]

/usr/sbin/ookla

command:
ookla -c http://www.speedtest.net/api/embed/vz0azjarf5enop8a/config -f jsonl

hm. looks like asus have a custom config and license etc.
i probably can't re-use their binary in spdmerlin

does running /usr/sbin/ookla work without any arguments?

 

[hifiwifi]

Just WPS reset and configure again and seem working fine. My vpn clients working now client1 and 3.

Does your WAN stay up if you stop/start a client? I'm experiencing that right now.

 

[CarlyElise]

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_41035. 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

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 for your ongoing efforts with this project! ISSUE found that is affecting firewall logging. It appears that it is not logging the OUT port information which is needed to determine the direction of traffic (inbound/outbound) This changed in the previous alpha. I have uninstalled skynet and the results are the same. Below is the example of what i'm seeing.

Inbound Block & Accept Being logged
Outbound Blocked being logged
Outbound Accept NOT being logged at all.

Alpha & Beta Not logging the OUT= "interface"
Dec 6 09:34:05 kernel: DROP IN=eth0 OUT= MAC=0c:9d:92:01:8d:68:00:ca:e5:3d:c4:19:08:00 SRC=173.249.33.72 DST=xxxxxx LEN=125 TOS=0x00

Dec 6 09:34:11 kernel: DROP IN=eth0 OUT= MAC=0c:9d:92:01:8d:68:00:ca:e5:3d:c4:19:08:00 SRC=185.45.195.151 DST=xxxxxx LEN=92 TOS=0x00

Dec 6 09:34:15 kernel: DROP IN=eth0 OUT= MAC=0c:9d:92:01:8d:68:00:ca:e5:3d:c4:19:08:00 SRC=77.57.81.80 DST=xxxxx LEN=132 TOS=0x00 PREC=0x00


Previously
Outbound Traffic Would log the outbound interface

Dec 1 23:39:38 kernel: ACCEPT IN=br0 OUT=eth0 MAC=0c:9d:92:01:8d:68:b8:bc:5b:f4:0a:a6:08:00 SRC=192.168.1.119

Dec 1 23:39:38 kernel: ACCEPT IN=br0 OUT=eth0 MAC=0c:9d:92:01:8d:68:b8:bc:5b:f4:0a:a6:08:00 SRC=192.168.1.119

Merlin, any thoughts on this would be greatly appreciated. thanks.

 

[JoJoDaClown]

Is your AI-Mesh connection wired or wireless? Some users reported earlier that they had to setup AI-Mesh wired and once that was working, they were able to connect wireless.

I have the exact same issues as Peter, I have AC5300 and AC88U. I've tried wired and wireless. I had only the node and main with PC connected to main; no other connections. I've tried every type of reset and setup, to no avail. When I revert back, and then reset, I can set up AiMesh without issue. There's something wrong with this build and the AC5300.

 

[JWoo]

Never had that issue here


Tried this this morning and can confirm clicking through the UI caused my AX58U to crash and reboot. Something very strange there.

There are now 3 of us so far that can confirm that rapidly clicking through the menu system (for example to check your settings) on 386 Beta 1 causes the RT-AX58U to crash and reboot.

 

[Deleted member 22229]

There are now 3 of us so far that can confirm that rapidly clicking through the menu system (for example to check your settings) on 386 Beta 1 causes the RT-AX58U to crash and reboot.

Yes confirmed i can also confirm the issue is not present in the latest stock firmware.

 

[Slawek P]

hm. looks like asus have a custom config and license etc.
i probably can't re-use their binary in spdmerlin

does running /usr/sbin/ookla work without any arguments?

No it does not - it is missing configuration file and only way to supply it appears to be url. No idea what this file is - it is neither CLI or Ookla server, perhaps it is Asus closed source.

asus:/www# /usr/sbin/ookla --help
Version: ookla 3.6.5.2

Usage: ookla [<options>]
  -h, --help                        Print usage information.
  -V, --version                     Print version number.
  -L, --servers                     List nearest servers
  -s, --server-id=#                 Specify a server, from the configuration, using its id
  -I, --interface=ARG               Bind to the specified interface when connecting to servers.
  -i, --ip=ARG                      Bind to the specified IP address when connecting to servers.
  -o, --host=ARG                    Specify a server, from the configuration, using its host's fully qualified domain name
  -t, --trace-level=#               [Deprecated: See -v] Specify a log level between 1 and 2 (1=info, 2=error)
  -p, --progress=yes|no             Enable or disable progress bar (default = on when interactive).
  -P, --precision=#                 Number of decimals to use (default = 2, valid = 0-8).
  -f, --format=ARG                  Output format (see below for valid formats).
  -u, --unit[=ARG]                  Output unit for displaying speeds (Note: this is only applicable
                                    for ‘human-readable’ output format and the default unit is Mbps).
  -a                                Shortcut for [-u auto-decimal-bits].
  -A                                Shortcut for [-u auto-decimal-bytes].
  -b                                Shortcut for [-u auto-binary-bits].
  -B                                Shortcut for [-u auto-binary-bytes].
      --selection-details           Show server selection details.
      --ca-certificate=ARG          CA Certificate bundle path
  -v                                Logging verbosity. Specify multiple times for higher verbosity.
      --delta-perf                  Output raw average speed since the last measurement.
  -m, --max-transfer-updates=#      Maximum number of log outputs during download/upload tests
  -l, --listen[=#]                  Start a local server, listening on the specified port, instead of running a test.
  -c, --config-url=ARG              Config url override

Looking at https://myrouter/internet_speed.html it calls do_speedTest_exe("", cur_server_id)
which looks as follows in same html - cgis nowhere to be found, must be Asus closed source

function do_speedTest_exe(exe_type, server_id){
var start = new Date();
var type = "";
var id = "";
test_start_time = start.getTime();
set_ookla_start_time(test_start_time);
if(typeof exe_type !== "undefined")
type = exe_type;
if(typeof server_id !== "undefined")
id = server_id;
$.ajax({
url: "/ookla_speedtest_exe.cgi",
type: "POST",
data: {
"type": type,
"id": id
}

BTW - if there's a slow down I mentioned it is both on CLI you are using and Asus Ookla page, so if Asus fixed it then it is likely for both. I will install beta in on the weekday to confirm