[Thread-1] [ 386.1_Alpha Build(s) ] Testing available build(s)

[octopus]

https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0

@RMerlin @thiggins is it possible to have "Alpha" prefix also?

New model, support is still being gradually implemented, it's a work-in-progress.
Early development, I have not uniformized build profiles yet.
Folks, I cannot stress this enough. These are ALPHA builds. That means work in progress, a lot of things are still being actively implemented. So yes, expect things to not be done yet, this is normal. Until it reaches official beta stage, expect things to NOT fully be implemented yet.

NEW ALPHA4 BUILD(S) date (2020-11-30)
RT-AC3100
RT-AC5300
RT-AC68U
RT-AC86U
RT-AC88U
RT-AX56U
RT-AX88U
RT-AX58U
RT-AX86U
GT-AC2900

NEW ALPHA3 BUILD(S) date (2020-11-22)
RT-AC3100
RT-AC5300
RT-AC68U
RT-AC86U
RT-AC88U
RT-AX56U
RT-AX88U
RT-AX58U
RT-AX86U
GT-AC2900

NEW ALPHA3 BUILD(S) date (2020-11-14)
RT-AC3100
RT-AC5300
RT-AC68U
RT-AC86U
RT-AC88U
RT-AX56U
RT-AX58U
RT-AX86U
RT-AX88U

NEW ALPHA2 BUILD(S) date (2020-11-03)
Available build(s)
RT-AC3100
RT-AC5300
RT-AC68U
RT-AC86U
RT-AC88U
RT-AX56U
RT-AX88U

386.1 (xx-xx-xxxx)
Switched to the new 386 codebase. 386 introduces
AiMesh 2.0, finalizes the move to OpenSSL 1.1.1
firmware-wide, adds a new speedtest (powered
by Ookla). For more details, please refer
to Asus's own release notes.

- NOTE: For developers, note that firmware code is
once again back on the master branch, with
both mainline and ax being reunified again.

- NEW: Added support for the RT-AX86U.
- NEW: Added stub and stub-v2 compression options to OpenVPN
clients. Not added to server, since compression is
considered deprecated, and will be removed most likely
in OpenVPN 2.6, for security reasons.
- NEW: Added tls-crypt-v2 support to OpenVPN clients.
- UPDATED: Merged GPL 386_40577 (beta GPL from Asus).
- UPDATED: Openssl to 1.1.1h.
- UPDATED: Updated to OpenVPN 2.5.0. Note that OpenVPN
2.4.0 or newer is now required by the exported
client config file.
- UPDATED: nano to 5.2.
- UPDATED: curl to 7.72.0.
- UPDATED: zlib to 1.2.11.
- UPDATED: lz4 to 1.9.2.
- UPDATED: e2fsprogs to 1.45.6.
- UPDATED: dropbear to 2020.81.
- CHANGED: firmware update checks are no longer using the
server address stored in nvram, for security
purposes. Devs who were using that nvram
should instead edit the webs_scripts/* to
use their own URL.
- CHANGED: The old legacy cipher setting is now only available
when running with static key authentication.
- CHANGED: Tweaks to the OpenVPN webui layout
- CHANGED: OpenVPN clients will now NAT all outbound traffic,
regardless of the source subnet.
- CHANGED: Reworked the display of DNSPrivacy presets
- CHANGED: Added AdGuard (ad blocking) and CIRA Canadian Shield
(non US-based service) to the DNSPrivacy presets.
- CHANGED: At boot time, OpenVPN killswitch will only be
applied for clients set to auto-start with WAN.
- CHANGED: Increased number of available mount points for addon
webpages to 20.
- FIXED: DHCP could fail to renew its lease with some ISPs when
Trend Micro engine was enabled (workaround provided
by Asus)
- REMOVED: Option to disable NCP. The NCP cipher list is
now used both for NCP and non-NCP endpoints.
- REMOVED: fq_codel support for Adaptive QoS. Due to a change
in how Trend Micro configures QoS, it is no longer
possible to intercept these to inject fq_codel.
- REMOVED: Support for the Cloudcheck mobile app.

 

[octopus]

I have tested and it's working fine.

Only thing is nvram show strange value. exclamation mark blink.

size: 63058 bytes (2478 left)
NVRAM usage 63127 / 65536 bytes bytes.


Uptime 0 days 0 hour(s) 8 minute(s) 54 seconds

 

[princi]

Great news!

The built-in Ookla speedtest sounds fantastic!

EDIT: Errr, said goodbye to the 68U long ago.
Will be keeping an eye out for 86U and AX-88U.

 

[S.claus]

It really sucks that fq_codel doesn't work with the new builds.

 

[Vexira]

It really sucks that fq_codel doesn't work with the new builds.

its not really that big of an issue, what really sucks is that ASUS hasn't made FQ_Codel native to adaptive qos, like netgear did to their qos.

if it becomes added to adaptive qos by asus themselves adaptive qos would be 100 times better.

 

[Treadler]

its not really that big of an issue, what really sucks is that ASUS hasn't made FQ_Codel native to adaptive qos, like netgear did to their qos.

if it becomes added to adaptive qos by asus themselves adaptive qos would be 100 times better.

Im currently running FlexQos just using sfq.
For my admittedly modest needs, working fine.

 

[hifiwifi]

I had a few issues and quickly rolled back to 384.19:

1. First try at upgrading failed. Router stayed at 384.19. Upgrade worked after hard reboot.
2. Any changes to VPN client would drop WAN connection. Would reconnect with ethernet cable unplug/plug.
3. AMTM failed to check for script updates.

Looking forward to progress on this! Thanks for your work, Merlin.

 

[AurelM]

First of all, a big thank you @RMerlin for all your continued development on this great firmware!

Since the file on onedrive is the bare .trx firmware and as far as I can see there is no hash/checksum of the file, after downloading, it has the following SHA256 hash:

91211c9d7fa3943222003cd8ed15bd6f27986b67be942a99beabbca86f9d2fa3 RT-AC68U_386.1_alpha2-g7f3d8269b3.trx

I've done a dirty update over AsusWRT-Merlin 384.19_0 using Mozilla Firefox 81.0.2 (latest) web browser in private mode with the following steps:
1. in Administration - Restore/Save/Upload Setting (/Advanced_SettingBackup_Content.asp), saved router settings (Save settings button) and backed up JFFS partition (Save button) of the current (384.19_0) firmware. This was done so that I could restore the router to this known good configuration in case I have any problems with updating the firmware (of course, I also have the current firmware on my pc);
2. in Network Map (/index.asp), under USB 2.0, safely removed the single usb flash drive I have connected to the router (Remove button). This was done so that RAM can be freed and be used in the firmware update process (which gives a better chance of successful update);
3. in Administration - Firmware Upgrade (/Advanced_FirmwareUpgrade_Content.asp), uploaded the new firmware (Upload text);
4. waited for the update process to finish, logged back in the router's WebUI and checked that the new version is being used;
5. connected to the router's terminal using ssh protocol and putty software and shutdown the router with halt command. Arguably it would be better to safely remove the usb drives like before, but I didn't do this;
6. unplugged the router's power supply from it's wall socket;
7. waited ~20 seconds for the residual electrical power in the various capacitors to be consumed;
8. plugged the power supply back in the wall socket;
9. after the router has finished booted, saved the router's settings and JFFS partition with the new firmware installed, just as I did in step 1.

A step that I didn't do now, but could help if there are issues with some WebUI elements is to close the browser and open a new private session while the router is booting after step 8 so that there are no cookies and/or cache stored for it. Alternatively one can force a refresh with CTRL+F5 or SHIFT+refresh button to tell the browser to disregard any cache it has (I did this since the new firmware has a new menu entry that had no icon before the forced refresh).

At this point I consider the update to be done and now I start checking the logs and various functions of the router, as well as the scripts that are installed on the usb flash drive.

So, the first thing I check for is that the internet is working, but this should be obvious since step 4 above as I would have internet on the pc I'm using to do the update from.
Then I proceed to check that OpenVPN server is working and that another remote router that is an OpenVPN client is connected to it. Also, I use my mobile phone with the carrier's internet to connect to the vpn server.
While using the phone I check that WiFi also works.
Next I go to System Log (/Main_LogStatus_Content.asp) and look at the log from the last reboot. I'm not going line by line (although this would be best), but browse through it to see if there is something obviously wrong. Checking for word error is also a good idea.
After this, I go through the different script's WebUI page and then to the terminal (again ssh with putty) and check the scripts that they are running, mostly using amtm.

Now I consider all done and come to this forum and read other people experiences and post my own.

_______________________________________________________
This update I had an issue in the log:

[date&time] [hostname] crond[252]: user [username]: parse error at Thu
[date&time] [hostname] crond[252]: user [username]: parse error at sh
[date&time] [hostname] crond[252]: user [username]: parse error at /opt/share/diversion/file/update-bl.div
[date&time] [hostname] crond[252]: user [username]: parse error at Thu
[date&time] [hostname] crond[252]: user [username]: parse error at sh
[date&time] [hostname] crond[252]: user [username]: parse error at /opt/share/diversion/file/update-bl.div
[date&time] [hostname] crond[252]: user [username]: parse error at Thu
[date&time] [hostname] crond[252]: user [username]: parse error at sh
[date&time] [hostname] crond[252]: user [username]: parse error at /opt/share/diversion/file/update-bl.div

I had this in cron (cru l):

[...]
00 2 * * Thu sh /opt/share/diversion/file/update-bl.div reset #Diversion_UpdateBL#
* * Thu sh /opt/share/diversion/file/update-bl.div reset #Diversion_UpdateBL#
[...]

Since both have the same name, I had to delete both and re add the good one:

cru d Diversion_UpdateBL
cru a Diversion_UpdateBL "00 2 * * Thu sh /opt/share/diversion/file/update-bl.div reset"

_______________________________________________________

[...]
Only thing is nvram show strange value. exclamation mark blink.

size: 63058 bytes (2478 left)
NVRAM usage 63127 / 65536 bytes bytes.
[...]

I don't have this issue, but also my NVRAM usage is lower, at 60746 / 65536 bytes.

 

[RMerlin]

its not really that big of an issue, what really sucks is that ASUS hasn't made FQ_Codel native to adaptive qos, like netgear did to their qos.

That's up to Trend Micro to do, not Asus.

 

[RMerlin]

That build was uploaded because Asus and I were testing a DHCP-related fix with a user who was affected by it. This should still be considered early alpha, and a lot will change in the coming weeks once I move to updated GPL code from Asus.

 

[laracroftonline]

That build was uploaded because Asus and I were testing a DHCP-related fix with a user who was affected by it. This should still be considered early alpha, and a lot will change in the coming weeks once I move to updated GPL code from Asus.

i can't wait to see whats next!

 

[Frankflash]

its not really that big of an issue, what really sucks is that ASUS hasn't made FQ_Codel native to adaptive qos, like netgear did to their qos.

if it becomes added to adaptive qos by asus themselves adaptive qos would be 100


thats not going to happen any time soon thats why adaptive qos is rubbish because trend micro an't going to fix it any time soon when has trend Micro ever fixed any thing NEVER

 

[Nasua]

I have problems with pia vpn client, i get this error in the log

Oct 21 00:05:50 ovpn-client1[5495]: ERROR: Failed to apply push options
Oct 21 00:05:50 ovpn-client1[5495]: Failed to open tun/tap interface
Oct 21 00:05:50 ovpn-client1[5495]: SIGUSR1[soft,process-push-msg-failed] received, process restarting

Fallback cipher seems to be missing from client settings

 

[Blacklistedcard]

I have a problem my AC86U aimesh node. All clients that are connected to aimesh AC86U node get a 169 ip address. When I look on my main AX88U router, all the devices display their proper IP address. Everything looks fantastic.

I can't ping the devices on the aimesh AC86U node either. Anybody else experience this with their nodes and devices connected to it?

My mesh is absolutely rock solid, just the IP address issue with the devices connected to the AC86U node.

 

[Blacklistedcard]

So far on AC86U and AX88 I have not seen any other problems (ac86u aimesh node).
Firmware built from commit: 9a732a2d09fcab00463d0a9bdb983544a3cf99f5

*VPN works fine.
*amtm scripts and updates works fine.
*My ax devices are running at full ax speeds.
*My ac devices are running at their full speed.
*WAN connection is stable no drops. Running at full speed.
*All cable devices attached to the AX88U are working fine and running at their full speed.

 

[Blacklistedcard]

I have a problem my AC86U aimesh node. All clients that are connected to aimesh AC86U node get a 169 ip address. When I look on my main AX88U router, all the devices display their proper IP address. Everything looks fantastic.

I can't ping the devices on the aimesh AC86U node either. Anybody else experience this with their nodes and devices connected to it?

My mesh is absolutely rock solid, just the IP address issue with the devices connected to the AC86U node.

I can ping the AC86U Aimesh Node directly...

ping 192.168.1.70
PING 192.168.1.70 (192.168.1.70) 56(84) bytes of data.
64 bytes from 192.168.1.70: icmp_seq=1 ttl=64 time=49.0 ms
64 bytes from 192.168.1.70: icmp_seq=2 ttl=64 time=2.65 ms
64 bytes from 192.168.1.70: icmp_seq=3 ttl=64 time=1.61 ms
64 bytes from 192.168.1.70: icmp_seq=4 ttl=64 time=1.72 ms
64 bytes from 192.168.1.70: icmp_seq=5 ttl=64 time=1.81 ms
64 bytes from 192.168.1.70: icmp_seq=6 ttl=64 time=1.92 ms
64 bytes from 192.168.1.70: icmp_seq=7 ttl=64 time=2.46 ms
64 bytes from 192.168.1.70: icmp_seq=8 ttl=64 time=3.02 ms
64 bytes from 192.168.1.70: icmp_seq=9 ttl=64 time=2.87 ms
64 bytes from 192.168.1.70: icmp_seq=10 ttl=64 time=2.00 ms
64 bytes from 192.168.1.70: icmp_seq=11 ttl=64 time=1.71 ms
64 bytes from 192.168.1.70: icmp_seq=12 ttl=64 time=2.28 ms
64 bytes from 192.168.1.70: icmp_seq=13 ttl=64 time=1.99 ms
64 bytes from 192.168.1.70: icmp_seq=14 ttl=64 time=2.11 ms

I can also ssh into the AC86U aimesh node fine.

ASUSWRT-Merlin RT-AC86U 386.1_alpha2-g9a732a2d09 Tue Oct 20 23:00:21 UTC 2020
admin@RT-AC86U-F210:/tmp/home/root# ls

 

[RMerlin]

I have problems with pia vpn client, i get this error in the log

Oct 21 00:05:50 ovpn-client1[5495]: ERROR: Failed to apply push options
Oct 21 00:05:50 ovpn-client1[5495]: Failed to open tun/tap interface
Oct 21 00:05:50 ovpn-client1[5495]: SIGUSR1[soft,process-push-msg-failed] received, process restarting

Fallback cipher seems to be missing from client settings

All ciphers are defined in the data-ciphers setting. There is no separate fallback cipher.

 

[cvee]

Wish me luck... installing now.
Luckily i use a 5300 bridged to a 3200... as Aimesh between 5300 and 68U just won't work right with ALL my IOT devices.

So i have a spare 68U to test on until aimesh becomes stable enough at some future date.
Not sure i'll see any huge difference as i'm only running 68u as Node... so new ui won't be visible.

 

[Nasua]

Has anyone made pia vpn client work ?

I'm getting this error

Oct 21 07:54:38 ovpn-client1[8265]: OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC') if you want to connect to this server.
Oct 21 07:54:38 ovpn-client1[8265]: ERROR: Failed to apply push options
Oct 21 07:54:38 ovpn-client1[8265]: Failed to open tun/tap interface
Oct 21 07:54:38 ovpn-client1[8265]: SIGUSR1[soft,process-push-msg-failed] received, process restarting
Oct 21 07:54:43 ovpn-client1[8265]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 21 07:54:43 ovpn-client1[8265]: TCP/UDP: Preserving recently used remote address: [AF_INET]188.126.94.122:1197
Oct 21 07:54:43 ovpn-client1[8265]: UDP link local: (not bound)
Oct 21 07:54:43 ovpn-client1[8265]: UDP link remote: [AF_INET]188.126.94.122:1197
Oct 21 07:54:45 ovpn-client1[8265]: [copenhagen403] Peer Connection Initiated with [AF_INET]188.126.94.122:1197
Oct 21 07:54:46 ovpn-client1[8265]: OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC') if you want to connect to this server.
Oct 21 07:54:46 ovpn-client1[8265]: ERROR: Failed to apply push options
Oct 21 07:54:46 ovpn-client1[8265]: Failed to open tun/tap interface
Oct 21 07:54:46 ovpn-client1[8265]: SIGUSR1[soft,process-push-msg-failed] received, process restarting
Oct 21 07:54:51 ovpn-client1[8265]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 21 07:54:51 ovpn-client1[8265]: TCP/UDP: Preserving recently used remote address: [AF_INET]188.126.94.105:1197
Oct 21 07:54:51 ovpn-client1[8265]: UDP link local: (not bound)
Oct 21 07:54:51 ovpn-client1[8265]: UDP link remote: [AF_INET]188.126.94.105:1197

No problems with 384.19

 

[AurelM]

Have you tried to adding BF-CBC to your openvpn client 1 Data ciphers field, just like the first line in the log says? (the field should be:
CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC:BF-CBC )

Also, isn't BF-CBC the cipher that your openvpn client 1 uses to connect in 384.19? (maybe this is set in the Legacy/fallback cipher field, which is no longer used in 386.1_alpha2 as @RMerlin said above)