Dear hnyman,
How are you doing ? - well I hope. I am getting two MT6000's on Friday - and I already have two DL-WRX36's - but I am still a bit leery about flashing the DL-WRX36 as the process seems a bit fraught with danger.
anyway, I like being able to go back to stock firmware on my hardware - and for the life of me - I am unable to fully make sense of how to go back to stock on the DL-WRX36. The instructions on the thread / wiki are a bit murky - at least IMHO.
Regarding Kernel 6.6 on R7800 - I am interested in what you think / have to say.
I attempted to build ipq806x 6.6 R7800 but I got no joy in the end - anyway - hopefully I will hear from you soon. Oh by the way, will you be building for the MT-6000 - just asking is all
I will not publish a proper community build like I have done for R7800, but I am still uploading my builds for MT6000 and DL-WRX36 into Dropbox.
Forum search would have revealed these posts and links to you:
Ps.
The DL-WRX36 flashing instructions are pretty clear, but the installation is really complicated and consists of several steps. (The option 1A, using a modified OEM backuåp, is the a bit simpler choice)
What firmware is your build using. I'm not seeing this on mine with standard firmware:
dmesg | grep firmware
[ 32.839052] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.9.0.2-00157 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 6cdc6ff9
[ 39.565968] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.9.0.2-00157 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 6cdc6ff9
@hnyman Is there any way to benefit from ASU but keep using your build along with any extra packages that I would otherwise need to re-install upon upgrading?
ASU is based on the OpenWrt buildbot binaries, from which it cooks the required firmware. It has no relation to third-party builds like my build.
My build is built directly from the source code with the package selection that I have defined. If you want to tailor my package selection, the easiest method is to download my build env creation script and patches, and build by yourself with modified package selection. Pretty easy, as the message 2 of this thread contains detailed advice on how to copy my build env to your own Linux for building.
But regarding ASU, you might look at the package selection list of my build (the recipe file .config.init in my directory), and pick from there the add-on packages that you want to add to ASU.
Ps. Note that you only need to add the "top package" like luci-app-sqm, and ASU will pull in the dependencies like sqm-scripts itself.
Thanks. That’s exactly what I was expecting to hear in first place. The former solution that you suggested is indeed a possibility that I have done years ago when your build used to offer only the ct firmware, but a bit more time consuming to be fair (I need to set up a linux VM first - I am a windows user - and require a few dozen GB of free space, etc - imo it is not as straightforward as ASU which you can do via your mobile phone..).
The only question mark for me now is if there is any bespoke configuration in your build (e.g. about leds, buttons, ports, file systems) that can’t be captured from the config/backup file upon migration. I suppose there isn’t, because all parameters are captured in the backup file and as long as all packages are present in the upgraded build, the relevant parameter is going to be picked up and applied. Correct?
Pretty much so.
There are some minor source code changes in my build, which won't be carried.
But those mainly affect the defaults to be built in, and you should already have them in your config. So, no major issue for you.
The 23.05 build includes the already merged fix to tackle the wifi performance issue in 23.05.4 (mentioned above as issue 15999, but which was never in my builds as the bug was introduced after my previous 23.05 build).
But the master build shows a new (possibly harmless) kernel warning/crash for each radio on R7800. Likely due to the recent bump of the mac80211 (generic wifi driver infra) to be kernel 6.9 based a few days ago.
Wifi still works, so the warning may be harmless, but possibly not.
The author of ath10k-ct today published the 6.9 version of ath10k-ct driver, so I have made a PR for using it. There is also a R7800 test build downloadable from my dropbox site. (ath10k-ct version 6.9 r27046-940f83cc8d-20240730)
I'm running latest release 23.05 (R7800-owrt2305-r24023-07cb7cb885-20240730-0932-sysupgrade) and I was testing speeds on wired. I'm on a 1 Gbps but only getting 360 mbps at max. I switched to my router appliance and was getting 800-900 which is in line with expectation. I have no SQM enabled atm.
Is there a setting I'm missing to enable max speeds that would allow me to only use the r7800 or is it a hardware limitation?
Thanks!
What is the configuration for your WAN uplink (particularly, do you need PPPoE or something). Assuming plain ethernet, ipq8065 won't do 1 GBit/s, but it can/ should do more than 360 MBit/s - PPPoE would be a quite significant workload, though.
Thanks. It looks that I am very close to achieve my plan above, as I installed manually 65 packages through luci on a release branch build (23.05.0) and subsequently restored my config from your build.
The only package that failed to install in first place and needed a workaround was wpad-openssl. Here is the error I got:
failed: Collected errors:
check_conflicts_for: The following packages conflict with wpad-openssl:
I needed to remove wpad-basic-mbedtls first, then install wpad-openssl and then re-install wpad-basic-mbedtls. As it stands now I cannot really notice any difference vs your build.
Now when it comes to ASU, I tried to use ASU to see if I can go to 23.05.4 flawlessly but I get the following error:
Collected errors:
check_data_file_clashes: Package libustream-openssl20201210 wants to install file /builder/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/lib/libustream-ssl.so
But that file is already provided by package * libustream-mbedtls20201210
Not sure if this relates again to the same regression that I observed before. Do I need to completely remove wpad-basic-mbedtls in order to keep wpad-openssl installed - in other words - is there any genuine conflict in which one should choose wpad-openssl over wpad-basic-mbedtls ? It appears that both packages serve the same purpose (created by the same author), have more-or-less the same dependencies and that wpad-basic-mbedtls is just a cut-down version of wpad-openssl (?). Correct me if I am wrong or am missing something here.
Well, half right, half wrong.
They are from the same wireless support package family, hostapd.
Yes, wpad-basic-xxx is the cut-down limited features version of wpad-xxx.
But the "xxx" above indicates the SSL library in use. Can be openssl, mdebtls or wolfssl. My own build is wholly based on the openssl variant of each package in the selection. There is nothing mbedtls based included in my build... So, wpad-basic-mbedtls is the cut-down version of wpad-mbedtls, not wpad-openssl.
I am not using ASU & related image cookers, so no advice regarding that. But in general, to get a pure openssl based system (like mine), you need to explicitly disable several default mbedtls packages variants and install the openssl variants instead. E.g. disable libustream-mbedtls and select libustream-openssl.
Btw, thanks for the knowledge sharing. Every time we speak I learn something new from you:
Back to our story now, I re-flashed a clean 23.05.0 image from scratch and installed 63-64 packages manually. There was no issue with installing wpad-openssl this time. Subsequently, I removed specifically these 3 packages without automatic deletion of unused dependencies:
luci-ssl was also removed upon upon uninstalling libustream-mbedtls20201210
libmbedtls12 is needed as part of libcurl14 installation - can't have one without the other, hence I left it there.
In a interim attempt before my final one, I also removed libucode20220812, however luci went bananas and I couldn't reconnect via luci anymore. In my last attempt I left it untouched. I can't see any impact of doing so.
After all the above, I was able to use ASU to jump flawlessly from 23.05.0 to 23.05.4 through my phone... Will test it soon with 23.05.5 when it comes out.
It is a pitty though that I will have to install 24.xx again from scratch given the DSA implementation in the release channel for ipq806x, but anyway the above method is still very straightforward and quicker than rebuilding the image on my own VM etc.
Btw, is there any plan to move from openssl to wolfssl at some point or are there issues with licences etc (I am just speculating here)? Or even some technical reason why you would stick with openssl?
