[ 388.2 alpha Build(s) ] Testing available build(s)

[ZebMcKayhan]

I'm getting 700-800 with wireguard on my asus rtax86u,on official fw I get 500 at best so big improvement

I would be suspicious at this number. If I were to guess you are measuring data going over wan and not vpn. Your router cannot make that speed with software nat and wireguard encryption. If you are using ipv6 merlin fw does not support ipv6 over vpn but your device used for speed test will probably prefer ipv6 and this goes over wan.

 

[seabass]

Thanks for taking the time to reply. I wasn't sure the wireless portion was part of the proprietary blob. I typically avoid the stock fw because of its instability but gave 22237 a try and it was a nice surprise to see the 2.4 clients working fine. Hopefully merlinwrt will eventually catch up with that release. I will give this a try to see how stable it is and go back to Merlin at the first sight of issues

I had similar issues with guest wifi on my AX6000 and AX11000 with 388.1. My setup was from scratch each time, and each time I experienced strange connectivity issues with guest network clients, and in some cases non-guest connections too, which made it all very strange and mysterious. The issue was not about failing to connect but rather a failure to route to the internet. I could connect to the management UI even though I couldn't connect to the internet. That all said, I eventually fixed this, but the fix wasn't entirely clear, I believe it had something to do with enabling native IPv6.

Since all the above, I've also tried from scratch configurations again. Those yielded success which I attributed to configuring my router live (i.e. with a valid WAN connection) rather than my original attempts which we all offline pre-configuration attempts. I did this so I could quickly drop in the new preconfigured router in place of my old one.

My experiences seem to show that order of configuration operations and/or being connected to WAN seem to matter.

Of course, this was all very frustrating and hugely time consuming. I've since decided to wait for something newer than 388.1 before trying again (there are other issues with the latest firmware on AX class routers related to TAP based site-to-site VPN tunnels)

*Note I need custom scripts for my site-to-site configuration, so I can't use sock ASUS, hence another reason I'm waiting...

 

[octopus]

New builds Alpha2

Microsoft OneDrive

onedrive.live.com

For now aviable:
RT-AX88U
RT-AX58U
RT-AX56U

 

[PR3MIUM]

AiMesh Bug ?

Will try to Format JFFS and doing a HardReset, having massive Speed decrease arround 40-80Mbit/s from 250Mbit/s only.

 

[Zastoff]

Smooth Update from 388.1 to 388.2_alpha2-g9dba35b46c on AX88u.

Thanks RMerlin

 

[Deleted member 84281]

AiMesh Bug ?

View attachment 48185

Will try to Format JFFS and doing a HardReset, having massive Speed decrease arround 40-80Mbit/s from 250Mbit/s only.

Possibly but Aimesh is closed source and nothing can be done to fix it. Run stock firmware if you want working Aimesh.

 

[octopus]

AiMesh Bug ?

View attachment 48185

Will try to Format JFFS and doing a HardReset, having massive Speed decrease arround 40-80Mbit/s from 250Mbit/s only.

Try to first delete then and reconnect again and test.

 

[PR3MIUM]

Formated JFFS and did a HardReset, the AiMesh was first connected then disconnected after 2 minutes.
Then the connection to 192.168.50.1 wasnt possible and tried it with router.asus.com wich worked.
Then in the UI everything was totaly laggy and took forever to switch to other Settings or Apply any Settings.
Could maybe also a driver Bug from Intel (channel 7209061)

After 5 more minutes all fine again and the Speed is back too.
Left side shows not connected but all are connected and working well.

 

[Tvbaas]

@PR3MIUM
Did you update all 3 AX88u units with the merlin firmware?
For best AiMesh results , just update your main AX88u router with merlin "RT-AX88U_388.2_alpha2-g9dba35b46c" and the other 2 AX88u AiMesh nodes with the standard Asus firmware version 3.0.0.4.388.22525 .

 

[PR3MIUM]

Now they are gone again under the AiMesh TAB and I saw them only in the First TAB.

Having on all 3 the same Firmware.
From the LOG:

Feb 25 22:39:50 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.94 8c:xx
Feb 25 22:39:50 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.94 8cxx DESKTOP-xx
Feb 25 22:39:51 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:39:51 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:40:04 bsd: bsd: Sending act Frame to 8c:xx with transition target eth7 ssid 3c:xx
Feb 25 22:40:05 bsd: bsd: STA:8c:xx no response
Feb 25 22:40:05 bsd: bsd: Sending act Frame to 8c:xx with transition target eth7 ssid 3c:xx
Feb 25 22:40:06 bsd: bsd: STA:8c:xx no response
Feb 25 22:40:23 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:40:23 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:40:36 hostapd: eth6: STA 8c:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Feb 25 22:40:36 bsd: bsd: Sending act Frame to 8c:xx with transition target eth7 ssid 3c:xx
Feb 25 22:40:37 bsd: bsd: STA:8c:xx no response
Feb 25 22:40:37 bsd: bsd: Sending act Frame to 8c:xx with transition target eth7 ssid 3c:xx
Feb 25 22:40:39 bsd: bsd: STA:8c:xx no response
Feb 25 22:40:42 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 8C:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 25 22:40:42 hostapd: eth6: STA 8c:xx IEEE 802.11: disassociated
Feb 25 22:40:55 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:40:55 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:41:27 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:41:27 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:41:59 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:41:59 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:42:31 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:42:31 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:43:03 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:43:03 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:43:35 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:43:35 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958
Feb 25 22:44:07 dnsmasq-dhcp[12103]: DHCPREQUEST(br0) 192.168.50.55 0c:xx
Feb 25 22:44:07 dnsmasq-dhcp[12103]: DHCPACK(br0) 192.168.50.55 0c:xx RT-AX88U-D958

Now 1 is connected and the other 1 is disconneted again.
Maybe tomorrow I have better Luck.

 

[STRUZZIN]

All AX58U & Mesh Units on A2 working great so far.

 

[PR3MIUM]

All working fine now, on AiMesh the 2 others are connected and the connection is very stable

Just the AiMesh Site is a little messed up I think.
When having a look at the AiMesh TAB it says not connected and ....

.... after waiting 20 seconds it changes to connected, the only bug and nothing to worry about

 

[Zastoff]

Seems that I cannot connect to my open vpn servers after update from 388.1 to alpha 2
Wireguard server works fine.
Cannot see that it is even trying to connect in router syslog or vpn status page to the openvpn servers.
I am using openvpn for android app to connect and from what i can see in that log is

09:49 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.

Have i missed something? Do i need to reconfigure my openvpn servers?
Or could it be that the app I use is outdated for this version of openvpn in this alpha?

 

[bar1]

Seems that I cannot connect to my open vpn servers after update from 388.1 to alpha 2
Wireguard server works fine.
Cannot see that it is even trying to connect in router syslog or vpn status page to the openvpn servers.
I am using openvpn for android app to connect and from what i can see in that log is

09:49 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.

Have i missed something? Do i need to reconfigure my openvpn servers?
Or is could it be that the app I use is outdated for this version of openvpn in this alpha?

Got the exact same experience going to alpha 2 from 388.1 (RT-AX88U);
OpenVPN clients can't connect to server. I've tried to reconfigure OpenVPN server.. no change. No obvious error msgs in the log.
Wireguard server ok.

 

[paul0363]

Got the exact same experience going to alpha 2 from 388.1 (RT-AX88U);
OpenVPN clients can't connect to server. I've tried to reconfigure OpenVPN server.. no change. No obvious error msgs in the log.
Wireguard server ok.

Same issue for me. No clients can connect to server. Connection attempt hangs and no connection made. Client side log:

Sun Feb 26 11:33:02 2023 Note: Treating option '--ncp-ciphers' as '--data-ciphers' (renamed in OpenVPN 2.5).
Sun Feb 26 11:33:02 2023 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Sun Feb 26 11:33:02 2023 OpenVPN 2.6.0 [git:v2.6.0/b999466418dddb89] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Jan 25 2023
Sun Feb 26 11:33:02 2023 Windows version 10.0 (Windows 10 or greater), amd64 executable
Sun Feb 26 11:33:02 2023 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
Sun Feb 26 11:33:05 2023 TCP/UDP: Preserving recently used remote address: [AF_INET]xx:xx:xx:xx:1194
Sun Feb 26 11:33:05 2023 UDPv4 link local: (not bound)
Sun Feb 26 11:33:05 2023 UDPv4 link remote: [AF_INET]xx:xx:xx:xx:1194

 

[elorimer]

388.2 upgrades to Openvpn 2.6, which deprecates some settings like compression and ciphers. Could that be it? Is the connection made, but no traffic flows, or is the connection refused?

 

[bar1]

I've tried AsusWRT 388.2 (300438822525) and had no problem with OpenVPN.

Router log taken from OpenVPN server start and trying to connect one 5G client (iphone):
Looks like there is no connection.

rc_service: httpd 1151:notify_rc restart_chpass;restart_vpnserver1
ovpn-server1[25349]: OpenVPN 2.6.0 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
ovpn-server1[25349]: library versions: OpenSSL 1.1.1t  7 Feb 2023, LZO 2.08
ovpn-server1[25350]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
ovpn-server1[25350]: PLUGIN AUTH-PAM: initialization succeeded (fg)
ovpn-server1[25350]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY
ovpn-server1[25350]: Diffie-Hellman initialized with 2048 bit key
ovpn-server1[25350]: TUN/TAP device tun21 opened
ovpn-server1[25350]: TUN/TAP TX queue length set to 1000
ovpn-server1[25350]: /usr/sbin/ip link set dev tun21 up mtu 1500
vpnserver1[25352]: PLUGIN AUTH-PAM: BACKGROUND: initialization succeeded
ovpn-server1[25350]: /usr/sbin/ip link set dev tun21 up
ovpn-server1[25350]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24
ovpn-server1[25350]: ovpn-up 1 server tun21 1500 0 10.8.0.1 255.255.255.0 init
ovpn-server1[25350]: Socket Buffers: R=[524288->524288] S=[524288->524288]
ovpn-server1[25350]: UDPv4 link local (bound): [AF_INET][undef]:1194
ovpn-server1[25350]: UDPv4 link remote: [AF_UNSPEC]
ovpn-server1[25350]: MULTI: multi_init called, r=256 v=256
ovpn-server1[25350]: IFCONFIG POOL IPv4: base=10.8.0.2 size=253
ovpn-server1[25350]: Initialization Sequence Completed

If client is on my wifi-network, it connects but no data transmitted:

ovpn-server1[25350]: 192.168.50.171:61568 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-AX88U, emailAddress=me@myhost.mydomain
ovpn-server1[25350]: 192.168.50.171:61568 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_VER=3.git::081bfebe
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_PLAT=ios
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_NCP=2
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_TCPNL=1
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_PROTO=30
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_GUI_VER=net.openvpn.connect.ios_3.3.2-5086
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_SSO=webauth,openurl,crtext
ovpn-server1[25350]: 192.168.50.171:61568 peer info: IV_BS64DL=1
ovpn-server1[25350]: 192.168.50.171:61568 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
ovpn-server1[25350]: 192.168.50.171:61568 TLS: Username/Password authentication succeeded for username 'client_1'
ovpn-server1[25350]: 192.168.50.171:61568 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
ovpn-server1[25350]: 192.168.50.171:61568 TLS: tls_multi_process: initial untrusted session promoted to trusted
ovpn-server1[25350]: 192.168.50.171:61568 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
ovpn-server1[25350]: 192.168.50.171:61568 [client] Peer Connection Initiated with [AF_INET]192.168.50.171:61568 (via [AF_INET]193.zz.yy.xx%br0)
ovpn-server1[25350]: client/192.168.50.171:61568 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
ovpn-server1[25350]: client/192.168.50.171:61568 MULTI: Learn: 10.8.0.2 -> client/192.168.50.171:61568
ovpn-server1[25350]: client/192.168.50.171:61568 MULTI: primary virtual IP for client/192.168.50.171:61568: 10.8.0.2
ovpn-server1[25350]: client/192.168.50.171:61568 Data Channel: using negotiated cipher 'AES-256-GCM'
ovpn-server1[25350]: client/192.168.50.171:61568 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
ovpn-server1[25350]: client/192.168.50.171:61568 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
ovpn-server1[25350]: client/192.168.50.171:61568 SENT CONTROL [client]: 'PUSH_REPLY,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,key-derivation tls-ekm' (status=1)
ovpn-server1[25350]: client/192.168.50.171:61568 PUSH: Received control message: 'PUSH_REQUEST'
ovpn-server1[25350]: client/192.168.50.171:61568 SIGUSR1[soft,remote-exit] received, client-instance restarting

Last line is client disconnect.

 

[Mutzli]

I updated my routers this morning and the only problem I have right now is some of the connected clients are not showing on the client list. They do show all up in the wireless log. The wireless log shows 26 connected devices plus another 4 wired clients for a total of 30 clients. On the client list from the home page I have only 13 total connected. I tried a reboot and refresh to no avail. I asume this could have something to do with AiMesh, since it takes about 30 seconds to show any clients on that page and there are even more missing with only 11 total showing.

 

[octopus]

Seems that I cannot connect to my open vpn servers after update from 388.1 to alpha 2
Wireguard server works fine.
Cannot see that it is even trying to connect in router syslog or vpn status page to the openvpn servers.
I am using openvpn for android app to connect and from what i can see in that log is

09:49 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.

Have i missed something? Do i need to reconfigure my openvpn servers?
Or could it be that the app I use is outdated for this version of openvpn in this alpha?

I had problems with the last release.
It turned out that all the certificates has been regenerated again.
Put the old ones in and it connected again.

 

[bar1]

I had problems with the last release.
It turned out that all the certificates has been regenerated again.
Put the old ones in and it connected again.

I did. Also tried to reconfigure OpenVPN from default. Didn't solve connection issue.