The app is called WiFiman
OpenWrt 23.05.0-rc2 r23228-cd17d8df2a / LuCI openwrt-23.05 branch git-23.118.79121-6fb185f
just got one of these, to replace a WRT router, is there any way to flash international version without TTL? hate to going through all the hustle of opening it up..
so mine came with " Version 3.0.48"
I tried to activate ssh to no avail, tried both create_exploit.js and create_exploit_hdr2.js, i get either
Invalid token
or
storage is full
tried factory reset a couple of times but i guess nothing more i can do to it.
any suggestions?
how did you manage to get ssh running?
what have you used, mine is on a little older firmware but i do not want to upgrade just in case i can not go back
I just noticed there is 23.05-rc2 so I decided to give AX9000 a try.
The first issue I had was that with 'Direct rooting device procedure' the generated bins were rejected for checksum error. I was using Chinese version so I just downgraded to the 1.0.108 listed in the 2nd method. I think I was on 1.0.140 but I forgot to save the version before downgrading.
The second issue is that I used the rc squashfs-factory.ubi during ubiformat step. Right now the device doesn't boot into any system, and all I can see is the orange light on. Is there a way to change boot order to the other partition, so I can reinstall the downgrade firmware before trying the GitHub image again?
1 Like
There is a TFTP Recovery Procedure out there - think instructions are around for the AX3600 and it is the same for that guy. Essentially run a TFP/DHCP server combo such as Tftpd64, set your computer's interface to 192.168.31.100/24 and plug into a LAN port. Keep pressing Reset while powering on the AX until it flashes orange. You'll see in the logs of the TFTP/DHCP servers that it'll acquire an IP shortly and try to grab an img file - make sure to place whatever stock image you want to feed it in the TFTP root folder (sometimes it's named as the hash of your IP . img, sometimes it's just the image that was flashed previously). Once TFTP has shown the file successfully transfered, the router will soon blink white indefinitely, just power off/on again, and you'll be on stock firmware, so stock portal will be up. Note that the telnet password won't work until you finish the configuration steps in the portaln - just click through them, then you can telnet and flash again to openwrt.
Regarding your flash issue, wiki says to use squashfs but you need to use the initramfs image and then after successfully booted in, do a sysupgrade to commit to flash.
cd /tmp
wget https://downloads.openwrt.org/releases/23.05.0-rc2/targets/ipq807x/generic/openwrt-23.05.0-rc2-ipq807x-generic-xiaomi_ax9000-squashfs-sysupgrade.bin
uci set system.@system[0].compat_version="1.0"
uci commit system
sysupgrade -n -p -F openwrt-23.05.0-rc2-ipq807x-generic-xiaomi_ax9000-squashfs-sysupgrade.bin
2 Likes
Thanks for the reply. I searched around and found that Xiaomi provides a Windows utils to perform those steps. It didn't work with USB Ethernet adapter so I had to find a PC with onboard Ethernet. But in the end I was able to flash the developer firmware (also from that page) which has SSH enabled by default after completing the initial configure steps.
I'll test your instructions now, as I already flashed the GitHub squashfs-factory.ubi and got the same broken system again 
Update: I was able to install 23.05-rc2 after following above instructions. If this works well enough we might buy a few more to use in our office 
1 Like
I tried to edit the Wiki page but self-registration is currently disabled. Hopefully this critical document can be updated before the official release.
1 Like
Glad you got it sorted.
For what it's worth, the Mi WiFi Repair Tool for PC you've linked and used is triggering all kinds of alarm bells... Besides it's been unreliable for me at least. https://www.virustotal.com/gui/file/436e57a5e2daf1c5b4ece8851a7b7517c1fbc9e69acba8fac3806aa160f251b5
The AX9000 has been stable for me, except for the fact that I cannot use 160MHz even with the patched BDF, and the fact that hardware offloading using the two dedicated NPUs is not supported.
Hello together, i am having problems with "radio1".
When i try to start it i get:
[ 48.092360] ------------[ cut here ]------------
[ 48.092401] WARNING: CPU: 2 PID: 1957 at ath11k_reg_update_chan_list+0x26c/0x2a0 [ath11k]
[ 48.096056] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_inet ath11k_pci ath11k_ahb ath11k ath10k_pci ath10k_core ath pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mac80211 cfg80211 slhc qrtr_smd qrtr_mhi qrtr qmi_helpers nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mhi libcrc32c crc_ccitt compat sha512_generic seqiv jitterentropy_rng drbg michael_mic hmac cmac leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom qca_nss_dp qca_ssdk gpio_button_hotplug ext4 mbcache jbd2 aquantia hwmon crc32c_generic
[ 48.151507] CPU: 2 PID: 1957 Comm: hostapd Tainted: G W 6.1.38 #0
[ 48.173744] Hardware name: Xiaomi AX9000 (DT)
[ 48.181204] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 48.185548] pc : ath11k_reg_update_chan_list+0x26c/0x2a0 [ath11k]
[ 48.192316] lr : ath11k_wmi_sta_keepalive+0x4cc4/0x5aa0 [ath11k]
[ 48.198566] sp : ffffffc00f6639c0
[ 48.204637] x29: ffffffc00f6639c0 x28: ffffff800705ba00 x27: ffffff800516d020
[ 48.207857] x26: 0000000000001003 x25: 0000000000000000 x24: 0000000000000001
[ 48.214975] x23: ffffff800516a020 x22: ffffff8005168508 x21: ffffff80051684d8
[ 48.222093] x20: 0000000000000000 x19: 0000000000000000 x18: ffffff80051487a0
[ 48.229212] x17: 0000000000000002 x16: 0000000000000018 x15: ffffff8005148764
[ 48.236329] x14: 0000000000000003 x13: 0000000000000066 x12: 0000000000000007
[ 48.243447] x11: ffffff800516d020 x10: 0000000000000004 x9 : 00000000ffffffff
[ 48.250565] x8 : ffffff800516b158 x7 : ffffff800516b138 x6 : 000000000000000d
[ 48.257684] x5 : 0000000000000001 x4 : 0000000000000040 x3 : ffffff8005168508
[ 48.264802] x2 : ffffff80045baf0c x1 : 0000000000080031 x0 : 0000000000000000
[ 48.271921] Call trace:
[ 48.279029] ath11k_reg_update_chan_list+0x26c/0x2a0 [ath11k]
[ 48.281293] ath11k_wmi_sta_keepalive+0x4cc4/0x5aa0 [ath11k]
[ 48.287195] drv_start+0x34/0x60 [mac80211]
[ 48.292920] ieee80211_do_open+0x22c/0x6f0 [mac80211]
[ 48.296828] ieee80211_do_open+0x6c4/0x6f0 [mac80211]
[ 48.302036] __dev_open+0x118/0x1b4
[ 48.307068] __dev_change_flags+0x140/0x194
[ 48.310369] dev_change_flags+0x24/0x6c
[ 48.314535] devinet_ioctl+0x398/0x68c
[ 48.318353] inet_ioctl+0x230/0x240
[ 48.322173] sock_ioctl+0x2d4/0x43c
[ 48.325557] __arm64_sys_ioctl+0x4c8/0xee0
[ 48.329032] invoke_syscall.constprop.0+0x5c/0x104
[ 48.333200] do_el0_svc+0x58/0x17c
[ 48.337971] el0_svc+0x18/0x54
[ 48.341355] el0t_64_sync_handler+0xf4/0x120
[ 48.344397] el0t_64_sync+0x174/0x178
[ 48.348822] ---[ end trace 0000000000000000 ]---
The interface can't be started.
I first thought that the 5GHZ chip from 8074 is broken but its working in the original firmware.
Anyone same problem and maybe a solution?
a_guy
1591
Based on stack trace it seems to be country selection related. Try to fiddle with country/channels/width combis
wolfxr
1592
And the fan still not working
You're righ, if i change Country to US on all interfaces it works. I get all radios online.
My prob is, i am not from US. Tried to play around with different "board-2.bin" for 8074 but none did properly work.
I'd just keep it as US but only use channels that are allowed in your country. At least until it's fixed.
On latest snapshot, 160MHz AP works for me on all 3 of my AX9000.
However nothing happens (aka nothing in logs, no connections) when using the radio on 160MHz Ch36 as a 802.11s batman-adv point.
Fri Jul 21 11:15:58 2023 daemon.notice netifd: Wireless device 'radio3' is now up
Fri Jul 21 11:15:58 2023 daemon.notice netifd: Interface 'batmesh' is enabled
Fri Jul 21 11:16:03 2023 daemon.notice wpa_supplicant[1944]: phy3-mesh0: interface state UNINITIALIZED->ENABLED
Fri Jul 21 11:16:03 2023 daemon.notice wpa_supplicant[1944]: phy3-mesh0: AP-ENABLED
Fri Jul 21 11:16:03 2023 daemon.notice wpa_supplicant[1944]: phy3-mesh0: joining mesh falcon-mesh2
Fri Jul 21 11:16:04 2023 daemon.notice netifd: Network device 'phy3-mesh0' link is up
Fri Jul 21 11:16:04 2023 daemon.notice netifd: Interface 'batmesh' has link connectivity
Fri Jul 21 11:16:04 2023 daemon.notice netifd: Interface 'batmesh' is setting up now
Fri Jul 21 11:16:04 2023 daemon.notice wpa_supplicant[1944]: phy3-mesh0: CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:00 completed [id=2 id_str=]
Fri Jul 21 11:16:04 2023 daemon.notice wpa_supplicant[1944]: phy3-mesh0: MESH-GROUP-STARTED ssid="falcon-mesh2" id=2
Fri Jul 21 11:16:04 2023 kern.info kernel: [19157.600582] IPv6: ADDRCONF(NETDEV_CHANGE): phy3-mesh0: link becomes ready
Fri Jul 21 11:16:04 2023 kern.info kernel: [19157.626542] batman_adv: bat0: Adding interface: phy3-mesh0
Fri Jul 21 11:16:04 2023 kern.info kernel: [19157.626610] batman_adv: bat0: Interface activated: phy3-mesh0
Fri Jul 21 11:16:04 2023 daemon.notice netifd: Interface 'batmesh' is now up
Wiphy phy3
EHT Iftypes: mesh point
EHT MAC Capabilities (0x0000):
EHT PHY Capabilities: (0x0000000000000000):
EHT MCS/NSS: (0x):
EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
EHT bw=160 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
EHT bw=160 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
EHT bw=160 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
Frequencies:
* 5180 MHz [36] (30.0 dBm)
* 5200 MHz [40] (30.0 dBm)
* 5220 MHz [44] (30.0 dBm)
* 5240 MHz [48] (30.0 dBm)
* 5260 MHz [52] (24.0 dBm) (radar detection)
* 5280 MHz [56] (24.0 dBm) (radar detection)
* 5300 MHz [60] (24.0 dBm) (radar detection)
* 5320 MHz [64] (24.0 dBm) (radar detection)
Somehow iw dev shows channel 149 instead of 36 as configured (and packet counts are increasing):
$ iw dev
phy#3
Interface phy3-mesh0
ifindex 34
wdev 0x300000004
addr c8:bf:4c:bb:ec:b0
type mesh point
channel 149 (5745 MHz), width: 160 MHz, center1: 5815 MHz
txpower 30.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 838 0 0 0 0 50788 838
1 Like
Setting Ch 52 @ 160MHz actually triggers wpa_supplicant and DFS... (unlike Ch 36) but interface remains in 80 MHz mode after the fact.
I wonder if it could be related to an issue similar to this patch..
After tracing hostapd's wpa_supplicant code for a little while I found that ieee80211h was disabled on the interface (and thus DFS channels / checks). The check is as follows:
# wpa_supplicant/mesh.c
# ssid->frequency = 5180`
# wpa_s->num_modes=1
# wpa_s->hw.num_modes[0].num_channels=28
if (ieee80211_is_dfs(ssid->frequency, wpa_s->hw.modes, wpa_s->hw.num_modes) && wpa_s->conf->country[0]) {
conf->ieee80211h = 1;
conf->ieee80211d = 1;
conf->country[0] = wpa_s->conf->country[0];
conf->country[1] = wpa_s->conf->country[1];
conf->country[2] = ' ';
wpa_s->mesh_params->handle_dfs = true;
}
# wpa_supplicant/ieee802_11_common.c
int ieee80211_is_dfs(int freq, const struct hostapd_hw_modes *modes, u16 num_modes) {
int i, j;
if (!modes || !num_modes)
return (freq >= 5260 && freq <= 5320) ||
(freq >= 5500 && freq <= 5700);
for (i = 0; i < num_modes; i++) {
for (j = 0; j < modes[i].num_channels; j++) {
if (modes[i].channels[j].freq == freq &&
(modes[i].channels[j].flag & HOSTAPD_CHAN_RADAR))
return 1;
}
}
return 0;
}
With this set of parameters ieee80211_is_dfs(...) = 0, DFS is essentially only enabled if the main frequency lands on a DFS frequency, which is not the case for Ch 36 @ 160MHz. My foo is not good enough to fix the check generically, but I now have mesh on radio3 @ 160 MHz fully working by simply hardcoding my case; (as well as preventing 149 from ever being selected as the antenna does not support it, otherwise the two ranges are marked available and picked randomly based on mesh id) <-- Think I may not need the 2nd half anymore now that DFS is fixed, need to verify:
--- a/wpa_supplicant/mesh.c
+++ b/wpa_supplicant/mesh.c
@@ -476,7 +476,9 @@ static int wpa_supplicant_mesh_init(stru
bss->conf->ap_max_inactivity = wpa_s->conf->mesh_max_inactivity;
bss->conf->mesh_fwding = wpa_s->conf->mesh_fwding;
- if (ieee80211_is_dfs(ssid->frequency, wpa_s->hw.modes, wpa_s->hw.num_modes) && wpa_s->conf->country[0]) {
+ if ( (ssid->frequency==5180 && freq->bandwidth==160) || (ieee80211_is_dfs(ssid->frequency, wpa_s->hw.modes, wpa_s->hw.num_modes) && wpa_s->conf->country[0]) ) {
conf->ieee80211h = 1;
conf->ieee80211d = 1;
conf->country[0] = wpa_s->conf->country[0];
--- a/src/ap/dfs.c
+++ b/src/ap/dfs.c
@@ -558,7 +558,8 @@ dfs_get_valid_channel(struct hostapd_ifa
const size_t meshid_len = iface->mconf->meshid_len;
sha256_vector(1, meshid, &meshid_len, (u8 *)&hash[0]);
- _rand = hash[0] + hash[1] + hash[2] + hash[3];
+ _rand = 0;
#endif
} else if (os_get_random((u8 *) &_rand, sizeof(_rand)) < 0)
return NULL;
cc @robimarko
Sadly, this is beyond my understanding on mac80211
1 Like
Unrelated - I modified package/firmware/ath11k-firmware/Makefile like so to try and replace the BDF file in the image directly, so I don't necessarily need to move my APs around and wire them up after an upgrade (as the APs are unreachable by default after an upgrade given the backhaul on radio3 is down
due to bad BDF).
PKG_NAME:=ath11k-firmware
PKG_SOURCE_DATE:=2023-07-24 # fake bump to try & avoid caching issues
PKG_SOURCE_VERSION:=69f6b7346b64784188dba791a9cfb614eefa441f
PKG_MIRROR_HASH:=4794c835019fe8a545812cd3cdc229ca0a1977dc8c489dde708a0dd26f323c9e
PKG_RELEASE:=1
[... unchanged ]
define Download/qcn9074-board
URL:=https://github.com/<fork>/ath11k-firmware/raw/master/QCN9074/hw1.0/
URL_FILE:=board-2.bin
FILE:=$(QCN9074_BOARD_FILE)
HASH:=971f8e59692f711c02ea8658b34f1c3821e03bfd2f89c19cd06fd02e97c862be # correct BDF hash
endef
$(eval $(call Download,qcn9074-board))
[... unchanged ]
And yet somehow after build I end up with a mix of old/new BDFs on disk, and the image has the old BDF (sha256sum = b7faf):
971f8e59692f711c02ea8658b34f1c3821e03bfd2f89c19cd06fd02e97c862be ./openwrt/staging_dir/target-aarch64_cortex-a53_musl/root-qualcommax/lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin
971f8e59692f711c02ea8658b34f1c3821e03bfd2f89c19cd06fd02e97c862be ./openwrt/build_dir/target-aarch64_cortex-a53_musl/ath11k-firmware-2023-07-28-006a4e2a/.pkgdir/ath11k-firmware-qcn9074/lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin
b7faf05221b6ae0eef7db54e8d6f710ef76199223a55c269882a4cc4a2e98f2e ./openwrt/build_dir/target-aarch64_cortex-a53_musl/root-qualcommax/lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin
Any idea?
Hello, @robimarko .
Currently, for the international models, it is safe to do sysupdate into v23.05-RC2, regarding the previous issue above?
Thanks.
Tiago.
