Asus TUF AX4200 support

[filippz]

@variant6

Thanks and interesting that you're also having 160mhz issues. I know my mesh nodes don't support 160mhz so haven't ruled this out as a problem yet. Do you see them change the channels too, or see the phantom 6ghz frequencies when they don't work?

When I try setting it to 36 and applied it the Luci reported 36 (6.130 GHz).

@variant6

How many networks are you running at a time?
I have 2 on 2.4ghz, and 1 & mesh on 5ghz. If I add anything to either they remain perpetually disabled.

I'm running 2 SSIDs on 2,4 GHz, and 2 SSIDs on 5GHz (one of those being mesh). I was lazy and adapted the config from C2600 so I haven't observed any issues by adding SSIDs from Luci - I tried it just now and it went OK.

@variant6

I'll try to break things with iw scan if I get some time and also look for the sae blocked issues. That might be from DFS blocking the wifi if it comes up on ch100 which would be expected.

Since you are using mesh it might be the same issue as mine. Maybe your nodes become "isolated" and your clients connected to them stop working the same as mine? In any case iw scan could help reproduce the behavior (you can just try the "Luci" way with the same result). If I'm reading the log correctly, SAE errors appear after the the DFS scan has already been done.

[variant6]

@filippz

When I try setting it to 36 and applied it the Luci reported 36 (6.130 GHz)

This is what I got out of logread -f when I am having channel issues @160. hostapd: could not get valid channel

20:38:28 2024 daemon.notice hostapd: phy1-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
20:38:29 2024 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->HT_SCAN
20:38:29 2024 daemon.err hostapd: could not get valid channel
20:38:29 2024 daemon.notice hostapd: phy1-ap0: interface state HT_SCAN->DFS

With the mesh off, changing to 160mhz ch 36:

20:46:04 2024 daemon.notice hostapd: phy1-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
20:46:04 2024 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->HT_SCAN
20:46:05 2024 daemon.notice netifd: Wireless device 'radio1' is now up
20:46:05 2024 daemon.notice hostapd: Switch own primary and secondary channel to get secondary channel with no Beacons from other BSSes
20:46:05 2024 daemon.notice hostapd: phy1-ap0: interface state HT_SCAN->DFS
20:46:05 2024 daemon.notice hostapd: phy1-ap0: DFS-CAC-START freq=5200 chan=40 sec_chan=-1, width=2, seg0=50, seg1=0, cac_time=60s

Something is off in the tangled mess of 160mhz, DFS, country codes, and channel selection.

For note, HR has a different reg setting in 5g (extra power and no outdoor restriction) to the rest of EU so have jumped between that a few times to see if there are changes.

I didn't get to try to kick anything off with iw scan but feel lucky to have 80mhz back on ch100. 160mhz seems to work on ch36 without a mesh ap.

[filippz]

Yes - something is definitely off when combining mesh, channels and friends. I'm by no means expert but I can't imagine that this would specific to AX4200. For me using ch 100 is not an issue, but still I'd like to know whats going on...
In my case I do have 160MHz setting working, but the mesh is not using it, while clients can/do:

My main concern is the intermittent stopping of the traffic over mesh which (assuming it's the same issue) can also be triggered by doing an ip scan and I'm out of ideas how to debug this further as tcpdump is showing ARP packets from one side of the mesh coming to the other and the reply from other side not being received by the originating side.

[andrehanekom]

I just want to find out, if I roll back from OpenWRT to AsusWRT with the firmware restore tool does that also delete/remove any partitions that OpenWRT created? Or is there still things left behind.

[variant6]

I think I briefly had the 160mhz ap + 80mhz mesh on ch 36 earlier.

Since there appears to be a max 2 APs, order probably matters for a scan. Disable your 5ghz AP and try the scan, if the mesh stays connected you're hitting that limit by trying to scan for other APs.

When my setup goes sideways, the mesh jumps to channel 149 and my power is limited to 13db

[variant6]

R7800 - 5Ghz breaks after DFS radar detection

5Ghz VHT160 on channel 100 breaks on radar DFS event and never comes back

Hi, I have an issue with VHT160 and DFS as if there is an radar event 5Ghz breaks complete and forever. It seems that it is not implemented (or faulty) in hostapd to revive the connection of the radar is gone. I also do not like to use 36 as fallback Openwrt will stay on that channel forever and it has less power. Does anybody know if this is known and perhaps somebody working on it? The Issue and discussion is from last year and I am sure somebody else should run into this. Should be fixed wi…

I haven't seen DFS detected in the logs yet but haven't been looking. This comes up looking for the valid channel with some interesting ways to test the fallback channels for later. The only valid 160mhz non DFS range is in the 6ghz space, which might explain how it gets to 149. Half of ch36@160 needs DFS so it might get skiped.

option channel 'auto'
option channels '100 36'

I don't see a way to drop to 80mhz on DFS detection. It also shouldn't kill the whole range, just that freq.

[remittor]

@andrehanekom

I just want to find out, if I roll back from OpenWRT to AsusWRT with the firmware restore tool does that also delete/remove any partitions that OpenWRT created? Or is there still things left behind.

I did not test this rollback option, since this utility refused to work on my system.
I advise you to rollback using facinstall, since in this case I can say for sure that all volumes created for OpenWRT will be deleted.

[andrehanekom]

I did follow this facinstall method. When the router rebooted I could ping it, but the login page did not want to open. There was only a Luci weblink but nothing else like the prompt to enter username / password. So I did a Emergency restore with the Asus tool and that worked 100%. But now I am not sure what garbage is left behind on the device.

[remittor]

@andrehanekom

But now I am not sure what garbage is left behind on the device.

Command for checking: ubinfo /dev/ubi0 -a

[andrehanekom]

Thank you, will paste the output here. Can I run this command on normal Asus WRT firmware? SSH

[andrehanekom]

Hi there. Herewith the output

Volumes count: 6
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 2016 (255983616 bytes, 244.1 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 40
Current maximum erase counter value: 8
Minimum input/output unit size: 2048 bytes
Character device major/minor: 250:0
Present volumes: 0, 1, 2, 3, 4, 5

Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1 LEBs (126976 bytes, 124.0 KiB)
State: OK
Name: nvram
Character device major/minor: 250:1

Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 8 LEBs (1015808 bytes, 992.0 KiB)
State: OK
Name: Factory
Character device major/minor: 250:2

Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 8 LEBs (1015808 bytes, 992.0 KiB)
State: OK
Name: Factory2
Character device major/minor: 250:3

Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 578 LEBs (73392128 bytes, 70.0 MiB)
State: OK
Name: linux
Character device major/minor: 250:4

Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 578 LEBs (73392128 bytes, 70.0 MiB)
State: OK
Name: linux2
Character device major/minor: 250:5

Volume ID: 5 (on ubi0)
Type: dynamic
Alignment: 1
Size: 799 LEBs (101453824 bytes, 96.8 MiB)
State: OK
Name: jffs2
Character device major/minor: 250:6
ahanekom@TUF-AX4200-1FDA:/tmp/home/root#

[andrehanekom]

Correct TUG AX4200

[filippz]

@variant6

Since there appears to be a max 2 APs, order probably matters for a scan. Disable your 5ghz AP and try the scan, if the mesh stays connected you're hitting that limit by trying to scan for other APs.

I already have only mesh active on 5GHz for my secondary - scan still breaks it.

@variant6

When my setup goes sideways, the mesh jumps to channel 149 and my power is limited to 13db

I haven't noticed that (at least after after a scan) - I'll keep my eye on it but we might actually experiencing different issues after all.

[variant6]

I think we have different problems too, 160mhz width detects a radar and all it changes immediately. The phy1-mesh0 doesn't seem to wait for another dfs, jumps to 149 while the phy-ap0 tries to scan on ch36 (160mhz requirement. I'm pretty sure there's a race or problem in the channel switch logic. The 6ghz channels would be a natural fit for 160mhz but this router can't use them so there's a bug there.

daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->DFS
daemon.notice hostapd: phy1-ap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
daemon.notice hostapd: phy1-ap0: DFS-CAC-COMPLETED success=0 freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0
daemon.notice hostapd: phy1-ap0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0
daemon.notice wpa_supplicant[1628]: phy1-mesh0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0
daemon.notice wpa_supplicant[1628]: phy1-mesh0: DFS-NEW-CHANNEL freq=5745 chan=149 sec_chan=1
daemon.notice hostapd: phy1-ap0: DFS-NEW-CHANNEL freq=5180 chan=36 sec_chan=1
daemon.notice hostapd: phy1-ap0: interface state DFS->DFS
daemon.notice hostapd: phy1-ap0: DFS-CAC-START freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
daemon.err hostapd: DFS start_dfs_cac() failed, -1
daemon.notice hostapd: phy1-ap0: interface state DFS->DISABLED

ch149 is expected to be 13db and 80MHz
(5725 - 5875 @ 80), (N/A, 13), (N/A)

I think some of my mania is related to the DFS channels being blocked for 30 minutes after I hit something on freq 5570 width 5. I'll try to scan with another AP on the 100 and 116 channel range to see if I really have a radar hit.

[variant6]

Ok, my 160mhz problem is definitely radar. I tested this with another AP on the 116 channel and it dropped out as quick as the ax4200. It also exhibited the same attempt to jump to a 6ghz channel so I think that's a bug in hostapd.

daemon.notice hostapd: phy1-ap0: DFS-RADAR-DETECTED freq=5580 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5610 cf2=0

I haven't had the general wifi failure for while now but am a bit better equipped to track it in logs now.

[SiliconWolf]

I have used your method @remittor and that workerd.

However i flashed the upgrade that is on the openwrt page for the AX4200, and my lan internet was gone, router still had connection as i could install packages and ping.

Is there something obvious that i missed?

Flashed your file again and it works.
I would like to flash the stock as your version gives me json parse error when updating any package.

Thanks in advance!

[variant6]

Just in time for the wifi crash!

kern.alert kernel: [345509.078843] Unable to handle kernel write to read-only memory at virtual address 0000000000000000
kern.alert kernel: [345509.087807] Mem abort info:
kern.alert kernel: [345509.090673]   ESR = 0x0000000096000045
kern.alert kernel: [345509.094497]   EC = 0x25: DABT (current EL), IL = 32 bits
kern.alert kernel: [345509.099895]   SET = 0, FnV = 0
kern.alert kernel: [345509.103025]   EA = 0, S1PTW = 0
kern.alert kernel: [345509.106239]   FSC = 0x05: level 1 translation fault
kern.alert kernel: [345509.111196] Data abort info:
kern.alert kernel: [345509.114154]   ISV = 0, ISS = 0x00000045
kern.alert kernel: [345509.118072]   CM = 0, WnR = 1
kern.alert kernel: [345509.121117] user pgtable: 4k pages, 39-bit VAs, pgdp=000000004672e000
kern.alert kernel: [345509.127637] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000

[remittor]

@variant6

I'm on a snapshot

@variant6

Just in time for the wifi crash!

kern.alert kernel: [345509.078843] Unable to handle kernel write to read-only memory at virtual address 0000000000000000

snapshot? Build date?

[variant6]

r24688-8b706d9297 Busybox was 23.12 so roughly then.

[variant6]

mt7615: tx.c: Kernel crash in mt76_tx

The occurrence during FT roaming matches last night and the dates line up. I'll try a new snapshot.