Beta Asuswrt-Merlin 386.2 Beta is now available

[raven-au]

20-March-2021: Beta 2 is now available. Changes since Beta 1:

snip...

I'm looking for more feedback from RT-AX68U and GT-AX11000 owners.

Possibly not that useful but I have installed beta 2 on my AX11000 last night.
I'm using the AX11000 as the AiMesh main node with two XT8 nodes.
I'm not using any addons, only AiProtection, Adaptive QOS/Automatic Setting on a 50/20 WAN link and CleanBrowsing DoT DNS.
I want to see how it goes before adding any functionality.
So far it seems to be working fine, I'll report any difficulties if they arise.

 

[drinkingbird]

On 500 mbps I had around 520 real, but on 1gbps I have the 940.

What's overhead?

Yes that makes sense, since your 500 meg connection was running on a 1 gig physical ethernet which left plenty of room for overhead beyond the 500M. However now that you are 1 gig speed over a 1 gig physical connection, the overhead has to come out of your usable bandwidth, since it can't to beyond 1 gig. At some point there will be 10 gig physical connections (well they are already very common but not in residential) at which point you'll be able to get a full gig of usable throughput (well, much more assuming they start offering multi-gig plans).

Overhead is the extra stuff you don't see that is needed to be able to send data from one place to the other (source address, destination address, various other parameters). To send 1 megabit of data actually requires around 1.05 megabits of bandwidth, and that is ideal conditions, full sized packets, etc. It can go as high as 20% for small packet sizes.

With some tweaking and very low latency between you and the test server the theoretical max is about 950mbits. With jumbo frames enabled, it can go as high as about 990 but that really only applies to LAN connections (PC to PC) since that isn't supported over the internet at this point, and probably never will be.

 

[SomeWhereOverTheRainBow]

snip...


Possibly not that useful but I have installed beta 2 on my AX11000 last night.
I'm using the AX11000 as the AiMesh main node with two XT8 nodes.
I'm not using any addons, only AiProtection, Adaptive QOS/Automatic Setting on a 50/20 WAN link and CleanBrowsing DoT DNS.
I want to see how it goes before adding any functionality.
So far it seems to be working fine, I'll report any difficulties if they arise.

I have been running my GT-AX11000 on the Beta for a while now. No signs of trouble yet. @RMerlin keeps getting it better and better.

 

[Maasamda]

AX88 - 386.2 beta2, someone else also having problems with OpenVPN server? Advanced settings, Manage Client-Specific Options to "Yes" and Allow Client <-> Client to "Yes". As a result, client access is only possible for 1 client, although other clients are listed on the general page. Switching both back to "No" and everything works fine again.

 

[Maasamda]

AX88 - 386.2 beta2, someone else also having problems with OpenVPN server? Advanced settings, Manage Client-Specific Options to "Yes" and Allow Client <-> Client to "Yes". As a result, client access is only possible for 1 client, although other clients are listed on the general page. Switching both back to "No" and everything works fine again.

Sorry, is AX86!

 

[heysoundude]

Yes that makes sense, since your 500 meg connection was running on a 1 gig physical ethernet which left plenty of room for overhead beyond the 500M. However now that you are 1 gig speed over a 1 gig physical connection, the overhead has to come out of your usable bandwidth, since it can't to beyond 1 gig. At some point there will be 10 gig physical connections (well they are already very common but not in residential) at which point you'll be able to get a full gig of usable throughput (well, much more assuming they start offering multi-gig plans).

Overhead is the extra stuff you don't see that is needed to be able to send data from one place to the other (source address, destination address, various other parameters). To send 1 megabit of data actually requires around 1.05 megabits of bandwidth, and that is ideal conditions, full sized packets, etc. It can go as high as 20% for small packet sizes.

With some tweaking and very low latency between you and the test server the theoretical max is about 950mbits. With jumbo frames enabled, it can go as high as about 990 but that really only applies to LAN connections (PC to PC) since that isn't supported over the internet at this point, and probably never will be.

I'm happy you've brought up jumbo frames. They're worth learning up on, and the excellent article on the smallnetbuilder website should help clear the subject up in your brains like it did mine.

Need To Know: Jumbo Frames in Small Networks - SmallNetBuilder

http://forums.smallnetbuilder.com/forumdisplay.php?f=19

www.smallnetbuilder.com

 

[RMerlin]

AX88 - 386.2 beta2, someone else also having problems with OpenVPN server? Advanced settings, Manage Client-Specific Options to "Yes" and Allow Client <-> Client to "Yes". As a result, client access is only possible for 1 client, although other clients are listed on the general page. Switching both back to "No" and everything works fine again.

Using the Client-specific options require each client to have a certificate with a unique common name, because it's used to identify which client rule to apply. However duplicate CNs are now rejected by default, since this is the recommended configuration by OpenVPN, and it improves security. This was changed a few releases ago (I forgot which exact release, might have been with 384.19 or 386.1).

If you still need to use client specific options and don`t want to generate unique client certificates for each client, then you will need to allow the use of the username as common name, or duplicate common names (which may not lead to the desired result however if you expect different client rules). Try either of these:

duplicate-cn

Or

username-as-common-name

in your Custom Settings.

 

[Maasamda]

Using the Client-specific options require each client to have a certificate with a unique common name, because it's used to identify which client rule to apply. However duplicate CNs are now rejected by default, since this is the recommended configuration by OpenVPN, and it improves security. This was changed a few releases ago (I forgot which exact release, might have been with 384.19 or 386.1).

If you still need to use client specific options and don`t want to generate unique client certificates for each client, then you will need to allow the use of the username as common name, or duplicate common names (which may not lead to the desired result however if you expect different client rules). Try either of these:

duplicate-cn

Or

username-as-common-name

in your Custom Settings.

Thanks!

 

[RMerlin]

28-March-2021: Beta 3 is now available. Changes since Beta 2:

ebfec843d1 Updated documentation
89ddc423a0 webui: fix duplicate variable introduced with 73e5ec95e2
73e5ec95e2 webui: Fix timezone detection (#729)
a8b66a50f3 webui: move main content down on index page when the disabled wifi warning banner is shown
60bcbe7027 webui: allow changing https LAN port while in AP mode
0bbc055140 build: no longer explicitely disable NFCM
ce8af5c05d Bumped revision to beta 3
2f7a878aad kernel: proper fix for wlan accumulating stats issue
cd7c5b268b openssl: update to 1.1.1k
9c5335994d rc: make entries in passwd and shadow be in the same order
f0b7578887 webui: fix display of connected IPSEC clients on VPNStatus page; added display of IKEv2 clients
29c13bc4e5 Merge pull request #725 from dave14305/patch-1
e618da48ba rc: do not use dnsfilter_custom when querying the server table for an IPv6
e45995ce66 rc: Rearrange Cake variable positions

 

[shabbs]

28-March-2021: Beta 3 is now available.

Nice. Let's DO THIS.

EDIT: Dirty upgrade from Beta 2 for all my devices - no issues so far. All devices re-connected.

 

[MvW]

Dirty upgrade from beta 2 to beta 3 on both my devices, went flawless, they came back up without issues. All seems to be working fine, no strange things in syslog. Will report if I find something out of the ordinary, but I don't expect to do so. Eric, many thanks for your continous effort.

Best regards,
Marco

 

[nzwayne]

Perfect timing for Beta3 release, wife out shopping for an hour (quiet yippeee.... Fortunately for me the dirty upgrade from Beta2 to Beta3, all went well perfectly to reconnect devices (usually around 30-35). Didn't spot anything weird in panels/logs in a quick peek.
As I've learnt with ASUS routers after significant changes, later on (minimum of an hour) perform a power off/on cycle. Then check panels, settings, logs, which devices are connecting where via my smartconnect setup etc.

 

[gerardr]

Performed a dirty upgrade to Beta3 from Beta2 this afternoon. The functionality seems fine. HOWEVER, on the LAN page / the DHCP Server tab, the table of defined clients is empty (I have 23 defined). The /jffs/nvram files dhcp_hostnames and custom_clientlist are both the same as in earlier firmware versions with the 23 entries. On the Network Map page's Client List pop-up the entries are correct in terms of the host's names and IP and MAC addresses, as well as their new icons. Sorry, I cannot for certain say that it was filled in with Beta2. The device is an RT-AX3000 running the RT-AX58U firmware.

 

[GHammer]

Performed a dirty upgrade to Beta3 from Beta2 this afternoon. The functionality seems fine. HOWEVER, on the LAN page / the DHCP Server tab, the table of defined clients is empty (I have 23 defined). The /jffs/nvram files dhcp_hostnames and custom_clientlist are both the same as in earlier firmware versions with the 23 entries. On the Network Map page's Client List pop-up the entries are correct in terms of the host's names and IP and MAC addresses, as well as their new icons. Sorry, I cannot for certain say that it was filled in with Beta2. The device is an RT-AX3000 running the RT-AX58U firmware.

Are you using YazDHCP? If so, try just reinstalling it. I had the same on an earlier version and a reinstall solved the issue. All entries were there, just not loaded for some reason until the reinstall. Permissions likely.

 

[GHammer]

Dirty upgrade from b1 , all is well for my install. Port forwards, YazDHCP, IPv6 firewall entries, cake.

 

[LimJK]

Fixed IKEv1 client display, and added IKEv2 client display.

Dirty Flashed 386.2 beta3 over beta2.
Confirm that this is fixed in 386.2 beta3
Thank You!

Edit: By the way, successful iOS Instant Guard (IPSec under the hood) connection is also shown as IKEv1 client on the VPN Status Page. Thank You!

 

[shabbs]

Maybe a beta 3 with OpenSSL 1.1.1k as well? (after Thursday)

Forthcoming OpenSSL release

mta.openssl.org

You got your wish...

Source:

https://twitter.com/x/status/1376249274380468227

 

[gerardr]

Are you using YazDHCP? If so, try just reinstalling it. I had the same on an earlier version and a reinstall solved the issue. All entries were there, just not loaded for some reason until the reinstall. Permissions likely.

Hi! Not using YazDHCP. Had to do a web search to even know what it was, sorry. I've looked around a bit, and noticed that in the nvram, there is no 'dhcp_hostnames=' entry (an empty definition). There are both empty and filled entries for dhcp_staticlist and custom_clientlist, but no empty entry for dhcp_hostnames.

 

[jata]

Hi! Not using YazDHCP. Had to do a web search to even know what it was, sorry. I've looked around a bit, and noticed that in the nvram, there is no 'dhcp_hostnames=' entry (an empty definition). There are both empty and filled entries for dhcp_staticlist and custom_clientlist, but no empty entry for dhcp_hostnames.

I have seen this issue where the dhcp manual assignments get dropped very occasionally in the past. Usually the dhcp server assigns the correct IPs to devices so I just re-added the manual assignments and was done.

I think you have quite a few manually assigned IPs so it might be worth installing YazDHCP that allows you to hold many more entries (as the high number of manual dhcp assignments might be what has caused this issue in the first place).

Sorry I can't be more help.

 

[XIII]

You got your wish...

Yes, I knew it was coming:

openssl: update to 1.1.1k · RMerl/asuswrt-merlin.ng@cd7c5b2

Third party firmware for Asus routers (newer codebase) - openssl: update to 1.1.1k · RMerl/asuswrt-merlin.ng@cd7c5b2

github.com

Did not know when though... (expected/hoped this weekend)

So: thanks again RMerlin!