What to do with WI-FI routers that are no longer up to spec

I was wondering if all the routers that are 4/32, or otherwise no longer supported due to memory limitations, could be stripped of all packages except those needed for smart switch functions and WI-FI needs, giving them a second life?

These could be excellent dumb APs, extenders and bridges.
My understanding is WPA3 could be completely software based, further adding value to what are now either being thrown away or sitting in a drawer doing nothing.

Yes, I realize they probably have old radios that would probably not be super fast. But the question remains: could the Firmware Selector be used to remove unnecessary packages leaving a list of known packages needed for something much simpler?
Could the necessary packages be published; these old routers already have most the glitches worked out and are very familiar.

Just an idea I've had for a while but lacked the temerity to ask.

1 Like

It is already done - if you go to download 8MB firmware and expand package selection there is no luci by default. I think it will not be able to trim to 4MB.

I hope LuCI is doable.

What we would not need is firewall, DHCP server, WAN, logs, diagnostics, USB; basically everything that is shut down when we set up a dumb AP.

Just a smart switch with WI-FI and a GUI.

And, okay: maybe 4MB is not doable. What is?

Kernel is 3,5-4MB depending on platform, one wifi kmod will break the camels back. It is really an engineering feat to get running kernel with any wifi functionality into 4MB and still keep configuration saved.

Okay: >4MB...

8MB is quite fine, some have recently some OEM slack space clawed back for overlay, next release will even gain some space over current.

WPA3 key setup is done in software, the AES stream later is done in netcard same as WPA2.

So just install the latest firmware and configure it as a dumb AP and that is it?

For 8MB yes, but note that openwrt starts with 20-someMB used RAM and each new client takes another 2MB, and you need zram-swap in 64MB device to sustain garden party

I was really thinking of usages with very low throughput needs (e.g. IoT, guest networks) and VLAN them.

Not anything demanding.

Okay, thanks! I'll mark it solved.

Pain is when you restart one and all 10 thermometers jump to other AP

Then I'll just treat them like my 7 girlfriends and not tell them about the other APs...

Just kidding about 7 girlfriends. :rofl:

1 Like

Got you, but having seven old routers at home is a bit too sentimental.

When you put it like that, 7 GFs sounds a lot better ... :wink:

1 Like

Just to provide some perspective for 4/32. No, I did not omit the firewall in that example -and never will- but those are the limits (and keep in mind, we are preparing for kernel v6.6, so add another ~600-800 KB to the tally). Not a small percentage of those who are asking for 4/32 support do not restrict their envisioned usage scenario to AP-only functionality, quite a lot do expect to use them as router as well - that's the hard line I draw into the sand for myself, I will not sacrifice firewall or IPv6 support, anything else may be let go for the sake of an experiment.

Another thing to consider, 'old' APs do litter the scarce frequency band more than 'modern' ones - yes, modern ones will use larger channel width, but they're finished quicker and then allow others including your neighbours to use the airtime. (<=) 802.11b is the worst offender here, given the different encoding and 22 MHz channel bandwidth, but the same also applies in any situation where you mix very disparate device generations with each other (I'm not complaining about the odd client here or there, but about the infrastructure devices, the APs) - and the effects of a 'rogue' AP go three times beyond the distance you scan 'see' (scan for) them. So for your own benefit, keeping your old devices running might do more harm to yourself, than you might expect.

Power consumption is another topic, yes modern routers are likely to have a higher power draw than your old ath79 doorstop (802.11ac/ax/be radios are power hungry, even more so with 2, 3, 4 of them per device - before even thinking about proprietary 'mesh systems' with 2-5 satellites operating), but devices of the wrt-54g(l) era vintage had rather ineffective transformer based PSUs, while more modern switching power supplies do waste less electricity.

1 Like

I'd forgotten you wrote that post.

Now I don't know if my question was cryptomnesia or original.

FWIW, some older versions of OpenWRT worked fine on 4/32 devices, including firewall (back then, it was the 2MB devices which were in the "sorry, we don't support that" camp, although it was possible to build 2MB images, as needed e.g. for the WL-700gE). There were many other features missing, of course.
It would be interesting to see a breakdown of where that size difference went (e.g. IPv6, WPA3, easier firewall config, which part in the kernel vs which part in other files (big difference if you have a USB port so you can expand the disk space), ...).

1 Like

You are talking about well over 15 years of development.

Everything has grown since then and expectations as well as cold hard requirements have changed over that time. At the same time -fortunately- the system specs have improved as well, if you bought a 4/32 device in the last decade you knew that it was the absolute bottom of the barrel and explicitly recommended against.

1 Like

What to do with WI-FI routers that are no longer up to spec?
Hang them on a string to scare seagulls away from your roof......

Sorry, could not help myself..... :wink:

@slh: Yes, newer machines are better and OpenWRT made the right decision when it decided to drop support for 4/32. But that's not directly relevant to the OP's question.

I was one of those using a 2MB machine back then, and I remember there were many tricks one could play to bring the size further down (at the cost of more work and reduced featureset). One of the first things was to configure the kernel by hand (so you have more control over which features are included and which aren't) and build the features you want directly into the kernel rather than as modules. Another trick I played was to do the same (manual configuration) for the Busybox tool.
Of course, the first thing was to give up on the GUI: no LuCI, no web server at all, no SSL. I have a vague recollection that for the 2MB device I also had to give up on dropbear (and wifi) and rely on telnet instead (yes, that's insecure: it was OK because that 2MB image only needed to be able to mount the attached disk, where the rest of the system was installed (with dropbear and a lot more), so I connected via telnet only under very controlled circumstances while setting up the machine or when I had to fix bootup issues).