OpenWrt is a popular Linux operating system targeting embedded devices, usually routers (but not only), and serves as a complete replacement for the vendor-supplied firmware on supported devices.
The developers released OpenWrt 19.07 on January 6, to succeed OpenWrt 18.06 the previous stable release. The new version brings various improvements including WPA3 support, client-side rendering of the LuCI web interface for faster rendering or a lower-load on the router, and introduces the ath79 target for MIPS routers with device tree support.
While WPA3 WiFi security is part of OpenWrt 19.07, it is not enabled by default because the necessary packages hostapd-openssl (access point), wpa-supplicant-openssl (station support only) and wpad-openssl (AP + station) take a fair amount of space, and won’t fit on devices with 8MB flash or less. Another reason for not enabling WPA3 is that many existing client devices will never support WPA3, and some client devices that support WPA2 will not connect to an access point configured with WPA2+WPA3 mixed mode.
LuCI web interface should render faster on OpenWrt 19.07 in cases where the client is more powerful than the router (most of the cases), as the client will not render the LuCI using JavaScript, instead of the previous way where the router would interpret Lua code for rendering. A known issue is that some LuCI apps have still not been adapted and if you suffer from crashes you should install the luci-compat package.
OpenWrt 19.07 introduces initial support for the new ath79 target, the device tree based successor of the popular ar71xx target used in MIPS routers. Both targets are still built in the latest OpenWrt version, but developers recommend to switch to the ath79 target since future releases of OpenWrt will drop support for the ar71xx target. You can follow the guide to upgrade from ar71xx to ath79 to do so.
Other changes include:
- Updated toolchain – musl libc 1.1.24, uClibc-ng 1.0.31, glibc 2.27, gcc 7.5.0, binutils 2.31.1
- Linux 4.14.162 for all targets with flow offloading bugfixes
- Network userland:
- hostapd 2.9, dnsmasq 2.80, dropbear 2019.78
- Fixes in network and wireless configuration handling
- Bugfixes in DHCPv6 client and server
- System userland:
- busybox 1.30.1
- Sysupgrade support for backup and upgrade capability checks
- Contains urngd, non-physical true random number generator daemon based on timing jitter
- Bugfixes in the process manager, system message bus, embedded web server and the configuration management library
- Platform and Driver Support
- Dropped adm5120, adm8668, ar7, au1000, ixp4xx, mcs814x, omap24xx, ppc40x, ppc44x and xburst target
- Updates and new device support across all targets
- Security fixes for LuCI web interface
It should also be noted that OpenWrt 19.07 will be the last version of the operating system to support devices with 32MB RAM and 4MB storage since they currently only offer limited functionality, and developers recommend devices with at least 16MB storage, and 64MB RAM, with 128MB RAM or more preferred.
Check out the detailed changelog for a thorough list of changes.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
> Linux 4.14.162 for all targets
…except Raspberry Pis where they have to rely on RPi Trading Ltd.’s heavily patched 4.19 kernel fork. For this lousy ‘router platform’ they also need to ship a copy of the RPi’s primary operating system called ThreadX but I failed to figure out which ThreadX release OpenWRT guys include in their 19.07 release.
But if it’s an old(er) ThreadX and OpenWRT misses a service to patch the USB chip’s firmware then chances are high that an RPi 4 running OpenWRT runs a lot hotter and wastes much more energy compared to the same hardware running a recent Raspbian Buster (which contains services to patch the various ‘firmwares’ accordingly).
Found it, ThreadX is handled as package
brcm2708-gpu-fwin OpenWRT and they’re at version 0c01dbefba45a08c47f8538d5a071a0fba6b7e83 which fortunately already supports future mainline kernels and contains at least two consumption/heat related RPi 4 fixes: ‘SDRAM firmware’ and ‘Clocking/Load-Step Firmware’. So only the ‘VLI firmware’ for the USB host controller allowing for (better) PCIe power management might be missing…What a great versioning scheme, easily memorable and so intuitive at comparing two version strings…
RPi is still one of the most popular router platforms. Everyone knows PiHole and similar products. RPi was one of the first SBCs to support full gigabits of network power. The modular bus architecture also makes it possible to attach more NICs when you need to route more complex networks. The NICs automatically support VLAN and other advanced routing techniques.
Jerry you’re pathetic. Really. Please reread your posts and fact-check them before clicking the “Post” button and you’ll look less like a fool attracting downvotes with each and every post you make.
First, no, I have never ever seen an RPi being used as a router because this platform was never made for this. There certainly are fanboys doing it just to prove it’s possible but most people won’t do it, because 1) it has a single port. 2) for a long time it was limited to 100 Mbps. 3) next it was fake Gigabit over USB.
And no, the RPi4B was not one of the first SBCs to support gigabit, it was one of the LAST one, if not the last one, to support it. The Guruplug that I bought about 10 years ago already had 2 GigE ports, and guess what, in addition it was really gigabit-capable. And it was cheap. So was my Dockstar, Goflex, Iomega Iconnect, Mirabox, Openblocks AX3, XP-GP, ClearFog, all the NanoPis M3/Fire2/Fire3/Neo2/M4/Neo4, CS008, MiQis, OrangePis, Odroids and even Atom-based boards bought over the last decade. Ah, the EspressoBin has 3 such ports and makes way more sense as a router. And only RPi was unable to offer gigabit for that many years when everyone else was already doing it, just because it has a guaranteed market of buyers who will take it to do anything provided they can proudly show it.
One Ethernet port at 100 mbps on “one of the most popular router platforms”.
This just made my day.
You should try yourself in stand up comedy.
“128MB RAM or more preferred.”
Are you kidding me?
That’s probably assuming you use features like stateful packet inspection, WPA3, etc. Or were you thinking 128MB isn’t much? I still think it’s a lot. My first Linux PC had 16MB and was a beast–at the time. 🙂
I started Linux with 1.6 MB (2 MB with the 640-1024kB non-remappable), it was very slow but used to work. With 4 MB I could start X. Then 16 MB allowed me to use 1024×768 graphics, it was great! Now bash alone uses more RAM the fully functional operating system by then, and it’s far from being the heaviest process. Try to figure where the problem is…
The first machine I used Linux on had 4MB (640×480 graphics) and was a 386DX/16. I don’t think we were using any kind of GUI at the time–there wasn’t one working yet. Ahh, the days of EMACS Eight Megs And Continuously Swapping.
Now you can run Electron based IDEs and fill 32 gigs. Things improve so much over the years.
And the humanity is talking about climate change… and people are wasting energy with this bullshit. Javascript is amazing. But people should stick to the stuff it was invented for.
Me and my schoolmates provided free Linux shell accounts an email on 486 DX 80 with stunning 8MB of memory running Slackware Linux .99pl11 Alpha … to anyone interested at university. Luckily not many knew what to do with that back in 1994 🙂
That reminds me of the days when CPU and math chip was seperate chips intel DX and SX. Cyrix, Amd and intel chip.
I had a Cyrix processor, was wondering why encoding a WAV in MP3 was taking 1 hour, while on a Intel Pentium of the same speed, it was taking 6 minutes. Cyrix had no math co-processor 🙂
It depends. The 6×86/6x86MX which made their initial success had one, it was just not pipelined, at the same moment intel was emitting pentium2 with a fully pipelined one and when games started to exploit it. That’s what ruined it.
However there were also low-end Cyrix CPUs to plug on 386 boards called 486slc/486dlc and a 5×86 for 486 boards, and none had an FPU. These ones were in fact IDT chips acquired by Cyrix and built by TI/ST/IBM and sold with Cyrix or the founder names on them. Some people used to say that IBM used to pick ones from the good bin and used the less good ones to put the Cyrix stamp. The 5×86 was a scaled down 6×86 and was not bad at all, even sometimes better than a real Pentium. But all of these couldn’t compete on certain processing by running on lower-spec’d motherboards and slower RAM. And indeed, their lack of FPU was a problem.
I have one.;) I need to inventory that old collection, it seems.
I think I still have the 6×86 @133 that used to be my file server for 5 years, and a 486DLC installed on a very late 386 motherboard which had 64 MB RAM, something totally insane for such a machine, that I wished I had earlier 🙂
Both of you are just overfed capitalists.
640Kb of RAM should be enough for everyone (c) Bill Gates
Don’t believe quotes on the Internet without proper sources. (c) Abraham Lincoln.
(Gates never said that.)
I tried it yesterday on 4/32MB D-Link DOR-600 B1 and am facing the same problem it already had with LEDE 18. I then found out that the overlay fs is a tmpfs instead of the usual jffs2 on mtd. Is this a limitation of 4/32MB or a bug in the dir 600 image?
I know here is not the openwrt bugtracker 😉
While I don’t know, maybe it could make sense for you to replace the NOR with a 8MB one. These are very cheap, I’ve done it already on a tiny “3G” router, all for good. In addition this flash usually is the largest pitch chip on the board so it doesn’t require strong soldering skills. You may enter into difficulties if you don’t have whatever programmer available though.
No plans on investing a single cent into this piece of crap. I used it as a satellite link simulator to annoy video conferencing vendors when i was still in the aviation industry. This router inserted so much packet loss and reorder it was great to see the Tandberg guy scratching his head. 😛
jffs2, the filesystem providing the backend storage for the overlay, needs at least 5 free erase blocks (usually 64 KB each) to function. If the firmware has grown too much to create a jffs2 (or if you ‘overfilled’ jffs to the point that it can’t mount anymore), only an emergency tmpfs backed overlay can be created on boot, leaving you with a non-persistent overlay.
You can report your device at https://forum.openwrt.org/t/report-devices-here-with-18-06-0-provided-image-too-big-to-save-overlay/18161 – however be aware that the margins to shrink OpenWrt’s default package set are exhausted, so the only fix will be disabling image generation for the affected devices, there is no magical incantation to make it fit again. But you can customize the image, either by building from source or using the provided imagebuilder to repack the firmware images, which can give you a little more space by dropping packages you might not require (e.g. the webinterface, package manager, ppp, etc.), which might be enough to keep your device working a little longer. But especially looking forward, your device won’t have enough flash, nor RAM, to remain viable. The official notice to drop support for 4/32 devices is only a (late) realization of facts, not a political decision for the future.
Do they work with industry and provide a white book of specifican for hardware design?
Thanks cool!
So I will definitely retire this annoying thing or maybe once im bored ill tinker with the openwrt buildsystem
I don’t know about you, but I’ve successfully used 18.06.4 imagebuilder for a dir 6** and will probably update to the recently released 18.06.6 stable over the weekend.
If not, I’ll probably just pick up a GL.iNet unit that fits the new specs and mess around with that.
Ill just use my zyxel 8/64MB instead for experiments