Adding OpenWrt support for Xiaomi AX3600 (Part 1)

Oh thank you. I bought this router as I have thought that I can use enough space for the packages. LOL.

Could you try changing 5Hz radio operating mode to "AC", it solved exact same problem with my Galaxy S10.
Before I was using "restart" branch for several months in WiFi 6 mode without any issues.
At first I complained here that I have no internet in a phone, but in reality it works with really limited range.
Similar to your case it works only about 3 meters from router.

I think it could be some incomaptibility when using 5GHz WiFi 6 (AX) devices.
I compared "iw phy" results from both versions and see some changes:

Dynamic SM Power Save
Beamformee STS <= 80Mhz: 3									 
Sounding Dimensions <= 80Mhz: 3

changed to

SM Power Save disabled                                
Beamformee STS <= 80Mhz: 7
Beamformee STS > 80Mhz: 3
Sounding Dimensions <= 80Mhz: 3
Sounding Dimensions > 80Mhz: 3

Is this change to Beamformee STS value 7 correct for this router?

Pleaser share the "cat /var/run/hostapd-phy0.conf" output for both the working and the non-working configuration.

I am using the 5GHz radio in AX mode on 160MHz with AC clients (phones, smart TV, etc.) but I see no range limitation between the two modes.

MOD: looking at the standard Beamformee STS <= 80Mhz: 7 can be correct, but it represents 8 space-time streams for a VHT SU PPDU. I am not sure if you can generate 8 space-time streams with only 4 antennas...

Galaxy S10 does not support 160Mhz. It does not find network at all, so I am using 80Mhz.
Old "restart" branch version that works:

OpenWrt SNAPSHOT r17747-05c152b104 80MHz
root@AX6:~# cat /var/run/hostapd-phy0.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=a
beacon_int=100
dtim_period=2
channel=36
chanlist=36

tx_queue_data2_burst=2.0
ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
ieee80211ac=1
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]
ieee80211ax=1
he_oper_chwidth=1
he_oper_centr_freq_seg0_idx=42
he_su_beamformer=1
he_mu_beamformer=1
he_default_pe_duration=4
he_rts_threshold=1023
he_mu_edca_qos_info_param_count=0
he_mu_edca_qos_info_q_ack=0
he_mu_edca_qos_info_queue_request=0
he_mu_edca_qos_info_txop_request=0
he_mu_edca_ac_be_aifsn=8
he_mu_edca_ac_be_aci=0
he_mu_edca_ac_be_ecwmin=9
he_mu_edca_ac_be_ecwmax=10
he_mu_edca_ac_be_timer=255
he_mu_edca_ac_bk_aifsn=15
he_mu_edca_ac_bk_aci=1
he_mu_edca_ac_bk_ecwmin=9
he_mu_edca_ac_bk_ecwmax=10
he_mu_edca_ac_bk_timer=255
he_mu_edca_ac_vi_ecwmin=5
he_mu_edca_ac_vi_ecwmax=7
he_mu_edca_ac_vi_aifsn=5
he_mu_edca_ac_vi_aci=2
he_mu_edca_ac_vi_timer=255
he_mu_edca_ac_vo_aifsn=5
he_mu_edca_ac_vo_aci=3
he_mu_edca_ac_vo_ecwmin=5
he_mu_edca_ac_vo_ecwmax=7
he_mu_edca_ac_vo_timer=255

radio_config_id=2409f7dd4ab4aa1422a73f773050e136
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=0
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
sae_require_mfp=1
wpa_passphrase=*********
wpa_psk_file=/var/run/hostapd-wlan0.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=AX6_5G
bridge=br-lan
		   
snoop_iface=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=SAE
okc=1
ieee80211w=2
group_mgmt_cipher=AES-128-CMAC
dynamic_vlan=0
vlan_naming=1
vlan_no_bridge=1
vlan_file=/var/run/hostapd-wlan0.vlan
config_id=6e7a3b12db469efde991bf3ba51e1b88
										  
bssid=9c:9d:7e:xx:xx:xx

Newest robimarko release image does not work:

OpenWrt SNAPSHOT r0-6001a6f 80MHz
root@AX6:~# cat /var/run/hostapd-phy0.conf
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=a
beacon_int=100
dtim_period=2
channel=36
chanlist=36

tx_queue_data2_burst=2.0
ieee80211n=1
ht_coex=0
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
ieee80211ac=1
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=42
vht_capab=[RXLDPC][SHORT-GI-80][SHORT-GI-160][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMER][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][VHT160-80PLUS80][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]
ieee80211ax=1
he_oper_chwidth=1
he_oper_centr_freq_seg0_idx=42
he_su_beamformer=1
he_mu_beamformer=1
he_default_pe_duration=4
he_rts_threshold=1023
he_mu_edca_qos_info_param_count=0
he_mu_edca_qos_info_q_ack=0
he_mu_edca_qos_info_queue_request=0
he_mu_edca_qos_info_txop_request=0
he_mu_edca_ac_be_aifsn=8
he_mu_edca_ac_be_aci=0
he_mu_edca_ac_be_ecwmin=9
he_mu_edca_ac_be_ecwmax=10
he_mu_edca_ac_be_timer=255
he_mu_edca_ac_bk_aifsn=15
he_mu_edca_ac_bk_aci=1
he_mu_edca_ac_bk_ecwmin=9
he_mu_edca_ac_bk_ecwmax=10
he_mu_edca_ac_bk_timer=255
he_mu_edca_ac_vi_ecwmin=5
he_mu_edca_ac_vi_ecwmax=7
he_mu_edca_ac_vi_aifsn=5
he_mu_edca_ac_vi_aci=2
he_mu_edca_ac_vi_timer=255
he_mu_edca_ac_vo_aifsn=5
he_mu_edca_ac_vo_aci=3
he_mu_edca_ac_vo_ecwmin=5
he_mu_edca_ac_vo_ecwmax=7
he_mu_edca_ac_vo_timer=255

radio_config_id=e558f35370144ea227f1b5c9ad16bcb0
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=0
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
sae_require_mfp=1
wpa_passphrase=*********
wpa_psk_file=/var/run/hostapd-wlan0.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=AX6_5G
bridge=br-lan
wds_bridge=
snoop_iface=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=SAE
okc=1
ieee80211w=2
group_mgmt_cipher=AES-128-CMAC
dynamic_vlan=0
vlan_naming=1
vlan_no_bridge=1
vlan_file=/var/run/hostapd-wlan0.vlan
qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
config_id=b3c512a76f822b4c626206fe9e759121
bssid=9c:9d:7e:xx:xx:xx

There is no practical diff between the two...

Yes, only difference are 160MHz capabilities in new firmware.
There is patch "ath11k: Fix beamformee STS in HE cap" that disables setting of beamformee, maybe I could try to apply it.
Also in recent post about AX9000 both beamformee are set to 7, but maybe that router supports more spatial streams.

Beamformee STS <= 80Mhz: 7
Beamformee STS > 80Mhz: 7
Sounding Dimensions <= 80Mhz: 3
Sounding Dimensions > 80Mhz: 3

That patch is long applied to Robi's branch, and the fact the AX9000 lists Beamformee STS > 80Mhz: 7 while the AX3600 only lists Beamformee STS > 80Mhz: 3 sounds correct, as the AX3600 is only able to do half of BB on 160MHz compared to the AX9000.

If I'm checking right it looks like that patch hasn't actually been applied to Robi's source looking in openwrt\build_dir\target-aarch64_cortex-a53_musl\linux-ipq807x_generic\linux-5.10.79\drivers\net\wireless\ath\ath11k\mac.c

		he_cap_elem->mac_cap_info[1] &=
			IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_MASK;
		he_cap_elem->phy_cap_info[4] &=
			~IEEE80211_HE_PHY_CAP4_BEAMFORMEE_MAX_STS_UNDER_80MHZ_MASK;
		he_cap_elem->phy_cap_info[4] &=
			~IEEE80211_HE_PHY_CAP4_BEAMFORMEE_MAX_STS_ABOVE_80MHZ_MASK;
		he_cap_elem->phy_cap_info[4] |= (ar->num_tx_chains - 1) << 2;

		he_cap_elem->phy_cap_info[5] &=
           ~IEEE80211_HE_PHY_CAP5_BEAMFORMEE_NUM_SND_DIM_UNDER_80MHZ_MASK;
		he_cap_elem->phy_cap_info[5] &=

Edit: yeah sorry, I was checking wrong.

2 Likes

That would be very strange as we are on 5.15-bacports which contains all of this. :slight_smile:

Checking the STS parameter (number of Space-Time Streams) I am still not sure how can it generate 8 of them with 4 antennas, but in one of the patch a developer states that the STS number does not depends on the number of TX chains, so be it: I believe him :slight_smile:

2 Likes

Developer could mean that firmware should set correct STS number and that it could be lower than number of TX chains. I also think that you must have at least as much antennas as you have streams.
Do you know if patch "ath11k: Fix beamformee STS in HE cap" was applied in "restart" branch?
I am thinking to try revert this change in "backports" branch and check if it helps.

If I recall it the "restart" branch was mostly 5.10 without many backports. So I would say it did not apply to that, but you can check the source to verify this.

But if you suspect this, you can try to set your network to 160MHz as although your clients are not able to utilize it, the radio - due to BB limitations - will switch back to STS 3. But if this is a suspicion, you should create a wireshark capture of the beacon of the AP in monitor mode and check the actually transmitted parameter over the air.

MOD: now that I though about it, as the Beamformee STS > 80Mhz: 7 parameter goes (receiving end on the AP), it might be that as your clients are 80MHZ capable, even if the channel is set to 160MHz, your clients will only transmit 80MHz and maybe the AP will try 8 spatial streams. Hard to tell.

@robimarko

I uploaded two PCAP captures of the AP's beacons in 2.4 and 5GHz modes, if someone wants to check them for consistency: link

2 Likes

About a meter from the AX3600, the 5GHz band set to AX 80MHz, an Intel AX200 links @ 1200Mbit/s RX/TX.

Pulling a file from my gigabit NAS which is cabled directly to the AX3600, the wireless throughput tops out quite low around 75MB/s.

I did also test the 5GHz @ 160MHz and even though the link rate is higher the throughput is the same.

Maybe problem is somewhere else. I create this revert patch but it does not help.

Beamformee STS <= 80Mhz: 7
Beamformee STS > 80Mhz: 3

changed back to
Beamformee STS <= 80Mhz: 3

Index: backports-5.15-rc6-1/drivers/net/wireless/ath/ath11k/mac.c
===================================================================
--- backports-5.15-rc6-1.orig/drivers/net/wireless/ath/ath11k/mac.c
+++ backports-5.15-rc6-1/drivers/net/wireless/ath/ath11k/mac.c
@@ -4370,6 +4370,12 @@ static int ath11k_mac_copy_he_cap(struct
 		he_cap_elem->mac_cap_info[1] &=
 			IEEE80211_HE_MAC_CAP1_TF_MAC_PAD_DUR_MASK;
 
+		he_cap_elem->phy_cap_info[4] &=
+		    ~IEEE80211_HE_PHY_CAP4_BEAMFORMEE_MAX_STS_UNDER_80MHZ_MASK;
+		he_cap_elem->phy_cap_info[4] &=
+		    ~IEEE80211_HE_PHY_CAP4_BEAMFORMEE_MAX_STS_ABOVE_80MHZ_MASK;
+		he_cap_elem->phy_cap_info[4] |= (ar->num_tx_chains - 1) << 2;
+
 		he_cap_elem->phy_cap_info[5] &=
 			~IEEE80211_HE_PHY_CAP5_BEAMFORMEE_NUM_SND_DIM_UNDER_80MHZ_MASK;
 		he_cap_elem->phy_cap_info[5] |= ar->num_tx_chains - 1;

Could you test at higher range? Near router my AX200 also gets iperf3 RX 714 Mbits/sec TX 530 Mbits/sec (limited by CPU). But at higher range speed constantly drops to 20 Mbits/sec.
And with old "restart" branch speed at same locations is 400-500 Mbits/sec.

Please check single core load on the AX3600 during the transfer with command "htop" (you might need to install it) and share it with us.

NAT and PPPoE offload does work, but wifi offload does not yet, and I have seen some relatively large CPU loads even around 300Mbits of transfer speeds over wifi.

Sorry it took me a while to get back to you. I can confirm that switching to AC mode does seem to resolve that range issue I was observing on my iOS / iPadOS devices.

Core 0 almost pegged during transfer.

I have irqbalance installed and enabled but it doesn't seem to help.

Moved more or less 10m away through a few thin walls. RX signal rate took a big hit but throughput didn't really that much..

I just noticed strange issue:
reflashing from "old stock" to the image from releases in @robimarko repo makes some mtd partitions to just disappear...

before:

root@XiaoQiang:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00100000 00020000 "0:SBL1"
mtd1: 00100000 00020000 "0:MIBIB"
mtd2: 00300000 00020000 "0:QSEE"
mtd3: 00080000 00020000 "0:DEVCFG"
mtd4: 00080000 00020000 "0:RPM"
mtd5: 00080000 00020000 "0:CDT"
mtd6: 00080000 00020000 "0:APPSBLENV"
mtd7: 00100000 00020000 "0:APPSBL"
mtd8: 00080000 00020000 "0:ART"
mtd9: 00080000 00020000 "bdata"
mtd10: 00080000 00020000 "crash"
mtd11: 00080000 00020000 "crash_syslog"
mtd12: 023c0000 00020000 "rootfs"
mtd13: 023c0000 00020000 "rootfs_1"
mtd14: 01ec0000 00020000 "overlay"
mtd15: 00080000 00020000 "rsvd0"
mtd16: 0041e000 0001f000 "kernel"
mtd17: 015cc000 0001f000 "ubi_rootfs"
mtd18: 01876000 0001f000 "data"

after:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "0:sbl1"
mtd1: 00100000 00020000 "0:mibib"
mtd2: 00300000 00020000 "0:qsee"
mtd3: 00080000 00020000 "0:devcfg"
mtd4: 00080000 00020000 "0:rpm"
mtd5: 00080000 00020000 "0:cdt"
mtd6: 00080000 00020000 "0:appsblenv"
mtd7: 00100000 00020000 "0:appsbl"
mtd8: 00080000 00020000 "0:art"
mtd9: 00080000 00020000 "bdata"
mtd10: 00080000 00020000 "crash"
mtd11: 00080000 00020000 "crash_syslog"
mtd12: 023c0000 00020000 "rootfs"
mtd13: 023c0000 00020000 "rootfs_1"
mtd14: 01ec0000 00020000 "overlay"
mtd15: 00080000 00020000 "rsvd0"

so, partitions

mtd16: 0041e000 0001f000 "kernel"
mtd17: 015cc000 0001f000 "ubi_rootfs"
mtd18: 01876000 0001f000 "data"

just disappeared and are not available to use from running system, so almost half of router's flash can't be used for anything...

Can you advice me, where mtd partitioning scheme is defined?

At first I suspected dts/dtsi files, but it seems, it described somewhere else...

EDIT: P.S. Sorry, @Gingernut, I "replied" to your message by mistake

Partitions are parsed from the SMEM directly, those partitions are created on the fly during rootfs mounting by QSDK on top of existing rootfs and overlay partitions.

oh :cry:

Can you then advice me, please, what maximum size of sysupgrade ubi image can be safely flashed on device?

--
Why I asking:
I just tried to prepare "all what I need" images multiple times, but unpacked rootfs size always been over 100+MB (~120+ in "peak" variant), and "factory" image was about 33Mb.
Minimally I had ~80-90M rootfs with 28M image (by disabling everything, even luci and only enabling kernel modules I need).
And I was scared about flashing such "giant" images (compared to what you have on releases page)...