piporomero
New Around Here
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
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.
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.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
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...
Uh... it doesn't look like normal. Is this intended? Or is it a bug?
I use 1000Mbps internet service
"The for ALL DEVICES flag of prof 1 has been set to ENABLE"
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!Was probably added at the same time Asus implemented white listing support. So, this is normal.
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?
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.
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: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.
Hello,All good on my AX56U
Any chance you could fix this in this release?
But after a while the graph 'forgets' the upper limit.
Maybe a setting to set the upper limits manually will work?
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.Can't be done. Technically, a VPN tunnel is part of the Internet, not part of the local network.
Use a 3rd part script, or you can add a firewall rule.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.
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"
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"
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 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.
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
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!