Networking Shares (luci-app-samba4) is broken in rc2. Anyone know the way to get the fix commit installed? I tried opkg update but it's not available on there, the new snapshot isn't up yet might have to wait for that.
Won't most browsers give a death warning when trying to access the router's web interface using HTTPS (given it will be a self-signed certificate)? If so, I don't think it's a good idea to enable HTTP to HTTPS redirection by default.
They will.
HTTPS is enabled by default in 21.02 after sysupgrade because:
- Old releases had
redirect_httpsset to1 - 21.02 contains SSL support
Old releases didn't have SSL support so redirect_https didn't affect them.
We can't blindly set redirect_https to 0 after sysupgrade as this could cause security issue for some users (those who actually were depending on SSL).
Fresh installs don't force HTTPS (they have redirect_https set to 0).
2 Likes
You're right. I built the image on Jun 1st, so I ended up with an older version of the package. I have now upgraded luci-mod-network (and a few other packages) on my AP and tested the conversion to the new network syntax again. Now it works just fine. Thanks.
correction needed here...
Packages are dependant on phase2 buildbot which can take up to 3 days in the current schedule/climate
imagebuilder is a dynamic 'bundler' of 'date-last-built' packages from the packages repo which are constantly being rebuilt
(edit: see comment re: 'target' > packages)
official images contain packages that are built 'on-the-fly' direct from the git packages source
this means that 'core' packages between an imagebuilder image and an official image can have alternate versions (in this case luci-mod-network) and that there is a 'predictable' and definite timing element to what packages will be rolled into an imagebuilder image ( either older than or newer than an official image )
when using the imagebuilder, it is best to check that the last date 'packages' were uploaded is later than the imagebuilder date... this is often only evident during breaking changes to version dependent packages (rpcd, iwinfo and in this case luci-mod-network) or packages with known bugs
and when seeking support always state whether or not you are using an imagebuilder generated image or officially downloaded image as whilst they are similar that are NOT the same thing...
(thanks jow and hnyman)
3 Likes
Well I guess we could change redirect_https to 0 on upgrade only if no TLS certificate is found (therefore, HTTPS couldn't possibly be used on the previous version).
redirect_https could also be set to 0 by default in a future 19.07.8
There is no way for newly flashed firmware to know what exact firmware and packages were used on previous install (before sysupgrade). Only configs (/etc/config/* and few more) get preserved.
well the TLS certificate must be stored somewhere and kept during upgrades isn't it?
Just like the SSH key.
OK, what if given user was purposely using HTTPS (without a valid certificate - ignoring warning in browser) and then he upgrades? He will loose HTTPS which means security issue.
Not according to my suggestion.
Steps would be as follows:
User A was using HTTPS on 19.07:
- User perform sysupgrade, keeping configuration files
- The upgrade script check for the presence of the TLS certificate. Since it's there, https redirection is kept, and no new TLS certificate is generated.
User B was NOT using HTTPS on 19.07:
- User perform sysupgrade, keeping configuration files
- The upgrade script check for the presence of the TLS certificate. Since it's not found, https redirection is set to 0.
- Random TLS certificate is generated, in case the user explicitly connects using HTTPS
No security issue at first glance, but perhaps I am missing something.
i can confirm v21 rc2 is same on all linksys wrt routers, the wifi sucks, loss signal can't use RDP at all and Facebook videos stop. it was so stable with this settings (36GHz 80Mhz)
the wifi was working since lede to all the way to openwrt v19, since v21 not good.
Dito. Helped me too. So anyone affected by the older luci-mod-network package can solve it by manually upgrading to the recent version.
opkg update
opkg upgrade luci-mod-network
It will then output:
Upgrading luci-mod-network on root from git-21.147.37148-a86e770 to git-21.151.71533-b860704...
Downloading https://downloads.openwrt.org/releases/21.02.0-rc2/packages/mips_24kc/luci/luci-mod-network_git-21.151.71533-b860704_all.ipk
Configuring luci-mod-network.
Netgear R6220: successfull migration from rc1 -> rc2 while keeping the settings. Two steps migration within Luci to adapt the network settings. No issue.
1 Like
My R7800 results from 19.07.07 to 21.02-rc2:
- Sysconfig successfully upgraded
- Wireless config was broken after upgrade, regulatory domain was not set (I'm in the US)
- Due to no reg domain set, the channels I have set were not allowed by the kernel so hostapd would not start
- LuCI network page successfully migrated my /etc/config/network settings
- LuCI wireless page does not update /etc/config/wireless when changes are made (don't see this change in release notes)
- LuCI wireless page does not show my 5ghz wlan0 device as active.
- LuCI wireless Associated Stations only lists 2.4ghz clients. No 5ghz clients.
After manually editing /etc/config/wireless to set the country option I was able to get my 5ghz channel (wlan0) active and clients can connect. They appear to be stable (only been an hour though).
Edit: After testing a reboot, LuCI now displays my wlan0 5ghz radio as active... and is showing 5ghz clients that are connected. Hm...
Unfortunately, this does not seem true. I did a fresh install yesterday on a Zyxel GS1900-8 and it defaulted to HTTPS right from the start. I have another one laying here and will just try it again. Let's see...
That might also be caused by your browser, not necessarily the router. Some browsers prefer https over http, and are very hard to convince otherwise - most remember (cache) stale (now no longer existing) http redirects from a previous firmware/ device and need to have their cache deleted to re-evaluate the situation.
3 Likes
Since upgrading, my kernel says on 21.02.0-rc2:
Jun 3 09:45:35 WifiAP-01 kernel: [ 50.432044] leds green:qss: Failed to get trigger sources for /leds/qss
Jun 3 09:45:35 WifiAP-01 kernel: [ 50.438862] leds green:qss: Failed to get trigger sources for /leds/qss
model: TP-Link Archer C7v2
I've hit a strange problem: Since upgrading from 21.02.0-rc1 to 21.02.0-rc2, my Sony PS5 did not connect correctly. It showed:
- SSID "xxx": ok
- Got IP: ok (I configured static IP address)
- Internet connection: fail
I've restarted my TP-Link Archer C7 v2 AP and still no luck. When everything was working like expected, I always was able to ping the PS5 from my computer - now I couldn't ping it. I then tried to configure DHCP on the PS5 - still no connection. I connected my mobile phone to the SSID the PS5 also uses and got a fine connection (local network, internet).
Now the workaround that I did never need before the upgrade: I ran out of options what to do and cold booted the PS5 a second time - it worked again without touching OpenWrt's config or anything else.
I'll report if that happens again. I don't like to say it's OpenWrt to blame here, just an observation that still would need proof. It could also be possible Sony updated the OS meanwhilst and they have a bug on their WiFi receiver.
Support for configuring devices (config device UCI sections) was added. It can be used for setting layer 2 options (like MTU and MAC address). It also supports bridge devices (including VLAN tagging).
This is quite awesome. I've worked around this issue on my WRT1900ACS with some custom hotplug.d scripts to correctly assign switch ports and VLANs (even without VLAN multiple bridges from uci never did their job in RC1). Removed them, reboot and tried to configure the very same configuraion via LuCI.
The web interface seems little buggy sometimes:
- The "Bridge VLAN filtering" tab does show additional ports from other bridges when opening for several bridges.
Opening the "bridge ports" selection once (without changes) and switch back to the VLAN tab resolves this. - Saving the VLAN configuration form an inconsistent stores invalid (duplicate) settings and even killed my entire configuration once, so it was reset to defaults.
Ended up restoring my config backup, migrating again and adding the VLAN config via terminal. Works fine now without additional scripts.
Interesting. Can´t log in to my WR1300 via http anymore, since I tried https. Website appears correctly, but entering credentials does not do anything...
https is working, so its not so urgent, just FYI.
Win 10, Firefox 89.0
HTH