Thanks for providing link to Fork
Ok so I need to build a custom build of openWRT, except what is writen on GH to uncomment device do I need to do something?
In previous comments I see someone posted some code, was it commited to that fork or it is a separete thing?
Thanks
i donât know why but fan_control doesnât work as service if i run manually it will control fan otherwise fan runs all time
instead of trying to fix it i always want to set gpio-fan with providing three different speed controls
little help with AI 
i managed to control fan but i am not sure how hysteresis thing works
&cluster_thermal {
trips {
cluster_fan_low: cluster-fan-low {
temperature = <65000>;
hysteresis = <10000>;
type = "active";
};
cluster_fan_mid: cluster-fan-mid {
temperature = <70000>;
hysteresis = <5000>;
type = "active";
};
cluster_fan_high: cluster-fan-high {
temperature = <75000>;
hysteresis = <5000>;
type = "active";
};
cluster_hot: cluster-hot {
temperature = <80000>;
hysteresis = <2000>;
type = "hot";
};
cluster_crit: cluster-crit {
temperature = <92000>;
hysteresis = <2000>;
type = "critical";
};
};
cooling-maps {
map_low {
trip = <&cluster_fan_low>;
cooling-device = <&gpio_fan 1 1>;
};
map_mid {
trip = <&cluster_fan_mid>;
cooling-device = <&gpio_fan 2 2>;
};
map_high {
trip = <&cluster_fan_high>;
cooling-device = <&gpio_fan 3 3>;
};
};
};
hello,
I mange to install NSS version in order to get max speed on 10gb ports.
I was able to get 7-8gbps speed for first run, however after that the sfp port got so hot that speeds dropped to 2-3gb.
internal thermal sensors shows around 66-68*c and it is staying like that.
How can I control fans speeds?
Is there any build in solution in openwrt or I need to install some package?
hi,
i donât think stock fan will hold 10gbit speed still but you can test with disabling automatic fan control and set fan to full speed
but my best guess you need active cooling system needs to place under the device
create a file with fan.sh put below lines init than run âsh fan.shâ ( setting will remain active until reboot )
for file in /sys/class/thermal/thermal_zone*/mode; do
echo disabled > "$file";
done
echo 2100 > /sys/class/hwmon/hwmon13/fan1_target
If stock fan hold the 10gb line as well, you need more aggressive fan control or full speed all time
does anyone know how to restore asus firmwere? I tried their recovery tool, did not work.
https://openwrt.org/docs/guide-user/installation/recovery_methods/asus_firmware_restoration_tool this does not show rt-ax89x...
tried putting firmwere on luci, failed.
did, also failed
Setup interface on Host PC with ip 192.168.50.75/24 (not the Router will ONLY accept tftp put over this IP) ; $ip a a 192.168.50.75/24 dev
The HostNIC and recovery is performed ONLY over the 1G WAN port NIC (this is the 'blue') NIC port next to the 10G Copper port.
Find valid recovery .trx
Run tftp to 192.168.50.1 ; $tftp 192.168.50.1
Unplug DC barrel jack whilst holding down the reset switch with a pointy thing
Leave Power Button Depressed(on)
Replug DC barrel jack whilst still holding reset switch with a pointy thing ; release after first LED indication
Power LED will flash slowly
Use TFTP client to put target firmware in bin mode; set trace to show progess; $tftp>trace ; $tftp>bin; $tftp>put .trx
Trace will show transfer ; wait for router to reboot.
no more ideas what to do
here is short cut
return offical 24.10 release than you will able the install custom package
install facinstall.ipk after that openwrt will support asus stock trx images you will able the install offical trx image from openwrt luci (flash operations tab)
I feel like I asked this question beforeâŚbut ill ask it again.
So even if I had fat stacks of cash and threw it at the OpenWRT developers so they can get to work on getting NSS working on these routers OpenWRT supports, its just not possible?
NSS licensing is unclear, it's not a man power issue, but IP (not of the network kind).
So if OpenWRT makes their own NSS stuff, they risk getting sued?
if they (re)use Qualcomm's code/blobs, yes.
if they reverse engineer the functionality and write their own, no.
Is it theoretically possible to implement NSS 'properly' (as a hardware flow-offloading variant, akin to what exists for Mediatek SOCs), yes. The kernel source is open and licensed accordingly, the licensing state of the NSS blobs is less clear, the firmware ABI not defined (~can change between versions without warning, not reeaaallllyyyyy documented), but this is not an immediate disqualification.
The NSS kernel code as-is however is a steaming pile of âŚsomething, QCA just did their thing without talking to netfilter folks - which is their right, but it doesn't help getting things merged. The patches are very invasive, hooking into and bypassing large parts of netfilter code (as well as some other projects), it doesn't stand a snowman's chance in hell to get merged. The existing code could only be used as (partial) reference documentation, someone would have to start from scratch again and rewrite this within the flow-offloading framework (very different semantics). Only trying this wil reveal if the existing NSS code matches flow-offloading semantics 'enough' to make this theoretically viable. QCA's NSS implementation is quite OCD, they've written it to go really overboard and offload a lot of different things, relying of patched variants of other things beyind 'just' the kernel (e.g. PPP, IPsec and more things can be offloaded) - which is cool for benchmarks, but doesn't make things easier for the poor soul who might want to re-implement this properly. The NSS firmware is a black box, any potential (security-) bugs cannot be fixed nor even audited, at best compromised offloading paths might be disabled (but given the full-offloading nature, this means almost no offloading for those cases).
NSS as a concept applies to:
But even among these SOCs, the major version of NSS differs, while the idea is the same, there are tangible difference between the SOCs (and the different versions released over time), there is no easy/ blanket compatibility between them.
ipq40xx does not use NSS.
Worse, the current wifi 7 SOCs (ipq957x and ipq53xx) do not use NSS anymore, so any development would be strictly for 'old' (which QCA doesn't care about anymore and won't help with adapted NSS firmwares, should the need arise) SOCs. It's not helpful for current/ future devices.
So even if you'd find a volunteer (unclear, given that NSS is a dead-end and not applicable to ipq53xx/ ipq957x), I'm pretty sure you wouldn't be able to afford it.
This is a full-time task for 2-3 seasoned developers and 3-5 years of work, finding out (documenting) what the current NSS firmware does, starting from scratch with a flow-offloading re-implementation - and then convincing the mainline/ netfilter developers to take it, given the extent of NSS, this alone will take many iterations reacting to their change requests (this alone will take at least half of the time).
tl;dr: it's not im-im-impossible, but chances for it to actually succeed are minimal - and given the efforts required, money will not help[*].
castles-in-the-air possible: yes
realistic: no.
--
[*] in the best case, you might be able to convince a university professor that this is the next best thing after sliced bread, so they make it their research topic, get grants, contribute their master students time as code monkeys. no, this is not going to happen.
Why don't you just use the excellent NSS community project. I use it for all routers that support NSS and it's rock solid and it's fun when sometimes there are new bugs in OpenWrt main branch and I always first think it maybe a NSS thingy.
I am just trying to wrap my head around how and why its so difficult for NSS support to happen.
all im reading so far is that not only is it confusing because theres a lack of documentation, but its also very âinvasiveâ. which has me thinking that even if the router uses the same SoC, it would be different for each router.
I thought it would have been cool though. if the OpenWRT could âchart this exclusion zoneâ and being able to use the map they created to make supporting NSS easier in the future.
And while I do feel very proud about donating this router and seeing how someone did make a build with NSS suport, it does make me think that someone would tell me âsee? i told you that you really wasted your time donating this routerâ
not that I would stop donating, I do want to continue donating more routers. reading about the lack of NSS support and all because of how it helps with 10gbps networking makes me feel like I would be climbing a flat concrete wall thatâs hundreds of feet high. Even with all the drill bits, batteries, rope, and anchors, it would be an exhausting climb.
This requires a lot of changes to the kernel. Hence the new patches. And no one wants to support new unique patches!
Which will never be accepted mainline, never to disappear - becoming more of a problem as the kernel progresses (porting to a new kernel is a major undertaking), especially when developer/ user interest starts to fade (old hardware, with newer stuff around). Mainlinr first is something to approach, because it saves you lots of work long term. Even within the NSS community builds, you see quite often breakage (as in offloading not working for a while), because these patches are fragile and need a lot of -constant- attention. It is a bad idea to buy hardware with non-mainline features in mind.
This does have me think that as a âjankâ, the keyword being âJankâ here, work around, one could have a X86 router handle the internet service that goes well and above 1gbps like 2.5gbps, 5gbps, or even 10gbps while the RT-AX89X router could function instead as a âlayer 3 switch with wifiâ.
A better chance is someone making a network accelerator chip that doesnât require some weird non upstreamed code. Qualcomm just never cared to do things right for these chips. They did work with upstream kernel in other cases, so really not sure why they couldnât handle this one as well.
Yeah, DEC750 can handle 8-9 Gbps without accelerator chips, just on AMD embedded CPU.
Thatâs exactly what I was thinking too. Combine such router with RT-AX89X for WiFi only.
While that exists (Mediatek) or may exist (ipq957x, there things seem to be moving into a better direction - with loooots of road left to pave), I would phrase that differently - there are platforms that don't even need weird hardware acceleration, but have the grunt power to just do it normally, in the kernel (looking into the general direction of x86_64).
Well, yeah. If routers could easily handle 10 Gbps just on the CPU, it would be perfect. Some already do as above, but none that Iâve seen that are also provide WiFi out of the box.