What's new

Beta Asuswrt-Merlin 388.1 Beta is available for select models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I have more items on the pop out menus then I think are suppose to be there. I have cleared cache and tried different browsers and all have the same.
ax86u on beta2

Adaptive QoS
Traffic Analyzer
USB App
IPv6
VPN

Some samples
1668269419767.png
1668269474373.png
 
Noticed AX86U_Pro moniker. What is the difference between AX86U and AX86U_Pro? Just CPU speed?
 
Dirty upgrade from beta1 and no issues to report.
 
Can I get some help from a fellow AX88U Wireguard user, please? Can you take one of your Wireguard routed devices, and assign a different DNS (than it uses) in DNS Director, and then check to make sure before and after the change with DNS leak test? Please report what you find.

Before (nothing special specified in DNS Manager):
1668274769172.png



After (Quad9 assigned to device in DNS Manager):
1668274692526.png
 
Think I found a small GUI-glitch... Under both 2,4 and 5 Ghz I see only "Enable" as the only choice under "Enable WMM". Tried both Brave and Firefox after full browser-cache wipe.

View attachment 45390
WMM is mandatory for newer wifi standards, so if you have Wifi mode set to anything other than Legacy, it will be hardcoded to Enable. This is normal and by design.
have more items on the pop out menus then I think are suppose to be there.
This popup comes from a third party script and not the firmware itself. Uninstall that popup if it doesn't behave correctly, it might not be compatible with this firmware version.
 
I have more items on the pop out menus

Yeah... you have more items installed than this beta firmware. When testing beta firmware don't slap 3rd party scripts on top. Obviously none of the scripts is tested for 388 beta firmware compatibility. This is common occurrence in all beta firmware threads - unrelated to firmware issues reported.
 
@RMerlin My DNS Director works, just not when used on a Wireguard device. I took a device out of the Wireguard tunnel. I was able to manipulate it's DNS as usual with DNS Director. I left the device configured in DNS Director (with 8.8.8.8 as a server) and put the device back into the tunnel. The DNS instruction in DNS Director remains in the GUI, but the DNS on the device is my VPN provider's DNS, as proved out with DNS leak test. A Wireguard client restart does nothing to resolve.
 
I'm also able to play with DNS on a OVPN client device without issue, just not DNS Director and Wireguard.
 
Running Beta 2. Was wondering if anyone noticed this odd behavior when setting 5ghz to Auto channel it only scans the lower channel numbers

Nov 12 15:27:52 acsd: acs_candidate_score_intf(1112): eth6: intf check failed for chanspec: 0xe832 (36/160)
Nov 12 15:27:52 acsd: acs_candidate_score_bgnoise(1577): eth6: bgnoise check failed for chanspec: 0xe832 (36/160)
Nov 12 15:27:52 acsd: acs_candidate_score_txop(1835): eth6: txop check failed for chanspec: 0xe832 (36/160)
Nov 12 15:27:52 acsd: acs_candidate_score_intf(1112): eth6: intf check failed for chanspec: 0xe932 (40/160)
Nov 12 15:27:52 acsd: acs_candidate_score_bgnoise(1577): eth6: bgnoise check failed for chanspec: 0xe932 (40/160)
Nov 12 15:27:52 acsd: acs_candidate_score_txop(1835): eth6: txop check failed for chanspec: 0xe932 (40/160)
Nov 12 15:27:52 acsd: acs_candidate_score_intf(1112): eth6: intf check failed for chanspec: 0xea32 (44/160)
Nov 12 15:27:52 acsd: acs_candidate_score_bgnoise(1577): eth6: bgnoise check failed for chanspec: 0xea32 (44/160)
Nov 12 15:27:52 acsd: acs_candidate_score_txop(1835): eth6: txop check failed for chanspec: 0xea32 (44/160)
Nov 12 15:27:52 acsd: acs_candidate_score_intf(1112): eth6: intf check failed for chanspec: 0xeb32 (48/160)
Nov 12 15:27:52 acsd: acs_candidate_score_bgnoise(1577): eth6: bgnoise check failed for chanspec: 0xeb32 (48/160)
Nov 12 15:27:52 acsd: acs_candidate_score_txop(1835): eth6: txop check failed for chanspec: 0xeb32 (48/160)
It never checks the higher numbered channels like 149.
 
Sorry if this has been asked before but how do I delete/clear an uploaded wireguard client configuration that I no longer wish to use?
 
Upgraded all my devices to beta 2 today. Did not see a direct repeat of the issue I previously had. My two AX88U nodes continue to be fine and my AX68U node stayed connected to the AIMesh. It is showing an error in the UI (attached) but devices have connected to it and are working fine as near as I can tell. There doesn't seem to be an actual issue with the node now, it just has that error. It also shows connection quality as great, and the devices attached to it have good network response and speed.

1668291994456.png
 
@RMerlin I reset to defaults and reconfigured everything by hand. No importing of settings or JFFS. If I put a DNS Server in the DNS (optional) field of the Wireguard client, I cannot manipulate the DNS of a device running through the client with DNS Director. If I leave the DNS field of the Wireguard client blank (it is optional), the DNS reported is the DoT DNS on the WAN page, as DNS Director is set to "router". Alternativly if I leave the DNS field blank in the Wireguard client, and manipulate DNS of a device in the tunnel with the DNS Director, it works great. I can change DNS back and forth. Is this the intended operation? Thanks sir.
 
Upgraded all my devices to beta 2 today. Did not see a direct repeat of the issue I previously had. My two AX88U nodes continue to be fine and my AX68U node stayed connected to the AIMesh. It is showing an error in the UI (attached) but devices have connected to it and are working fine as near as I can tell. There doesn't seem to be an actual issue with the node now, it just has that error. It also shows connection quality as great, and the devices attached to it have good network response and speed.

View attachment 45417
I have the same issue with two AX86U nodes with Beta2 (or Beta1). Putting them back to Stock firmware then all ok. Nodes of AX56U & AXE11000 with Beta2 (or Beta1) no issues. The uplink device is a AX6000.
 
The fullcone nat not being supported by kernel is that because ASUS took it out or just not there in general? An if they did take it out why would they do that?
 
I bought a new GT-AX6000 two days ago and immediately installed the new Beta1 firmware, then upgraded yesterday to Beta2.

All seems to be going OK, except that a couple of times the 2.4GHz WiFi has totally refused to accept connections after a start or reboot of the router. The problem went away after another reboot. Is there a chance that it's the beta firmware, or am I more likely to have a faulty router? The log messages look like this when I turn on debugging:

Nov 13 08:09:55 wlceventd: wlceventd_proc_event(469): wl0.1: Deauth_ind D0:BA:E4:E7:A7:FC, status: 0, reason: Disassociated due to inactivity (4)
Nov 13 08:09:56 wlceventd: wlceventd_proc_event(469): wl0.1: Deauth_ind D0:BA:E4:E7:A7:FC, status: 0, reason: Unspecified reason (1)
Nov 13 08:09:56 wlceventd: wlceventd_proc_event(505): wl0.1: Auth D0:BA:E4:E7:A7:FC, status: Successful (0)

But then it keeps looping for all devices (which are mostly my IoT devices on the 2.4 guest network).

When I tried to connect to the regular 2.4 GHz SSID with an Android tablet it came up with a message along the lines of "access point is fully occupied" (or words to that effect).
 
Status
Not open for further replies.

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top