Sort of. I have 3x RT3200's with 2x connecting via WDS to BOTH br-lan (via 5 GHz) and br-guest (via 2.4 GHz). I've seen before a weird issue where my guest network connectivity went strange until I rebooted my main router. I can't remember many details surrounding that state, and haven't seen it recently. In general my funky WDS setup seems rock solid with these devices.
Is it safe to upgrade through the attended Sysupgrade?
I'm installed 22.03.0 via UBI installer.
newest image in UBI repo is 22.03.1 and I want to upgrade to 22.03.02
attended sysupgrade can downalod 22.03.02 image for me, but
-
Is it safe for UBI image install?
https://openwrt.org/toh/linksys/e8450 say you cannot install the non-UBI firmware (*.bin). -
Is it stable version or untested snapshot?
Once you have converted to UBI flash layout using @daniel's installer, you do not need to run / flash the UBI installer file again.
It is safe to use upgrade using regular sysupgrade ITB file, for example https://downloads.openwrt.org/releases/22.03.2/targets/mediatek/mt7622/openwrt-22.03.2-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb
ITB files are for UBI layout.
BIN files are for non-UBI (stock firmware) flash layout.
3 Likes
I'm getting two errors when I try to upgrade the firmware of my Belkin RT3200 from a very old (r18942-cbfce92367 in Feb 2022) development build to the latest (openwrt-22.03.2-mediatek-mt7622-linksys_e8450-squashfs-sysupgrade.bin).
In brown: "The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform." and in red: "Image check failed" / "Device linksys,e8450-ubi not supported by this image".
I thought I had converted it to UBI permanently - In LuCI Status and under System is says "Linksys E8450 (UBI)" - but honestly I can't say where I left off (the last time I worked on it was more than 8 months ago and it's been in the closet). I've done a system reset via the interface; I backed up the stock data way back when I started tinkering and don't care about saving anything. I'll start from scratch, but I honestly don't know where "scratch" is given that I've got OpenWrt on there already and upgrading the firmware isn't working.
I have no doubt this is me missing something stupid obvious. I apologize for cluttering up the thread, but would appreciate any help. Thank you!
You were using the wrong image, ".bin" is for non-ubi layout. Try the one with ".itb" suffix.
Has anybody tried this patch to fix/improve 802.11r:
Just wondering, if the proper fix is in the pipeline for next 22.03 release, or the next major release?
Cheers.
Flashed latest snapshot (OpenWrt SNAPSHOT r21203-aca8bb5cc3 / LuCI Master git-22.299.72136-a98e2ea) on my RT3200 this morning and noticed that a lot of processes are started/running. Is this by design?
Normal. Depending on your packages/daemons installed/configured you can have 100+ running.
Randomly I get those messages in the log, always on wlan0 and not on wlan1, this happen not every day and when the "off" to "static" loop begin it may run between 10 to 50 time before it stop.
Is this normal?
Sun Nov 6 18:02:13 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx off
Sun Nov 6 18:02:14 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx static
Sun Nov 6 18:02:14 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx off
Sun Nov 6 18:02:18 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx static
Sun Nov 6 18:04:29 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx off
Sun Nov 6 18:04:35 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx static
Sun Nov 6 18:05:49 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx off
Sun Nov 6 18:05:52 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx static
Sun Nov 6 18:05:52 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx off
Sun Nov 6 18:05:53 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx static
Sun Nov 6 18:05:58 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx off
Sun Nov 6 18:05:59 2022 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED xx:xx:xx:xx:xx:xx static
I'm using 22.03.2, no WED, and with this config
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/18000000.wmac'
option band '2g'
option htmode 'HT20'
option channel '11'
option txpower '6'
option country 'IT'
option cell_density '0'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'xxxxxx'
option encryption 'sae-mixed'
option key 'xxxxxxxxxx'
config wifi-device 'radio1'
option type 'mac80211'
option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
option band '5g'
option txpower '6'
option country 'IT'
option cell_density '0'
option htmode 'HE80'
option channel '140'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'xxxxxxxxx'
option encryption 'sae-mixed'
option key 'xxxxxxxxxxxxxxxxxx'
Does it always happen with the same connected station? If so, which device (wifi hardware, driver, OS) is it?
I have the same with one of my devise on 2.4G. It is Android 12 (Lineage 19.1) OnePlus 5T.
By now I have seen this happening with OnePlus 6T OxigenOS 11.1.2.2
kworker stands for kernel worker, these aren't ordinary processes but processes that handle kernel-level tasks asynchronously. As a simplified example, consider a network device that can buffer 10 packets. Once the buffer is full, it'll interrupt the kernel to go and process the packet buffer. The kernel will want to put the device back in a state where it can accept the next 10 packets as quickly as possible (to avoid dropped packets), so the actual "interrupt code" will just grab the buffer contents, schedule the actual routing of the packets in the buffer for later, and resume the device. The kworker will then take care of routing the packets inside that buffer when a CPU is free, which could even be a different CPU from the one that got interrupted. This routing of packets can then be done in parallel with the next "I've got 10 packets!" interrupt, thus making better use of the available resources.
In practice, the inner workings of network devices and drivers is more complex than this and HW can take care of more stuff on its own, but that's the general idea. Having many kworkers either ready to process hw events asynchronously or just having them ready waiting until there is (keep them persistent rather than spawning a new one on every interrupt) is thus nothing to be concerned about.
3 Likes
For those who haven't seen this - this is cool:
And the RT3200 can easily handle it without breaking a sweat.
2 Likes
Thanks for this information.
I was just wondering about the amount of kworkers active on the router. In my perception there were a lot less active in previous builds. Guess I was wrong.
Maybe later this week I have some time and take a look how this looks under 22.03.
It looks like we will get hardware QoS (or some kind of trafic shaper) soon https://patchwork.kernel.org/project/linux-mediatek/list/?series=693712
4 Likes
ok that would mean we could activate sqm with software offloading and hwo right?
I think the SoC will handle everything and it should work with HW offloading.
But I'm not sure exactly what this series does. Looks like it's shaping traffic to no exceed link speed of the port. Not sure if it can be configured for custom speed.