OpenWrt 19.07 Released with WPA3 Security, a Faster LuCI web interface

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.

Support CNX Software - Donate via PayPal, become a Patron on Patreon, or buy review samples
Subscribe
Notify of
guest
28 Comments
oldest
newest most voted
tkaiser
tkaiser
9 months ago

> 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… Read more »

tkaiser
tkaiser
9 months ago

Found it, ThreadX is handled as package brcm2708-gpu-fw in 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…

Diego
Diego
9 months ago

What a great versioning scheme, easily memorable and so intuitive at comparing two version strings…

Jerry
Jerry
9 months ago

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.

Willy
Willy
9 months ago

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… Read more »

David Jashi
David Jashi
9 months ago

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.

zoobab
9 months ago

“128MB RAM or more preferred.”

Are you kidding me?

David Willmore
David Willmore
9 months ago

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. 🙂

willy
willy
9 months ago

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…

David Willmore
David Willmore
9 months ago

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.

Jerry
Jerry
9 months ago

Now you can run Electron based IDEs and fill 32 gigs. Things improve so much over the years.

Philipp Blum
Philipp Blum
9 months ago

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.

Igor Pecovnik
9 months ago

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 🙂

theguyuk
theguyuk
9 months ago

That reminds me of the days when CPU and math chip was seperate chips intel DX and SX. Cyrix, Amd and intel chip.

zoobab
9 months ago

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 🙂

Willy
Willy
9 months ago

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… Read more »

David Willmore
David Willmore
9 months ago

I have one.;) I need to inventory that old collection, it seems.

Willy
Willy
9 months ago

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 🙂

David Jashi
David Jashi
9 months ago

Both of you are just overfed capitalists.
640Kb of RAM should be enough for everyone (c) Bill Gates

Max
Max
9 months ago

Don’t believe quotes on the Internet without proper sources. (c) Abraham Lincoln.
(Gates never said that.)

Diego
Diego
9 months ago

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 😉

Willy
Willy
9 months ago

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.

Diego
Diego
9 months ago

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. 😛

slh
slh
9 months ago

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… Read more »

theguyuk
theguyuk
9 months ago

Do they work with industry and provide a white book of specifican for hardware design?

Diego
Diego
9 months ago

Thanks cool!
So I will definitely retire this annoying thing or maybe once im bored ill tinker with the openwrt buildsystem

RK
RK
9 months ago

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.

Diego
Diego
9 months ago
  RK

Ill just use my zyxel 8/64MB instead for experiments

Advertisements