Adding OpenWrt support for Xiaomi AX3600 (Part 1)

It's a mess 11.5.0.5 have more fixes than 11.5.0.6

Considering they changed ABI i wonder if this is the reason WiFi offload doesn't work.

Its not unusual, they have been doing this for a while now.

I'm in any case very disappointed with intel wifi, have to try those gixes, are you aware of a tweak to activate ch 12 and 13? Very strange behavior if my wifi is set to 13, it will neither find the 5GHz AP while 2.4g is on 13... Never encountered this with any other card, at least in the past few years. Same with linux and windows 10.

Hi guys, tell me how many devices did you manage to connect to the AX3600 ?. We want to put in the conference room , participants 100-120 devices will be connected mainly phones. The video from the performance stage will be duplicated. Will the Aะฅ3600 (openwrt) be able to use the resources, or can you not count on it?
Devices will operate primarily at 5 GHz, in 802.11 ะะฅ modes, and 802.11 AC.

You will have to do that kind of benchmarking yourself, but I would plan with at least 3-4 APs for that number of clients.

Perhaps the memory of the AX3600 router is not enough?

That is very much possible (each client needs accounting, which implies RAM usage), but I very much doubt anyone has tried to find the limits so far. More than 25-30 concurrent clients are rarely found in 'normal' home environments (and even those who do push the limits, tend to do so with IoT stuff, which aggressively powersaves, typically requires little bandwidth (often 2.4-GHz-only, leaving the 5 GHz band open) and isn't up all the time; a conference room full of notebooks and smartphones would be another topic, especially during coffee breaks, a boring presentation or during some kind of major sports playoff).

2 Likes

There is probably not enough RAM with 512MB only, though QCA caps at 128 peers in 512MB mode but I wouldn't really try it.

BTW, QCA finally looks to decided to drop the useless intersection

6 Likes

@Ansuel Do you maybe have time to test the tsens patches on IPQ806x?
I have been preparing IPQ807x tsens support for upstreaming and want to make sure it wont break older platforms

3 Likes

sure think i can test them this night

1 Like

Great, I want to sort out the bindings and send it out tommorow.
I actually spent more time trying to get dt-bindings to look for the correct interrupt name when IPQ8074 is set but failed than actually refactoring and testing the IRQ

1 Like

just to make sure the related commits are

drivers: thermal: tsens: Add support for combined interrupt ยท robimarko/linux@b03a435 ยท GitHub
drivers: thermal: tsens: allow configuring min and max trips ยท robimarko/linux@b0d9cfe ยท GitHub
drivers: thermal: add IPQ8074 support ยท robimarko/linux@c0546b9 ยท GitHub

1 Like

Yeah, thats correct.
I see that I messed up the commit name as well

1 Like

i tested the combined and min max trips and all works correctly. I posted a comment on the combined patch

2 Likes

Thanks, Il try to send it upstream today

3 Likes

Sent out the APSS clock support, though I already see that its gonna require to be reworked and the PLL split into the existing IPQ-PLL driver.

they already review them?

No, but I can already feel it coming.
I doubt they will review anytime soon, been waiting for couple of days for the GCC clock patches

Hello guys, tell me, I wonder if you noticed, in Wi-Fi 802.11n/80211ac, versions of a weak device with a signal, the data transfer was down and pings were growing, in theory, 802.11ax should solve this problem, since there is OFDMA 512 FFT, and there are no "hidden nodes" . Has anyone tested the network only from 802.11AX standard devices, for example, the AX3600 point, if one of the devices has a weak signal? . I wonder how Scheduling and Resource Allocation ?, is it controlled at the hardware level or does the driver make these mechanisms work?

I'll give it another try then. Thanks!

Does this mean that ath11k will respect the regd domain?

BTW, I have figured out the issue with IPv6, it had to do with VLAN filtering + multicast snooping. As it seems multicast is snooped on a bridge level and not on a per VLAN level, breaking multicast (which is used for ipv6) on all VLANs except for one. There was already a patch sent and accepted which is supposed to be on our kernel 5.15 but I can't enable it, I can't find the parameters.
If someone wants to take a look here's the link:
https://lwn.net/Articles/867804/
Either way, I'll probably be creating a new thread to discuss this and replace the current default "br-lan" with a switch-wide bridge with VLAN filtering.

@bitthief I've recently seen your developments based on robimarko's repo, what's the state of those changes? Does NSS work? What's the state of those packages?

1 Like