You can mix HE80 and HE160 devices, each will run at the maximum supported channel bandwidth supported at both ends. But on 5 GHz, 160 MHz channel bandwidth is rather fragile and often doesn't work out (with congestion and if you connect many clients), so I wouldn't bother too much about this aspect anyways (and as explained, the e8450/ rt3200 can only do HE80 anyways).
Hi,
I did some more investigation in the forum and in github and I want to test if the below commit didn't break the WDS@160Mhz connection : https://forum.openwrt.org/t/mesh-and-ap-on-the-same-radio-stopped-working-on-24-10-0/223821/15?u=underworld
However it seems that I do not have snapshots available after the fix of OKD, as I was using attendedsysupdate until I moved to 24.rc7.Do you know where can I download snapshots from let's say November? Another way is if you can help me find wpad-basic-mbedtls - 2024.09.15~5ace39b0-r1 or wpad-mbedtls - 2024.09.15~5ace39b0-r1 and install it on 24.0.xxx?
Thank you
Kind regards
K
There is a new installer release 1.1.4: https://github.com/dangowrt/owrt-ubi-installer/releases
Is it okay to stick with 1.1.3 which i run since some month with self build snapshots? Seems the only change is a newer U-Boot version
You can't, snapshot builds are refreshed roughly daily and not retained. All you could do, is building from source with your chosen git hash from that time frame.
Thanks. Well, it is time to learn something new
So you did release that new release in the end @daniel! Nice one. Weren’t you going to announce that on this thread?
Has anyone tested or used to upgrade from the old layout running 23.XX? To be the first is a daunting prospect.
I implemented this setup, and I am unhappy, as the opposite arrangement (E8450 as the main router, Flint 2 as a repeater downstairs) provided better throughput in the LAN. However, E8450 as the main router crashed two days ago during an important meeting, which was never the case with 23.05.x and early 24.10 rcs.
So, I think I will downgrade to -rc5 and swap the devices again. Instructions on how to downgrade to 23.05.5 would also be appreciated. I have a USB serial cable.
I tested the new 1.1.4 installer. Force flashed the unsigned installer and then used that to flash the official OpenWrt 24.10 image. Rebooted just fine and seemed to work.
A word of caution though. If you plan on restoring your 23.05 backup configs, be sure to follow the In case the configuration wants to be preserved section of the official installation instructions, otherwise you'll run into the issue shown below when you try to flash a new Attended Sysupgrade build on top of your new 24.10 install.
If you're like me and ignored those instructions like a silly goober, you can still salvage your 24.10 install by running the two uci commands and fixing your /etc/config/ubootenv
and /etc/fw_env.config
like it says in the instructions. After that Attended Sysupgrade should work again.
Did you retain the crash log? It’s not related to the crash log I posted earlier associated with the 2.4 GHz driver is it?
Otherwise if it’s WDS related that’s disconcerting.
Anyone else use WDS with 24.XX?
I don't know how to get the crash log. /sys/fs/pstore
is empty. 2.4 GHz might be related, as I created a test AP with a different SSID on that radio for the purpose of testing policy-based routing.
WOW! Amazing!
@daniel , what about the new installer for people that already has 1.1.3 installed and running 24.10?
I've been running the 1.1.3 installer since snapshots and then all the 24.10 RCs and now 24.10.0.
Just backup the config, flash the installer, flash the sysupgrade and restore the config??
Does the new U-Boot do something special? What can you tell us about this release?
Thanks in advance, very grateful about your job with the RT3200 and many Mediatek devices!
Thanks for your bravery and report! I have started the upgrade process and all went just fine for the first device. Configuring from scratch so this will take a while.
Just upgraded from 23.05.5 (original UBI installer) to 24.10.0
- flashed new 1.1.4 installer
- rebooted OK (in recovery)
- flashed 24.10.0 sysupgrade
- rebooted OK
- restored previous backup (following 'configuration preserved guide')
Then reboot seemed KO (no power led)
I had to power off/on several times before booting in default config (not recovery). - I restored again the same backup, this time, reboot was OK and configuration was correctly restored.
I'm not sure what happened, but it is fixed now.
You don't need to and can not use it. If you like you may update fip/U-Boot and initramfs/recovery image manually.
No, the new release of v1.1.4 is mostly done because v1.1.3 (which is based on an OpenWrt snapshot build) can not be reproduced any more (also due to the change to apk
as package manager).
Regarding the weekly crash mt76 issue 934 that @lynx is experiencing; is this something that daily/weekly restarts could workaround, or is the crash merely unlikely enough that a week is statistically enough time for it to appear even if recently restarted?
I have an old router that has a tendency to crash if left on too long, but its OEM firmware has a weekly/daily scheduled restart function that lets me avoid this.
Since 2.4 GHz is absolutely essential, I am wary of switching over from my current older router; and as this will be my first attempt at using OpenWRT, I am avoiding snapshots.
If this is fixed, will it make its way to release branch (24.10.x), or will I need to hold off until 25.x?
Is this a similar config to a guest network? I ask because that is what I plan on using, so I would be more likely to see such an issue.
So will there be a 1.1.5 for 25.x when only apk
is available?
Edit: Ah, UBI installer issue 204:
Yes, for 25.xx release we will have to migrate to APK
So, the installer scripts will need to change, but then the more meaningful question I suppose is how much does fip/U-Boot and initramfs/recovery actually change from 1.1.3→1.1.4→APK version?
Downgrading from 24.x to 23.x on this device is a fairly involved process due to the way the data layout has shifted. You'll first and foremost need a good, safe, valid copy of that particular router's 'factory' volume, which is now in UBI. From there, it's a matter of following the 'hard recovery' instructions posted in this topic to go through the process of using mtk_uartboot and a serial console to load the 22.x BL2 image (don't use the BL2 from 23.x due to the OKD issue!), restore the 'factory' data into the 23.x layout's MTD partition, and then load in the 23.x FIP, Recovery, and Production firmware images.
Although the bl2, the FIP, the recovery, and the production images can be downloaded from the firmware selector, the factory data is unique to each individual router.
It's a separate network that is not bridged to the main one and is routed through a VPN.
I don't believe restarts helps, but I guess if you can afford to have restarts, might as well try it if you see the crashes happening. I have only seen this crash 3 times IIRC, and they are all random events AFAICT. When the crash happens, I do notice from syslog that there are many attempts at 2.4GHz connections, and I believe that is likely the cause of the crash. Since I added whitelisted known good MAC addresses at the router for the 2.4GHz interface it has not crashed since. Fingers crossed.
But the root cause is still not known at the moment. My E8450 may crash the next minute if the exact scenario that triggers the crash happens.
I think that would be similar for the hardware & driver then, two independent SSID on one radio; also isolated from the main network. The main difference would be routing packets into the VPN rather than directly on the internet facing interface, yes?
Since consumer router VPN encryption is done on the CPU, if you have the same mt7615e driver issues, they are likely unrelated to the presence or absence of VPN config, I would guess.
@quarky @lynx do you have multiple SSIDs active on one radio?
For the hardware and driver, yes, that's similar.
And yes I have two SSIDs on the 2.4 GHz radio, one left-over from the times when I had certain 2.4 GHz only hardware, and one for the VPN.