Could you upload your version (sysupgrade) somewhere on the server and add a download link?
I uploaded it as a pre-release to github. Works for me but otherwise completely untested and minimal build.
1 Like
I work your bild but I think the wifi range is significantly worse than the original firmware. In addition, in the original firmware on 5GHz, 1 radio is visible and on openwrt we have 2 radios. Why is that?
WiFi is not my strong point, I hope someone else can chime in.
I assume you adjusted the power for the radio? According to the wikidev it got two 5GHz chips, not sure how stock represents them.
RAX120 has two 5Ghz Radios and ath11k represents that as two independent devices both capable of 4x4 streams.
Stock firmware use proprietary QCA-WIFI that is combining that two radios to one device with 8x8 streams.
Please note that each radio is working in a different frequency range, one in the lower 5Ghz band and one in the upper band.
1 Like
just new here, and have a couple of questions:
- does this solve the random rebooting issue in the official firmware?
- is openwrt on rax120v2 stable enough for daily use?
- looks like official firmware is also based on openwrt, are we using the same stock radio driver?
thanks!!!
Looks like no movement on github for weeks...
How's the stability @patient0 ? Should we work with @robimarko to upstream ?
The custom QCA firmware that combines both 5G modems into one is also an interesting point to explore, but it's probably out of scope given there is no upstream support for it.
I left comments and they need to be resolved, author has not been active so far.
@nschimme I don't use it as my daily device and don't know about stability.
@robimarko @jewest added me as an collaborator back in January. I already made the changes you requested in my fork of his (I DM's him three weeks ago to ask if it is ok if I push the changes, no answer). So I can push them, what is preferred a forced push or an additional commit? I'm a dummy, I'm on holiday and while I can apply and push the commit, I can't test it. Only my trusty APU2 got with me on holiday 
I wonder if anyone can confirm (e.g. @jewest @patient0) if the jffs2 persistence related problem (mentioned by @NastyNeightK and me) happens on your side with an old or a newer (e.g. rebased and compiled in 2023) branch.
I am interested in giving this problem another shot, but before that I'd like to confirm if it's a unsloved problem for everyone. (is it already fixed?) (or is it a problem happens only on my and @NastyNeightK side bc of mis configuration?)
I haven't tested. But the method itself is pretty generic, it should work regardless of branch version: either work directly or with very light work to port to new branch.
I does work for me (with the commit/repo the image mentioned in the post 3 three weeks ago is based on). But it's a regular UBIFS image not jffs2 anymore, which seems appropriate for a NAND based device.
(how do I reference a previous post, any way to shortcut like #185?)
