Installing LEDE 17.x or 18.x on Zyxel NBG-419N 4mb/32mb

Installing and Using OpenWrt
1

I have a few Zyxel NBG-419n's that I use to increase the WiFi coverage on my property as they were free (given out by the phone company when they upgraded users). I use a WRT1900ACS as my main router.

https://wiki.openwrt.org/toh/zyxel/nbg419n

I decided to upgrade one of them from OpenWRT CC to the current LEDE 17.x release. Installed with no issues.

Upon loading I am having an issue where my settings are not saved upon reboot, even a simple setting of the root password. From what I had figured out in researching things it sounds like it is touch and go with the 4mb devices having enough space to save settings (something with the overlay partition/mount being in ram). I also tried a newer LEDE 18.x snapshot and the settings are not saved.

Is this a known issue with 4mb devices or should this be working?

I will be posting a bit more information tonight when I have access to the router again. Anything besides df -h that would be useful?

2

https://openwrt.org/supported_devices/432_warning

If you still have enough free flash for a persistent overlay (at least 4 erase blocks at 64 KB each) depends on the device in question, 'ideally' the vendor reserves only 128 KB for u-boot and 64 KB for ART, leaving the rest to the actual firmware (OpenWrt in this case), but some vendors reserve more than that - and with devices that are extremely marginal to begin with, this quickly becomes a major issue. You'll probably have to use the imagebuilder (or better the full buildroot) to strip down your image - or replace the hardware with something better.

2 Likes
3

Suggests that the /overlay partition isn't working as expected, which can be caused by insufficient flash.

Seeing that the overlay filesystem is (or isn't) mouted, such as:

jeff@office:~$ mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mtdblock3 on /overlay type jffs2 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

I know the desire to stick with what you've already got (owning and running five, somewhat outdated Archer C7s myself). At some point the $/€20 or so for a current, 802.11ac router may be less painful to spend than the hours in getting it running on an older device, the performance limits that the older wireless technologies put on the entire network, and the potential problems if/when the underpowered devices unexpectedly crash or freeze.

There are many opinions on inexpensive devices in the long thread

4

Appreciate the link and response. I've actually managed to setup a working build of LEDE and did a couple builds and was able to flash and run them. I'll probably look into building a custom image as I really only need these as WiFi APs, can probably dig up a list of packages I can remove to gain some space.

5

I've noticed the same issue on my 4MB Flash/32MB RAM D-Link Dir 615D1 device: I can not persist configuration changes with 1806RC1, overlay-partition is mapped to RAM. So no config can be persisted beyond restart.

Is this just as a config bug of certain devices' RC1-build script?

Shouldn't 4/32 device images rather have no LuCi or have IPv6 removed, and in return still be able to persist config changes to disk?

6

Disclaimer, I'm not an OpenWrt developer and don't pretend to speak for them - the opinions expressed below are my very own.

You run into the limits of the hardware, it's as simple as that. Sure, one could could customize the configuration for each device, but the tradeoffs are different for every individual - and it would require checking (as in testing) every device (out of >750 supported ones) individually, that's not realistically possible.

https://openwrt.org/supported_devices/432_warning still stands - and it's a valid issue, which won't get easier as time goes by and with further (upstream-) updates. Moving ar71xx to the device tree based ath79 target will help a bit, at the same time the newer kernel is already bigger by itself, so most of the wins are already eaten up again. There are a couple of plans floating around to try keeping 4 MB flash devices alive for a bit longer (e.g. new in 18.06~ is the "tiny" subtarget, but the ecosystem has grown enough to mostly eat up all the gains relative to 17.01.x), these might even involve not including luci (hint, the master snapshots don't include luci either, so use them if you're in doubt) for them (which will make the device 'unusable' for most casual users), but you can't avoid the cold hard fact that it's getting increasingly difficult to keep devices with 4 MB flash OR 32 MB RAM alive.

What is simply not possible, is expecting that every single device for which images are built is guaranteed to work, it all boils down to users testing it and filing bugs in case of problems - the particular issue of "flash not large enough to fit the release image, with the default package set" might however be 'unsolvable' in the short term (and in the long term you'll lose against newer upstream versions only getting larger, than smaller - so you'll have to cut even more), respectively only be solvable by not generating an image for the affected device in the first place.

2 Likes
7

I appreciate the responses. I flashed the 18.x snapshot and it doesn't include Luci, which I thought would allow it to have enough free space to setup correctly, but it didn't.

BusyBox v1.28.3 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06-SNAPSHOT, r7102-3f3a2c966a
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
tmpfs                    13.7M    648.0K     13.0M   5% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev


BusyBox v1.23.2 (2016-01-02 10:46:55 CET) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER (15.05.1, r48532)
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                  448.0K    212.0K    236.0K  47% /
/dev/root                 2.3M      2.3M         0 100% /rom
tmpfs                    14.2M    488.0K     13.7M   3% /tmp
tmpfs                    14.2M     48.0K     14.2M   0% /tmp/root
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock6          448.0K    212.0K    236.0K  47% /overlay
overlayfs:/overlay      448.0K    212.0K    236.0K  47% /
root@OpenWrt:~#

I was hoping not having Luci would at least get the device setup correctly so I could configure and save settings.

As of right now I've gone back to CC, which I also posted the df -h of.

8

Due to serious security issues, sticking on an outdated/ unsupported release like 15.05.1 should not be considered an option, regardless of the device in question. You'll find pretty capable devices (which should be good for OpenWrt for several years to come) on the used market for the equivalent of a fastfood meal - and pretty nice dual-band ones brandnew starting around 40 USD/ EUR.

2 Likes
9

@bmasephol: snapshots never include Luci. Not having Luci does give some free space. but still devices with 4MB do not have the opkg-tool as part of their images due to space limitations, so you cannot use opkg to manually add LuCi. To put custom packages on small devices your only choice is to create custom build images.

@slh: appreciate your time and thoughts
I think my thoughts are basically the same what you are also saying: I totally agree 4/32 devices should not be considered for serious usage when buying something new.
But my expectation is: If openwrt.org has "stable" image as downloads for such devices, then these images should at least be somewhat usable. My opinion is, a device that cannot store&persist basic config changes (you cannot even set a root password on it) is not useful and in consequence such an image should not be offered for download in my opinion.

People will clearly accept if their 4/32 device is no longer supported, but are disappointed if they find an stable image download, that eventually later turns out to not be of any practical use. People at least expect a note like "you most likely can not store config changes any more on 4/32 devices, if you use 1806"

What I do not know: It could be a different case due to lack of information in the current phase:
It could be that working images can only provided for some of the many 4/32 devices (as devices differ, as the boot partition size has different size from vendor to vendor, leaving varying free space left).
If users in the current RC-phase have to find this out first, this is also fine. But in this case someone needs to speak up and tell people "hey guys listen, our automatic build scripts cannot detect whether available space is sufficient and we do not have the capacity to find this out manually on every 4/32 device. We need volunteers to manually test 1806RC1 on different 4/32 devices and provide feedback on the Wiki device pages whether 1806 works or not"

But from a user perspective, it's not helpful to kind of see the roof flying off and still see claims that everything is fine (we still have wiki notes like "4/32 is ok, you just will not have LuCi and cannot have custom packages" plus there are ongoing forum discussions for months saying "4MB is not a problem, devices still supported, but with 32MB RAM you can't do anything beyond basic routing".
This does not reflect what the current 4/32 experiences on 1806 are. There are more open threads with other devices: LEDE on D-Link Dir-615 H1 (4MB Flash, 32 MB RAM)

Long story short: Users get confused because of the gap between current communication and their practical experience regarding 4/32 devices and we should do something about this.

I think we need to at least add a clear note on the release note page of 1806 (https://openwrt.org/releases/18.06/start).
I am willing to help and provide such a text update on the wiki on this issue. and I think we need to stop telling people in the forum that 4/32 devices are still supported for a while.
But for this the specific dev thoughts on 4/32 + Release 1806 would be helpful first.

1 Like
10

There is a very clear message on every device page which lists only 4 MB flash or 32 MB RAM, its URL has been posted twice in this thread already.

11

Since when is that?

12

I don't know if it was already consider but creating a lede/openwrt-TINY/LIMITED version with a limited feature set for 4/32 devices and a clear note that these devices are not powerful enough for vpn,vlan,you-call-it,...

I have a lot's of 4/32 in stock/use which do there (simple router) job with lede without any problems. Manufacturers eol was maybe 5 or 10 years ago and lede/openwrt is the only reason these devices are still alive/usable/supported. Not supporting this category means sending these devices to death/trash... and I think we are talking about a lot's of devices... So it's kind a environmental devices to take...

For (buying) new devices it's a different chapter... sure... But still there are bargains for less than $10 and they DO THERE JOB! :crazy_face:

13

I think the biggest thing for me about upgrading devices is that I have "working" devices that are 4mb and really wouldn't go looking to update if I wasn't as into tech as I am. I've handed out a few of these routers configured with CC to friends/family. As long as those devices keep blinking lights at them they will never look to update them. That is a good and bad thing. Good since they wouldn't upgrade to a possibly non functional version of OpenWrt, but bad in the sense that they might have security issues that could possibly cause them issues.

14

With that, I definitely agree. If there is a specific device that truly can't persist settings, then yes, I agree that it should be removed from the buid list.

Given the number of "screams" when some decade-old or under-resourced device is even considered from removal, I don't know that I'd agree with that. Personally, I think that the project should drop "official" support for every 4/32 device, and change its messaging to state that "best for LEDE OpenWRT" only includes devices with, as a stake in the sand, 16/128 as a minimum.

15

Not only cause problems for them, but everyone on the Internet.

While an individual might "not care" that their router was compromised, they can become jump points for other attacks, participate in DDoS attacks, and other nefarious activities that impact others. Supporting devices with significant, known vulnerabilities without resolving those vulnerabilities is, in my opinion, not an acceptable action.

2 Likes