@jeff Can you please explain where you see space problems with 8MB devices?
While I obviously can't speak for jeff, there isn't really any problem with 8/64 devices yet (and I wouldn't expect them to arise that soon), as long as you treat your router like a traditional router with few additional services.
On the RAM side, 64 MB doesn't really lend itself to pretty commonly used extra services like adblocking (the DNS based blocklists are large, even 128 MB RAM can quickly become challenging there[0]). Similarly 802.11ac, and ath10k/ ath10k-ct in particular, do require more RAM than previous generations. With a single ath10k{,-ct} based wlan card (and 2.4 GHz serviced by ath9k --> archer c7) 128 MB RAM probably do, if you have two of them (ipq40xx --> RT-AC58U) that is no longer sufficient and >=256 MB RAM are required.
On the flash side, 8 MB are comfortable with the default package set and some additional services (your figures are about right), but many enthusiasts (which often also covers beginners) are looking into OpenWrt particularly to use additional services. Once you start with VPN (openssl itself amounts to ~0.9-1.0 MB flash usage), you're pretty much immediately in the 6-7 MB range (so ~1 MB free space) - while not limiting yet, there isn't that much headroom left either (other services like adblock, bcp38, ddns, etc. are basically negligible in terms of flash requirements). But other very popular services like samba4 (just fits into 16 MB flash), minidlna (serving media locally) or some more fringe services like asterisk (~13 MB) are also around the upper end of flash requirements.
Things like background downloading services or p2p applications will require significant amount of RAM and, obviously, externally attached storage for all practical intents and purposes.
IMHO, as long as your treat your router like one did treat them in the past (a boring router, NAT, firewall plus some selected additional services), 8/128[1] should remain comfortable for quite some time to come; 8/64 is a bit more limiting, but should continue to work for a while as well. So these devices don't need to be recommended against, if you already own them and match your expectations accordingly - personally I wouldn't really recommend this class of devices for new purchases[2] though, because users will find ways to hit the limits[4].
--
[0] simple example, install luci-app-adblock and enable all provided example blocklists - not really going to work with 128 MB RAM.
[1] assuming 802.11n - or at least not-ath10k.
[2] for that I'd personally say 32/256 (maybe 16/256), 2+ cores (preferably ARMv7/ ARMv8[3]) and concurrent dual-band 802.11ac WLAN, but that's a) the enthusiast in me speaking and b) something I feel safe to recommend without knowing in detail what the user might want to do now or in the immediate future.
[3] the recommendation for ARM and against mips is based on surveying the router market, aside from old low-end designs with just some lip-stick on top, there haven't really been any new devices based on mips for a while.
- Broadcom --> Northstar is ARMv7
- Marvell --> Armada XP and 380 are ARMv7, Armada 3700 && 7k are ARMv8
- Mediatek --> mt7623/ mt7629 are ARMv7, mt7622 is ARMv8
- QCA --> ipq40xx/ ipq806x are ARMv7, ipq807x is ARMv8
[4] just looking at the requests for package inclusion into community builds for 4/32 is often revealing, many of those requested features (VPN, adblock, samba4, etc.) really are beyond the abilities of those devices.
2 Likes
alot devices 8/64 here. i also have very powerfull openwrt devices. i can confirm that my ubiquiti powerbeam m2 400 is more stable than my wrt 3200 acm and my zyxel 6617. this specific device will stay up for months, years.
slh hits the nail on the head with
However, there is far too much evidence to believe that users are willing to do that. I agree with his further statement
Yes, users of 8 MB devices will run into space issues when they try to install packages to meet their reasonable expectations.
Users expect reasonable feature parity with the OEM firmware for their devices. They even expect that a just-released, third-party firmware that boasts about “extensibility” and “security” will provide reasonable feature parity with current, OEM firmware for other devices. This includes their interpretation of “marketing claims”, which may be in excess of what actual functionality of the device may be (QoS/SQM are notable in this regard).
What are those features?
Let’s start with an older, well-known router — https://www.tp-link.com/us/home-networking/wifi-router/archer-c7/
- easily shares files & media with networked devices or remotely via FTP server
- Guest Network Access - provides secure Wi-Fi access for guests sharing your home or office network
- Easy setup and management with Tether App
- Parental Controls
- IPv6
- Quality of Service
File systems supported “always” include FAT, NTFS. exFAT is often supported. ext2/3/4 is sometimes supported, and often recommended by the forum. Some even support HFS+ (WRT32X, for example).
VPN has become a reasonable expectation of many OpenWrt users as well, for both privacy as well as for “cloaking” of access to specific service providers.
“Repeater” functionality is expected for a class of devices, often with limited resources. I’ll skip that for now.
So let’s see what that comes up to with a ROM before talking about what happens if a user installs onto JFFS2
Working with the Archer C7v2 on ath79 (master of November 15th)
- Easy setup
- luci
- remote/app-based management
- (Not really available with OpenWrt)
- Easily share files and media
- luci-app-samba4
- (requires manual addition of libcap)
- vsftpd (no LuCI available)
- kmod-fs-
- exfat
- ext4
- ntfs
- vfat
- luci-app-samba4
- Parental controls
- luci-app-adblock
- QoS
- luci-app-qos
- luci-app-sqm
- VPN
- luci-app-openvpn
- luci-app-vpnbypass
- openvpn-openssl
- (skipping WireGuard)
11,141,919 bytes >> 8 MB
Try to install that on a device from a "release" build as packages?
I've flashed https://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ar71xx/generic/openwrt-19.07-snapshot-r10704-17d8e47d35-ar71xx-generic-gl-ar300m-squashfs-sysupgrade.bin (not present on the ath79 target in 19.07) as I don't have a spare Archer C7v2 up right now. Note also that this is Linux 4.14, not Linux 4.19.
Remember that less than four erase blocks free in JFFS2 is risky (256 kB) and that this device has a 16 MB NOR flash (8092 1K-blocks extra, compared to 8 MB flash). So dropping below ~8.3 MB available indicates likely problems for devices with only 8 MB of flash.
This device also does not have a 5 GHz radio, so does not include the common ath10k-ct driver and firmware, as well as a copy of the ART segment onto the overlay.
As-installed
Filesystem Size Used Available Use% Mounted on
/dev/mtdblock5 11.6M 496.0K 11.1M 4% /overlay
opkg install kmod-fs-exfat kmod-fs-ext4 kmod-fs-ntfs kmod-fs-vfat block-mount
/dev/mtdblock5 11.6M 916.0K 10.7M 8% /overlay
opkg install luci-app-qos luci-app-sqm
/dev/mtdblock5 11.6M 1.5M 10.1M 13% /overlay
opkg install luci-app-openvpn openvpn-openssl
/dev/mtdblock5 11.6M 2.8M 8.8M 24% /overlay
opkg install luci-app-adblock
/dev/mtdblock5 11.6M 2.9M 8.8M 25% /overlay
opkg install luci-app-vpnbypass
/dev/mtdblock5 11.6M 3.1M 8.5M 27% /overlay
opkg install vsftpd
/dev/mtdblock5 11.6M 3.1M 8.5M 27% /overlay
It should be pretty clear at this point that "file sharing" of any flavor isn't going to fit (there would only be a couple hundred kB available on an 8 MB device), but for completeness
opkg install luci-app-samba4
Filesystem Size Used Available Use% Mounted on
/dev/mtdblock5 11.6M 11.2M 412.0K 97% /overlay
Can barely do that on an 16 MB device.
3 Likes
But overlayfs is not compressed as squashfs is 
I'm aware of that -- earlier in the post I showed that the ROM-compressed image size was well over 8 MB for what many would consider "functional parity" with OEM.