Probably worth taking some photos of the board to compare and see if something has changed physically, if not checking serial logs during boot and reboot would show if there is anything wrong.
Successfully installed on a Cudy WR3000S.
This device is rather newly supported and don't have a wiki support page yet. How can it be created? Installation can be done easier than described in the original commit (web GUI install rather than serial install). Such information is important for users and is worthy to be part of a support page.
My third R4S is a newer one without this tripod hole ... although I am not aware that they changed anything from a hardware perspective, except for this tripod hole in the case. I ordered it in July. It boots and is also able to reboot.
I know it is quite an ask, but it would be absolutely terrific if you could get an UART cable and provide a serial log. Otherwise we might not be able to figure out what's going on. As said, if I ever see this behavior again I will happily provide the log, but at this stage I can not reproduce it with any of my R4S.
We should probably also move this discussion here.
Cudy added the transition image recently.
You can create a wiki page yourself. Login to the wiki using github at https://openwrt.org/de/start?do=login or send me a PM in the forum with your desired user name and email address and I will create an account for your.
I can confirm, that you are right and I was wrong (also @dimitris ). I compiled a whole image of 24.10.0-rc6 for myself without MBEDTLS_SSL_TLS1_3_COMPATIBILITY_MODE in mbedtls. Everthing was fine, but TLSv1.3 did not work with openvpn-mbedtls. Openvpn also did not show any TLSv1.3 ciphers, like you said. Sad, that there is more work to do.
Anyway that was a great exercise for myself. Now I look with different eyes to the firmware selector This makes things way easier...
@hauke Thank you for the 24.10.0-rc6 release. Updated GL.iNet GL-MT6000 (Flint 2), GL.iNet GL-MT3000 (Beryl AX) and Dynalink DL-WRX36 without any issues.
I noticed that LuCI git "openwrt-24.10" branch is not synced to "master" branch. I think it was synced until 24.10.0-rc4 and then later diverged, but looks like the LuCI changes / fixes in "master" branch are also required in "openwrt-24.10" branch (like a rebase / fast-forward).
If the TLS exporter is "all" that's needed for openvpn to support TLS 1.3 with mbedtls, it seems that keeping an eye on the pull request and its 3.6 backport counterpart is the first step. Luckily it seems to be getting some attention.
For now, when time permits I plan on moving my relevant devices to openvpn-openssl.
@hauke - Thank you for the reply. My test device is an old PC with an Intel i7 Gen 8 (Kaby Lake) processor, i915 chipset. I have used this same device to test various OpenWRT versions since 21.x. Prior to testing 24.10.0-rc6, I had never before seen the "percpu: allocation" errors.
I was wondering if it was perhaps an upstream bug with the newer kernel version 6.6.73, or at least perhaps an incompatibility of that kernel version with the processor in my test PC. Or maybe BIOS settings?
Maybe a difference in the hardware specs of the VM you spun up?
Also, it might be worth noting that I have all of the i915 firmware-, dmc, and the intel-microcode packages installed.
Yes! As a matter of fact I was also testing version 1.50.x of BanIP in conjunction with 24.10.0-rc6. Thank you for the information @dibdot. I had not yet seen that post in your thread.
Hello. I'm curious how it works: we have had 6 release candidates with a seventh one in the pipeline. I know of one build, I think it was RC3 that failed. Could some of the developers involved give us more insight why the 24 release has had so many RCs this time around when compared to other stable releases?
Thanks for the link. I read it, and yes there still outstanding issues, so I can see why they are still working on the release, but was it that these (more critical) issues were picked up later during the various RCs when compared to other releases?
I haven't updated to the RC's yet because of this known issue
seeing the current state I would not expect this to be fixed in the first final release.
Would there be an estimation about when this issue will be fixed or should I just wait and hold the update?
I know all devs are doing the great work in there free time so if it takes a while then it takes a while, I'm just hoping to be able to migrate to the latest release.
On R7800 pppoe on wan.6 (802.11q VLAN) shows a speed regression in comparison to 23.05 on a 1gbps fiber uplink (probably due to DSA).
The EX5601-T1 runs pppoe on this uplink with almost wire speeds (970+)
This makes things way easier...