The OpenWrt Firmware Selector

I've noticed that as well. The packages on the website are also behind in terms of updates.

That's correct.

There's another software that will build an image with certain versions, patches, etc. I have not specifically used that to build a whole image (only to cross compile code to make a program for an OpenWrt device).

Maybe others can elaborate - or maybe even opine if that would be something easy to add on a firmware selector web GUI.

I mentioned the ease of use of the selector in another thread (in contract to one installing it themselves). It was after reception of mixed responses - mainly that I install it myself and assumptions I was ignorant for asking or mentioning issues with the selector.

Edit: also, you can select to install SNAPSHOT with luci-ssl - that should provide all up-to-date packages (but it all will be ahead of the current release - your terminology regarding that is somewhat a misnomer because yes, updated packages are no longer the released version 19, 21, 22, etc.).

Well, snapshots also upgrade the kernel and other firmware bits. I do prefer to have a stable kernel and related components so general functions don't break with just up to date packages like on Ubuntu, for example.

Packages were being updated through the firmware selector with the 22.03 branch since I've been running it for a few weeks now. The problem is the 22.03.1 branch.

1 Like

OK, that's odd. I haven't observed that. As I noted, all hashes remained the same in every case I've tested.

That's cool. maybe someone else can mention that.

Also...you are aware that .1 is already "EoLed" for 22.03.2 (coming soon) which has major security fixes too?

I am aware that .2 is incoming.

On another note, I just find the release cadence quite interesting. Perhaps weekly updates for those running official images would be cool, but having to build and test on each supported device isn't feasible. Feel free to ignore.

Thanks for reporting this behavior. Builds are cached for 12 hours so same package combinations result in the same hash. A better approach would be to automatically delete images whenever the internal update process detects new packages. I’ll put some thoughts into that.

@mwarning another solution would be that the firmware selector requests specific package versions based on available package lists. That’s how auc does it and thereby avoids the caching issue

3 Likes

Version upgrades possible? I am running a router with OpenWrt 21.02.2, and used the Attended Sysupgrade app (in LuCI) to upgrade. (Default config - it's config'd to use https://sysupgrade.openwrt.org)

The only suggestion was 21.02.4: I didn't see a choice to upgrade to 22.03.x

Is this expected? Thanks.

Update: I posted this note minutes before the announcement of OpenWrt 21.02.5 that fixes several CVE's. I just checked again, and the Attended Sysupgrade LuCI app does not offer 21.02.5. Is this expected? Thanks again.

I love this tool - however,

When selecting "TP-Link TL-WR1043N/ND v3", I get the answer "Unsupported version: 22.03.2"

Is that the expected behaviour?

This message appears while the build server is still not finished creating images for new releases. We need to wait for a day or two. Archer C50 v4 -- same here.

The latest releases were added to the upgrade server, thanks to @otaran

If you enable advanced mode you'll get branch upgrades. It's more likely to break things when switching branches so it's not shown per default.

3 Likes

Yes - 21.02.5 and 22.03.2 are now available in the Attended Sysupgrade GUI.

Ahah - I see now. Thanks.

i have a wrt3200 and did a attendend sysupgrade to 21.02.5
in advanced reboot i have
01 Current OpenWrt 21.02.5 (Linux 5.4.215)
which is corretc, however on the first status page it is

Firmware Version OpenWrt 21.02.3 r16554-1d4dea6d4f / LuCI openwrt-21.02 branch git-22.245.77575-63bfee6
Kernel Version 5.4.215

kernel version seems correct but version is wrong
also when i run opkg update it updates from the older 21.02.3 version
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a9_vfpv3-d16/routing/Packages.gz

this cant be correct, i assumed it would render me with latest version
i´m i missing something?

/t

I just observed another thing:

When you browse to a device on the firmware selector - for a stable release, it offers you the file at the downloads site (i.e. including LuCI). But, the list of packages shown above the link doesn't include LuCI. You have to press "Request Build" to get an image with the packages listed (i.e. doesn't list LuCI).

Those familiar with OpenWrt might observe that instantly, others might be confused. Just FYI.

1 Like

Would anyone like to chime in?

Requires testing.

I'm in I R A N. My internet is heavily monitored and is extremely slow.

I'm running openwrt-22.03.0 on a raspberry pi 3b+. This is a LOT faster than the govmnt sanctioned wifi hotspot I had to buy for internet access.

The sanctioned WIFI hotspot is a DLINK DWR-M921 and if you look the specs; it's a crippled version of the same model that's available in the EU and Australia.

Pay attention to the "M" in the model name designation. It stands for Middle-East, Africa, ... the usual suspects, Incidentally this junk cost me $150 USD instead of the less than 100 it would have cost me in the US for the more powerful version with more ram and flash storage which would have made installing openwrt directly on the wifi hotspot possible. I think I saw it for as low as $49.95 on the web. I bought this gem less than 6 months ago because the only way I can get internet is over LTE with a 4G SIM card.

I accidentally downloaded the wrong firmware for some off the shelf USB wifi stick because I was trying to setup a whole house VPN gateway and it killed my WIFI configuration. So I'm trying to download the latest image and install from scratch.

When I try to download the firmware for rasapberry pi it acts in a very weird way. The download bar suddenly jumps back or slows way the down and stops. I'm worried about it being tampered with on route to my machine. I of course did a shasum check to verify the file.

Here is what the shasum should be:
sha256sum: 1a4c5f7db99a316765859dccb8ff24081a0c7f4199a0fe63792e458c763cb336

Here is what I get:
shasum -a 256 openwrt-22.03.2-bcm27xx-bcm2710-rpi-3-ext4-factory.img
9ef6699bd70137a026fb936458f42a1051afc35c25000e2b897b2a86c967ef8d openwrt-22.03.2-bcm27xx-bcm2710-rpi-3-ext4-factory.img

Yes it does echo the filename after the shasum command.

By the way, my VPN keeps dropping as I'm typing this. I get a weird error while I'm typing:

"Draft is being edited in another window. Please reload this page. "

I'll try to upload an image of what the "reload page message looks like in a sec; but, They have reduced the upload speeds to 0.08 Mbps. So not sure it will work... that's why the screenshot will be a separate post.

Anyway, I'm did the shasum on a Mac mini M1. Does that make any difference? Apple silicon and all that.

Back to the topic. Is the file corrupted in transport? Yes I'm paranoid; I have good reason to be given my locale. :frowning:

I tried to download several times. No luck on the SHA. Is this an error with openwork.org, or is it blatant tampering??

BB

BTW the your draft is being edited message was displayed for than 15 times while I was typing. I stopped counting. My VPN is supposedly on; and I'm using https to access the site.

Before I forget ... My sincere thanks to the German, Chinese, and the Russian governments for helping the guys over here with deep packet inspections and sh**ting all over the internet, Awesome hardware and software my friends! You guys make the world a better place. You rock!! Especially Germany!!! That one was a huge surprise that I found out about today.

I'm sure the ladies over here wish to thank all of the German engineers for the wonderful software and hardware they have provided to the Morality and Virtue Police over here.

I did indeed read the rules. I'm not criticizing the German people; only the idea of selling software that helps beak the internet to a bunch of really lovely people. Farfegnugen all the way!!!! I'm feeling it!!!

small

Got it. This is the notification that kept popping up as I was typing. There were no other open windows on my system.

This would be a very funny situation if it wasn't so sad.

Yes, that's correct.

Yes, if the SHA256 doesn't match then the file is definitely corrupted. This could either have happened in transit (due to bad connectivity or deliberately) or by malware on your local system.

The best is to setup the VPN connection with policy routing and firewall in such a way that all local traffic only ever goes through the VPN and only the traffic of the VPN client itself is routed through your ISP. This can quite easily be done with wireguard.

No, SHA-256 is the same no matter on which OS or architecture it has been calculated.

Europe is full of companies exporting tools for mass-surveillance and censorship-enforcement, and it's hardly ever talked about, while people and media do scandalize NSO or Cellbrite, they hardly ever even mention ipoque (Germany), FinFisher/Gamma (Germany), ...

I don't know if it helps much, but I uploaded the bcm2710 release files to https://wormhole.app/pnJYP#J3GSooSBqB-p5Kbt_IuDJQ

We could also try BitTorrent or other protocols which bring some built-in integrity checking.

Before blaming a malicious actor, I'd first point at browsers/ operating systems which try to be helpful by automatically decompressing (g)zip archives (e.g. MacOS).

1 Like

Omg, what a terrible feature.

SHA-256 of uncompressed images:

9ef6699bd70137a026fb936458f42a1051afc35c25000e2b897b2a86c967ef8d  openwrt-22.03.2-bcm27xx-bcm2710-rpi-3-ext4-factory.img
64feb5a3cfee79b224b024cb72345cfb9b1fd0485e11df4d0b4cd69a3679dfd5  openwrt-22.03.2-bcm27xx-bcm2710-rpi-3-ext4-sysupgrade.img
3a81c79065f822fffff0c236e60d5ef77976a2926e5cc89ffdfd1979e8c018c8  openwrt-22.03.2-bcm27xx-bcm2710-rpi-3-squashfs-factory.img
e2140a05381b093b9c6fb695bd64defaeb5a5cf8825a86c4b4117ed467de976c  openwrt-22.03.2-bcm27xx-bcm2710-rpi-3-squashfs-sysupgrade.img

So that matches then, it's just that this extremely stupid Apple OS indeed transparently decompresses the file while downloading...