Re: [PATCH v2 5/6] mvebu: implement compatibility version for DSA migration
On 14.07.20 04:28, Adrian Schmutzler wrote: This implements the newly introduced compat-version to prevent upgrade between swconfig and DSA for mvebu. Just define a compat version with minor increment and an appropriate message for both image (in Makefile) and device (in base-files). Having taken care of sysupgrade, we can put back the SUPPORTED_DEVICES that have been removed in previous patches to prevent broken config. While at it, fix alphabetic sorting in 02_network. Signed-off-by: Adrian Schmutzler --- Added in v2 --- .../base-files/etc/board.d/02_network | 14 -- target/linux/mvebu/image/cortexa9.mk | 19 +++ 2 files changed, 27 insertions(+), 6 deletions(-) diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network index 9718b332a7..9255f2535e 100755 --- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network +++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network @@ -23,6 +23,7 @@ mvebu_setup_interfaces() linksys,wrt3200acm|\ linksys,wrt32x) ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" "wan" + ucidef_set_compat_version "1.1" ;; marvell,a385-db-ap) ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2" @@ -30,18 +31,19 @@ mvebu_setup_interfaces() marvell,axp-gp) ucidef_set_interface_lan "eth0 eth1 eth2 eth3" ;; - solidrun,clearfog-pro-a1) - # eth0 is standalone ethernet - # eth1 is switch - # eth2 is SFP - ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 lan6" "eth0 eth2" - ;; solidrun,clearfog-base-a1) # eth0 is standalone ethernet # eth1 is standalone ethernet # eth2 is SFP ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2" ;; + solidrun,clearfog-pro-a1) + # eth0 is standalone ethernet + # eth1 is switch + # eth2 is SFP + ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 lan6" "eth0 eth2" + ucidef_set_compat_version "1.1" + ;; *) ucidef_set_interface_lan "eth0" ;; diff --git a/target/linux/mvebu/image/cortexa9.mk b/target/linux/mvebu/image/cortexa9.mk index 7f0a2fe697..1a4c43d133 100644 --- a/target/linux/mvebu/image/cortexa9.mk +++ b/target/linux/mvebu/image/cortexa9.mk @@ -6,6 +6,11 @@ # See /LICENSE for more information. # +define Device/dsa-migration + DEVICE_COMPAT_VERSION := 1.1 + DEVICE_COMPAT_MESSAGE := Config cannot be migrated from swconfig to DSA +endef Shouldn't this be defined in a more central place as it at least impacts two, later more targets? + define Device/buffalo_ls421de $(Device/NAND-128K) DEVICE_VENDOR := Buffalo @@ -63,16 +68,19 @@ endef define Device/linksys_wrt1200ac $(call Device/linksys) + $(Device/dsa-migration) DEVICE_MODEL := WRT1200AC DEVICE_ALT0_VENDOR := Linksys DEVICE_ALT0_MODEL := Caiman DEVICE_DTS := armada-385-linksys-caiman DEVICE_PACKAGES += mwlwifi-firmware-88w8864 + SUPPORTED_DEVICES += armada-385-linksys-caiman linksys,caiman endef TARGET_DEVICES += linksys_wrt1200ac define Device/linksys_wrt1900acs $(call Device/linksys) + $(Device/dsa-migration) DEVICE_MODEL := WRT1900ACS DEVICE_VARIANT := v1 DEVICE_ALT0_VENDOR := Linksys @@ -82,11 +90,13 @@ define Device/linksys_wrt1900acs DEVICE_ALT1_MODEL := Shelby DEVICE_DTS := armada-385-linksys-shelby DEVICE_PACKAGES += mwlwifi-firmware-88w8864 + SUPPORTED_DEVICES += armada-385-linksys-shelby linksys,shelby endef TARGET_DEVICES += linksys_wrt1900acs define Device/linksys_wrt1900ac-v1 $(call Device/linksys) + $(Device/dsa-migration) DEVICE_MODEL := WRT1900AC DEVICE_VARIANT := v1 DEVICE_ALT0_VENDOR := Linksys @@ -94,32 +104,38 @@ define Device/linksys_wrt1900ac-v1 DEVICE_DTS := armada-xp-linksys-mamba DEVICE_PACKAGES += mwlwifi-firmware-88w8864 KERNEL_SIZE := 3072k + SUPPORTED_DEVICES += armada-xp-linksys-mamba linksys,mamba endef TARGET_DEVICES += linksys_wrt1900ac-v1 define Device/linksys_wrt1900ac-v2 $(call Device/linksys) + $(Device/dsa-migration) DEVICE_MODEL := WRT1900AC DEVICE_VARIANT := v2 DEVICE_ALT0_VENDOR := Linksys DEVICE_ALT0_MODEL := Cobra DEVICE_DTS := armada-385-linksys-cobra DEVICE_PACKAGES += mwlwifi-firmware-88w8864 + SUPPORTED_DEVICES += armada-385-linksys-cobra linksys,cobra endef TARGET_DEVICES += linksys_wrt1900ac-v2 define Device/linksys_wrt3200acm $(call Device/linksys) + $(Device/dsa-migration) DEVICE_MODEL := WRT3200ACM DEVICE_ALT0_VENDOR := Linksys DEVICE_ALT0_MODEL := Rango DEVICE_DTS := armada-385-li
Re: [PATCH v2 4/6] base-files: fwtool: make compat_version backward compatible
On 14.07.20 04:28, Adrian Schmutzler wrote:
So far, the compatibility mechanism only works if both device and
image are already updated to the new routines. This patch extends
the sysupgrade metadata and fwtool_check_image() to account for
"older" images as well:
The basic mechanism for older devices to check for image compatibility
is the supported_devices entry. This can be exploited by putting
a custom message into this variable of the metadata, so older FW
will produce a mismatch and print the message as it thinks it's the
list of supported devices. So, we have two cases:
device 1.0, image 1.0:
The metadata will just contain supported_devices as before.
device 1.0, image 1.1:
The metadata will contain:
"new_supported_devices":["device_string1", "device_string2", ...],
"supported_devices":["Upgrade incompatible. Please check Wiki ..."]
Does that mean starting from 1.1 all sysupgrade images will carry a
informative only "supported_device" array until the end of time?
This is maybe a bit of a big request but as there will be 19.07.4
release without DSA, couldn't some firmware migration patches be added
there and anyone trying to upgrade from 19.07.x will receive a message
like "Please upgrade to 19.07.4 before installing 20.x"? Maybe it's not
feasible, but as ideally all (correct?) devices move to DSA, we will
have compat 1.1 everywhere and `supported_devices` is useless.
If the device is "legacy", i.e. does not have the updated fwtool.sh,
it will just fail with image check and print the content of
supported_devices. Upgrade can still be performed with -F like when
SUPPORTED_DEVICES has been removed to prevent bricking.
If the device has updated fwtool.sh (but is 1.0), it will just use
the new_supported_devices instead, and work as intended (flashing
with -n will work, flashing without will print the appropriate
warning).
This mechanism should provide a fair tradeoff between simplicity
and functionality.
Signed-off-by: Adrian Schmutzler
---
Changes in v2:
- Add DEVICE_COMPAT_MESSAGE and reword comment for legacy warning.
---
include/image-commands.mk | 5 -
package/base-files/files/lib/upgrade/fwtool.sh | 7 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 9da712e733..e21472a659 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -393,7 +393,10 @@ metadata_json = \
"metadata_version": "1.0", \
By replacing the meaning of `supported_devices` to
`new_supported_devices` we should also modify `metadata_version`.
"compat_version": "$(call json_quote,$(compat_version))", \
$(if $(DEVICE_COMPAT_MESSAGE),"compat_message": "$(call
json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
- "supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))], \
+ $(if $(filter-out
1.0,$(compat_version)),"new_supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
+ $(if $(filter-out 1.0,$(compat_version)),"supported_devices": \
+ ["$(call json_quote,Image version $(compat_version)
incompatible to device: $(if $(DEVICE_COMPAT_MESSAGE),$(DEVICE_COMPAT_MESSAGE),Please
check documentation ...)"]$(comma)) \
+ $(if $(filter
1.0,$(compat_version)),"supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
"version": { \
"dist": "$(call json_quote,$(VERSION_DIST))", \
"version": "$(call json_quote,$(VERSION_NUMBER))", \
diff --git a/package/base-files/files/lib/upgrade/fwtool.sh
b/package/base-files/files/lib/upgrade/fwtool.sh
index 1807aecd6d..59f981f6c3 100644
--- a/package/base-files/files/lib/upgrade/fwtool.sh
+++ b/package/base-files/files/lib/upgrade/fwtool.sh
@@ -51,7 +51,12 @@ fwtool_check_image() {
json_get_var compatmessage compat_message
[ -n "$imagecompat" ] || imagecompat="1.0"
- json_select supported_devices || return 1
+ # select correct supported list based on compat_version
+ # (using this ensures that compatibility check works for devices
+ # not knowing about compat-version)
+ local supported=supported_devices
+ [ "$imagecompat" != "1.0" ] && supported=new_supported_devices
+ json_select $supported || return 1
json_get_keys dev_keys
for k in $dev_keys; do
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/6] base-files: fwtool: implement compatibility check for images
On 14.07.20 04:28, Adrian Schmutzler wrote:
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.
To solve this situation, this patchset introduces a compatibility
version for devices. In this patch, the actual checks are implemented
into fwtool_check_image():
If an incompatible change is introduced, one can increase either
the minor version (1.0->1.1) or the major version (1.0->2.0).
Minor version increment:
This will still allow sysupgrade, but require to reset config
(-n or SAVE_CONFIG=0). If sysupgrade is called without -n, a
corresponding message will be printed. If sysupgrade is called
with -n, it will just pass, with supported devices being checked
as usual. (Which will allow us to add back SUPPORTED_DEVICES for
many cases.)
Major version increment:
This is meant for potential (rare) cases where sysupgrade is
not possible at all, because it would break the device.
In this case, a warning will be printed, and -n won't help.
What are those rare cases? I just can't think of anything where not even
a clean sysupgrade would be possible. Would it mean to go back to stock
firmware and then upgrade a 2.x version? If there isn't a scenario maybe
a single integer is easier to handle than a pseudo float.
If image check fails because of one of the versions parts not
matching, the content of DEVICE_COMPAT_MESSAGE is printed in
addition to the generic message (if set).
For both cases, upgrade can still be forced with -F as usual.
Signed-off-by: Adrian Schmutzler
---
Changes in v2:
- Move compat check AFTER supported_devices check
- Improve error messages
---
.../base-files/files/lib/upgrade/fwtool.sh| 24 ++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/package/base-files/files/lib/upgrade/fwtool.sh
b/package/base-files/files/lib/upgrade/fwtool.sh
index a0b3fb0a04..1807aecd6d 100644
--- a/package/base-files/files/lib/upgrade/fwtool.sh
+++ b/package/base-files/files/lib/upgrade/fwtool.sh
@@ -44,13 +44,35 @@ fwtool_check_image() {
}
device="$(cat /tmp/sysinfo/board_name)"
+ devicecompat="$(uci -q get system.@system[0].compat_version)"
+ [ -n "$devicecompat" ] || devicecompat="1.0"
+
+ json_get_var imagecompat compat_version
+ json_get_var compatmessage compat_message
+ [ -n "$imagecompat" ] || imagecompat="1.0"
json_select supported_devices || return 1
json_get_keys dev_keys
for k in $dev_keys; do
json_get_var dev "$k"
- [ "$dev" = "$device" ] && return 0
+ if [ "$dev" = "$device" ]; then
+ # major compat version -> no sysupgrade
+ if [ "${devicecompat%.*}" != "${imagecompat%.*}" ]; then
+ echo "The device is supported, but this image is
incompatible for sysupgrade based on the image version
($devicecompat->$imagecompat)."
+ [ -n "$compatmessage" ] && echo "$compatmessage"
+ return 1
+ fi
+
+ # minor compat version -> sysupgrade with -n required
+ if [ "${devicecompat#.*}" != "${imagecompat#.*}" ] && [
"$SAVE_CONFIG" = "1" ]; then
+ echo "The device is supported, but the config is
incompatible to the new image ($devicecompat->$imagecompat). Please upgrade with -n."
I'd write "Please upgrade with -n to reset the device configuration"
+ [ -n "$compatmessage" ] && echo "$compatmessage"
+ return 1
+ fi
+
+ return 0
+ fi
done
echo "Device $device not supported by this image"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
On 2020-07-15 13:52, John Crispin wrote: > > On 15.07.20 13:39, Jo-Philipp Wich wrote: >> Hi, >> >>> If we can't come up with a working automatic scheme, maybe we could have >>> an option to disable the cpu port per vlan? >> Having a default-enabled "option self" or "option local" was my idea as >> well. Any idea which name fits better? >> >> ~ Jo >> > self is what ip-bridge uses as a parameter name for this feature I think local is a better fit - self/master seems to be used for bridge vlan filter command target selection, not just for this feature. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC] usage of mkhash, sha256sum and md5sum
Hi,
the OpenWrt system requires the calculation of both md5 and sha256 sums
at various places, this is partly done via a small C file in
./scripts/mkhash.c and partly by using a sha256sum binary. A ancient
wrapper ./scripts/md5sum is added for Mac OS X compatibility.
* Should we create our own crypto by using ./scripts/mkhash.c? I
remember from some previous discussions on IRC and GitHub that there are
generally concerns against it, also a motivation for[0]. I understand
that Felix just reinvent the code but used established sources, however
it is used for package signing (not image signing). I'm fairly sure less
eyes look through that code than e.g. the Debian implementation.
* Currently include/package-ipkg.mk uses a host installed `sha256sum`
binary which is not covered via include/prereq{,-build}.mk. Should it be
added to prereq or replaced by mkhash?
* Can ./scripts/md5sum be removed or is it still required for Mac OS X
builds.
* Any reason not to replace `mkhash ` by using `sum | cut -d '
' -f 1`? Both sha256sum and md5sum seem to be available per default on
Debian, Alpine and OpenWrt.
Best,
Paul
[0]: https://github.com/openwrt/openwrt/pull/2911
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: store buildsystem revision in packages
In the past buildinfo files where added to enable testing for
reproducible builds. The combination of the three buildinfo files
feeds.buildinfo, config.buildinfo and version.buildinfo allow to
recreate the buildsystem and check if compiled binaries are bit for bit
the same as distributed on official servers.
To support the verification efforts of the reproducible-builds.org team
this patch adds the buildsystem revision to the package index. This way
external feeds all external feeds can be rebuild and verified.
Instead of adding a single file to the Packages folder containing the
revision, the per package storage of revisions allow iterative updates.
Even though the buildbots currently rebuild all packages, it would also
be possible to only rebuild upgraded packages in the future.
To keep the `Packages` small, it is ignored when creating the index.
Tested with buildsystem and SDK on ath79/generic.
Signed-off-by: Paul Spooren
---
include/package-ipkg.mk | 1 +
package/Makefile| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk
index 622cbf3223..1dc8dc8f56 100644
--- a/include/package-ipkg.mk
+++ b/include/package-ipkg.mk
@@ -184,6 +184,7 @@ $$(call addfield,Depends,$$(Package/$(1)/DEPENDS)
)$$(call addfield,License,$(LICENSE)
)$$(call addfield,LicenseFiles,$(LICENSE_FILES)
)$$(call addfield,Section,$(SECTION)
+)$$(call addfield,BuildsystemRevision,$(REVISION)
)$$(call addfield,Require-User,$(USERID)
)$(if $(PKG_CPE_ID),CPE-ID: $(PKG_CPE_ID)
)$(if $(filter hold,$(PKG_FLAGS)),Status: unknown hold not-installed
diff --git a/package/Makefile b/package/Makefile
index 58c1ba2bbf..9ab99dadc3 100644
--- a/package/Makefile
+++ b/package/Makefile
@@ -84,7 +84,7 @@ $(curdir)/index: FORCE
mkdir -p $$d; \
cd $$d || continue; \
$(SCRIPT_DIR)/ipkg-make-index.sh . 2>&1 > Packages.manifest; \
- grep -vE '^(Maintainer|LicenseFiles|Source|SourceName|Require)'
Packages.manifest > Packages; \
+ grep -vE
'^(Maintainer|LicenseFiles|Source|SourceName|Require|BuildsystemRevision)'
Packages.manifest > Packages; \
case "$$(((64 + $$(stat -L -c%s Packages)) % 128))" in 110|111)
\
$(call ERROR_MESSAGE,WARNING: Applying padding in
$$d/Packages to workaround usign SHA-512 bug!); \
{ echo ""; echo ""; } >> Packages;; \
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- СОВЕТСКИЕ МУЛЬТФИЛЬМЫ Большая коллекция, состоящая из 600 мультфильмов! Здравствуйте, предлагаем Вашему вниманию обновлённую коллекцию мультфильмов. В наши дни выходит много разных мультфильмов, особенно в зарубежном прокате, но разве они могут сравнится с нашими отечественными мультиками, которые воспитывают у детей доброту, сострадание, бескорыстие и другие необходимые качества, которыми должен обладать настоящий человек. Конечно, у советских мультипликаторов не было тех безграничных технических возможностей при создании фильмов, что были у их западных коллег. Но от этого качество мультипликационных фильмов не становится хуже. Наоборот, именно советские мультфильмы признаны психологами самыми гармоничными, подходящими и полезными для становления и развития психики маленького человечка. Вы не увидите обилие «стрелялок и пищалок», эмоционально подавляющих сюжетных линий, злых монстров и агрессии персонажей. Все мультфильмы направлены на то, чтобы воспитать живого, думающего и доброго человека. Другими словами, чтобы воспитать личность. В этом и заключается секрет успеха советской мультипликации и даже ее победы в борьбе за зрительские симпатии. Многим из этих мультфильмов уже более полу века, однако, они передаются от родителей к детям, как эталон детской мультипликации. Отличие нашей коллекции от других — это большое количество мультфильмов, современная реставрация, благодаря чему все записи имеют отличное качество с сохранением оригинального звучания и изображения (привычные голоса героев и видео). Предлагаемая нами коллекция послужит прекрасным подарком для детей, они будут счастливы получив такой не иссекаемый запас доброты, радости и веселья. Коллекция состоит из 600 мультфильмов, общей продолжительностью 129 часов 48 минут. Записана на внешний USB накопитель (флешка). Проблем с воспроизведением не возникнет, можно смотреть на компьютере, планшете, смартфоне, телевизоре и т.д. Запись на внешний USB накопитель имеет ряд преимуществ в сравнении с обычными DVD дисками, USB накопитель гораздо легче, занимает меньше места, обладает высокой надёжностью сохранности записей, а это значит, что наша коллекция будет радовать Вас много лет. Мы гарантируем отличное качество всех записей. На самом носителе создана продуманная структура, все записи разнесены по каталогам, имеются плейлисты, прописаны теги, а также полный список вошедших записей, поэтому проблем с поиском и навигацией не возникнет. С полным списком вошедших в коллекцию мультфильмов Вы можете ознакомится в прикрепленном к письму файле. Стоимость коллекции на внешнем USB накопителе — 6500 (Шесть Тысяч Пятьсот) Рублей. Продаются только вместе. Доставка включена в стоимость. Доставка и оплата коллекции осуществляется только по России — почтой, наложенным платежом, никакой предоплаты не требуется, оплата только в момент получения на почте, доставка включена в стоимость. Сроки доставки зависят от расстояния и степени загрузки почты, но как правило это 7-14 суток с момента отправки. Напоминаем, что у нас нет курьерской доставки — только почтой, в том числе и по Москве. Для оформления заказа просьба не забывать указывать: --- Ваш почтовый индекс (пишите правильный индекс — это ускорит доставку); --- Ваш город и точный адрес (название улицы, номер дома и номер квартиры); --- Ф.И.О. получателя и ОБЯЗАТЕЛЬНО номер контактного телефона (лучше сотовый); Заказы\вопросы направляйте по адресу: multfi...@cwhflash.ru Мы очень ответственно относимся к качеству нашего товара, поэтому перед отправкой всё дополнительно проверяется, как следствие отправка бракованной продукции сведена к нулю. Товар упаковывается в специальный ударостойкий материал, что в значительной степени уменьшает риск повреждения при транспортировке. Если вдруг с полученным товаром возникнут проблемы, то все наши покупатели всегда могут рассчитывать на квалифицированную техническую поддержку. Мы никогда не отказываемся от гарантийных обязательств, в случае проблемы Вы можете рассчитывать на замену, почтовые расходы мы берём на себя. По вашему желанию, данная коллекция может быть записана на DVD диски. Для записи используются надёжные DVD диски со специальным покрытием, которое повышает устойчивость диска к механическим повреждениям, таким как трещины и царапины, а это значит, что наша коллекция будет радовать Вас много лет. Коллекция упакована в пластиковые боксы (slim-dvd), имеет красивые и продуманные обложки, с обратной стороны которых указан список вошедших на каждый диск записей и другая полезная информация, поэтому проблем с поиском и навигацией не возникнет. Если хотите приобрести коллекцию, записанную на DVD дисках, то в этом случае просьба сообщить нам об этом в своей за
Re: [PATCH] dropbear: Enable Ed25519 for normal devices
On Wed, Jul 15, 2020 at 5:15 PM Paul Spooren wrote: > > The Ed25519 key pairs are much shorter than RSA pairs and are supported > by default in OpenSSH. Looking at websites explaining how to create new > SSH keys, many suggest using Ed25519 rather than RSA, however consider > the former as not yet widely established. OpenWrt likely has a positive > influence on that development. > > As enabling Ed25519 is a compile time option, it is currently not > possible to install the feature via `opkg` nor select that option in an > ImageBuilder. > > Due to the size impact the option should only be enabled for devices > with `!SMALL_FLASH`. > > This approach seems cleaner than splitting `dropbear` into two packages > like `dropbear` and `dropbear-ed25519`. > > Signed-off-by: Paul Spooren I like this. > --- > package/network/services/dropbear/Config.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/network/services/dropbear/Config.in > b/package/network/services/dropbear/Config.in > index 3de4189e08..2836229043 100644 > --- a/package/network/services/dropbear/Config.in > +++ b/package/network/services/dropbear/Config.in > @@ -51,7 +51,7 @@ config DROPBEAR_ECC_FULL > > config DROPBEAR_ED25519 > bool "Ed25519 support" > - default n > + default y if !SMALL_FLASH > help > This enables the following public key algorithm: > ssh-ed25519 > -- > 2.25.1 > > > ___ > 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] dropbear: Enable Ed25519 for normal devices
The Ed25519 key pairs are much shorter than RSA pairs and are supported by default in OpenSSH. Looking at websites explaining how to create new SSH keys, many suggest using Ed25519 rather than RSA, however consider the former as not yet widely established. OpenWrt likely has a positive influence on that development. As enabling Ed25519 is a compile time option, it is currently not possible to install the feature via `opkg` nor select that option in an ImageBuilder. Due to the size impact the option should only be enabled for devices with `!SMALL_FLASH`. This approach seems cleaner than splitting `dropbear` into two packages like `dropbear` and `dropbear-ed25519`. Signed-off-by: Paul Spooren --- package/network/services/dropbear/Config.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/network/services/dropbear/Config.in b/package/network/services/dropbear/Config.in index 3de4189e08..2836229043 100644 --- a/package/network/services/dropbear/Config.in +++ b/package/network/services/dropbear/Config.in @@ -51,7 +51,7 @@ config DROPBEAR_ECC_FULL config DROPBEAR_ED25519 bool "Ed25519 support" - default n + default y if !SMALL_FLASH help This enables the following public key algorithm: ssh-ed25519 -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] dnsmasq: Ignore carrier status for bridge interfaces
dnsmasq sometimes does not listen for DHCP at bootup on lan (see bug FS#1765).
This occurs because netifd can incorrectly indicate carrier down on an
interface through devstatus after issuing a carrier up hotplug event.
This patch ignores carrier status for bridge interfaces, as this does not
reflect media state so is not a useful check.
Signed-off-by: Reuben Dowle
---
package/network/services/dnsmasq/files/dnsmasq.init | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 9288971..3aafdf9 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -104,9 +104,12 @@ dhcp_check() {
# If there's no carrier yet, skip this interface.
# The init script will be called again once the link is up
- case "$(devstatus "$ifname" | jsonfilter -e @.carrier)" in
- false) return 1;;
- esac
+ local carrier
+ local type
+ eval $(devstatus "$ifname" | jsonfilter -e "carrier=@.carrier" -e
"type=@.type")
+ if [ "$carrier" = "false" -a "$type" != "bridge" ]; then
+ return 1
+ fi
udhcpc -n -q -s /bin/true -t 1 -i "$ifname" >&- && rv=1 || rv=0
--
2.7.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [OpenWrt-Devel] [PATCH] dnsmasq: Ignore carrier status for bridge interfaces
I have resent the patch, hopefully without the legal text being added on by our company email server. Reuben -Original Message- From: Petr Štetiar Sent: Sunday, 12 July 2020 1:25 am To: Reuben Dowle Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH] dnsmasq: Ignore carrier status for bridge interfaces Reuben Dowle [2020-01-20 20:41:29]: Hi, > The information in this email communication (inclusive of attachments) > is confidential to 4RF Limited and the intended recipient(s). If you > are not the intended recipient(s), please note that any use, > disclosure, distribution or copying of this information or any part > thereof is strictly prohibited and that the author accepts no > liability for the consequences of any action taken on the basis of the > information provided. IANAL, but I don't like this. Please resend for example from personal/scratch email with proper From: or such, but without this additional footer. Thanks. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [OpenWrt-Devel] Targets without 5.4 support yet
On Wed, 15 Jul 2020, m...@adrianschmutzler.de wrote: At least for the 4.14 targets, I expect them to be archived if there is no update until after the next release (or at the latest after the one following it). I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which is quite a core item obviously, so I thought about reaching out to Boris for some guidance) it's looking good so far. If anyone's interested in helping, I'll share what I have. Also, if there is no one else interested in cns3xxx, I'm happy to take a look at that, I've got two devboards in the shed for that. Any success with pistachio and 5.4? Nope. The board is fine, apart from the NAND, so it's a bit of a regression as it stands now. Regards, -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [OpenWrt-Devel] Targets without 5.4 support yet
> > At least for the 4.14 targets, I expect them to be archived if there is no > update until after the next release (or at the latest after the one following > it). > > > I'm working on bringing pistachio up to 5.4, apart from the spi-nand (which is > quite a core item obviously, so I thought about reaching out to Boris for some > guidance) it's looking good so far. If anyone's interested in helping, I'll > share > what I have. Also, if there is no one else interested in cns3xxx, I'm happy to > take a look at that, I've got two devboards in the shed for that. Any success with pistachio and 5.4? openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] fstools: block: remove the swapon/swapoff applets
The swapon/swapoff applets enabled by default in BusyBox have more features than
the ones from block-mount's block app, which makes them redundant.
This patch removes only those applets, while both keeping all the internal
functionality required to handle hotplug/fstab swap and also shaving off a few
bytes from the block executable:
Before: 92724 bytes
After: 89532 bytes
Signed-off-by: Rui Salvaterra
---
block.c | 127
1 file changed, 127 deletions(-)
diff --git a/block.c b/block.c
index 569bf56..ffb92d9 100644
--- a/block.c
+++ b/block.c
@@ -1691,127 +1691,6 @@ static int main_info(int argc, char **argv)
return 0;
}
-static int swapon_usage(void)
-{
- fprintf(stderr, "Usage: swapon [-s] [-a] [[-p pri] DEVICE]\n\n"
- "\tStart swapping on [DEVICE]\n"
- " -a\tStart swapping on all swap devices\n"
- " -p pri\tSet priority of swap device\n"
- " -s\tShow summary\n");
- return -1;
-}
-
-static int main_swapon(int argc, char **argv)
-{
- int ch;
- FILE *fp;
- char *lineptr;
- size_t s;
- struct probe_info *pr;
- int flags = 0;
- int pri;
- struct stat st;
- int err;
-
- while ((ch = getopt(argc, argv, "ap:s")) != -1) {
- switch(ch) {
- case 's':
- fp = fopen("/proc/swaps", "r");
- lineptr = NULL;
-
- if (!fp) {
- ULOG_ERR("failed to open /proc/swaps\n");
- return -1;
- }
- while (getline(&lineptr, &s, fp) > 0)
- printf("%s", lineptr);
- if (lineptr)
- free(lineptr);
- fclose(fp);
- return 0;
- case 'a':
- cache_load(0);
- list_for_each_entry(pr, &devices, list) {
- if (strcmp(pr->type, "swap"))
- continue;
- if (swapon(pr->dev, 0))
- ULOG_ERR("failed to swapon %s\n",
pr->dev);
- }
- return 0;
- case 'p':
- pri = atoi(optarg);
- if (pri >= 0)
- flags = ((pri << SWAP_FLAG_PRIO_SHIFT) &
SWAP_FLAG_PRIO_MASK) | SWAP_FLAG_PREFER;
- break;
- default:
- return swapon_usage();
- }
- }
-
- if (optind != (argc - 1))
- return swapon_usage();
-
- if (stat(argv[optind], &st) || (!S_ISBLK(st.st_mode) &&
!S_ISREG(st.st_mode))) {
- ULOG_ERR("%s is not a block device or file\n", argv[optind]);
- return -1;
- }
- err = swapon(argv[optind], flags);
- if (err) {
- ULOG_ERR("failed to swapon %s (%d)\n", argv[optind], err);
- return err;
- }
-
- return 0;
-}
-
-static int main_swapoff(int argc, char **argv)
-{
- if (argc != 2) {
- ULOG_ERR("Usage: swapoff [-a] [DEVICE]\n\n"
- "\tStop swapping on DEVICE\n"
- " -a\tStop swapping on all swap devices\n");
- return -1;
- }
-
- if (!strcmp(argv[1], "-a")) {
- FILE *fp = fopen("/proc/swaps", "r");
- char line[256];
-
- if (!fp) {
- ULOG_ERR("failed to open /proc/swaps\n");
- return -1;
- }
- if (fgets(line, sizeof(line), fp))
- while (fgets(line, sizeof(line), fp)) {
- char *end = strchr(line, ' ');
- int err;
-
- if (!end)
- continue;
- *end = '\0';
- err = swapoff(line);
- if (err)
- ULOG_ERR("failed to swapoff %s (%d)\n",
line, err);
- }
- fclose(fp);
- } else {
- struct stat s;
- int err;
-
- if (stat(argv[1], &s) || (!S_ISBLK(s.st_mode) &&
!S_ISREG(s.st_mode))) {
- ULOG_ERR("%s is not a block device or file\n", argv[1]);
- return -1;
- }
- err = swapoff(argv[1]);
- if (err) {
- ULOG_ERR("failed to swapoff %s (%d)\n", argv[1], err);
- return err;
- }
- }
-
- return 0;
-}
-
int main(int argc, char **argv)
{
char *base = basename(*argv);
@@ -182
[PATCH] fstools: disable swapon/swapoff symlink creation
The swapon/swapoff applets enabled by default in BusyBox have more features than the ones from block-mount's block app, which makes them redundant. This patch removes disables the creation of the symlinks for the swapon/swapoff block applets. A follow-up patch will remove the applets themselves from the block executable. Signed-off-by: Rui Salvaterra --- package/system/fstools/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile index 6b813cb433..ed0b3a7a80 100644 --- a/package/system/fstools/Makefile +++ b/package/system/fstools/Makefile @@ -114,8 +114,6 @@ define Package/block-mount/install $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/block $(1)/sbin/ $(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/lib/libblkid-tiny.so $(1)/lib/ - $(LN) ../../sbin/block $(1)/usr/sbin/swapon - $(LN) ../../sbin/block $(1)/usr/sbin/swapoff endef -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Jo-Philipp Wich > Sent: Mittwoch, 15. Juli 2020 14:19 > To: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org > Subject: Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA > VLAN filter rules > > Hi, > > > I'm not sure whether using an asterisk is wise here, as it might pose > > interesting problems when people use scripts to set/evaluate uci > > config (as you have to be extra careful to not have it treated as a > > wildcard.) I'd be happy if we could find another symbol here. > > hm, can you elaborate on the problem here? Scripts which use uci values > verbatim without quoting are prone to any kind of shell injection flaws, not > sure if papering over such deficiencies is the way to go here. I'm not having a specific case in mind; and of course you are right about unquoted values. However, I just tend to not use certain special characters as a symbol without need as there always will be a case where "problems" show up later. For example, one might create interesting effects when using sed on uci config values (same would be true for the dot in swconfig at the moment, I admit). Of course, this is just for consideration, I won't insist on it if you think the asterisk is a superior solution here. Best Adrian > > ~ Jo 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: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
I guess the vlan_default_pvid setting would fit into the config device block in this scheme? On Wed, 15 Jul 2020 at 09:59, Jo-Philipp Wich wrote: > > Hi, > > > Changes: > > - The device is created as a netifd bridge > > - Bridge vlan sections should always refer to the bridge instead of > > automatically be applied to the first one > > - Use = instead of . to mark tagging modifiers. "." is already used > > for vlan interface names and reusing it here creates ambiguity. > > - Allow specifing pvid as a modifier instead of needing to create a > > separate port section. > > > > The section names are optional, I chose to put them in to make it easier > > to modify the sections from scripts > > > > What do you think? > > First of all, I was reworking dsaconfig into a very similar direction for a v3 > so overall I do like your proposal and I think it makes sense. > > Specific points from my side: > > - I dislike the equal sign syntax, colon would fit better imho > - For denoting pvid I used a trailing asterisk, like the old roboswitch config > - The bridge-vlan sections should be anonymous > - Bridge vlan filtering will be implicitely enabled as soon as at least one > bridge-vlan section references a bridge device? > > > So my preferred configuration would look like (choosing list over option > notation for ports but that should have no code impact): > > config device > option name switch0 > option type bridge > > config bridge-vlan > option device switch0 > option vlan 1 > list ports 'lan1' > list ports 'lan2:t' > > config bridge-vlan > option device switch0 > option vlan 2 > list ports 'wan:u'# I think we also should support an explicit > # untag which is equivalent to no suffix > > config bridge-vlan > option device switch0 > option vlan 5 > list ports 'lan2:t*' # The "*" denotes a PVID > list ports 'lan3' > > config bridge-vlan > option device switch0 > option vlan 8 > list ports 'lan2:t' > list ports 'lan4' > > config bridge-vlan > option device switch0 > option vlan 11 > list ports 'lan2:t' > list ports 'lan4:t' > > > ~ Jo > > ___ > 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: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
Hi, > I'm not sure whether using an asterisk is wise here, as it might pose > interesting problems when people use scripts to set/evaluate uci > config (as you have to be extra careful to not have it treated as a > wildcard.) I'd be happy if we could find another symbol here. hm, can you elaborate on the problem here? Scripts which use uci values verbatim without quoting are prone to any kind of shell injection flaws, not sure if papering over such deficiencies is the way to go here. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
> - For denoting pvid I used a trailing asterisk, like the old roboswitch config I'm not sure whether using an asterisk is wise here, as it might pose interesting problems when people use scripts to set/evaluate uci config (as you have to be extra careful to not have it treated as a wildcard.) I'd be happy if we could find another symbol here. Best Adrian 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: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
On 15.07.20 13:39, Jo-Philipp Wich wrote: Hi, If we can't come up with a working automatic scheme, maybe we could have an option to disable the cpu port per vlan? Having a default-enabled "option self" or "option local" was my idea as well. Any idea which name fits better? ~ Jo self is what ip-bridge uses as a parameter name for this feature John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
Hi, > If we can't come up with a working automatic scheme, maybe we could have > an option to disable the cpu port per vlan? Having a default-enabled "option self" or "option local" was my idea as well. Any idea which name fits better? ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
Jo-Philipp Wich writes: > config device > option name switch0 > option type bridge > > config bridge-vlan > option device switch0 > option vlan 1 > list ports 'lan1' > list ports 'lan2:t' If we can't come up with a working automatic scheme, maybe we could have an option to disable the cpu port per vlan? Something like config bridge-vlan option device switch0 option vlan 2 option self 0 # defaults to true list ports 'lan2:t' Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC] CI testing of device-tree .dts files
Hi all, I played today a bit with dt-schema[0] which allows to validate device-tree schema files via something called json-schema[1], a schema description written in, *drums*, yaml. Ideally vendors specify their hardware in the Kernel[2] and dt-schema validates each .dts file added to OpenWrt. The output for the TP-Link 4300 v1 looks currently like the following: user@dawn:~/src/openwrt/openwrt$ dt-validate -n -s /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-5.4.51/Documentation/devicetree/bindings/processed-schema.yaml /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:266:15: ahb: pcie-controller@180c:ranges: [[33554432, 0, 268435456, 268435456, 0, 67108864, 16777216, 0, 0, 0, 0, 1]] is not valid under any of the given schemas (Possible causes of the failure): /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:266:15: ahb: pcie-controller@180c:ranges: [[33554432, 0, 268435456, 268435456, 0, 67108864, 16777216, 0, 0, 0, 0, 1]] is not of type 'boolean' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:266:16: ahb: pcie-controller@180c:ranges:0: [33554432, 0, 268435456, 268435456, 0, 67108864, 16777216, 0, 0, 0, 0, 1] is too long /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml: uart@1802: $nodename:0: 'uart@1802' does not match '^serial(@[0-9a-f,]+)*$' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:60:9: pinmux@1804002c: '#address-cells' is a dependency of '#size-cells' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml: uart@1850: $nodename:0: 'uart@1850' does not match '^serial(@[0-9a-f,]+)*$' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml: eth@1900: $nodename:0: 'eth@1900' does not match '^ethernet(@.*)?$' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:109:19: eth@1900: compatible: ['qca,ar9340-eth', 'syscon'] is not valid under any of the given schemas (Possible causes of the failure): /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:109:19: eth@1900: compatible: ['qca,ar9340-eth', 'syscon'] is too long /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml: eth@1a00: $nodename:0: 'eth@1a00' does not match '^ethernet(@.*)?$' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:140:19: eth@1a00: compatible: ['qca,ar9340-eth', 'syscon'] is not valid under any of the given schemas (Possible causes of the failure): /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:140:19: eth@1a00: compatible: ['qca,ar9340-eth', 'syscon'] is too long /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:193:7: usb@1b00: '#address-cells', '#size-cells', 'caps-offset', 'port@1', 'reset-names' do not match any of the regexes: 'pinctrl-[0-9]+' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:200:19: usb@1b00: phy-names:0: 'usb' was expected /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:193:7: usb@1b00: '#address-cells', '#size-cells', 'caps-offset', 'port@1', 'reset-names' do not match any of the regexes: 'pinctrl-[0-9]+' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:200:19: usb@1b00: phy-names:0: 'usb' was expected /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:320:5: leds: 'qss', 'system', 'usb1', 'usb2', 'wlan2g' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' /home/user/src/openwrt/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/image-ar9344_tplink_tl-wdr4300-v1.dtb.yaml:343:5: ath9k-leds: 'wlan5g' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' /home/user/src/openwrt/openwrt/build_dir/target-mi
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
On 2020-07-15 09:56, Jo-Philipp Wich wrote: > Hi, > >> Changes: >> - The device is created as a netifd bridge >> - Bridge vlan sections should always refer to the bridge instead of >> automatically be applied to the first one >> - Use = instead of . to mark tagging modifiers. "." is already used >> for vlan interface names and reusing it here creates ambiguity. >> - Allow specifing pvid as a modifier instead of needing to create a >> separate port section. >> >> The section names are optional, I chose to put them in to make it easier >> to modify the sections from scripts >> >> What do you think? > > First of all, I was reworking dsaconfig into a very similar direction for a v3 > so overall I do like your proposal and I think it makes sense. > > Specific points from my side: > > - I dislike the equal sign syntax, colon would fit better imho I didn't pick it, because it is already used for linux alias netdevices. Since we don't use those, I guess it might not be a problem in practice. > - For denoting pvid I used a trailing asterisk, like the old roboswitch config Fine with me as well. > - The bridge-vlan sections should be anonymous Sure. As I pointed out, the section name should be optional. > - Bridge vlan filtering will be implicitely enabled as soon as at least one > bridge-vlan section references a bridge device? Yes. I just discussed with John that I'm going to start working on a netifd prototype implementation this week, and I'll include your proposed modifications. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
Hi, > Changes: > - The device is created as a netifd bridge > - Bridge vlan sections should always refer to the bridge instead of > automatically be applied to the first one > - Use = instead of . to mark tagging modifiers. "." is already used > for vlan interface names and reusing it here creates ambiguity. > - Allow specifing pvid as a modifier instead of needing to create a > separate port section. > > The section names are optional, I chose to put them in to make it easier > to modify the sections from scripts > > What do you think? First of all, I was reworking dsaconfig into a very similar direction for a v3 so overall I do like your proposal and I think it makes sense. Specific points from my side: - I dislike the equal sign syntax, colon would fit better imho - For denoting pvid I used a trailing asterisk, like the old roboswitch config - The bridge-vlan sections should be anonymous - Bridge vlan filtering will be implicitely enabled as soon as at least one bridge-vlan section references a bridge device? So my preferred configuration would look like (choosing list over option notation for ports but that should have no code impact): config device option name switch0 option type bridge config bridge-vlan option device switch0 option vlan 1 list ports 'lan1' list ports 'lan2:t' config bridge-vlan option device switch0 option vlan 2 list ports 'wan:u'# I think we also should support an explicit # untag which is equivalent to no suffix config bridge-vlan option device switch0 option vlan 5 list ports 'lan2:t*' # The "*" denotes a PVID list ports 'lan3' config bridge-vlan option device switch0 option vlan 8 list ports 'lan2:t' list ports 'lan4' config bridge-vlan option device switch0 option vlan 11 list ports 'lan2:t' list ports 'lan4:t' ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
Hi, I would like to propose an alternative configuration format that is structurally close to your proposal, but more generic in that it is not tied to DSA directly but configures bridge vlans instead. Here's the converted form of your example: config device switch0 option name switch0 option type bridge config bridge-vlan vlan1 option device switch0 option vlan 1 option ports 'lan1 lan2=t' config bridge-vlan vlan2 option device switch0 option vlan 2 option ports wan config bridge-vlan vlan5 option device switch0 option vlan 5 option ports 'lan2=pt lan3' config bridge-vlan vlan8 option device switch0 option vlan 8 option ports 'lan2=t lan4' config bridge-vlan vlan11 option device switch0 option vlan 11 option ports 'lan2=t lan4=t' Changes: - The device is created as a netifd bridge - Bridge vlan sections should always refer to the bridge instead of automatically be applied to the first one - Use = instead of . to mark tagging modifiers. "." is already used for vlan interface names and reusing it here creates ambiguity. - Allow specifing pvid as a modifier instead of needing to create a separate port section. The section names are optional, I chose to put them in to make it easier to modify the sections from scripts What do you think? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
