for initrams i have to interruppt the bootloader. with key do i have to press to interrupt it
Guys, I am trying to debug the issue with my Poco F2 Pro reconnecting every couple of seconds.
Has anybody identified the specific patch causing it?
I only have AC clients on my side, no such issues are present.
For me, it happens even in AC mode.
Its quite stupid, connects, drops, reconnects and just in circle.
I even tried various coolsnowwolf "LEDE" patches
From time to time on my AX3600 I can observe some warning call stack in dmesg:
[ 9870.448126] nss_port5_tx_clk_src: rcg didn't update its configuration.
[ 9870.448156] WARNING: CPU: 3 PID: 677 at update_config+0xd8/0xec
[ 9870.459054] 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 nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 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 tun 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
[ 9870.513475] CPU: 3 PID: 677 Comm: kworker/3:2 Tainted: G W 5.10.75 #0
[ 9870.535710] Hardware name: Xiaomi AX3600 (DT)
[ 9870.544163] Workqueue: events qca_mac_sw_sync_work_task [qca_ssdk]
[ 9870.547949] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
[ 9870.554027] pc : update_config+0xd8/0xec
[ 9870.560182] lr : update_config+0xd8/0xec
[ 9870.564087] sp : ffffffc01310bb00
[ 9870.567991] x29: ffffffc01310bb00 x28: 0000000000000000
[ 9870.571207] x27: 0000000000000000 x26: 0000000000000001
[ 9870.576590] x25: 0000000000000001 x24: ffffffc008866000
[ 9870.581884] x23: 0000000000000001 x22: ffffffc010850030
[ 9870.587179] x21: 0000000000000000 x20: 0000000000000000
[ 9870.592476] x19: ffffffc010a961f0 x18: 000000000000024e
[ 9870.597770] x17: 0000000000000000 x16: ffffffc008773dbc
[ 9870.603065] x15: ffffffc010a07d08 x14: 00000000000006ea
[ 9870.608360] x13: 000000000000024e x12: ffffffc01310b7d8
[ 9870.613656] x11: fffffffffffe92b0 x10: fffffffffffe9268
[ 9870.618950] x9 : ffffffc010a5fd08 x8 : 0000000000003750
[ 9870.624246] x7 : ffffffc010a07d08 x6 : 0000000000000001
[ 9870.629541] x5 : ffffff801f6ea6d8 x4 : 0000000000000000
[ 9870.634837] x3 : 0000000000000027 x2 : 0000000000000027
[ 9870.640130] x1 : 0000000000000023 x0 : 000000000000003a
[ 9870.645428] Call trace:
[ 9870.650717] update_config+0xd8/0xec
[ 9870.652889] clk_rcg2_configure+0x58/0x84
[ 9870.656712] clk_rcg2_set_rate+0x30/0x50
[ 9870.660618] clk_change_rate+0x148/0x2c4
[ 9870.664609] clk_core_set_rate_nolock+0x14c/0x230
[ 9870.668516] clk_set_rate+0x3c/0x150
[ 9870.673585] ssdk_uniphy_clock_rate_set+0x80/0x130 [qca_ssdk]
[ 9870.677184] ssdk_port_speed_clock_set+0xc0/0x148 [qca_ssdk]
[ 9870.682789] qca_hppe_mac_sw_sync_task+0x394/0x898 [qca_ssdk]
[ 9870.688514] qca_mac_sw_sync_work_task+0x40/0x610 [qca_ssdk]
[ 9870.693784] process_one_work+0x1d4/0x380
[ 9870.699506] worker_thread+0x7c/0x4e0
[ 9870.703411] kthread+0x128/0x130
[ 9870.707057] ret_from_fork+0x10/0x34
[ 9870.710354] ---[ end trace 6665d7060229d6a1 ]---
[41154.309217] nss-dp 3a001200.dp2 eth0: PHY Link is down
[41165.573267] nss-dp 3a001200.dp2 eth0: PHY Link up speed: 1000Is this know issue that may leed to some side effect? For me even if this occurs router seems to be working stable.
Exactly the same happens on my Poco F3 Pro and I thought I solved it by adding a few coolsnowwolf patches but it didn't in the end.
Have you tried a few different channels?
I don't remember now but I think the disconnections more or less stopped when I switched to channel 52 but I still got complaints about terrible wireless reliability at home so I had to revert back to OEM firmware.
Could you also, as a test, change the phone's region to UK?
I think it could be due to the recent mac80211 changes or due to regdb.
installed and works very well, transfers similar to factory
I tried just 2G channel 1 and 5G channel 149.
Why would changing the region change anything?
Its probably something in mac80211 as regdb is effectivly ignored due to the FW enforcing the one in the BDF and even worse doing it incorectly as for ETSI it applies insane restrictions.
Dont have a clue to where to even start debugging, this is where doing 5 kernel versions just is just pain
Edit: >>post moved to an extra topic<<
I am not able to set up the device as a dumb access point.
The clients simply do not get an IP address. Interestingly, they do get a connection after about 5 minutes of waiting. By then, however, most clients usually interrupt the connection themselves.
The configuration I used for this works wonderfully on my Redmi AC2100 and Mi 3G - but unfortunately not here.
I have used self-compiled builds, the pre-compiled releases from robimarko and also the bloated build from here and also various others linked here in the thread.
I have the same effect with all of them.
In order to understand my problem, I approached it with a minimal configuration:
# don't do router jobs on dump ap:
service firewall stop && service firewall disable
service dnsmasq stop && service dnsmasq disable
service odhcpd stop && service odhcpd disable
# join my lan-network 192.168.0.0/24 with gateway 192.168.0.2
uci set network.lan.ipaddr='192.168.0.11'
uci set network.lan.gateway='192.168.0.2'
# disable dhcp6, ra for ipv6
uci del dhcp.lan.ra
uci del dhcp.lan.ra_slaac
uci del dhcp.lan.dhcpv6
uci set dhcp.lan.ignore='1'
uci del dhcp.lan.ra_flags
uci add_list dhcp.lan.ra_flags='none'
# only bridging - no routing on interface lan
uci del firewall.cfg02dc81.network
# wireless settings
uci set wireless.radio1.htmode='HE40'
uci set wireless.radio1.channel='40'
uci set wireless.radio1.country='DE'
uci set wireless.default_radio1.ssid='Test'
uci set wireless.default_radio1.encryption='psk2+ccmp'
uci set wireless.default_radio1.key='testtest'
uci set wireless.radio1.disabled='0'
uci commit
wifi reload
Result: The clients simply do not manage to get into the network. The router itself has perfectly fine internet-connection (opkg update etc. works fine).
I uploaded the client-side wireshark recording >>here<<.
This looks really good actually.
Yep. It was never as good as this one before.
Any chance you can get to the 160MHz and Rx offload patches? Would be nice trying those out.
Well, I was trying to get to those but since I cant really test with my phone its hard to test and my notebooks don't have AX cards, otherwise I would have backported those yesterday.
BTW, it looks like 2.6.0.1 FW is coming in SFP 11.5 as they have started uploading BDF-s for that.
https://source.codeaurora.org/quic/qsdk/oss/ath11k-bdf/commit/?h=NHSS.QSDK.11.5.0.5.r4&id=afb81e8ae6088e5d52fa4ccc61572b4e00e9e778
I also have no AX clients, but I can check a few BW combinations with my analyzer, if at least the signal levels and flatness of the spectrum is correct. 80P80 can also be tested.
Well, it's not just AX, AC doesn't work as well with the same symptoms.
Just rebuilt your latest mods, applied WLAN.HK.2.5.0.1-01192 and it works quite nicely on AC and N. Although I have to mention that I am using my own edited BDF. Kinda doubt this has anything to do with your issue...
I doubt its the BDF.
And its the f*cking wired networking mess, I was using one of the LAN ports for uplink and it caused the WLAN not to have any networking hence trying to disconnect/connect and get networking, now when WAN port is used it magically works.
Ahh, for f*ck sake... Maybe the issue is with the NSS bridge-mgr not taking into account that any port can be used for any purpose.
