Has anyone run into reboot loop with qosmio latest commit 04665e8 on 24.10-nss using as WDS client?
I built and installed without issues until I enable WDS Client. WDS AP is earlier built r29031-164fc5a971
Symptoms: Boots normal and after mx4200v1 led becomes solid and 10-15 sec later (believed connecting wds AP and reset itself) and reboot. Since it is on a reboot loop, i cannot get boot log to show errors.
I have to push reset button and invoked failsafe mode and do factory reset to deBrick the router.
I have since rollbacked to r29181-d052ad817b to keep wds client working for now.
Could you test with the following patch?
Download and rebuild mac80211
curl -sJL https://gist.githubusercontent.com/qosmio/5a61c74961e66748cd3dd8b0a79504b8/raw/3183c353e869ee187b75f68fa74565bd4f4c6cd3/999-908-QSDK-CP-wifi-ath11k-Fix-the-WMM-param-type.patch -o package/kernel/mac80211/patches/nss/ath11k/999-908-QSDK-CP-wifi-ath11k-Fix-the-WMM-param-type.patch
make package/mac80211/{clean,compile} -j$(nproc) V=s
1 Like
It would appeared the patch works, I did a make world after make package per instruction and deployed the new build.
I assumed if I get latest on the current 24.10-nss, I would need to do the same patch until you include this to your repo?
As always, Thank you very much for your awesome assist.
OpenWrt 24.10-SNAPSHOT, r29230-04665e89fc
root@HomeNetNMX4200:~# nss_diag
MODEL: Linksys MX4200v1
OPENWRT: r29230-04665e89fc
IPQ BRANCH: 24.10-nss
IPQ COMMIT: 04665e89fc
IPQ DATE: 2025-12-29
NSS FW: NSS.HK.11.4.0.5-6-R
MAC80211: v6.12.61-0-gdcbeffaf66d0
ATH11K FW: WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1
INTERFACE: br-lan tx-checksumming: on rx-gro-list: off
lan1 tx-checksumming: on rx-gro-list: off
lan2 tx-checksumming: on rx-gro-list: off
lan3 tx-checksumming: on rx-gro-list: off
phy2-sta0 tx-checksumming: on rx-gro-list: off
wan tx-checksumming: on rx-gro-list: off
1 Like
Whilst on the subject of cooling, has anyone tried putting heatsinks from mx5300 onto mx4200 and 4300 ? Or any kind of better cooling ?
1 Like
From my testing on ipq40xx/ MAP-AC2200, I managed to successfully scan for bluetooth devices (hcitool scan hci0) - does that work for you? I never tried anything beyond that, as I had no purpose for bluetooth on my router (it's an interested topic, but not enough to find a use case for doing so).
I don't really want to go even more off-topic for this thread, but so far I've dodged the bullet in that regard (tasmota/esphome wifi XOR zigbee). It probably helped that I came (actually still come) late to the party and try hard to standardize on one single -non-routable- rf protocol (zigbee) only (if I can't get wifi + opensource firmware). That aside, I don't really see the advantage of covering this task on the router either, the actual processing doesn't really work there (yes, I know, docker and friends go a long way, but the router hardware is still poor (CPU, RAM, flash)) and dealing with encapsulating (e.g. socket based) the traffic to a different system for processing doesn't make it more beautiful either. Even if I did want to go there, adding a USB bluetooth adapter would probably easier and help with a heterogeneous router/ AP infrastructure (only one of my routers happens to have BT) - besides that, most modern IoT networks (zigbee, thread, z-wave) are self-meshing (bluetooth not really), so adding the feature to an AP doesn't really help (at least not in an infrastructure way, like a wifi AP, only as powersource/ respectively getting router-only firmware (rather than coordinator) is going to be 'fun'). (And most of the time, the included coordinator hardware is stone old, with silicon bugs and barely any firmware development to begin with, there are better/ more recent option via USB - or modern BT/ wifi PCIe cards)
All I asked was "does the scan detect any devices" 
it was just yes or no question.
I've pushed the fix to 24.10-nss. A simple make package/mac80211/{clean,compile} && make world should be all you need.
24.10-nss:
| date | commit | desc |
|---|---|---|
| 2026-01-05 | 8f05fb6529 | ath11k_nss: Fix kernel crash due to invalid WMM param type |
Also, for anyone using nat46 module please verify if the latest commit is working for you. I've only compile tested and loaded but no way to properly test since my ISP is already native IPv6.
main-nss:
| date | commit | desc |
|---|---|---|
| 2026-01-05 | f9deac3d10 | nat46: Fix up patches for 2025-11-04 snapshot |
3 Likes
Has anyone tried the new option Enable kTLS support.
The PR comments claim:
This commit add option to enable kTLS support, improving performance by offloading TLS encryption and decryption to kernel space.
* Reduced CPU usage by minimizing data copying between user space and kernel space.
* Enables the use of the sendfile() system call with encrypted sockets for zero-copy data transmission.
* Leverages hardware-accelerated NIC that support TLS offloading.
Would not recommend enabling it.
2 Likes
@qosmio could you update 25.12 branch to latest rc2?
Are you planning to add this commit to the main OpenWrt branch?
I can confirm that my mx4300 also crashes whenever enabling WDS client mode on main OpenWRT (non-nss build) branches after 24.10.4 (including 25.12rc)
The only solution is to boot to the second partition running 24.10.4.
1 Like
I, like some others have discussed elsewhere in the thread, have struggled to get a functional three node setup going on these builds using 802.11s meshing. I've been quite happy with the two node setup I've got going now, but I've got that itch to try to find a way to get the third node going, probably via WDS (so I can still take advantage of nss, unlike batman).
Does anyone who is running a 3+ node setup on these NSS builds, using WDS, have any feedback on what to expect? In particular, my main node (connected to the ethernet) will need to be at the edge of the mesh, which is what was giving me problems with 802.11s. Does WDS on this build work well for this situation? It worked reasonably well on the stock firmware, but that firmware had other problems that discouraged me from using it...
1 Like
while i like nss build for my 3 MX4300 AP’s with ethernet backhaul for all, one main usecase breaks and is the main reason to have to use non-nss openwrt build.
in AP mode(no firewall,dnsmasq,odhcpd), with the multi-bridge nonDSA configuration needed for nss build, and creation of multiple bridges for different vlans, am running into bridge loop issues when mDNS is turned on in upstream main router if the AP has vlan1 (iphone) and vlan2(roku). this is not an issue with non-nss BridgeFiltering setup. hope someone was able to get the right settings and make it work(have tried tweaking many wireless params/igmp snooping/stp settings etc to no avail)