That was also my thinking. 32MB in total should be fine. IMHO I'm not a fan of running advanced L3+ stuff on a switch. Routing offloading is non-functional anyway right now.
If the failover is easy might be another story. For my Zyxel device, both partitions would end up with an rt-loader in place which you usually only flash once and never change again if not necessary. So to have an easy/good failover could be a potential feature extension for rt-loader. This would add more complexity but allows us to shape this how we want it. Different sizes of the dual-partitions with the main partition taking most of the space and the recovery one being very minimal, or whatever.
32MB devices could work for basic switching (and lets be honest, besides testing routing from an academic standpoint, the CPUs on realtek targets are not enough for modern routing). I have web UI with luci-app-lldpd as well as the prometheus-node-exporter setup with 22MB free out of 32MB.
Bigger question is how can this be integrated with boot processes so that a failed upgrade results in a reboot to the old partition? We can of course use a serial cable on the console but once we have gone that far we may as well reflash and restore the config.
Especially so if we start gutting out some of the default packages that simply don't make sense on a layer-2 device (firewall4, nftables, dnsmasq, odhcpd, and so on). If you want to use LuCI, you currently have to play a lot of games to do this, as luci-light has a dependency on luci-app-firewall, which sucks in a ton of stuff in that list. I've been poking around at this on and off for the past year on my AP with a luci-layer2 "collection" that keeps all the device management modules, but makes all WAN, DNS, DHCP and other layer-3+ capabilities purely add-ons.
It is pretty ugly, isn't it? My current recipe is roughly this, with my luci-layer2 package comprising the "adds". (I should PR it, so anyone interested can play with it and I can get some feedback...)
remove:
luci
luci-light
firewall4
dnsmasq
odhcpd-ipv6only
add:
luci-mod-admin-full
luci-theme-bootstrap
rpcd-mod-rrdns
uhttpd
uhttpd-mod-ubus
nftables is a dependency of both firewall4 and dnsmasq, so gets dropped implicitly; likewise for a bunch of nft libs and kmods.
Even with firewall4 and a bunch of luci packages the usage can be kept to only 10MB or so on 25.10 rc5, assuming I am not grossly misinterpreting the partition allocation on this 32MB HPE JG921A:
The dual-boot possibilities we have right now are rather bad, usually it's only a failed image check which triggers switching to the other partition. That should be both the case for devices running U-boot, and those that run Zyxel stuff (Bootbase + BootExtension). But as said, this is rather useless IMO.
Just some wild thoughts:
We could implement something simple, a boot counter somewhere in memory that is read by U-boot/rt-loader and if it is exceeded, it'll switch to the other partition. This counter needs to be reset by a small userspace script. With this, we could cover cases where the kernel is in a crash loop.
The case where Linux boots fine but our networking doesn't work is a bit trickier but a small userspace script could also do some checks and if some fail, trigger a reboot but don't clear the counter.
nftables is essential in one of my uses cases for switches, but only for the INPUT queue.
I wouldn't even think of using a switch as a passthrough firewall/router due to the lack of processing power. However, restricting the number of devices being allowed to connect to LuCI is important for defense-in-depth. Obviously, the best path is to have a separate management VLAN and to provide no access to the management interface from the user VLAN (great for office environments), but this is probably a bit unrealistic for a home network.
It is, and there are often other recovery methods. Usually, I try to keep a dual image layout if possible, but I gladly sacrifice it if there is an alternative recovery method (e.g. TFTP) for more/enough flash space. On the ZyXEL GS1920 there was no other choice as there is only a 16MiB flash chip.
I am also going to use both partitions on the XikeStor SKS7300 series because there is an RJ45 console port and it comes with a console cable out of the box (and network works in U-Boot). The HPE JG92x switches also have a standard console port.
And then there are devices where it's just useless to only use one image slot: The TP-Link SG2452P is such an example. While there are two partitions for the rootfs, only one kernel is present. The second image will never boot with an OpenWrt kernel.
To be honest, I find a dual image design rather useless on an embedded device, especially when running OpenWrt. Sure, things can go wrong, but if you dare to install OpenWrt, you should be able to hook up serial console for recovery. Thinking back how often I've had to attach serial for recovery on my production devices, this tends towards zero. The exception are devices that lack another way to return back to stock, but I don't remember any.
I couldn't resist buying a Zyxel GS1900-8HP Rev B2. @cryator did I understand you correctly that the B1 firmware image works well for switching, but you need to adjust the PoE config to get power on all ports?
Oh, I fully expect there are many cases where this is true, but my aim is to give those who want to strip things down the ability to do so without all sorts of work. (It's a lot easier to say apk add firewall4 when needed than it is to figure out how to apk del <a bunch of stuff> && apk add <some other stuff>.)
Has someone tried flashing a EWS2910P-FIT ?
It seems that the file format is different from the "non-fit" EWS2910P. (bix vs imag)
I also connected the serial port as mentioned in the wiki, but there is a key protecting the uboot commandline:
Enter correct key to stop autoboot: 0
So they seem to have added some security unfortunately. Someone has more info on this variant?
The sticker on the case says v1, the PCB says v3. I'd trust the PCB silkscreen
Indeed I had a further look, but there the annoying 64 byte header. So I had AI figure it out and create a tool to make valid imag files. And low and behold, the image actually worked! The only (? ) problem remaining now is to flash a non-recovery image. Since I get this message in Luci: System running in recovery (initramfs) mode. even after flashing a sysupgrade image.
I'm a bit worried/puzzled about this message in the serial console:
Cannot parse config file '/etc/fw_env.config': No such file or directory
Failed to find NVMEM device
But the file seems to be there, and its contents look reasonable:
Thanks! This is the package format indeed!
In the end I managed to boot in non-failsafe mode by modifying the uboot boocmd a bit to have the same offsets as userspace: A dirty way, but it worked
) problem remaining now is to flash a non-recovery image. Since I get this message in Luci: