Re: [PATCH opkg 0/5] Purge packages from cache when they have incorrect checksum
On Fri Nov 20, 2020 at 12:43 AM HST, Baptiste Jonglez wrote: > Hi, > > Any news on this patch series? It should definitely be considered > before the 20.XX branching because it fixes FS#2690 (bug related to > imagebuilder), and I would like to backport it to 19.07 at some point. I CI built this and tested the ImageBuilder as follows: * Run once and create firmware images * Run `echo "foo" >> dl/base-files*.ipk * Run again The `opkg` detects correctly a checksum missmatch and downloads a fresh copy again. Excellent! Below a snipped log --- 8< --- Installing kernel (5.4.77-1-211d098873122e25225ddfe3f75dbf13) to root... Configuring kernel. Installing base-files (237-r14984-d369993898) to root... Removing base-files from cache because it has incorrect checksum. Downloading http://downloads.openwrt.org/snapshots/targets/ath79/generic/packages/base-files_237-r14984-d369993898_mips_24kc.ipk Installing libubox20191228 (2020-08-06-9e52171d-1) to root... Copying /tmp/f1/openwrt-imagebuilder-ath79-generic.Linux-x86_64/dl/libubox20191228_2020-08-06-9e52171d-1_mips_24kc.ipk. Installing libuci20130104 (2020-10-06-52bbc99f-3) to root... --- >8 --- I couldn't come up with a simple way to change the size while keeping the same checksum (hoping overall there is no such way anyway), so that's untested. However, as this patch "recycles" the previously working size check I have no doubt it keeps working. Size for mvebu/cortexa9/arm_cortex-a9_vfpv3-d16 increased a tiny bit, but that seems totally worth it. Comparing package sizes... Change Local Remote Package +98 66602 66504 opkg Therefore, Acked-by: Paul Spooren > > Thanks, > Baptiste > > On 25-08-20, Baptiste Jonglez wrote: > > From: Baptiste Jonglez > > > > The motivation of this patch series is to fix FS#2690. Because packages > > are continuously rebuilt, the ImageBuilder ends up with old packages in > > its cache, and fails because checksums don't match with the new package > > index from the download server. > > > > The approach to solve this problem is the following. Before using a package > > from the cache, verify its size and checksum against the package index, and > > delete the package from the cache if they don't match. The install process > > will then proceed to download the "fixed" package as usual. > > > > The main patch is "download: purge cached packages that have incorrect > > checksum". The other ones are either cleanup or refactoring to prepare > > for the main change. > > > > Baptiste Jonglez (5): > > download: remove compatibility with old cache naming scheme > > libopkg: factor out checksum and size verification > > download: factor out the logic for building cache filenames > > download: purge cached packages that have incorrect checksum > > opkg_verify_integrity: better logging and error conditions > > > > libopkg/opkg_download.c | 123 > > libopkg/opkg_download.h | 1 + > > libopkg/opkg_install.c | 76 +++-- > > 3 files changed, 108 insertions(+), 92 deletions(-) > > > > -- > > 2.27.0 > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] download: handle possibly invalid local tarballs
Currently it's assumed, that already downloaded tarballs are always
fine, so no checksum checking is performed and the tarball is used even
if it might be corrupted.
From now on, we're going to always check the downloaded tarballs before
considering them valid.
Steps to reproduce:
1. Remove cached tarball
rm dl/libubox-2020-08-06-9e52171d.tar.xz
2. Download valid tarball again
make package/libubox/download
3. Invalidate the tarball
sed -i 's/PKG_MIRROR_HASH:=../PKG_MIRROR_HASH:=ff/'
package/libs/libubox/Makefile
4. Now compile with corrupt tarball source
make package/libubox/{clean,compile}
Signed-off-by: Petr Štetiar
---
Changes since v1:
* fixed infinite re-downloading of the source tarball when using
KERNEL_GIT_LOCAL_REPOSITORY
include/host-build.mk | 2 ++
include/package.mk| 2 ++
scripts/download.pl | 18 ++
3 files changed, 22 insertions(+)
diff --git a/include/host-build.mk b/include/host-build.mk
index 7d84ab0f5fc4..4ac140518113 100644
--- a/include/host-build.mk
+++ b/include/host-build.mk
@@ -186,6 +186,8 @@ ifndef DUMP
clean-build: host-clean-build
endif
+ $(DL_DIR)/$(FILE): FORCE
+
$(_host_target)host-prepare: $(HOST_STAMP_PREPARED)
$(_host_target)host-configure: $(HOST_STAMP_CONFIGURED)
$(_host_target)host-compile: $(HOST_STAMP_BUILT) $(HOST_STAMP_INSTALLED)
diff --git a/include/package.mk b/include/package.mk
index 50bd838180d8..5eb4460db86c 100644
--- a/include/package.mk
+++ b/include/package.mk
@@ -189,6 +189,8 @@ define Build/CoreTargets
$(call Build/Autoclean)
$(call DefaultTargets)
+ $(DL_DIR)/$(FILE): FORCE
+
download:
$(foreach hook,$(Hooks/Download),
$(call $(hook))$(sep)
diff --git a/scripts/download.pl b/scripts/download.pl
index 351b06a08b2f..2d87f47f842b 100755
--- a/scripts/download.pl
+++ b/scripts/download.pl
@@ -262,6 +262,24 @@ foreach my $mirror (@ARGV) {
push @mirrors, 'https://sources.openwrt.org';
push @mirrors, 'https://mirror2.openwrt.org/sources';
+if (-f "$target/$filename") {
+ $hash_cmd and do {
+ if (system("cat '$target/$filename' | $hash_cmd >
'$target/$filename.hash'")) {
+ die "Failed to generate hash for $filename\n";
+ }
+
+ my $sum = `cat "$target/$filename.hash"`;
+ $sum =~ /^(\w+)\s*/ or die "Could not generate file hash\n";
+ $sum = $1;
+
+ exit 0 if $sum eq $file_hash;
+
+ die "Hash of the local file $filename does not match (file:
$sum, requested: $file_hash) - deleting download.\n";
+ unlink "$target/$filename";
+ cleanup();
+ };
+}
+
while (!-f "$target/$filename") {
my $mirror = shift @mirrors;
$mirror or die "No more mirrors to try - giving up.\n";
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 20:23, Paul Spooren wrote: On Fri Nov 20, 2020 at 7:35 AM HST, Adrian Schmutzler wrote: Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Alberto Bursi Sent: Freitag, 20. November 2020 17:32 To: openwrt-devel@lists.openwrt.org Subject: Re: 20.xx: postponse LuCI HTTPS per default On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. I'm curious where the whole topic evolves to, but that's not the subject of this thread. How about we use `luci-ssl` per default but set `redirect_https` to 0. This way everyone can access in a secure way, without changing the current user experience. An optional combination of Luiz idea could warn the users using HTTP, allowing to "ignore" or "activate redirect". I think that's a feasible solution for 20.xx. Spinning up a massive HTTPS dDNS or defining a new standard accepted in all common browsers seems a bit out of scope, for now. Paul I'm not sure what you are accomplishing with this beyond increasing the default image size. The way I see it, we either switch to https by default or we don't. Adding luci-ssl without redirect manages to annoy both types of users for no reason imho. It is just bloat for people using http, it's inconvenient for those that use https and would have liked the redirect to work by default -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 19:22, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. maybe, but it's still better than sending all communication to the management interface as plain text. What is the difference between transmitting packets containing cleartext and transmitting encrypted packets to a party whose identity you do not know? What are you talking about? After the initial "pairing" process where you see the warning, the browser remembers the certificate for all subsequent connections. If the certificate changes (and it will change only if you do a firmware reset to default settings) you will see the the warning again. So you are just changing a CA-based system to a local pairing system. (I really do not mean for any of my comments here or earlier to be patronizing. I am just trying to describe my point of view.) When I make the first SSH connection to a new router, I confirm the fingerprint of the router's key using a serial-port connection. Thus I know it is safe to accept the pairing. If I were to skip this step, then I would have no assurance regarding to whom my encrypted messages were being sent now and in the future. I think that if the first setup is done with only the router and the trusted PC connected to it through an ethernet cable (wifi is disabled by default), there is physically nothing else on that "network" so whatever you see can be accepted even if you don't have "dual authentication" with the serial port. The only way for that to go bad is if your PC isn't trusted, but if that's the case, using a serial console from the same PC won't help much. Although I understand what you mean. How would our scheme recreate this? What would the interface provide to the user to help them perform this step? What would it recommend? Some tugging on Luiz Angelo Daros de Luca's proposal earlier in this thread (Fri, 20 Nov 2020 14:25:10), especially the addition of a suggested verification process, might help. How can you recreate a secure two-step verification process without two different communication mediums? I don't think it is possible, so this isn't viable. Imho the only thing that can be done for most devices is adding a http landing page that explains how to do the first pairing in the most secure way, like I said above. "make sure the device is connected through an ethernet cable to a trusted PC only, and that there are no other ethernet cables connected to this device, when you are ready to accept the self-signed certificate press OK button" And when you press OK it will redirect to https and you will get the warning and must accept it. Does it make sense to add this kind of "first setup" webpage to the device's web interface? Maybe. I have already mentioned some time ago in the older version of this discussion that 99% of the users that are doing this for the first time are going to be following some documentation anyway, so we could just write this down in the install tutorial in the wiki. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
I added a kernel flag to differentiate between both driver versions. https://github.com/openwrt/openwrt/pull/3596 I would backport this to 19.07 if it gets accepted. On 11/20/20 3:30 PM, Baptiste Jonglez wrote: Hi, On 20-11-20, Adrian Schmutzler wrote: -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Baptiste Jonglez Sent: Freitag, 20. November 2020 11:21 To: openwrt-devel@lists.openwrt.org; John Crispin Cc: Baptiste Jonglez Subject: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging" From: Baptiste Jonglez This change has been causing several issues on ipq40xx devices, including: this seems to lack a Signed-off-by? You're totally right, thanks for spotting this. I've just sent a v2. Baptiste ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 18:35, Adrian Schmutzler wrote: Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Alberto Bursi Sent: Freitag, 20. November 2020 17:32 To: openwrt-devel@lists.openwrt.org Subject: Re: 20.xx: postponse LuCI HTTPS per default On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. I'm not sure you can actually not "maintaining two defaults" regardless of what is decided. From what I understand, https support is an addon to the base http web interface infrastructure and not a fully different thing. So I think that if you switch to https by default you still need to maintain the "non-https" part of the web interface infrastructure anyway. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. Yeah I wouldn't treat it as a blocker, it's getting late for a release already and nobody in the main developer list seems to care about setting a default either way. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: 20.xx: postponse LuCI HTTPS per default
On Fri Nov 20, 2020 at 7:35 AM HST, Adrian Schmutzler wrote: > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Alberto Bursi > > Sent: Freitag, 20. November 2020 17:32 > > To: openwrt-devel@lists.openwrt.org > > Subject: Re: 20.xx: postponse LuCI HTTPS per default > > > > > > > > On 20/11/20 17:17, Fernando Frediani wrote: > > > Hi Alberto > > > > > > On 20/11/2020 13:09, Alberto Bursi wrote: > > >> > > >> > > >> > > >> The only thing I can accept as a valid complaint against https by > > >> default is the increased minimum space requirements, everything else > > >> I really don't understand nor agree with. > > > > > > It's exactly this I am referring to when I talk about the extras not > > > the steps the user will take to enable it. So why I mentioned to leave > > > it as optional and easy to do for those who wish (and have space) to have > > it. > > > > > > > Devices with low flash space (and RAM) are already receiving special > > treatment (different compile options, different default packages) to lower > > space footprint. > > > > These devices can (should?) be left out of the "https by default" easily. > > No, this is not an option. We certainly won't have (read "maintain") > _two_ defaults for a matter like this. > > Apart from that, this discussion was not intended to discuss the various > options _again_, but to ask whether we should have "https by default" as > a _blocker_ for the next release. > Personally, since the discussion seems to be as open and unresolved as a > few months ago, I'm against making this a blocker. I'm curious where the > whole topic evolves to, but that's not the subject of this thread. How about we use `luci-ssl` per default but set `redirect_https` to 0. This way everyone can access in a secure way, without changing the current user experience. An optional combination of Luiz idea could warn the users using HTTP, allowing to "ignore" or "activate redirect". I think that's a feasible solution for 20.xx. Spinning up a massive HTTPS dDNS or defining a new standard accepted in all common browsers seems a bit out of scope, for now. Paul > > Best > > Adrian > > > > > But I would be strongly against degrading security for everyone just because > > of these devices. > > > > -Alberto > > > > > Regards > > > Fernando > > > > > >> > > >> > > >>> Yes it is nice to have everything ready and automated to be done > > >>> with a few clicks for those cases that require it. In fact I think > > >>> this would be a better solution for now so it will be possible to > > >>> gather gradually this transition (or not) from HTTP to HTTPS even > > >>> for local/lan applications and see how often people would opt to use it. > > >>> > > >>> Still should it end up having HTTPS by default I see self-signed > > >>> certificates are the way to go. Yes there are the warnings and I > > >>> really don't think there is any issue with it. > > >>> Those accessing the router Web Interface are not 'normal' Internet > > >>> users and they know what they are doing so the warning from > > >>> self-signed certificates should not be a surprise for them. > > >>> And those cases when admins prefer they can always replace the > > >>> self-signed one for Let's Encrypt for example. > > >>> > > >>> Regards > > >>> Fernando > > >> > > >> > > >> -Alberto > > >> > > >> ___ > > >> openwrt-devel mailing list > > >> openwrt-devel@lists.openwrt.org > > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] treewide: replace my o2.pl email address
I'm still available at the old address. Signed-off-by: Tomasz Maciej Nowak --- package/boot/uboot-tegra/Makefile | 4 ++-- target/linux/tegra/Makefile | 2 +- target/linux/tegra/image/Makefile | 2 +- tools/cbootimage-configs/Makefile | 2 +- tools/cbootimage/Makefile | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/package/boot/uboot-tegra/Makefile b/package/boot/uboot-tegra/Makefile index 4b9f7876f80e..778019257da0 100644 --- a/package/boot/uboot-tegra/Makefile +++ b/package/boot/uboot-tegra/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2017-2019 Tomasz Maciej Nowak +# Copyright (C) 2017-2019 Tomasz Maciej Nowak # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -11,7 +11,7 @@ PKG_RELEASE := 1 PKG_HASH := 76b7772d156b3ddd7644c8a1736081e55b78828537ff714065d21dbade229bef -PKG_MAINTAINER := Tomasz Maciej Nowak +PKG_MAINTAINER := Tomasz Maciej Nowak include $(INCLUDE_DIR)/u-boot.mk include $(INCLUDE_DIR)/package.mk diff --git a/target/linux/tegra/Makefile b/target/linux/tegra/Makefile index 5dd4d439849e..cf929fb0f104 100644 --- a/target/linux/tegra/Makefile +++ b/target/linux/tegra/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2017-2019 Tomasz Maciej Nowak +# Copyright (C) 2017-2019 Tomasz Maciej Nowak # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. diff --git a/target/linux/tegra/image/Makefile b/target/linux/tegra/image/Makefile index 33e7b508d966..aa0083f9ae47 100644 --- a/target/linux/tegra/image/Makefile +++ b/target/linux/tegra/image/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2017-2019 Tomasz Maciej Nowak +# Copyright (C) 2017-2019 Tomasz Maciej Nowak # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. diff --git a/tools/cbootimage-configs/Makefile b/tools/cbootimage-configs/Makefile index 5a1fc568cb4c..cafd4e5a20dd 100644 --- a/tools/cbootimage-configs/Makefile +++ b/tools/cbootimage-configs/Makefile @@ -1,5 +1,5 @@ # -# Copyright (c) 2017-2019 Tomasz Maciej Nowak +# Copyright (c) 2017-2019 Tomasz Maciej Nowak # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. diff --git a/tools/cbootimage/Makefile b/tools/cbootimage/Makefile index 42640eab363b..71fdb5768c29 100644 --- a/tools/cbootimage/Makefile +++ b/tools/cbootimage/Makefile @@ -1,5 +1,5 @@ # -# Copyright (c) 2017-2019 Tomasz Maciej Nowak +# Copyright (c) 2017-2019 Tomasz Maciej Nowak # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. >>> maybe, but it's still better than sending all communication to the >>> management interface as plain text. >> What is the difference between transmitting packets containing cleartext >> and transmitting encrypted packets to a party whose identity you do >> not know? > What are you talking about? After the initial "pairing" process where you > see the warning, the browser remembers the certificate for all subsequent > connections. > If the certificate changes (and it will change only if you do a firmware > reset to default settings) you will see the the warning again. > > So you are just changing a CA-based system to a local pairing system. (I really do not mean for any of my comments here or earlier to be patronizing. I am just trying to describe my point of view.) When I make the first SSH connection to a new router, I confirm the fingerprint of the router's key using a serial-port connection. Thus I know it is safe to accept the pairing. If I were to skip this step, then I would have no assurance regarding to whom my encrypted messages were being sent now and in the future. How would our scheme recreate this? What would the interface provide to the user to help them perform this step? What would it recommend? Some tugging on Luiz Angelo Daros de Luca's proposal earlier in this thread (Fri, 20 Nov 2020 14:25:10), especially the addition of a suggested verification process, might help. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: state of the DSA
On 2020-11-20 09:29, Georgi Valkov wrote: On Thu, Nov 19, 2020 at 8:37 PM Rosen Penev wrote: On Thu, Nov 19, 2020 at 4:40 PM Paul Spooren wrote: Hi all, DSA (Distributed Switch Architecture)[0] is a main feature of 20.xx and one of the last blockers for a branch. The goal states[1] support where possible, not necessarily every target. This mail thread should be used to get an overview of the missing bits. The following targets seem use `swconfig`, should/can they be ported? Please post states and links to work in progress migrations: * apm821xx/nand * ath25 * ath79 * bcm47xx * bcm53xx * bcm63xx * ipq40xx * ipq806x * kirkwood * lantiq/xrx200 * lantiq/xway * lantiq/xway_legacy * mediatek I believe mediatek exclusively uses DSA. I looked into this more: ~/d/o/t/linux (master)> git grep CONFIG_SWCONFIG=y apm821xx/nand/config-default:CONFIG_SWCONFIG=y ath25/config-5.4:CONFIG_SWCONFIG=y ath79/config-5.4:CONFIG_SWCONFIG=y bcm47xx/config-5.4:CONFIG_SWCONFIG=y bcm53xx/config-5.4:CONFIG_SWCONFIG=y bcm63xx/config-5.4:CONFIG_SWCONFIG=y ipq40xx/config-5.4:CONFIG_SWCONFIG=y ipq806x/config-5.4:CONFIG_SWCONFIG=y ipq807x/config-default:CONFIG_SWCONFIG=y lantiq/config-5.4:CONFIG_SWCONFIG=y mediatek/mt7622/config-5.4:CONFIG_SWCONFIG=y mediatek/mt7623/config-5.4:CONFIG_SWCONFIG=y mediatek/mt7629/config-5.4:CONFIG_SWCONFIG=y mpc85xx/config-5.4:CONFIG_SWCONFIG=y ramips/mt7620/config-5.4:CONFIG_SWCONFIG=y ramips/mt76x8/config-5.4:CONFIG_SWCONFIG=y ramips/rt288x/config-5.4:CONFIG_SWCONFIG=y ramips/rt305x/config-5.4:CONFIG_SWCONFIG=y ramips/rt3883/config-5.4:CONFIG_SWCONFIG=y rtl838x/config-5.4:CONFIG_SWCONFIG=y sunxi/config-5.4:CONFIG_SWCONFIG=y mt7628 seems to have DSA support upstream. kirkwood is not there. ath79/tiny/config-default:CONFIG_NET_DSA=y gemini/config-5.4:CONFIG_NET_DSA=y imx6/config-5.4:CONFIG_NET_DSA=y ipq806x/config-5.4:CONFIG_NET_DSA=y kirkwood/config-5.4:CONFIG_NET_DSA=y mediatek/mt7622/config-5.4:CONFIG_NET_DSA=y mediatek/mt7623/config-5.4:CONFIG_NET_DSA=y mvebu/config-5.4:CONFIG_NET_DSA=y octeon/config-5.4:CONFIG_NET_DSA=y ramips/mt7621/config-5.4:CONFIG_NET_DSA=y rtl838x/config-5.4:CONFIG_NET_DSA=y is the DSA stuff. Some of the swconfig targets can be ported. For example I remember using a DSA patch for a Netgear R7800. * mpc85xx * ramips/mt7620 * ramips/mt76x8 * ramips/rt288x * ramips/rt305x * ramips/rt3883 All other targets can be considered as DSA targets? If you're working or testing around that, please comment and share the status. LuCI support is added via a PR[2] on GitHub. Best, Paul [0]: https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html [1]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx [2]: https://github.com/openwrt/luci/pull/4307 I hope to see Port Mirroring and Switch configuration in LuCI fully functional again when 20.x.x is released! We should be able to configure each PHY and port, since WRT3200ACM and others have multiple Ethernet interfaces. And it is more efficient to use all of them. I’d rather have one mapped as wan and the other as lan in ifconfig, like I currently have using swconfig. With an option on the Switch configuration page, to split lan into lan1 lan2 lan3 lan4, since multiple networks are less common. It would be nice if LuCI can add, remove and rename interfaces as seen in ifconfig. And also choose which PHY they map to. Georgi Valkov Please don't use an older mail to reply to and then paste in the contents of another mail thread or similar. This will screw up the threading. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 17:47, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. maybe, but it's still better than sending all communication to the management interface as plain text. What is the difference between transmitting packets containing cleartext and transmitting encrypted packets to a party whose identity you do not know? What are you talking about? After the initial "pairing" process where you see the warning, the browser remembers the certificate for all subsequent connections. If the certificate changes (and it will change only if you do a firmware reset to default settings) you will see the the warning again. So you are just changing a CA-based system to a local pairing system. What I am arguing is that just falling back on self-signed certificates in order to turn on HTTPS is not a good solution and is in fact counter-productive. I disgree with your argument, self-signed certificates are NOT less secure than http. Pairing is fine and secure even if you don't have the certificate mafia to "assure" that something is trusted. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: 20.xx: postponse LuCI HTTPS per default
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Alberto Bursi > Sent: Freitag, 20. November 2020 17:32 > To: openwrt-devel@lists.openwrt.org > Subject: Re: 20.xx: postponse LuCI HTTPS per default > > > > On 20/11/20 17:17, Fernando Frediani wrote: > > Hi Alberto > > > > On 20/11/2020 13:09, Alberto Bursi wrote: > >> > >> > >> > >> The only thing I can accept as a valid complaint against https by > >> default is the increased minimum space requirements, everything else > >> I really don't understand nor agree with. > > > > It's exactly this I am referring to when I talk about the extras not > > the steps the user will take to enable it. So why I mentioned to leave > > it as optional and easy to do for those who wish (and have space) to have > it. > > > > Devices with low flash space (and RAM) are already receiving special > treatment (different compile options, different default packages) to lower > space footprint. > > These devices can (should?) be left out of the "https by default" easily. No, this is not an option. We certainly won't have (read "maintain") _two_ defaults for a matter like this. Apart from that, this discussion was not intended to discuss the various options _again_, but to ask whether we should have "https by default" as a _blocker_ for the next release. Personally, since the discussion seems to be as open and unresolved as a few months ago, I'm against making this a blocker. I'm curious where the whole topic evolves to, but that's not the subject of this thread. Best Adrian > > But I would be strongly against degrading security for everyone just because > of these devices. > > -Alberto > > > Regards > > Fernando > > > >> > >> > >>> Yes it is nice to have everything ready and automated to be done > >>> with a few clicks for those cases that require it. In fact I think > >>> this would be a better solution for now so it will be possible to > >>> gather gradually this transition (or not) from HTTP to HTTPS even > >>> for local/lan applications and see how often people would opt to use it. > >>> > >>> Still should it end up having HTTPS by default I see self-signed > >>> certificates are the way to go. Yes there are the warnings and I > >>> really don't think there is any issue with it. > >>> Those accessing the router Web Interface are not 'normal' Internet > >>> users and they know what they are doing so the warning from > >>> self-signed certificates should not be a surprise for them. > >>> And those cases when admins prefer they can always replace the > >>> self-signed one for Let's Encrypt for example. > >>> > >>> Regards > >>> Fernando > >> > >> > >> -Alberto > >> > >> ___ > >> openwrt-devel mailing list > >> openwrt-devel@lists.openwrt.org > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Hi, I guess we could simply ask the user by default (with options to auto generate a certificate or ignore https). Luci already warns that a root password must be set. Why not also add something like: "Upgrade to a secure connection?". "No password Set! There is no ... ... " "You are using an unencrypted connection! Before informing sensitive information, like a password, it is recommended to enable encryption (https) ... # it will require authentication if a password is already set " If the user opts to use it, it could generate a self-signed certificate and offer it to be downloaded/imported even before using it. http://192.168.1.1/luci/https-settings#generate-self-signed... HTTP Settings: #if "the certificate is not trusted by the browser. Can we test it using ajax?" Click here to download and import the router certificate now. Otherwise, your browser will warn you that the router certificate is not trusted. Then, you can ignore the error and continue. However, it would be safer to add the router to browser certificate exceptions. You might need to do it again every time the certificate is regenerated. If the certificate warning page reappears again for the same router at the same browser, it might not be automatically trusted as it could be a malicious device impersonating your router trying to steal your credentials. #endif [Generate a new self-signed certificate] [Generate a new certificate request] / [Import the signed certificate] # if a CSR was generated [Generate a new Let's Encrypt certificate] # it would be a nice add-on [Remove current certificate and disable encryption] The next luci request will redirect the browser to https:// My 2 cents, --- Luiz Angelo Daros de Luca luizl...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 17:39, Fernando Frediani wrote: Hi. I don't really see having HTTPS by default as something that make such a difference for most common users nor as a major security issue in the context it is used at the cost it puts, which may seems not too much but I always think of the very minimal for a default image and HTTPS isn't something really necessary for I would say most scenarios. Yes you have already said that you don't think people at home need HTTPS, but I still think it makes sense to have it in all devices that aren't limited by low flash space, for the reasons I already mentioned. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
>> I think making use of self-signed certificates in production is a bad >> idea because (1) it reinforces poor practices, namely electing to trust >> a self-signed certificate and (2) it does not authenticate the >> server/router, a critical piece of the TLS security model. > maybe, but it's still better than sending all communication to the > management interface as plain text. >> My point of view is that we should delay HTTPS-by-default until we have >> a scheme for establishing the identity of the router. Until then, we >> should be honest and make use of HTTP. What is the difference between transmitting packets containing cleartext and transmitting encrypted packets to a party whose identity you do not know? > nobody is working on that, and in most cases it's not really possible. You > always have a point where the user has to make the call of trusting the > device's ID or code or something. Yes. This is true, and trusting CAs is a specialization of this. I understand that we do not have a scheme yet, and the necessary out-of-band channels in a router are limited. What I am arguing is that just falling back on self-signed certificates in order to turn on HTTPS is not a good solution and is in fact counter-productive. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Hi. I don't really see having HTTPS by default as something that make such a difference for most common users nor as a major security issue in the context it is used at the cost it puts, which may seems not too much but I always think of the very minimal for a default image and HTTPS isn't something really necessary for I would say most scenarios. Again I am not against using HTTPS but rather leaving it as optional for those who really want to enable. So not really concerned about the low flash devices, but because this will be yet another thing to increase the size of the default image. On 20/11/2020 13:32, Alberto Bursi wrote: On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. But I would be strongly against degrading security for everyone just because of these devices. -Alberto Regards Fernando Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 17:17, Fernando Frediani wrote: Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Devices with low flash space (and RAM) are already receiving special treatment (different compile options, different default packages) to lower space footprint. These devices can (should?) be left out of the "https by default" easily. But I would be strongly against degrading security for everyone just because of these devices. -Alberto Regards Fernando Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Hi Alberto On 20/11/2020 13:09, Alberto Bursi wrote: The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. It's exactly this I am referring to when I talk about the extras not the steps the user will take to enable it. So why I mentioned to leave it as optional and easy to do for those who wish (and have space) to have it. Regards Fernando Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 16:52, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. maybe, but it's still better than sending all communication to the management interface as plain text. My point of view is that we should delay HTTPS-by-default until we have a scheme for establishing the identity of the router. Until then, we should be honest and make use of HTTP. nobody is working on that, and in most cases it's not really possible. You always have a point where the user has to make the call of trusting the device's ID or code or something. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 16:31, Fernando Frediani wrote: Yes, exactly it is only an issue when someone have to access the web interface via wifi. In a home environment that is a small issue. Not sure how it is a small issue when wifi is the main method used to connect to a router and the Internet in a home environment. In a more corporate environment there are two options: 1) access is done via wired network or 2) enable HTTPS, which make more sense. which means that now everyone that wants a secure system has to go for additional setup steps, or compile/assemble their own firmware images. And this for what, because of a one-time popup in the browser? Enabling HTTPS by default is still not worth in my view given the extras that come with it and I like the idea of keep the default as simple and possible. It is literally one additional click on a button in the browser, and you will never see that warning again in that browser after that. This is nothing if compared to the learning curve to actually install and configure OpenWrt additional functionality on a new device. The only thing I can accept as a valid complaint against https by default is the increased minimum space requirements, everything else I really don't understand nor agree with. Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
The only reason I see to have HTTPS and certificates in OpenWrt in my view is to give some layer of security for those accessing the router via Wifi or over the Internet for example. And only admins, who have setup the router or work directly with it will access it (not normal users) so they know well what they are doing to not find a problem to have a self-signed certificate, or if it's the case they may deploy (optionally and later on) a Let's Encrypt certificatate which will be in even fewer cases. Fernando On 20/11/2020 12:52, W. Michael Petullo wrote: I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. My point of view is that we should delay HTTPS-by-default until we have a scheme for establishing the identity of the router. Until then, we should be honest and make use of HTTP. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
I think making use of self-signed certificates in production is a bad idea because (1) it reinforces poor practices, namely electing to trust a self-signed certificate and (2) it does not authenticate the server/router, a critical piece of the TLS security model. My point of view is that we should delay HTTPS-by-default until we have a scheme for establishing the identity of the router. Until then, we should be honest and make use of HTTP. -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: 20.xx: state of the DSA
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Spooren > Sent: Freitag, 20. November 2020 01:36 > To: openwrt-devel@lists.openwrt.org > Subject: 20.xx: state of the DSA > > Hi all, > > DSA (Distributed Switch Architecture)[0] is a main feature of 20.xx and one of > the last blockers for a branch. The goal states[1] support where possible, not > necessarily every target. since we discuss this in the context of the next stable release, I don't think the focus should be on which targets are supported and which are not. 20.xx/21.xx will be a mixed release in that context. Our main interest should be to clarify what needs to be done in order to release DSA with proper support (on the platforms that already have it), and then get these things done quickly. Best Adrian > > This mail thread should be used to get an overview of the missing bits. > > The following targets seem use `swconfig`, should/can they be ported? > Please post states and links to work in progress migrations: > > * apm821xx/nand > * ath25 > * ath79 > * bcm47xx > * bcm53xx > * bcm63xx > * ipq40xx > * ipq806x > * kirkwood > * lantiq/xrx200 > * lantiq/xway > * lantiq/xway_legacy > * mediatek > * mpc85xx > * ramips/mt7620 > * ramips/mt76x8 > * ramips/rt288x > * ramips/rt305x > * ramips/rt3883 > > All other targets can be considered as DSA targets? If you're working or > testing around that, please comment and share the status. > > LuCI support is added via a PR[2] on GitHub. > > Best, > Paul > > [0]: https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html > [1]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx > [2]: https://github.com/openwrt/luci/pull/4307 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Yes, exactly it is only an issue when someone have to access the web interface via wifi. In a home environment that is a small issue. In a more corporate environment there are two options: 1) access is done via wired network or 2) enable HTTPS, which make more sense. Enabling HTTPS by default is still not worth in my view given the extras that come with it and I like the idea of keep the default as simple and possible. Yes it is nice to have everything ready and automated to be done with a few clicks for those cases that require it. In fact I think this would be a better solution for now so it will be possible to gather gradually this transition (or not) from HTTP to HTTPS even for local/lan applications and see how often people would opt to use it. Still should it end up having HTTPS by default I see self-signed certificates are the way to go. Yes there are the warnings and I really don't think there is any issue with it. Those accessing the router Web Interface are not 'normal' Internet users and they know what they are doing so the warning from self-signed certificates should not be a surprise for them. And those cases when admins prefer they can always replace the self-signed one for Let's Encrypt for example. Regards Fernando On 20/11/2020 11:46, Alberto Bursi wrote: On 20/11/20 14:22, Fernando Frediani wrote: I don't see having HTTPS by default in LuCI as something good or even necessary ? It's actually an unnecessary complication that could always be optional. One of the main reasons is that in many and probably most cases of a new deployed OpenWrt router there is still no Internet connection available. Also it doesn't seem to be that people need it since access by default is only done via the LAN interfaces. Not using SSL means anyone in the LAN can snoop the password to access the router. While this is a non-issue for most home wired networks, it is for wifi and most people will use wifi on their router. WPA2 is not going anywhere for a long while still and it is susceptible to deauth attacks. After the attacker has captured enough handshakes after the deauth they will know the wifi password. It just takes a while but there are plenty of automated tools to do that 24/7 like Pawnagotchi (a raspberry zero running a dedicated application) or wifi pineapples or whatever. Using SSL for web interface means the system is at least compartimentalized so in case someone breaks into the wifi/LAN they won't also take over the router as well. If someone for some reason wishes for example to expose the LuCI web interface to the internet than fine to have it running on HTTPS and that can be enabled by those who wish to operate in such way. As this example there are certainly others that justify to have a HTTPS but I don't they they are most. The same way I see as interesting to have an automated way to generate SSL Certificates (ex: via Let's Encrypt), but again, that should be optional to only those who wish to use HTTPS for their specific needs. Fernando On 20/11/2020 06:44, Karl Palsson wrote: "Paul Spooren" wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: state of the DSA
On 20/11/20 01:36, Paul Spooren wrote: Hi all, DSA (Distributed Switch Architecture)[0] is a main feature of 20.xx and one of the last blockers for a branch. The goal states[1] support where possible, not necessarily every target. This mail thread should be used to get an overview of the missing bits. The following targets seem use `swconfig`, should/can they be ported? Please post states and links to work in progress migrations: * apm821xx/nand * ath25 * ath79 * bcm47xx * bcm53xx * bcm63xx * ipq40xx * ipq806x * kirkwood wait, why kirkwood? I have one of the two kirkwood devices with a switch, running snapshot and it's definitely been using DSA for a while Checking the kernel config CONFIG_HAVE_NET_DSA=y and there is no CONFIG_SWCONFIG Yes it is using DSA. The commit to move kirkwood to DSA is 4fd7e539e4f90128bdd7cb71c729a4b32f5de86e from April 28 * lantiq/xrx200 * lantiq/xway * lantiq/xway_legacy * mediatek * mpc85xx * ramips/mt7620 * ramips/mt76x8 * ramips/rt288x * ramips/rt305x * ramips/rt3883 All other targets can be considered as DSA targets? If you're working or testing around that, please comment and share the status. LuCI support is added via a PR[2] on GitHub. Best, Paul [0]: https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html [1]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx [2]: https://github.com/openwrt/luci/pull/4307 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
On 20/11/20 14:22, Fernando Frediani wrote: I don't see having HTTPS by default in LuCI as something good or even necessary ? It's actually an unnecessary complication that could always be optional. One of the main reasons is that in many and probably most cases of a new deployed OpenWrt router there is still no Internet connection available. Also it doesn't seem to be that people need it since access by default is only done via the LAN interfaces. Not using SSL means anyone in the LAN can snoop the password to access the router. While this is a non-issue for most home wired networks, it is for wifi and most people will use wifi on their router. WPA2 is not going anywhere for a long while still and it is susceptible to deauth attacks. After the attacker has captured enough handshakes after the deauth they will know the wifi password. It just takes a while but there are plenty of automated tools to do that 24/7 like Pawnagotchi (a raspberry zero running a dedicated application) or wifi pineapples or whatever. Using SSL for web interface means the system is at least compartimentalized so in case someone breaks into the wifi/LAN they won't also take over the router as well. If someone for some reason wishes for example to expose the LuCI web interface to the internet than fine to have it running on HTTPS and that can be enabled by those who wish to operate in such way. As this example there are certainly others that justify to have a HTTPS but I don't they they are most. The same way I see as interesting to have an automated way to generate SSL Certificates (ex: via Let's Encrypt), but again, that should be optional to only those who wish to use HTTPS for their specific needs. Fernando On 20/11/2020 06:44, Karl Palsson wrote: "Paul Spooren" wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: state of the DSA
Hi, It is not necessary to enable swconfig for this target. I initially enabled it because luci was checking for the swconfig binary in order to show switch information at all. This is no longer necessary. Birger On 20.11.20 06:12, Rosen Penev wrote: > On Thu, Nov 19, 2020 at 8:37 PM Rosen Penev wrote: > rtl838x/config-5.4:CONFIG_SWCONFIG=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
Hi, On 20-11-20, Adrian Schmutzler wrote: > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Baptiste Jonglez > > Sent: Freitag, 20. November 2020 11:21 > > To: openwrt-devel@lists.openwrt.org; John Crispin > > Cc: Baptiste Jonglez > > Subject: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double > > tagging" > > > > From: Baptiste Jonglez > > > > This change has been causing several issues on ipq40xx devices, including: > > this seems to lack a Signed-off-by? You're totally right, thanks for spotting this. I've just sent a v2. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07 v2] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
From: Baptiste Jonglez
This change has been causing several issues on ipq40xx devices, including:
- VLAN tagging no longer works correctly:
https://bugs.openwrt.org/index.php?do=details_id=3239
- poor performance with tagged VLANs:
https://bugs.openwrt.org/index.php?do=details_id=3457
See also
https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-longer-works/69569
There are have been discussions on ways to fix the issue in the links
above (including switching to DSA), but nothing that can realistically
be introduced in the 19.07 branch.
This reverts commit 8c191712558c ("ipq40xx: fix ethernet vlan double
tagging")
Note that it's not a clean revert because this patch was touched in
148d59c67edd ("kernel: update kernel 4.14 to version 4.14.193") even
though the semantic of the patch was left unchanged.
Fixes: FS#3239
Fixes: FS#3457
Fixes: 8c191712558c ("ipq40xx: fix ethernet vlan double tagging")
Signed-off-by: Baptiste Jonglez
---
.../716-essedma-vlan-double-tag.patch | 128 --
1 file changed, 128 deletions(-)
delete mode 100644
target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
diff --git
a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
deleted file mode 100644
index e268351273..00
--- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From: Sven Eckelmann
-Date: Wed, 8 Feb 2017 16:26:00 +0100
-Subject: [PATCH] ipq40xx: Fix ar40xx port separation
-
-It is currently not possible to submit (or receive) VLAN tagged frames over
-the ar40xx PHY switch and the edma ethernet device.
-
-This can be worked around by disabling enable_vlan. The separation of the
-eth0 and eth1 ports is then done by the vlan_tag information from the
-device tree. But the ar40xx PHY switch then also has to parse the word3
-port bitmap (word3) from the TDP when data was received from the CPU port
-(0).
-
-IssueID: #2857
-
-Forwarded: no
- The ar40xx.c change was forwarded to Xiaofei Shen
- (QCA). But John Crispin will rewrite the driver anyway and we have to check
- later if this change is required in his driver too.
- drivers/net/phy/ar40xx.c | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
a/drivers/net/phy/ar40xx.c
-+++ b/drivers/net/phy/ar40xx.c
-@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
- ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
- AR40XX_PORT_AUTO_LINK_EN, 0);
-
-- ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-+ /* CPU port is setting headers to limit output ports */
-+ if (port == 0)
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
-+ else
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
-
-@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
- t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
- AR40XX_PORT0_FC_THRESH_OFF_DFLT;
- ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
-+
-+ /* set service tag to 802.1q */
-+ t = ETH_P_8021Q | AR40XX_ESS_SERVICE_TAG_STAG;
-+ ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
- }
-
- static void
-@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- u32 pvid = priv->vlan_id[priv->pvid[port]];
-
- if (priv->vlan) {
-- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+ if (priv->vlan_tagged & BIT(port))
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
-+ else
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+
- ingress = AR40XX_IN_SECURE;
- } else {
- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNTOUCH;
-@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
-
-- t = AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-- t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+ t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+
-+ /* set CPU port to core port */
-+ if (port == 0)
-+ t |= AR40XX_PORT_VLAN1_CORE_PORT;
-+
-+ if (priv->vlan_tagged & BIT(port))
-+ t |= AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-+ else
-+ t |= AR40XX_PORT_VLAN1_PORT_TLS_MODE;
-+
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN1(port), t);
-
- t = members;
a/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-+++ b/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-@@ -970,7 +970,6 @@ static int edma_axi_probe(struct platfor
- edma_netdev[i]->netdev_ops = _axi_netdev_ops;
- edma_netdev[i]->max_mtu = 9000;
- edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM
--|
RE: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Baptiste Jonglez
> Sent: Freitag, 20. November 2020 11:21
> To: openwrt-devel@lists.openwrt.org; John Crispin
> Cc: Baptiste Jonglez
> Subject: [PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double
> tagging"
>
> From: Baptiste Jonglez
>
> This change has been causing several issues on ipq40xx devices, including:
this seems to lack a Signed-off-by?
Best
Adrian
>
> - VLAN tagging no longer works correctly:
> https://bugs.openwrt.org/index.php?do=details_id=3239
> - poor performance with tagged VLANs:
> https://bugs.openwrt.org/index.php?do=details_id=3457
>
> See also https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-
> longer-works/69569
>
> There are have been discussions on ways to fix the issue in the links above
> (including switching to DSA), but nothing that can realistically be
> introduced in
> the 19.07 branch.
>
> This reverts commit 8c191712558ce94 ("ipq40xx: fix ethernet vlan double
> tagging")
>
> Note that it's not a clean revert because this patch was touched in
> 148d59c67edd5 ("kernel: update kernel 4.14 to version 4.14.193") even
> though the semantic of the patch was left unchanged.
>
> Fixes: FS#3239
> Fixes: FS#3457
> ---
> .../716-essedma-vlan-double-tag.patch | 128 --
> 1 file changed, 128 deletions(-)
> delete mode 100644 target/linux/ipq40xx/patches-4.14/716-essedma-vlan-
> double-tag.patch
>
> diff --git a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-
> tag.patch b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-
> tag.patch
> deleted file mode 100644
> index e268351273..00
> --- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
> +++ /dev/null
> @@ -1,128 +0,0 @@
> -From: Sven Eckelmann
> -Date: Wed, 8 Feb 2017 16:26:00 +0100
> -Subject: [PATCH] ipq40xx: Fix ar40xx port separation
> -
> -It is currently not possible to submit (or receive) VLAN tagged frames over -
> the ar40xx PHY switch and the edma ethernet device.
> -
> -This can be worked around by disabling enable_vlan. The separation of the
> -eth0 and eth1 ports is then done by the vlan_tag information from the -
> device tree. But the ar40xx PHY switch then also has to parse the word3 -port
> bitmap (word3) from the TDP when data was received from the CPU port -
> (0).
> -
> -IssueID: #2857
> -
> -Forwarded: no
> - The ar40xx.c change was forwarded to Xiaofei Shen
>
> - (QCA). But John Crispin will rewrite the driver anyway and we have to check
> - later if this change is required in his driver too.
>
> - drivers/net/phy/ar40xx.c | 6 +-
> - 1 file changed, 5 insertions(+), 1 deletion(-)
> -
> a/drivers/net/phy/ar40xx.c
> -+++ b/drivers/net/phy/ar40xx.c
> -@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
> - ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
> - AR40XX_PORT_AUTO_LINK_EN, 0);
> -
> --ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
> -+/* CPU port is setting headers to limit output ports */
> -+if (port == 0)
> -+ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
> -+else
> -+ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
> -
> - ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
> -
> -@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
> - t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
> - AR40XX_PORT0_FC_THRESH_OFF_DFLT;
> - ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
> -+
> -+/* set service tag to 802.1q */
> -+t = ETH_P_8021Q | AR40XX_ESS_SERVICE_TAG_STAG;
> -+ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
> - }
> -
> - static void
> -@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
> - u32 pvid = priv->vlan_id[priv->pvid[port]];
> -
> - if (priv->vlan) {
> --egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
> -+if (priv->vlan_tagged & BIT(port))
> -+egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
> -+else
> -+egress =
> AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
> -+
> - ingress = AR40XX_IN_SECURE;
> - } else {
> - egress = AR40XX_PORT_VLAN1_OUT_MODE_UNTOUCH;
> -@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
> - t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
> - ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
> -
> --t = AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
> --t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
> -+t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
> -+
> -+/* set CPU port to core port */
> -+if (port == 0)
> -+t |= AR40XX_PORT_VLAN1_CORE_PORT;
> -+
> -+if (priv->vlan_tagged & BIT(port))
> -+t |= AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
> -+else
> -+t |= AR40XX_PORT_VLAN1_PORT_TLS_MODE;
> -+
> - ar40xx_write(priv,
Re: 20.xx: postponse LuCI HTTPS per default
I don't see having HTTPS by default in LuCI as something good or even necessary ? It's actually an unnecessary complication that could always be optional. One of the main reasons is that in many and probably most cases of a new deployed OpenWrt router there is still no Internet connection available. Also it doesn't seem to be that people need it since access by default is only done via the LAN interfaces. If someone for some reason wishes for example to expose the LuCI web interface to the internet than fine to have it running on HTTPS and that can be enabled by those who wish to operate in such way. As this example there are certainly others that justify to have a HTTPS but I don't they they are most. The same way I see as interesting to have an automated way to generate SSL Certificates (ex: via Let's Encrypt), but again, that should be optional to only those who wish to use HTTPS for their specific needs. Fernando On 20/11/2020 06:44, Karl Palsson wrote: "Paul Spooren" wrote: Hi, The current list of release goals for 20.xx states[0] that LuCI should use HTTPS per default. This works by creating on-device a self-signed certificate. Self-signed certificates result in warnings and may cause more harm than good, multiple discussion are found in the mail archive. As no clean solution seems in reach while 20.xx seems close, I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Paul Spooren [2020-11-19 13:09:02]: Hi, > while 20.xx seems close, I don't share your view on this one, 21.xx is close, yes :-) Just being realistic here. So I would say, that if this issue should be tackled, there is still some time left to do so. > I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per > default. Do we need to make this hard decission? Can't we leave it to the end users? We need most of the SSL stuff for other parts, so why not benefit from that in other parts? For the start, can't we simply introduce some first time welcome page on HTTP, explain to the user, that HTTPS is available, the pros and cons of this solution and let the user decide? In less intrusive way, this welcome page/wizard could be replaced with some information box "HTTPS is just a moments away", so the user would need to explicitly request that HTTPS feature. There might be some better UX approach, but please try hard to move forward, not backward :-) -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg 0/5] Purge packages from cache when they have incorrect checksum
Hi, Any news on this patch series? It should definitely be considered before the 20.XX branching because it fixes FS#2690 (bug related to imagebuilder), and I would like to backport it to 19.07 at some point. Thanks, Baptiste On 25-08-20, Baptiste Jonglez wrote: > From: Baptiste Jonglez > > The motivation of this patch series is to fix FS#2690. Because packages > are continuously rebuilt, the ImageBuilder ends up with old packages in > its cache, and fails because checksums don't match with the new package > index from the download server. > > The approach to solve this problem is the following. Before using a package > from the cache, verify its size and checksum against the package index, and > delete the package from the cache if they don't match. The install process > will then proceed to download the "fixed" package as usual. > > The main patch is "download: purge cached packages that have incorrect > checksum". The other ones are either cleanup or refactoring to prepare > for the main change. > > Baptiste Jonglez (5): > download: remove compatibility with old cache naming scheme > libopkg: factor out checksum and size verification > download: factor out the logic for building cache filenames > download: purge cached packages that have incorrect checksum > opkg_verify_integrity: better logging and error conditions > > libopkg/opkg_download.c | 123 > libopkg/opkg_download.h | 1 + > libopkg/opkg_install.c | 76 +++-- > 3 files changed, 108 insertions(+), 92 deletions(-) > > -- > 2.27.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07] ipq40xx: Revert "ipq40xx: fix ethernet vlan double tagging"
From: Baptiste Jonglez
This change has been causing several issues on ipq40xx devices, including:
- VLAN tagging no longer works correctly:
https://bugs.openwrt.org/index.php?do=details_id=3239
- poor performance with tagged VLANs:
https://bugs.openwrt.org/index.php?do=details_id=3457
See also
https://forum.openwrt.org/t/vlan-tagging-on-ipq40xx-gl-b1300-no-longer-works/69569
There are have been discussions on ways to fix the issue in the links
above (including switching to DSA), but nothing that can realistically
be introduced in the 19.07 branch.
This reverts commit 8c191712558ce94 ("ipq40xx: fix ethernet vlan
double tagging")
Note that it's not a clean revert because this patch was touched in
148d59c67edd5 ("kernel: update kernel 4.14 to version 4.14.193") even
though the semantic of the patch was left unchanged.
Fixes: FS#3239
Fixes: FS#3457
---
.../716-essedma-vlan-double-tag.patch | 128 --
1 file changed, 128 deletions(-)
delete mode 100644
target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
diff --git
a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
b/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
deleted file mode 100644
index e268351273..00
--- a/target/linux/ipq40xx/patches-4.14/716-essedma-vlan-double-tag.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From: Sven Eckelmann
-Date: Wed, 8 Feb 2017 16:26:00 +0100
-Subject: [PATCH] ipq40xx: Fix ar40xx port separation
-
-It is currently not possible to submit (or receive) VLAN tagged frames over
-the ar40xx PHY switch and the edma ethernet device.
-
-This can be worked around by disabling enable_vlan. The separation of the
-eth0 and eth1 ports is then done by the vlan_tag information from the
-device tree. But the ar40xx PHY switch then also has to parse the word3
-port bitmap (word3) from the TDP when data was received from the CPU port
-(0).
-
-IssueID: #2857
-
-Forwarded: no
- The ar40xx.c change was forwarded to Xiaofei Shen
- (QCA). But John Crispin will rewrite the driver anyway and we have to check
- later if this change is required in his driver too.
- drivers/net/phy/ar40xx.c | 6 +-
- 1 file changed, 5 insertions(+), 1 deletion(-)
-
a/drivers/net/phy/ar40xx.c
-+++ b/drivers/net/phy/ar40xx.c
-@@ -1200,7 +1200,11 @@ ar40xx_init_port(struct ar40xx_priv *pri
- ar40xx_rmw(priv, AR40XX_REG_PORT_STATUS(port),
- AR40XX_PORT_AUTO_LINK_EN, 0);
-
-- ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-+ /* CPU port is setting headers to limit output ports */
-+ if (port == 0)
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0x8);
-+ else
-+ ar40xx_write(priv, AR40XX_REG_PORT_HEADER(port), 0);
-
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), 0);
-
-@@ -1243,6 +1247,10 @@ ar40xx_init_globals(struct ar40xx_priv *
- t = (AR40XX_PORT0_FC_THRESH_ON_DFLT << 16) |
- AR40XX_PORT0_FC_THRESH_OFF_DFLT;
- ar40xx_write(priv, AR40XX_REG_PORT_FLOWCTRL_THRESH(0), t);
-+
-+ /* set service tag to 802.1q */
-+ t = ETH_P_8021Q | AR40XX_ESS_SERVICE_TAG_STAG;
-+ ar40xx_write(priv, AR40XX_ESS_SERVICE_TAG, t);
- }
-
- static void
-@@ -1568,7 +1576,11 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- u32 pvid = priv->vlan_id[priv->pvid[port]];
-
- if (priv->vlan) {
-- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+ if (priv->vlan_tagged & BIT(port))
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_TAG;
-+ else
-+ egress = AR40XX_PORT_VLAN1_OUT_MODE_UNMOD;
-+
- ingress = AR40XX_IN_SECURE;
- } else {
- egress = AR40XX_PORT_VLAN1_OUT_MODE_UNTOUCH;
-@@ -1579,8 +1591,17 @@ ar40xx_setup_port(struct ar40xx_priv *pr
- t |= pvid << AR40XX_PORT_VLAN0_DEF_CVID_S;
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN0(port), t);
-
-- t = AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-- t |= egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+ t = egress << AR40XX_PORT_VLAN1_OUT_MODE_S;
-+
-+ /* set CPU port to core port */
-+ if (port == 0)
-+ t |= AR40XX_PORT_VLAN1_CORE_PORT;
-+
-+ if (priv->vlan_tagged & BIT(port))
-+ t |= AR40XX_PORT_VLAN1_PORT_VLAN_PROP;
-+ else
-+ t |= AR40XX_PORT_VLAN1_PORT_TLS_MODE;
-+
- ar40xx_write(priv, AR40XX_REG_PORT_VLAN1(port), t);
-
- t = members;
a/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-+++ b/drivers/net/ethernet/qualcomm/essedma/edma_axi.c
-@@ -970,7 +970,6 @@ static int edma_axi_probe(struct platfor
- edma_netdev[i]->netdev_ops = _axi_netdev_ops;
- edma_netdev[i]->max_mtu = 9000;
- edma_netdev[i]->features = NETIF_F_HW_CSUM | NETIF_F_RXCSUM
--| NETIF_F_HW_VLAN_CTAG_TX
- | NETIF_F_HW_VLAN_CTAG_RX | NETIF_F_SG |
-
Re: 20.xx: postponse LuCI HTTPS per default
"Paul Spooren" writes: > The current list of release goals for 20.xx states[0] that LuCI should > use HTTPS per default. This works by creating on-device a self-signed > certificate. Self-signed certificates result in warnings and may cause > more harm than good, multiple discussion are found in the mail archive. I believe the certificate discussion is a side-track. The problem you are trying to solve is not specific to OpenWrt. I am all for making OpenWrt better than the rest of the world, but there's gotta be some realistic limits to that.. Every embedded device with https support use a self-signed sertificate of some sort today. OpenWrt can do that too. Doing so does not prevent a better solution in the future, if there ever is one. The underlying issue should be considered a browser security bug IMHO. Failing to support standalone embedded https is compromising security by making certificate warnings unavoidable. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
"Paul Spooren" wrote: > Hi, > > The current list of release goals for 20.xx states[0] that LuCI > should use HTTPS per default. This works by creating on-device > a self-signed certificate. Self-signed certificates result in > warnings and may cause more harm than good, multiple discussion > are found in the mail archive. > > As no clean solution seems in reach while 20.xx seems close, > I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs > `luci`) per default. > > This isn't a vote but a request for developer/user opinions. Very much in favour of leaving this off, self-signed isn't viable by default Sincerely, Karl Palsson OpenPGP-digital-signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: state of the DSA
> On Thu, Nov 19, 2020 at 8:37 PM Rosen Penev wrote: >> >> On Thu, Nov 19, 2020 at 4:40 PM Paul Spooren wrote: >>> >>> Hi all, >>> >>> DSA (Distributed Switch Architecture)[0] is a main feature of 20.xx and >>> one of the last blockers for a branch. The goal states[1] support where >>> possible, not necessarily every target. >>> >>> This mail thread should be used to get an overview of the missing bits. >>> >>> The following targets seem use `swconfig`, should/can they be ported? >>> Please post states and links to work in progress migrations: >>> >>> * apm821xx/nand >>> * ath25 >>> * ath79 >>> * bcm47xx >>> * bcm53xx >>> * bcm63xx >>> * ipq40xx >>> * ipq806x >>> * kirkwood >>> * lantiq/xrx200 >>> * lantiq/xway >>> * lantiq/xway_legacy >>> * mediatek >> I believe mediatek exclusively uses DSA. > I looked into this more: > > ~/d/o/t/linux (master)> git grep CONFIG_SWCONFIG=y > apm821xx/nand/config-default:CONFIG_SWCONFIG=y > ath25/config-5.4:CONFIG_SWCONFIG=y > ath79/config-5.4:CONFIG_SWCONFIG=y > bcm47xx/config-5.4:CONFIG_SWCONFIG=y > bcm53xx/config-5.4:CONFIG_SWCONFIG=y > bcm63xx/config-5.4:CONFIG_SWCONFIG=y > ipq40xx/config-5.4:CONFIG_SWCONFIG=y > ipq806x/config-5.4:CONFIG_SWCONFIG=y > ipq807x/config-default:CONFIG_SWCONFIG=y > lantiq/config-5.4:CONFIG_SWCONFIG=y > mediatek/mt7622/config-5.4:CONFIG_SWCONFIG=y > mediatek/mt7623/config-5.4:CONFIG_SWCONFIG=y > mediatek/mt7629/config-5.4:CONFIG_SWCONFIG=y > mpc85xx/config-5.4:CONFIG_SWCONFIG=y > ramips/mt7620/config-5.4:CONFIG_SWCONFIG=y > ramips/mt76x8/config-5.4:CONFIG_SWCONFIG=y > ramips/rt288x/config-5.4:CONFIG_SWCONFIG=y > ramips/rt305x/config-5.4:CONFIG_SWCONFIG=y > ramips/rt3883/config-5.4:CONFIG_SWCONFIG=y > rtl838x/config-5.4:CONFIG_SWCONFIG=y > sunxi/config-5.4:CONFIG_SWCONFIG=y > > mt7628 seems to have DSA support upstream. kirkwood is not there. > > ath79/tiny/config-default:CONFIG_NET_DSA=y > gemini/config-5.4:CONFIG_NET_DSA=y > imx6/config-5.4:CONFIG_NET_DSA=y > ipq806x/config-5.4:CONFIG_NET_DSA=y > kirkwood/config-5.4:CONFIG_NET_DSA=y > mediatek/mt7622/config-5.4:CONFIG_NET_DSA=y > mediatek/mt7623/config-5.4:CONFIG_NET_DSA=y > mvebu/config-5.4:CONFIG_NET_DSA=y > octeon/config-5.4:CONFIG_NET_DSA=y > ramips/mt7621/config-5.4:CONFIG_NET_DSA=y > rtl838x/config-5.4:CONFIG_NET_DSA=y > > is the DSA stuff. > > Some of the swconfig targets can be ported. For example I remember > using a DSA patch for a Netgear R7800. >>> * mpc85xx >>> * ramips/mt7620 >>> * ramips/mt76x8 >>> * ramips/rt288x >>> * ramips/rt305x >>> * ramips/rt3883 >>> >>> All other targets can be considered as DSA targets? If you're working or >>> testing around that, please comment and share the status. >>> >>> LuCI support is added via a PR[2] on GitHub. >>> >>> Best, >>> Paul >>> >>> [0]: https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html >>> [1]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx >>> [2]: https://github.com/openwrt/luci/pull/4307 I hope to see Port Mirroring and Switch configuration in LuCI fully functional again when 20.x.x is released! We should be able to configure each PHY and port, since WRT3200ACM and others have multiple Ethernet interfaces. And it is more efficient to use all of them. I’d rather have one mapped as wan and the other as lan in ifconfig, like I currently have using swconfig. With an option on the Switch configuration page, to split lan into lan1 lan2 lan3 lan4, since multiple networks are less common. It would be nice if LuCI can add, remove and rename interfaces as seen in ifconfig. And also choose which PHY they map to. Georgi Valkov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] generic: add DTR quirk patch for MR400 LTE
Ignore this one please. I forgot 3/4.
Filip
On Fri, Nov 20, 2020 at 09:16:53AM +0100, Filip Moc wrote:
> This is required for LTE module MR400 in TL-MR6400 v4.
>
> Signed-off-by: Filip Moc
> ---
>
> Notes:
> v1->v2:
> - Moved from hack to backports
>
> Upstream commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df8d85d8c69d6837817e54dcb73c84a8b5a13877
>
> ...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 34 +++
> 1 file changed, 34 insertions(+)
> create mode 100644
> target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
>
> diff --git
> a/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
>
> b/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
> new file mode 100644
> index 00..91c95573f6
> --- /dev/null
> +++
> b/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
> @@ -0,0 +1,34 @@
> +From df8d85d8c69d6837817e54dcb73c84a8b5a13877 Mon Sep 17 00:00:00 2001
> +From: Filip Moc
> +Date: Tue, 17 Nov 2020 18:36:31 +0100
> +Subject: net: usb: qmi_wwan: Set DTR quirk for MR400
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
> +
> +Signed-off-by: Filip Moc
> +Acked-by: Bjørn Mork
> +Link: https://lore.kernel.org/r/20201117173631.ga550...@moc6.cz
> +Signed-off-by: Jakub Kicinski
> +---
> + drivers/net/usb/qmi_wwan.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> +index 581ed51abb532..fc378ff56775b 100644
> +--- a/drivers/net/usb/qmi_wwan.c
> b/drivers/net/usb/qmi_wwan.c
> +@@ -1070,7 +1070,7 @@ static const struct usb_device_id products[] = {
> + {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
> + {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
> + {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
> +-{QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB TL131 TDD
> LTE (China Mobile) */
> ++{QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD
> LTE (China Mobile) */
> + {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
> + {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
> + {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
> +--
> +cgit 1.2.3-1.el7
> +
> --
> 2.28.0
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 3/4] generic: add DTR quirk patch for MR400 LTE
This is required for LTE module MR400 in TL-MR6400 v4.
Signed-off-by: Filip Moc
---
Notes:
v1->v2:
- Moved from hack to backports
Upstream commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df8d85d8c69d6837817e54dcb73c84a8b5a13877
...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 34 +++
1 file changed, 34 insertions(+)
create mode 100644
target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
diff --git
a/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
b/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
new file mode 100644
index 00..91c95573f6
--- /dev/null
+++
b/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
@@ -0,0 +1,34 @@
+From df8d85d8c69d6837817e54dcb73c84a8b5a13877 Mon Sep 17 00:00:00 2001
+From: Filip Moc
+Date: Tue, 17 Nov 2020 18:36:31 +0100
+Subject: net: usb: qmi_wwan: Set DTR quirk for MR400
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
+
+Signed-off-by: Filip Moc
+Acked-by: Bjørn Mork
+Link: https://lore.kernel.org/r/20201117173631.ga550...@moc6.cz
+Signed-off-by: Jakub Kicinski
+---
+ drivers/net/usb/qmi_wwan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
+index 581ed51abb532..fc378ff56775b 100644
+--- a/drivers/net/usb/qmi_wwan.c
b/drivers/net/usb/qmi_wwan.c
+@@ -1070,7 +1070,7 @@ static const struct usb_device_id products[] = {
+ {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
+- {QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB TL131 TDD
LTE (China Mobile) */
++ {QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD
LTE (China Mobile) */
+ {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
+--
+cgit 1.2.3-1.el7
+
--
2.28.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] generic: add DTR quirk patch for MR400 LTE
This is required for LTE module MR400 in TL-MR6400 v4.
Signed-off-by: Filip Moc
---
Notes:
v1->v2:
- Moved from hack to backports
Upstream commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df8d85d8c69d6837817e54dcb73c84a8b5a13877
...usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch | 34 +++
1 file changed, 34 insertions(+)
create mode 100644
target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
diff --git
a/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
b/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
new file mode 100644
index 00..91c95573f6
--- /dev/null
+++
b/target/linux/generic/backport-5.4/789-net-usb-qmi_wwan-Set-DTR-quirk-for-MR400.patch
@@ -0,0 +1,34 @@
+From df8d85d8c69d6837817e54dcb73c84a8b5a13877 Mon Sep 17 00:00:00 2001
+From: Filip Moc
+Date: Tue, 17 Nov 2020 18:36:31 +0100
+Subject: net: usb: qmi_wwan: Set DTR quirk for MR400
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+LTE module MR400 embedded in TL-MR6400 v4 requires DTR to be set.
+
+Signed-off-by: Filip Moc
+Acked-by: Bjørn Mork
+Link: https://lore.kernel.org/r/20201117173631.ga550...@moc6.cz
+Signed-off-by: Jakub Kicinski
+---
+ drivers/net/usb/qmi_wwan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
+index 581ed51abb532..fc378ff56775b 100644
+--- a/drivers/net/usb/qmi_wwan.c
b/drivers/net/usb/qmi_wwan.c
+@@ -1070,7 +1070,7 @@ static const struct usb_device_id products[] = {
+ {QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
+ {QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
+ {QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
+- {QMI_FIXED_INTF(0x05c6, 0x9025, 4)},/* Alcatel-sbell ASB TL131 TDD
LTE (China Mobile) */
++ {QMI_QUIRK_SET_DTR(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD
LTE (China Mobile) */
+ {QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
+ {QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
+ {QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
+--
+cgit 1.2.3-1.el7
+
--
2.28.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: R: R: Someone working on kernel 5.9?
ansuels...@gmail.com wrote: > > ansuels...@gmail.com wrote: > > > > Ansuel Smith wrote: > > > > > If you want I can port 5.9 to ipq806x and check if there is any > > > > > problem. That way it will be ready when 5.10 is released (i think > > > > > minimal change from 5.9 to 5.10) > > > > tsense patches not apply, ar8216 driver need small fix: > > > > > > > > > I think that with 5.10 we will be able to switch to qca8k dsa (and trash > > > the ar8216 driver). > > Why we can't do this now? > We already can... to switch and use dsa we just need to update entries in > the dts. > > > About tsense I'm still waiting a kernel guy to review my patches to add > > > support upstream, I would delay as much as we can the porting of tsens > > > patch hoping that the upstream patch gets accepted before official 5.10 > > > support from openwrt. > > Heh. 5.10-rc1 is already out, no new features is allowed to merge. > > Maybe in 5.11 or 5.12 you see your patches in kernel. > > > Since the entire tsense driver is a big patch that adds source file, it will > be better > to backport the new driver from upstream to 5.10 instead of adapt the old > patch. > At worst we can just use the proposed patch that already works and is a lot > cleaner > Than what we have now. This series https://lore.kernel.org/linux-pm/20200814134123.14566-1-ansuels...@gmail.com/ is enough for replace ipq806x/patches/0063-* ? Or need backport something else? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
> From: Michael Richardson > Subject: Re: 20.xx: postponse LuCI HTTPS per default > Date: 2020-11-20, 7:26:44 AM EET > To: "Paul Spooren" , openwrt-devel@lists.openwrt.org > > > > Paul Spooren wrote: >> The current list of release goals for 20.xx states[0] that LuCI should >> use HTTPS per default. This works by creating on-device a self-signed >> certificate. Self-signed certificates result in warnings and may cause >> more harm than good, multiple discussion are found in the mail archive. > >> As no clean solution seems in reach while 20.xx seems close, I'd like to >> suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. > >> This isn't a vote but a request for developer/user opinions. > > I agree with postponing this. > I think that we need to do some work on this problem. > This is a subset (an easier subset actually) of a general IoT onboarding > problem. > > I would like to form a design-team to figure out what we can do in practice, > and I would be happy to lead/act-as-convenor it via a series online working > meetings if the group wants. > > The need for a PPPoE username/password is one of the challenges. I think we should keep the non-secure HTTP available as a fallback, because some web browsers, may refuse to connect to self-signed certificates. The following changes would keep compatibility, yet also help users switch to the secure interface. * If using HTTP at the login page, display a link to the HTTPS login. * Also display a link with some help: Why HTTPS is important. * The help should explain the warning about unsigned certificates. * Avoid automatic permanent redirect to HTTPS unless the user wants this. * The design should be easy to notice, yet not intrusive. Regarding the idea to use Let’s Encrypt, in theory part of the process can be automated, but OpenWRT still has to know the DNS name of the site. If Let’s Encrypt integration is provided, it would be better to enable and configure it manually. After that the system can update its certificate using a cron task. Georgi Valkov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
