[Beta] Asuswrt-Merlin 384.16 beta (and 384.13_5) are available

[piporomero]

Hi guys, i have an ax88u with 384.16 beta1 and I think i found a bug. I disable the 802.11ax support and when the router is rebooted its enable again. Anyone is having the same issue? thanks

 

[wiz]

updated 5300 to 16 beta 1. 2.4 network was dropping clients and iphones could not connect . 5.2 wifi worked fine. Tried a few changes to 2.4 wifi settings, no change. went back to version 15 and working fine. it was a dirty flash.

I had this when I went to 315. Reset to factory default and manually reconfigure mine did the trick.

 

[Sora]

Uh... it doesn't look like normal. Is this intended? Or is it a bug?
I use 1000Mbps internet service
The speed doesn't always come out
It often fluctuates at a rate of 700 Mbps to 500 Mbps or below, and the graph scale fluctuates frequently, which is very confusing. Is there any option to specify graph scale separately?

 

[FTC]

Hi, I found this morning a strange message in the log exactly at 2:00 AM :

"The for ALL DEVICES flag of prof 1 has been set to ENABLE"

Is this normal ? I had never seen this in the past...

 

[Maghook]

Hi guys, i have an ax88u with 384.16 beta1 and I think i found a bug. I disable the 802.11ax support and when the router is rebooted its enable again. Anyone is having the same issue? thanks

Noticed this glitch only with the initial setup wizard on my AX88U (setting up in ap mode). There you could disable 802.11ax on global basis but after rebooting it's still enabled on both bands. So yes, there is a glitch I guess in the ASUS code at that point.

 

[JGrana]

Hi, I found this morning a strange message in the log exactly at 2:00 AM :

"The for ALL DEVICES flag of prof 1 has been set to ENABLE"

Is this normal ? I had never seen this in the past...

I have an AX88U running 316b1.
I did a grep "prof 1 has been set" in syslog.*
I don't see this message.

 

[RMerlin]

Uh... it doesn't look like normal. Is this intended? Or is it a bug?
I use 1000Mbps internet service

The graph will base its scale on the highest record speed while you display it. So unless you fully load your connection, it won't be able to know what its upper limit is.

It's not perfect (as there is no simple way to make it), but it's good enough for its intended use.

"The for ALL DEVICES flag of prof 1 has been set to ENABLE"

Trend Micro engine debug output indicating its state. Was probably added at the same time Asus implemented white listing support. So, this is normal.

 

[Simon W]

Was probably added at the same time Asus implemented white listing support. So, this is normal.

Ah so this is new(ish) then.. I discovered it for the first time the other day, didn't think I'd seen it before!

 

[Davidncali001]

So I thought this was supposed to look like this because it was a work in progress. Any idea how this happened and maybe what I can do to fix it?

 

[RMerlin]

So I thought this was supposed to look like this because it was a work in progress. Any idea how this happened and maybe what I can do to fix it?

Open the browser console and look for any Javascript error.

 

[Delusion]

The graph will base its scale on the highest record speed while you display it. So unless you fully load your connection, it won't be able to know what its upper limit is.

It's not perfect (as there is no simple way to make it), but it's good enough for its intended use.

But after a while the graph 'forgets' the upper limit. Maybe a setting to set the upper limits manually will work? otherwise, the graphs are very confusing and maybe it's even better leaving only speed numbers without the graphs

 

[Mike S]

Asuswrt-Merlin 384.16 Beta (and 384.13_5 for RT-AC87U and RT_AC3200) are now available.

The focus of this release was the addition of two new models, the RT-AX58U (and it's RT-AX3000 cousin) and the RT-AX56U.

I am also formally announcing that as of now, the RT-AC87U and RT-AC3200 are on limited support (which has already been the case for the last two releases, I'm just making it official now since the solutions I investigated didn't work out). The main reason is these two models are no longer based on the same code as their other recent models, and that older code is no longer compatible with mine, making it impossible for me to compile my latest GPL code for these two models. If eventually Asus decides to bring them back on the same codebase as the other main models (like the RT-AC68U or RT-AC88U) then I will be able to bring them back into full support mode. However if it doesn't happen in the near future, then I will eventually be forced to completely drop these two models. For now I just backported a few fixes to them, see the 384.13_5 changelog for details.

The highlights of this release:

• Added support for the RT-AX58U, RT-AX3000 and RT-AX56U.
• Merged GPL 384_8253 (for AX models).
• Merged 384_7977 binary blobs for the RT-AX88U.
• Updated components: Tor (0.4.2.6), curl (7.68.0), nano (4.8), inadyn (2.6), getdns (1.6.0), stubby (0.3.0), amtm (3.1.4).
• The Wireless Log page will now show Guest clients separately from the regular ones.
• Added traffic meter to the main status page. To save space, I removed the mostly useless RAM chart (but it will still report usage itself)
• Fixed VPN clients being unable to use the router as their DNS server.
• Fixed miniupnpd refusing to work if WAN IP was a private IP (was only partly fixed in the past)
• And a few other minor fixes to the webui

The following will require extended testing.

RT-AX56U and RT-AX58U:

• IPSec VPN Server
• AiCloud services
• USB disk sharing performance
• Ipset
• And everything else in general, but these are more important

RT-AC87U and RT-AC3200:

• Just make sure that there were no regressions in the couple of backports made to these two (see their changelog for details)

Please keep discussions in this thread for these specific beta releases and the changes introduced by them. Off-topic posts may be moved, deleted or ignored based on my humor at the time.


Downloads are here.
Changelog is here.

I just updated my RT-AC68P with 384.16_beta1. Everything seems to be working, except for one bug, that also exists in 384.14:

When I configure the router (at my home) with a Guest WiFi SSID, guests are able to access an OpenVPN tunnel that connects to another Asus router at my office location. The guests have full access to my office LAN.

My understanding is that the guests should only be able to access the internet and no computers on my local LAN. This is working correctly, except for the ability to access remote locations thru my OpenVPN tunnel.

Any chance you could fix this in this release?

Thanks,

 

[bengan65]

All good on my AX56U

Hello,
have you got openvpn client to working on that beta!!
tryed flash but after have flashed says connecting use airvpn
should do hardware reset after have flashed that beta

 

[RMerlin]

Any chance you could fix this in this release?

Can't be done. Technically, a VPN tunnel is part of the Internet, not part of the local network.

 

[RMerlin]

But after a while the graph 'forgets' the upper limit.

There's no reason for it to "forget" the value, it's a Javascript variable, so it will remain valid for as long you are on that page. If it somehow gets wiped, then something is wrong with your browser.

Maybe a setting to set the upper limits manually will work?

No. Feature bloat, nobody would even be aware of its existence, and it would waste precious nvram space while some routers are desperately running low on available nvram space already.

 

[bengan65]

Tryed that beta not luck vpn is connecting nothing more.
Can some help me tryed but going not good.
When have flashed cant see in log if vpn client is connected or not but when flash back to asus firmware then can see in logg
is connected but not seeing that ip-adress from vpn provider.
very strange
another thing both beta and asus firmware try use airvpn dns server then my wan port showing red ligth but could surfing on internet that strange too.
was contact with asus support they say is something wrong with my router

 

[Mike S]

Can't be done. Technically, a VPN tunnel is part of the Internet, not part of the local network.

As an alternative, would it be possible to have two separate DHCP address pools; One for the regular SSIDs and one for Guest SSIDs? That would make it possible to use the OpenVPN Client Policy Rules to force the Guests to use the WAN interface only.

 

[Martineau]

As an alternative, would it be possible to have two separate DHCP address pools; One for the regular SSIDs and one for Guest SSIDs? That would make it possible to use the OpenVPN Client Policy Rules to force the Guests to use the WAN interface only.

Use a 3rd part script, or you can add a firewall rule.

e.g. you probably could insert a generic blocking rule such as

iptables -I OVPN -i wl+ -o tun1+ -j DROP -m comment --comment "Block ALL Guest interfaces thru ANY VPN Client"

or explicit interfaces

iptables -I OVPN -i wl0.1 -o tun13 -j DROP -m comment --comment "Block 2.4 GHz Guest 1 thru via VPN Client 3"

You should implement the rule using one of the openvpn-event trigger scripts

e.g. assuming you use the openvpn-event template script, you would create
vpnclientX-route-up

iptables -D OVPN -i wl+ -o tun1+ -j DROP -m comment --comment "Block ALL Guest interfaces thru ANY VPN Client"
iptables -I OVPN -i wl+ -o tun1+ -j DROP -m comment --comment "Block ALL Guest interfaces thru ANY VPN Client"

 

[GC70]

I will need the content of that ovpn file to check, as this setting is based upon the content, and the handling is different between older legacy models like the RT-AC87U and the other models.

Hi Merlin, the files i'm using are the ExpressVPN config files; I tried many, for some different server, doesn't matter the location, but any time I decide to change and upload .ovpn file, only this setting stays uncheked (RT-AX88U)

I can attach one of them, just for example

Thanks in advance for your kindly time
my best regards

dev tun
fast-io
persist-key
persist-tun
nobind
remote usa-newjersey-3-ca-version-2.expressnetw.com 1195

remote-random
pull
comp-lzo no
tls-client
verify-x509-name Server name-prefix
ns-cert-type server
key-direction 1
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1200
verb 3
cipher AES-256-CBC
keysize 256
auth SHA512
sndbuf 524288
rcvbuf 524288
auth-user-pass

.....Certificate
.....Keys

 

[Simon W]

The much discussed new graph (current upload/download speed on the main page) is, in my opinion, a nice visual add-on that @RMerlin has introduced = a good use of page space, thanks.

But I can't believe the amount of airtime and chatter this is now causing.. colours, scale, Mbs vs/ MB/s etc.. seriously?!

• Asus provide a good, if not in some areas feature-deficient, and often buggy, firmware.
• @RMerlin takes this and does a wonderful job of cleaning it up, including fixing / updating some key areas.
• Job done. As I understand it, that's the totality of this projects goal. Rinse and repeat for new firmware versions, all the time with an element of continuous improvement.

I mean, sure, there are plenty of areas I'd personally like further developing. But I'd be rightly referred to the 3rd bullet above - beyond the scope of the project.

Surely, if time is available (which I'm certain is at a premium in any event) there are more fundamental things to improve/tweak/whatever, no?!

Still, don't let me stop the discussion. But I might suggest, if you are really concerned about your routers current throughput, rather than relying on a graph you seem unhappy with - one that wasn't even there before - may I draw your attention to the more detailed Traffic Analyser pane.. there you go - made for the job!

</rant over>