OpenWrt 21.02.0 - First Stable Release


Screenshot from Edgerouter X Network->Interfaces->Devices. It is a single switch device with 5 ports.

2 Likes

It is just a badly named CPU port. Normally it would be simply called „eth0“ or similar. No need to touch it at all.

3 Likes

Would it be worth me making an gitlab issue about it?

1 Like

Not sure. Usually such naming decisions come from upstream kernel development and OpenWrt tries to minimize the amount of local patches. I haven’t checked though if your particular model is upstream or only supported in OpenWrt yet. In the latter case it might be possible to change the name yet.

Maybe it would also make sense to hide DSA master devices in LuCI as there is no valid use case I can think of that requires explicit configuration for them.

2 Likes

I love OpenWrt. I have been running OpenWrt on my WRT1900ACS for years, OpenWrt allows me to setup my network the way I want.
I also have a Netgear WAC104 (CAT 5e to the WRT1900ACS) located on the other end of the house from the WRT1900ACS. With the addition of WPA3 to OpenWrt I decided to move the WAC104 to OpenWrt. It is working great!

Since the WAC104 is an WAP (no WAN network/connection) do I need to do anything with the firewall settings? I suspect not.

anything new?

Another forum member has reported problems bridging wifi to the WAN port after upgrading from 19.07 to 20.02, where the router is to be used as a vpn client router. The WAN port is hard wired to LAN port of ISP facing router. It is unconventional, but it does work in the past.

ISP router LAN <-> WAN openwrt vpn router (with wifi on WAN)

wireless devices connecting the wifi cannot get connectivity. (eg. no DHCP IP address from ISP facing router)

image

https://forum.openwrt.org/t/ac57u-update-firmware-to-21-02-0-warning/105744/17

The device in question with the issue is RT-AC57u v1. MT7621 device using DSA, 21.02.0.

I cannot reproduce the problem with Home Hub 5A running 21.02 - this is a Lantiq non-DSA device.

Unclear at this time if it is a bug specific to this Mediatek device, a bug/misconfiguration relating to DSA, or whether it is by design.

Anyone with more knowledge of DSA or Mediatek devices wish to comment, to help decide whether to raise a OpenWrt bug report?

1 Like

I confirm - there are some strange WDS issues, RC3 is fine.

OK, I was sloppy, it's not a LetsEncrypt certificate, it is a self-signed certificate.

And the issue I have is accessing an upgraded router across the Internet. I have habitually done this using ssh

#ssh -L <random high unused portnumber>:localhost:80 root@<FQDN-of-router-managed-across-Internet>

Then point web-browser on local machine at http://localhost:<same random high unused portnumber>

The initial setup of the router, before it was sent overseas included me connecting to a LAN port with a short Ethernet cable and setting up ssh (TOFU). Since then it has been upgraded remotely more than once. I have been pleasantly impressed with the quality of OpenWrt upgrades allowing me to do this.

So, when I connect, and am presented with a browser warning, I'd like some independent means of verifying the certificate details. If I can connect with SSH and dig around in the file system to check the certificate being presented to the browser is the one on the router, I'll be happy.

The issues around use of https on IoT devices (including equipment running OpenWrt) are discussed here: LWN.NET OpenWrt and self -signed certificates. Worth reading, including the comments.

I very much value not needing to rely on a CA. Some of my managed equipment is off-net, and will never be connected to the Internet, so I really don't want to run my own CA and import certificates into browsers on all the management machines. SSH TOFU works well enough when the first use is in a carefully managed security domain.

I'm interested in learning about the way OpenWrt has addressed this. I was not aware that a self-signed certificate was created when https was enabled. Looking at the certificate details, it seemed to me to have been pre-built and incorporated into the distributed upgrade. I need to check.

See this explanation from @hynman in my previous thread.

1 Like

I have packet loss when I play Cod
I think it will go back to rc1, it still doesn't seem stable
In rc1 I can play well without loss or anything strange being the first stable version

1 Like

Cudy WR1300 just upgraded fine from RC4, no issues.

Thank you for the link to the explanation for why the Invalid Certificate warning appears. However, now that the warning has appeared (for whatever reason), I'd like to know how I assure myself that the certificate details presented to me in the browser are authentic.
I was under the impression that it is a certificate common to all images. That might be false. If it is a common certificate, then it is possible for the certificate details to be recorded on the OpenWrt website, or in the download area.
If the self-signed certificate is generated fresh for each installation, then I'd like to know where to look on the router if I log in (securely) using SSH to find the details to compare with those presented in the browser. This is a basic MITM mitigation, as I am accessing via https for the first time across the Internet.*

If a mod wants to move this thread to somewhere else on the forum, please do so.

*I'm pretty certain I am not a 'person of interest' to anyone, but some people need to take all the care they can. I am interested to see what process can be used to assure the first-use connection of https. As I already have the ability to connect securely via SSH, it should be possible to take advantage of that to assure the ongoing security of https connections.

Do you have any kernel faults in system log for dropped packages?

Have this all the time on my ER4 but without any real noticeable impact of the function on the network.
ER4 is new to OpenWRT since 21.02 so I don’t have any 19.06 experience for that device.

Not on TP-Link Archer C7 v2 (Uptime 5 days). Very clean kernel log.

Obviously, different cpu / device to yours, so does not appear to be a generic problem.

1 Like

They don’t appear in the kernel log for me. They are in the system log as kernel error during run time.

The kernel log seems to only show boot log and then stops until next reboot…

Well after a reboot this morning I had a pppoe connection but no internet access. I had enable "accept local" on eth0 for it to finally work.

We are getting off track so quickly: assuming you're using the default uhttpd as the luci web server backend. Check the init script, you'll find how the keys are generated which are stored as /etc/uhttpd.key and /etc/uhttpd.crt.

1 Like

This release doesn't support Xiaomi Mi Router 3G?

Yes, it is generated when uhttpd, the tiny web server used for the web interface, is first started, using a tiny generator tool (px5g).

In the interest of keeping the environment small, OpenWrt does not come with an SSL utility, just with SSL libraries and that tiny small generator (px5g) to create that certificate. By default, there's no tool that can calculate and present the fingerprint for you.

And yes, it would actually be nice if such a small tool existed. However, as far as I can see there's no such tool approaching any sort of "small" available as an OpenWrt package, there's only openssl which comes with a bit of overhead. Using openssl you can then display the fingerprint:
openssl x509 -noout -fingerprint -sha256 -in /etc/uhttpd.crt

... or you pull the certificate (/etc/uhttpd.crt) from the router to a local machine and get the fingerprint there.

Edit: While I see the sentiment, the same problem arises with SSH. You are willing to trust the SSH connection, but not the SSL connection from the same device. There's a chicken and egg scenario here, and you can realistically only avoid that if you eliminate the physical possibility of MITM. (Edit2: i.e., as @mbo2o says below, initialize the device without any other connection inbetween you and the device.)

3 Likes