From personal experience: DLM can and does recognize the difference between a line fault and a line that was deliberately taken down. But it's having trouble telling the difference if the line goes down and almost immediately tries to synchronize again (as it happens with a reboot.) This can be avoided by deliberately keeping the line down for several minutes, I usually keep it down for 10 to 15 minutes and I haven't seen any punishments since.
1 Like
Tangent: Assia's DSLExpresse DLM/DSM solution apparently collects the data it acts on as counts in 15 Minutes, so keeping a modem down for 16 Minutes should gurantee to fall into the next bin....
1 Like
I am getting adguardhome errors on start
panic: qtls.CertificateRequestInfo Doesn't match
This was not a problem with rc4.
Running on a Raspberry pi 4B and using OpenSSL instead of WolfSSL because I could not get acme running with WolfSSL.
been testing Xiaomi Router 4a 100M. So far it no longer having RAM usage issue. it stays on the same RAM usage even after a few days of uptime, in 19.07 this router will crash just a few days (worse just a few hours) of uptime due to rougue RAM usage issue which will go down to only 3MB ram free.
I removed it on my test bench and now install it on my home network with some few package installed with 16MB free RAM and it no longer go below that RAM usage now.
been happy with 21.02 release all the routers I have now in mesh mode no longer randomly crash.
Installed 21.02.0 release and all is working fine, my issues you are referring to have been long fixed running both on my EA and MR routers.
Attempted at least 2 installs. Went back to Netgear firmware and used factory.img each time. After configuring wireless successfully, wireless would fail after moving on to other parts ofconfiguration.
Now using 19.07.8 and things seem to be ok. 21 needs more work in my opinion. The Netgear R7800 should do well with OpenWrt.
Thanks for this.
It's not a topic for this thread and the safe delay may vary between ISPs. But I think I shall avoid doing anything until my local connection recovers,
I updated from 19.07.8 with keep settings. Note that I think the upgrade script does migrate something. So restoring old config files after install is not a good idea. Also note that luci also changes something in the config (ifname gets renamed I think).
For the e4200v2 I did setup by hand again (mainly changing vlan via luci)
Hope this helps.
Just for the record, I am not 100% convinced that the two reported problems with flow offloading (the first related to long-lived connections like ssh, and the second to ipv6) have the same cause.
Thank you for all the hard work producing this newest release.
With the enablement of https connections, I think it would be good to provide an independent source of details about the LetsEncrypt certificate used.
When I connect to my router running OpenWrt 21.02.0 with https, my browser (Firefox) continues to give a warning "Warning: Potential Security Risk Ahead". If I opt to continue, by clicking "Advanced..." I get:
<router-domain name> uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
View Certificate
[Go Back (Recommended)] [Accept the Risk and Continue]
The certificate details are
Certificate
LEDE
Subject Name
Country ZZ
State/Province/County Somewhere
Locality Unknown
Organisation LEDEfe1d8314
Common Name LEDE
Issuer Name
Country ZZ
State/Province/County Somewhere
Locality Unknown
Organisation LEDEfe1d8314
Common Name LEDE
Validity
Not Before Mon, 30 Aug 2021 22:21:32 GMT
Not After Thu, 31 Aug 2023 22:21:32 GMT
Public Key Info
Algorithm RSA
Key Size 2048
Exponent 65537
Modulus C9:20:BD:A3:57:97:13:93:E1:CB:47:7D:FD:B2:6C:5C:64:22:C0:0...
Miscellaneous
Serial Number 35:B0:BD:57:D8:8A:42:0A:94:71:DF:A9:5A:DF:11:80
Signature Algorithm SHA-256 with RSA Encryption
Version 3
Download PEM (cert) PEM (chain)
Fingerprints
SHA-256 8B:9E:BE:39:BC:58:D5:BF:8B:F5:FD:36:88:08:AF:74:F7:57:CE:DF...
SHA-1 C7:59:CD:19:03:9D:5E:07:4D:17:9A:A1:BC:18:F9:78:0B:7C:90:12
Now, the problem is, I don't know if the details are authentic, or someone is doing a sophisticated MITM attack. For the paranoid*, could the appropriate details be posted on the OpenWrt website, so that on first use, I can check the certificate details?
*For the really paranoid, this would be insufficient. In any case, I should probably generate my own certificate. As it is, I will probably continue to use http through an SSH tunnel as long as browsers allow me to use http.
How to update from 07.19.8 Archer A7 v5?By updating sysupgrade?
details about the LetsEncrypt certificate used
What makes you think this is the case? What kind of LE certificate is used you believe?
As you can see in the warning message your Openwrt box is using a self signed certificate so it cannot be validated by the default Mozilla CA certificate pool hence the message:
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
Also if you have a freshly installed 21.02 with HTTPS enabled and you connect to it directly (via cable), and changed nothing in firewall settings it should be a really-really sophisticated MITM attack to hijack your device ... very-very unlikely. You know, with default config accessing device from WAN is blocked, only can access from LAN side, WiFi is disabled, you need direct wired connection.
By the way due to being a self signed certificate which is
a) created when you first run the built-in web server in HTTPS mode,
b) specific to your device
no "appropriate details" can be posted imho.
So I would not worry about authenticity, the alarm message is a bit annoying at first indeed but you need to allow FF/Chrome only once to proceed and next time it will not complain.
I don't know your network setup but I assume you control your own Openwrt device and your network too, and HTTP over SSH tunnel within your own network looks like overkill. And actually it is working very alike: your SSH keys are created too by your device, they are neither any way publicly validated. The very first time your SSH client will raise a similar warning and it is up to you to allow the connection to proceed, then your 'self created' key is stored in your client's repository and next time it will not ask again. So looks not any more secured imho.
1 Like
I guess the entries on https://openwrt.org/docs/guide-developer/releases/goals/21.02 can be marked green now.
I am looking forward to the 22 release chart starting now.
1 Like
Dsa still being worked on actually. To make this huge task more manageable each target architecture group is being converted to dsa individually .
There are a few GitHub threads open where things are happening, eg ipq806x (which among others, is the soc inside the popular R7800) is located here if you’re interested following along
It’s not clear yet whether these changes will actually get backported from master into the 21.02 branch, but I’m hoping that is the plan still.
That part is clear, it's not going to happen - not for 21.02.
1 Like
On the Devices page there is a DSA device and individual ports. Why is that? Isn't DSA an architecture, a way of configuring switches, and not a device? What am I missing?
Isn't the idea behind dsa to represent a switch as a bunch of interfaces that can ne configured with the standard linux tools? So creating a bridge over all ports will give you a switch.... (not sure where/how switch specificvsettings like STP should be configured, but I have not researched that topic all too deeply.
That's what I thought too, but in luci "dsa" is it's own device, alongside with "br-lan" and "eth0" and the rest. I had br-lan and eth0 active (non-greyed) while dsa was greyed. Checking the "Accept local" checkbox turned dsa into non-greyed. Weird.
EDIT: In fact, making any change in the configuration seems to "activate" (non-grey) a device.
DSA is an abstraction layer similar to swconfig... with the key difference that switch 'ports' are represented to the upper OS as specific named 'named-logical-ports-or-devices'
for most OpenWrt devices... the logical representation of a DSA-switch-port is with i.e. lan[0-4] naming...
With DSA, the CPU port still appears as an interface, but as far as i know you shouldn't need to touch it -- it should be brought up when you configure the port interfaces (as you saw), and configuration happens through bridges, or the port interfaces.
1 Like