Adding OpenWrt support for Xiaomi AX3600 (Part 1)

will have some fun with testing ipq806x with 5.15 as i need to test new dsa feature... (sorry for ot)
Wonder how much patch i will have to remove from generic

I gave 5.15 in OpenWrt a go recently, lets just say that it was a pain and I gave up.
There is just too many hacks that weren't upstreamed and that wont apply

Sad... i tried 5.11 some times ago and i didn't have to remove that much stuff from it...

So i did some more digging into the high memory usage on ath11k and it kind of seems to be expected behaviour ? As in the memory doesn't seem to be leaking as such it's just seems to be a large amount of references held. (It's odd, although it could just be that it's not developed on devices that are limited to 512mb of memory)

It would be interesting to see how the 1gb devices fair

1 Like

Sysupgrade only updates the rootfs partition right?

I was trying to keep the Xiaomi firmware on rootfs_1 and run OpenWRT on rootfs but I can't for the life of me get a system upgrade to apply.

I think it's been mentioned a few times on here, that to so a sysupgrade you MUST have flashed both mtd12 and mtd13 partitions first (i.e. flash the one you are NOT booted into first using either:
nvram get flag_boot_rootfs
or from openwrt:
fw_printenv flag_boot_rootfs
to find out which one). Then reboot into openwrt and flash the OTHER partition.

P.S. I can't instantly see this on the wiki, should I add it?

2 Likes

OK thanks.

I asked because I have another dual rootfs partition router which sysupgrade only upgrades the rootfs partition and I could keep OEM firmware on rootfs_1.

The upgrade script must have been modified for the IPQ807x target.

Hello,
first of all, thanks for all the hard work done so far - I've flashed AX3600 few days ago and since then, I'm using it as my main router. So far it seems to perform really decently but I noticed one issue, which I hadn't before with Archer C7V5 with 19.04 OpenWRT - namely, wake on lan refuses to work on my end. Did anyone else had such issue with latest backport branch?
Thanks in advance!

I am a bit sad as 5.16 will contain a lot of ath11k stuff that we need. I wonder how soon Hauke can do some backporting. Among the many things, 160MHz is also in that set of patches...

I can tell you that Hauke won't do any more backporting, they set the 5.15 backports as the target for the next stable and you will only see point updates.
That doesn't mean that we cant just backport whatever we need

2 Likes

Yeah, this tends to happen when thinking about something else and typing fast.
Fixed it now, thanks.

1 Like

Do we need to wait until 5.15 lands in Owrt, or the two things are not related?

No, they are completely separate.
The backports only backport wireless drivers which is great when they are newer than the available kernels in OpenWrt but kind of loses sense otherwise.
It has a great side-effect off all targets using the same wireless drivers regardless if they have or haven't been ported to a newer kernel

The patches seemed to have totally solved the disconnects on the affected Xiaomi phone.

Thanks

1 Like

I recently noticed a lot of "nf_conntrack: nf_conntrack: table full, dropping packet" and I can also see that my Active Connections are at 95%. I noticed that 2/3 of the connections are pretty old UDP sessions. Can it be that we are missing a reasonable timeout value somewhere and these sessions are not dropped for some reason? As there is really no reason to keep all these open.

Just saw that Blocktrron had pushed an updated qca-nss ssdk v11.4-csu1 and a ath11k firmware
WLAN.HK.2.5.0.1-01192-QCAHKSWPL_SILICONZ-1 v2 over at:

We use the ones in ath11k-firmware repo so we need to wait for the QCA guys to upload them.

Non the less, we can start testing it now :slight_smile:

I loaded it, and so far so good. Both radios work as they did with previous versions.

@dchard I really have no clue how the QCA hackery is supposed to work, they hacked the networking part really badly.

Maybe Transmission is not closing sockets properly, as even after a standard systemctl stop, almost all sessions remain. I might try to dig in to the stock fw to see if we are not missing any sysctl parameters.