OpenWrt 21.02.0 second release candidate

Release and security announcements
166

Fiouz,

Thank you for this very helpful answer. I propose that OpenWrt (a) should produce a self-signed certificate with the SAN fields, which only requires knowing a domain name and IP address for the router and (b) have a download button for the certificate so that the user can easily obtain it and install it in the Trust Chain of their client (e.g. keychain on the Mac).

Using this approach, I was able to make the warnings go away. I followed the procedure here to make a self-assigned certificate. Then I used SFTP to get the certificate from the router to my Mac. Finally, I installed it in Keychain (the "login" keychain), double-clicked it in keychain, twisted down the "Trust" info, and told Keychain to trust the certificate. No more warnings!

While users can do this, I am not a coder and know just the bare minimum about Linux. It was a very error prone process for me and took a couple of hours to get right. I think OpenWrt could make this a process that takes a minute instead of a couple of hours for the novice.

jeremy

167

Or you could just live with HTTP for local OpenWrt router web administration as this is the default for new installations.

168

should browser vendor(s) standardise and simplify this process one-click:"add trusted local device"... perhaps...

supporting every browser and complex keychain add routine (which might change in the next browser release?) seems like alot of pain when in the current climate 70+% of users already know this and click 'accept anyway' (or whatever that browser's flavour of the year is in handling self signed certs)

1 Like
169

@roschelle63 you may look into adding a certificate download button to the package luci-app-uhttpd

Openwrt cannot do anything else to make this easier

170

What if the hostname or IP address is changed by the user?

171

@mpratt14 -- exactly.
@jow -- if there's someone who has the skill to code this as an improved version of luci-app-uhttpd I would be happy to help spec it out and to be a tester.

I don't have the coding skills.

Let me know if I can help. Meanwhile, I have resolved the problem for myself personally -- so I think the conversation is moot unless someone is planning to make changes to OpenWRT -- in which case, let me know.

jeremy

172

I foresee 'hackers' using social engineering to get people to install their certificates.

2 Likes
173

v21.02.0-rc3 is on its way.

174

There were some last moment fixes for the rc3. For rc2 we had way too many bug reports caused by Image Builders using outdated packages.

Please don't use rc3 Image Builders until the release gets officially announced.

6 Likes
175 
[20:39] <rmilecki> jow: ynezz: one more security question: could we have uci-defaults changing "redirect_https" from "1" to "0" IF there is no certificate? AKA: https was probably never used at all)
[22:00] <jow> rmilecki: regarding security question; no since the certificates are generated by the uhttpd intit script on first start, way later than uci-defaults
176

Ok well uhttpd could still change redirect_https from 1 to 0 on automatic certificate generation after upgrades, but I guess it would be a dirty fix

177

21.02rc2 now has a script that tweaks the minimum CPU frequency and governor to "reduce" the amount of crashes the C2600 gets.

If you haven't done this already, try setting your governor to performance. Seems to help a lot of us out with stability:

If it does, it's just masking the issue for a while. The core problem remains, even with the attempted fix the devs added to the C2600 image.

178

speaking of security...

under release goals > improve security of imagebuilder

it mentions ADD_LOCAL_KEY ...

@aparcar are you able to explain to the broader community how this works so we can begin to make use of this security improvement?

make help | grep KEY
	make image ADD_LOCAL_KEY=1 # store locally generated signing key in built images
179

@Torxgewinde
Thanks for the info, Was asking if any other qualcomm IPQ users was doing the same, Is seem to be happening sicne 19.x release though. And NAS is wired.

without echo performance

root@FB750:~# ping 192.168.2.10
PING 192.168.2.10 (192.168.2.10): 56 data bytes
64 bytes from 192.168.2.10: seq=0 ttl=128 time=0.605 ms
64 bytes from 192.168.2.10: seq=1 ttl=128 time=2.152 ms
64 bytes from 192.168.2.10: seq=2 ttl=128 time=2.193 ms
64 bytes from 192.168.2.10: seq=3 ttl=128 time=3.716 ms
64 bytes from 192.168.2.10: seq=4 ttl=128 time=2.646 ms
64 bytes from 192.168.2.10: seq=5 ttl=128 time=2.216 ms

Now with echo performance

root@FB750:~# ping 192.168.2.10
PING 192.168.2.10 (192.168.2.10): 56 data bytes
64 bytes from 192.168.2.10: seq=0 ttl=128 time=0.589 ms
64 bytes from 192.168.2.10: seq=1 ttl=128 time=0.513 ms
64 bytes from 192.168.2.10: seq=2 ttl=128 time=0.512 ms
64 bytes from 192.168.2.10: seq=3 ttl=128 time=0.503 ms
64 bytes from 192.168.2.10: seq=4 ttl=128 time=0.510 ms
64 bytes from 192.168.2.10: seq=5 ttl=128 time=0.509 ms

@anon72830772
never a crash with my FRITZ!Box 7530 however was capped at ~600Mbps but when investigating with htop (over SSH) i can see that only CPU 0 was been hit maxed with other 1-3 cores was sort of IDLE irqbalance fixed and now back to 950Mbps

180

Turns out that the busybox "ip rule" command can not process or show these "not" arguments. When I installed the ip-tiny package I could see the "not" was correctly in place.

Resolved

1 Like
181

so it was not a regression? and on 19 'opkg<ip' was required for this (show) functionality?

182

The command line "ip rule" problem was not a regression (it it is a bit odd on 1907 also). It turns out ip-tiny had been installed as a dependency for me on 19.07, so I did not see it there. And uci seems to be generating the right rules, but it does not use the command line to set that up.

I am still having a routing differences in 2102 which I am still investigating.

1 Like
184

Thank you for your suggestion to change govenor. I have installed a snapshots, and now I see, that rc3 is close. I think I will try to opgrade first, and wait a few days. If the problem persists with rc3, I will try to change govenor.

185

no, as of 21.02 rc2 https is the default for luci

186

I am currently trying rc2 on an Asus WL-500W.

In failsafe mode, the device is not reachable via the network.
This is a regression from rc1.
When the device is booted normally, networking is fine even on rc2.
In addition, I tried the upcoming rc3, and networking in failsafe mode is also broken there.

I suspect it is caused by ifname usage in /lib/preinit/10_indicate_preinit, but I have not debugged it.
@rmilecki?

Update: this bug was already reported as FS#3866

2 Likes