I'm using RPi4 and https-dns-proxy isn't working see this thread https://www.reddit.com/r/openwrt/comments/y1iyd7/help_httpsdnsproxy_isnt_working_anymore/
what is happended? why 22.03.2 released already? not even a week from 22.03.1 is 22.03.1 corrupted?
See here: https://forum.openwrt.org/t/openwrt-22-03-1-first-service-release/139424/32?u=eginnc
A new serious security issue was announced a couple days ago, and the OpenWrt developers have already tagged new stable versions to take care of it.
It is not as if we needed another reminder that the OpenWrt developers are awesome, but....well, they're awesome!
yeah 100% agree. They are awesome. I am eagerly awaiting the release announcement though, as this bug sounds really serious. Maybe somebody should also make a bug announcement post similar to the WolfSSL bug?
Or convert this one:
Thank you very much.
Unfortunately the problem with the USB-Port permanently resetting on Linksys MR8300 or maybe all ipq40xx platforms still exists in latest OpenWRT v22.03.01
In short, upon connecting an external usb storage device, the port keeps resetting / disables power to the device for short time leading to permanent connect / disconnect loop.
Please see Linksys MR8300, OpenWrt 22.03.0-rc4, USB port-powered storage devices not working - #29 by Barney for details. Maybe it hasn't come to the developers attention yet, since it is in another forum.
Upgraded from 21.02.02 to this version; noticed something is broken with SQM on this version - can get past 600mbit with SQM enabled. Running on i3-4160 CPU @ 3.60GHz, so not CPU bound, barley touching 15% on all cores.
When I disable SQM i get full gigabit download.
Reverted to previous version for a quick test and SQM is working fine; ingress set to 930mbit, and get around 900 on download test.
Anybody else has this problem?
I've been troubleshooting this for at least 3 hours, and half an hour after posting this I found the culprit; it seems the processor scaling_governor changed:
Version 22.03.1 scaling_governor:
ondemand performance schedutil /
schedutil is selected by default
Version 21.02.2 scaling_governor:
performance powersave /
powersafe is selected by default
When I change the scaling_governor to
ondemand - everything works as a charm, 900+ mbit with SQM, and processor going to around 8% on all cores.
Setting the minimum frequency to 1.2Ghz also does the trick
Your edit causes some confusion! You say 22.03.1 scaling-governor is set to "ondemand" by default and then state "When I change the scaling_govenor to ondemand -everything works as a charm". What are you changing if the default is already "ondemand"?
Maybe this will help:
Maybe I've written it poorly; for version 22.03.1 - there are 3 different settings for scaling_governor:
schedutil is selected by default
Anyone who installed on BT HomeHub 5A?
Is there any Boot Loop Issue?
@Sentenzo - this "hush" I'm seeing is actually everywhere. please don't blame OpenWrt, as this is an upstream software issue.
Did you see the LWN post about a employee at @ pple Inc. - who knew YEARS ago?
I thinks there's a rush to push the update faster than the news is spreading. I've only seen one news article at first...and it's been mostly copy/pasted until the last few hours.
I am not a dev.
OpenWrt 22.03.2 was tagged only 2 days ago in git. It takes about 2 days or more for the buildbots to compile all the packages and build images for all the target devices. The devs typically make an official announcement (in forum and mailing list etc.) only after the builds are completed and available in https://downloads.opewrt.org/ .
It's also not ready on the Firmware Seletor.
I believe the tag has to be manually enabled in the Firmware Selector (The OpenWrt Firmware Selector). I believe this is done only after official announcement of the release.
Within hours of the upstream announcement a thread was opened here and patches were backported. If this is such a critical issue, flash a snapshot or stable snapshot, step back, breathe deep and take a chill pill. It's a router, no one is dying here, unless this was the cause of the war plane into the highrise.
This is the [tin foil] hat consideration I, you (it seems) and others should use for such things (i.e. if I want a quick image, wait for the Firmware Selector). I explained that to someone just moments ago.
A state actor would use: time , money and resources to make [Zero-Day exploitation] software...and they [usually] wouldn't us it on [lil 'ol] us once they developed it.
(Edit: RIP to those lost that day - I was a teacher that day, I could see one of the sites burning from my classroom. I was responsible for communication and accounting the whereabouts of all students with the headmaster/principal/administration, etc. My comments are not meant to be vulgar, but relevant to security and safety.)
i have noticed this is not whole OpenWrt project issue, firmwares baked 26 hours ago, i've flashed them seconds it ready, i can't understood announcment issue only
This is the point I was making - I think the community could [perhaps] draft a Wiki page explaining the delay.
Just directing others to [just] make an image is the cause of frustrations, etc.
page explaining the delay.
Like this one right here:
The build system may still be running, and it is a pretty big job. It typically takes several days for everything to complete. The official announcement will come after everything is done.
Why don't you go check your stock firmware for whatever device your flashing and see how up to date it is? This is free open source software.
Wifi vulnerabilities are BS anyway, the person would have to be sitting with wifi hardware in range of your wifi trying to inject/see data with tools to exploit it, likelyhood of that is almost zero. Glad they are fixed, but nothing to get excited about.