Yepp, did that. Even with US the channels are still disabled. Hmm. Did the javascript exploit break the whole radio stuff ?
Wait, all of the channels are disabled?
That shouldn't be the case, I don't know which exploit are you talking about
Yes, all disabled.
The exploit from bruda, #179 . Should I try another board2.bin ?
I don't see that it touches ART at all, so it shouldn't have messed anything up.
Let me check again tomorrow, but for sure there is a couple of channels that are done by the built-in radio.
Different BDF isn't gonna help here, the frequency restrictions should be in the caldata itself
Thanks!
I just noticed I do not have the original caldata file in the backup of the original firmware... I ommited /tmp while backup up... 
Any stable openwrt for ax9000 yet?
I found some openwrt firmware on QQ
I tried some but the wifi 5g low band is disappear
1 Like
I have caught a kernel panic on a AX9000 from the -backports branch with latest patches:
[63782.995667] detected buffer overflow in memcpy
[63782.995710] ------------[ cut here ]------------
[63782.999010] Kernel BUG at fortify_panic+0x20/0x24 [verbose debug info unavailable]
[63783.003782] Internal error: Oops - BUG: 0 [#1] SMP
[63783.011153] Modules linked in: ecm iptable_nat ath11k_ahb ath11k ath10k_pci ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD nf_nat nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_quota xt_pkttype xt_physdev xt_owner xt_multiport xt_mark xt_mac xt_limit xt_comment xt_cgroup xt_addrtype xt_TCPMSS xt_LOG ppp_async nlmon nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 mdio_netlink iptable_mangle iptable_filter ip_tables hwmon crc_ccitt compat qca_nss_pppoe pppoe pppox ppp_generic slhc nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 qca_nss_drv qca_nss_dp qca_ssdk seqiv jitterentropy_rng drbg michael_mic hmac cmac leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_qcom gpio_button_hotplug
[63783.065836] CPU: 2 PID: 2592 Comm: netifd Not tainted 5.10.80 #0
[63783.088066] Hardware name: Xiaomi AX9000 (DT)
[63783.094230] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[63783.098492] pc : fortify_panic+0x20/0x24
[63783.104559] lr : fortify_panic+0x20/0x24
[63783.108461] sp : ffffffc01233b7a0
[63783.112367] x29: ffffffc01233b7a0 x28: ffffff800659a280
[63783.115582] x27: ffffffc01233bdf0 x26: 0000000000000000
[63783.120964] x25: 000000000000000a x24: 0000000000000000
[63783.126259] x23: ffffffc01154d300 x22: 0000000000000018
[63783.131554] x21: ffffff8003f4bf00 x20: 0000000000546180
[63783.136849] x19: ffffff8014a64c00 x18: 00000000000001ad
[63783.142144] x17: 0000000000000000 x16: 0000000000000000
[63783.147440] x15: ffffffc0114a7d48 x14: 0000000000000507
[63783.152734] x13: 00000000000001ad x12: ffffffc01233b4b8
[63783.158030] x11: ffffffc0114ffd48 x10: 00000000fffff000
[63783.163325] x9 : ffffffc0114ffd48 x8 : 0000000000000000
[63783.168620] x7 : ffffffc0114a7d48 x6 : 0000000000000001
[63783.173916] x5 : 0000000000000000 x4 : 0000000000000000
[63783.179211] x3 : 0000000000000000 x2 : ffffff803edea1a8
[63783.184506] x1 : ffffff803ede46d0 x0 : 0000000000000022
[63783.189802] Call trace:
[63783.195095] fortify_panic+0x20/0x24
[63783.197280] ecm_db_exit+0x42c/0x49c [ecm]
[63783.201093] ecm_db_exit+0x464/0x49c [ecm]
[63783.204995] atomic_notifier_call_chain+0x5c/0x90
[63783.209075] ip6_route_add+0x13c/0x1a4
[63783.213845] inet6_rtm_newroute+0x98/0xa0
[63783.217493] rtnetlink_rcv_msg+0x10c/0x34c
[63783.221573] netlink_rcv_skb+0x5c/0x130
[63783.225565] rtnetlink_rcv+0x1c/0x2c
[63783.229295] netlink_unicast+0x1ec/0x2e0
[63783.233116] netlink_sendmsg+0x1a4/0x394
[63783.237024] ____sys_sendmsg+0x270/0x2b4
[63783.240928] ___sys_sendmsg+0x7c/0xc0
[63783.244834] __sys_sendmsg+0x5c/0xb0
[63783.248394] __arm64_sys_sendmsg+0x28/0x34
[63783.252042] el0_svc_common.constprop.0+0x88/0x190
[63783.255948] do_el0_svc+0x74/0x94
[63783.260720] el0_svc+0x14/0x20
[63783.264105] el0_sync_handler+0xa8/0x130
[63783.267057] el0_sync+0x184/0x1c0
[63783.271143] Code: aa0003e1 912b4040 910003fd 97fff56c (d4210000)
[63783.274355] ---[ end trace e940b99b430b29a2 ]---
[63783.280425] Kernel panic - not syncing: Oops - BUG: Fatal exception
This is the first time I have seen it.
Its a ECM bug, you can see thst kernel detected buffer overflow
I tested the firmware today.
The bug still here
mate you are not even using Robimarko's branch.
This is seriously getting annoying, here and elsewhere as well. I counted 4 individual cases already when someone upgraded to a QSDK based crap because they thought it is "Openwrt", it f*cked up the factory partition table, then they sysupgraded to Robi's branch, which led to a brick. So it is not just annoying, but misleading as well, and it causes effective damage to the less educated.
Therefor, these post should be removed by a moderator.
1 Like
Easy to replicate. Boot, connect an Android phone, disable wifi on the phone, wait a few minutes then re-enable wifi. The crash is immediate.
I can tell you that I wont be looking at the ECM, its just a black hole for time
I'm wondering if this bug is affecting only AX9000 or AX3600 as well?
Does anyone has a log of the boot sequence of the AX9000 with the latest (as of Nov 29) -backports firmware ? The boot doesn't complete, no network no console shell etc. The last lines I have are:
[ 3.096222] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 3.108843] init: - preinit -
strings: standard output: Broken pipe
[ 3.161592] random: jshn: uninitialized urandom read (4 bytes read)
[ 3.174488] random: jshn: uninitialized urandom read (4 bytes read)
[ 3.181667] random: jshn: uninitialized urandom read (4 bytes read)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 6.237729] procd: - early -
[ 6.237796] procd: - watchdog -
[ 6.759283] procd: - watchdog -
[ 6.759528] procd: - ubus -
[ 6.764147] urandom_read: 3 callbacks suppressed
[ 6.764153] random: ubusd: uninitialized urandom read (4 bytes read)
[ 33.761299] pmd9655_ldo11: disabling
It stays stuck at this point waiting for something that never happens.
Turns out that the culprit was a corrupt /etc/passwd, ubusd didn't initialize itself correctly and procd was stuck in a loop trying to connect.
Sorry for the noise.
As it is in the ecm driver it should affect all AX routers.
I think I have found the culprit, it is the calls to ipv6_addr_prefix() in ecm_db_ipv6_route_table_update_event() the third argument is not checked and goes overboard. There are a lot of other issues in this function (an ipv6 address stored in a ip_addr_t and so on).
If someone is interested I have a patch, which may not address the root cause of the issue (the value of cfg->fc_dst_len). At least the router has not crashed since.
Thanks @flebourse
Might be worth creating a PR with this patch to @robimarko's repo, so other owners of the AX9000 (and possibly AX3600) would benefit from it?
I have added a PR to the -backports branch.
Check again.
You sent it to the upstream OpenWrt