Re: [PATCH] imagebuilder: add check if target is sourced from a feed
Hello Thomas I tested your patch, it works well. Thanks But I don't know how you created your imagebuilder. On my side, building an imagebuilder for a target sourced from a feed didn't work. I forgot to send a second commit that fixes this issue comprehensive. Thanks for the reminder. So I just sent a patch to fix it: http://lists.openwrt.org/pipermail/openwrt-devel/2024-March/042452.html Yours change looks exactly like my modification. So I don't care which one is used. The main thing is that it is fixed. I opened a pullrequest right now that include the fix that a had on my patch set [1] for a long time. And also the patch I have already send to the mailing list [2]. Best regards Florian [1] https://github.com/openwrt/openwrt/pull/14937 [2] https://patchwork.ozlabs.org/project/openwrt/patch/20231020114527.3586387-1...@dev.tdt.de/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] imagebuilder: add check if target is sourced from a feed
If a target is not upstream because it is still under development, it can still be added to the openwrt via a feed and can be build. Although the build is successful, no new images can be build with the new board, because it cannot find them. To fix this issue add a check to the imagebuilder and test if the target is located in the feed directory. Signed-off-by: Florian Eckert --- The problem occurred when we started using the new LGM target from MXL in Openwrt. target/imagebuilder/files/Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/target/imagebuilder/files/Makefile b/target/imagebuilder/files/Makefile index 78ec7e2e94..0466fc7dcc 100644 --- a/target/imagebuilder/files/Makefile +++ b/target/imagebuilder/files/Makefile @@ -205,8 +205,13 @@ build_image: FORCE @echo @echo Building images... rm -rf $(BUILD_DIR)/json_info_files/ - $(NO_TRACE_MAKE) -C target/linux/$(BOARD)/image install TARGET_BUILD=1 IB=1 EXTRA_IMAGE_NAME="$(EXTRA_IMAGE_NAME)" \ - $(if $(USER_PROFILE),PROFILE="$(USER_PROFILE)") + if [ -d "target/linux/feeds/$(BOARD)" ]; then \ + $(NO_TRACE_MAKE) -C target/linux/feeds/$(BOARD)/image install TARGET_BUILD=1 IB=1 EXTRA_IMAGE_NAME="$(EXTRA_IMAGE_NAME)" \ + $(if $(USER_PROFILE),PROFILE="$(USER_PROFILE)"); \ + else \ + $(NO_TRACE_MAKE) -C target/linux/$(BOARD)/image install TARGET_BUILD=1 IB=1 EXTRA_IMAGE_NAME="$(EXTRA_IMAGE_NAME)" \ + $(if $(USER_PROFILE),PROFILE="$(USER_PROFILE)"); \ + fi $(BIN_DIR)/profiles.json: FORCE $(if $(CONFIG_JSON_OVERVIEW_IMAGE_INFO), \ -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: firewall4: loopback device is ACCEPTED before include chain-prepend input
Hello Jo, Can you whip up a patch for that? Don't forget to do the same for `output` as well. A friedly ping about this topic, maybe you have over looked my patch [1]? Best regards Florian [1] https://patchwork.ozlabs.org/project/openwrt/patch/20230907070406.8665-1...@dev.tdt.de/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: replace SourceName with PKG_NAME compile unit name
Currently, the same information is stored at the Packages.manifest in the 'Package:' variable and also additionally in the 'SourceName:' variable. So we have for Packages.manifest for strongswan-charon-cmd: ``` Package: strongswan-charon-cmd Version: 5.9.11-1 SourceName: strongswan-charon-cmd License: GPL-2.0-or-later Section: net ``` This is not correct. Several installable packages are built from the same strongswan source. Therefore it makes more sense that the source name is really the source name. In this case the it is 'strongswan'. After this change the Packages.manifest for strongswan-charon-cmd: ``` Package: strongswan-charon-cmd Version: 5.9.11-1 SourceName: strongswan License: GPL-2.0-or-later Section: net ``` In summary. The 'Package' name is the name of the package to be installed on the target system. The 'SourceName' is the compile unit from which the package was build from. This must be the same for all installable packages built from the same compile unit. This commit fixes that. Signed-off-by: Florian Eckert --- include/package-ipkg.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk index aeb9ed746a..f4cbe59246 100644 --- a/include/package-ipkg.mk +++ b/include/package-ipkg.mk @@ -225,7 +225,7 @@ $$(call addfield,Depends,$$(Package/$(1)/DEPENDS) )$$(call addfield,Provides,$$(call mergelist,$$(filter-out $(1)$$(ABIV_$(1)),$(PROVIDES)$$(if $$(ABIV_$(1)), $(1) $(foreach provide,$(PROVIDES),$(provide)$$(ABIV_$(1)) )$$(call addfield,Alternatives,$$(call mergelist,$(ALTERNATIVES)) )$$(call addfield,Source,$(SOURCE) -)$$(call addfield,SourceName,$(1) +)$$(call addfield,SourceName,$(PKG_NAME) )$$(call addfield,License,$(LICENSE) )$$(call addfield,LicenseFiles,$(LICENSE_FILES) )$$(call addfield,Section,$(SECTION) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: replace SourceName with PKG_NAME compile unit name
Currently, the same information is stored at the Packages.manifest in the 'Package:' variable and also additionally in the 'SourceName:' variable. So we have for Packages.manifest for strongswan-charon-cmd: ``` Package: strongswan-charon-cmd Version: 5.9.11-1 SourceName: strongswan-charon-cmd License: GPL-2.0-or-later Section: net ``` This is not correct. Several installable packages are built from the same strongswan source. Therefore it makes more sense that the source name is really the source name. In this case the it is 'strongswan'. After this change the Packages.manifest for strongswan-charon-cmd: ``` Package: strongswan-charon-cmd Version: 5.9.11-1 SourceName: strongswan License: GPL-2.0-or-later Section: net ``` In summary. The 'Package' name is the name of the package to be installed on the target system. The 'SourceName' is the compile unit from which the package was build from. This must be the same for all installable packages built from the same compile unit. This commit fixes that. Signed-off-by: Florian Eckert --- include/package-ipkg.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk index aeb9ed746a..f4cbe59246 100644 --- a/include/package-ipkg.mk +++ b/include/package-ipkg.mk @@ -225,7 +225,7 @@ $$(call addfield,Depends,$$(Package/$(1)/DEPENDS) )$$(call addfield,Provides,$$(call mergelist,$$(filter-out $(1)$$(ABIV_$(1)),$(PROVIDES)$$(if $$(ABIV_$(1)), $(1) $(foreach provide,$(PROVIDES),$(provide)$$(ABIV_$(1)) )$$(call addfield,Alternatives,$$(call mergelist,$(ALTERNATIVES)) )$$(call addfield,Source,$(SOURCE) -)$$(call addfield,SourceName,$(1) +)$$(call addfield,SourceName,$(PKG_NAME) )$$(call addfield,License,$(LICENSE) )$$(call addfield,LicenseFiles,$(LICENSE_FILES) )$$(call addfield,Section,$(SECTION) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firewall4: ruleset: also evaluate the custom includes for the loopback interface
Before this change, the user defined include rules in the output and input
chain were not evaluated for the leepback interface. Traffic related to
the loopback interface was always accepted.
To ensure that the custom rules also apply to the loopback interface,
this commit moves the custom rule for the input and output chain before
the accept rule of the loopback interface.
User defined rules for the input and output chain are now always
evaluated for the entire traffic.
Signed-off-by: Florian Eckert
---
root/usr/share/firewall4/templates/ruleset.uc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/root/usr/share/firewall4/templates/ruleset.uc
b/root/usr/share/firewall4/templates/ruleset.uc
index 7bd9309..639795e 100644
--- a/root/usr/share/firewall4/templates/ruleset.uc
+++ b/root/usr/share/firewall4/templates/ruleset.uc
@@ -97,9 +97,9 @@ table inet fw4 {
chain input {
type filter hook input priority filter; policy {{
fw4.input_policy(true) }};
+{% fw4.includes('chain-prepend', 'input') %}
iifname "lo" accept comment "!fw4: Accept traffic from loopback"
-{% fw4.includes('chain-prepend', 'input') %}
ct state established,related accept comment "!fw4: Allow
inbound established and related flows"
{% if (fw4.default_option("drop_invalid")): %}
ct state invalid drop comment "!fw4: Drop flows with invalid
conntrack state"
@@ -145,9 +145,9 @@ table inet fw4 {
chain output {
type filter hook output priority filter; policy {{
fw4.output_policy(true) }};
+{% fw4.includes('chain-prepend', 'output') %}
oifname "lo" accept comment "!fw4: Accept traffic towards
loopback"
-{% fw4.includes('chain-prepend', 'output') %}
ct state established,related accept comment "!fw4: Allow
outbound established and related flows"
{% if (fw4.default_option("drop_invalid")): %}
ct state invalid drop comment "!fw4: Drop flows with invalid
conntrack state"
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
firewall4: loopback device is ACCEPTED before include chain-prepend input
Hello, I have a use case, where I want to add rules via the firewall include feature, because this could not be modulated via the fw4 feature set. That could be done, if we add the rules into the directory `usr/share/nftables.d/chain-pre/input/` [1], because I need this rules in the input change. This rules get loaded via fw4 and where added correctly. If I look closer into the code, then I see that packages that are for the loopback interface always get accepted before the include rules gets checked [2]. But I need also this custom rule check via the include feature of the fw4 for the loopback interface. Is there a reason why this decision was made, to add the custom include after the loopback interface? Or could we move the include before the loopback check? Best regards Florian [1] https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/usr/share/firewall4/templates/ruleset.uc;h=7bd930937600f67488c4543cd1bfb6493e23b018;hb=HEAD#l102 [2] https://git.openwrt.org/?p=project/firewall4.git;a=blob;f=root/usr/share/firewall4/templates/ruleset.uc;h=7bd930937600f67488c4543cd1bfb6493e23b018;hb=HEAD#l100 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: replace SourceName with PKG_NAME
Currently, the same information is stored in the Packages.manifest in the 'Package:' variable and also additionally in the 'SourceName:' variable. Packages.manifest for strongswan-charon-cmd (before): Package: strongswan-charon-cmd Version: 5.9.11-1 ... SourceName: strongswan-charon-cmd License: GPL-2.0-or-later Section: net This is not correct. Several install packages are built from the strongswan source. Therefore it makes more sense that the source name is really the source name. In this case it is 'strongswan' $PKG_NAME. Packages.manifest for strongswan-charon-cmd (after): Package: strongswan-charon-cmd Version: 5.9.11-1 ... SourceName: strongswan License: GPL-2.0-or-later Section: net Signed-off-by: Florian Eckert --- include/package-ipkg.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk index 3063a86a28..afa2b81eb9 100644 --- a/include/package-ipkg.mk +++ b/include/package-ipkg.mk @@ -179,7 +179,7 @@ $$(call addfield,Depends,$$(Package/$(1)/DEPENDS) )$$(call addfield,Provides,$$(call mergelist,$$(filter-out $(1)$$(ABIV_$(1)),$(PROVIDES)$$(if $$(ABIV_$(1)), $(1) $(foreach provide,$(PROVIDES),$(provide)$$(ABIV_$(1)) )$$(call addfield,Alternatives,$$(call mergelist,$(ALTERNATIVES)) )$$(call addfield,Source,$(SOURCE) -)$$(call addfield,SourceName,$(1) +)$$(call addfield,SourceName,$(PKG_NAME) )$$(call addfield,License,$(LICENSE) )$$(call addfield,LicenseFiles,$(LICENSE_FILES) )$$(call addfield,Section,$(SECTION) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: replace SourceName with PKG_NAME
Currently, the same information is stored in the Packages.manifest in the 'Package:' variable and also additionally in the 'SourceName:' variable. Packages.manifest for strongswan-charon-cmd (before): Package: strongswan-charon-cmd Version: 5.9.11-1 ... SourceName: strongswan-charon-cmd License: GPL-2.0-or-later Section: net This is not correct. Several install packages are built from the strongswan source. Therefore it makes more sense that the source name is really the source name. In this case it is 'strongswan' $PKG_NAME. Packages.manifest for strongswan-charon-cmd (after): Package: strongswan-charon-cmd Version: 5.9.11-1 ... SourceName: strongswan License: GPL-2.0-or-later Section: net Signed-off-by: Florian Eckert --- include/package-ipkg.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk index 0613fb8521eef324e06db338c78a82870079ffba..e3673bc27feb3b609a59c1a5168e78164e50dcb3 100644 --- a/include/package-ipkg.mk +++ b/include/package-ipkg.mk @@ -179,7 +179,7 @@ $$(call addfield,Depends,$$(Package/$(1)/DEPENDS) )$$(call addfield,Provides,$$(call mergelist,$$(filter-out $(1)$$(ABIV_$(1)),$(PROVIDES)$$(if $$(ABIV_$(1)), $(1) $(foreach provide,$(PROVIDES),$(provide)$$(ABIV_$(1)) )$$(call addfield,Alternatives,$$(call mergelist,$(ALTERNATIVES)) )$$(call addfield,Source,$(SOURCE) -)$$(call addfield,SourceName,$(1) +)$$(call addfield,SourceName,$(PKG_NAME) )$$(call addfield,License,$(LICENSE) )$$(call addfield,LicenseFiles,$(LICENSE_FILES) )$$(call addfield,Section,$(SECTION) -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] system-notification: initial checkin
Hello Enrico, Thanks for your feedback! I think the idea can be nice, however I would like to make sure that thismechanism can be ignored by an admin with no consequences. This is only informative. I see this especially in connection with the LuCI. So that events that happens on the system can be displayed. I already have a small app for this [1]. Is this the case? In other words - if I store 20 messages with maximum allowed amount of text in all strings, how much data am I storing? There is currently only the restriction that the number of messages is limited to 20. This can be reduced or increased. I can't say how much memory this takes up. I haven't thought about that yet. We can also limit this, so that the message may only have a certain length Furthermore, I suggest calling both the rpcd plugin and the user-facing script with the same name. That is indirectly the case. The script is called 'system-notification' and the ubus backend is called 'system.notification'. I didn't want to call it only 'notification' now, because it might already be taken. The name 'notification' is very common. And - di I miss it or you can not actually create a notification from the user-facing script? Why not implement that as well? I have deliberately not implemented this, because I am not sure how to do it, as the message can become relatively long. The creation of the notification will probably be the system via a bus call. -- Florian Eckert [1] https://github.com/TDT-AG/luci/commit/aa4b0425206448f1336dc7a94fe31c4cc089a0c9 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] system-notification: initial checkin
This package provides a ubus backend that can be used to save system
notification. The notifications are not persistent. They are lost after
every reboot.
The following ubus methods are available:
add:
The command adds a notification to the ubus backend.
ubus call system.notification add
'{"title":"","description":""}'
In addition, the following json string could be optional set.
* url: {"url": ""} Additional information are available at this
extrenal URL.
* opkg: {"package": ""} Package can be updated.
remove:
The command removes a notification from the ubus backend.
ubus call system.notification remove '{"uuid": ""}'
list:
The command dumps all staged notification from the ubus backend.
ubus call system.notification list
flush:
The command removes all stage notification from the ubus backend.
ubus call system.notification flush
Signed-off-by: Florian Eckert
---
package/utils/system-notification/Makefile| 81 +++
.../files/usr/bin/system-notification | 105 +
.../usr/libexec/rpcd/system.notification | 220 ++
3 files changed, 406 insertions(+)
create mode 100644 package/utils/system-notification/Makefile
create mode 100644
package/utils/system-notification/files/usr/bin/system-notification
create mode 100644
package/utils/system-notification/files/usr/libexec/rpcd/system.notification
diff --git a/package/utils/system-notification/Makefile
b/package/utils/system-notification/Makefile
new file mode 100644
index 00..8dcbc190e6
--- /dev/null
+++ b/package/utils/system-notification/Makefile
@@ -0,0 +1,81 @@
+#
+# Copyright (C) 2021 TDT AG
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See https://www.gnu.org/licenses/gpl-2.0.txt for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=system-notification
+PKG_VERSION:=0.1
+PKG_RELEASE:=1
+
+PKG_MAINTAINER:=Florian Eckert
+PKG_LICENSE:=GPL-2.0
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/system-notification
+ SECTION:=base
+ CATEGORY:=Base system
+ TITLE:=System notification
+endef
+
+define Package/system-notification/description
+ This package provides a ubus backend that can be used to save system
+ notification. The notifications are not persistent. They are lost after
+ every reboot.
+
+ The following ubus methods are available:
+
+ add:
+ The command adds a notification to the ubus backend.
+ ubus call system.notification add
'{"title":"","description":""}'
+ In addition, the following json string could be optional set.
+ * url: {"url": ""} Additional information are available at this
extrenal URL.
+ * opkg: {"package": ""} Package can be updated.
+
+ remove:
+ The command removes a notification from the ubus backend.
+ ubus call system.notification remove '{"uuid": ""}'
+
+ list:
+ The command dumps all staged notification from the ubus backend.
+ ubus call system.notification list
+
+ flush:
+ The command removes all stage notification from the ubus backend.
+ ubus call system.notification flush
+endef
+
+define Build/Compile
+endef
+
+define Package/system-notification/postinst
+#!/bin/sh
+if [ -z "$${IPKG_INSTROOT}" ] && [ -x /etc/init.d/rpcd ]; then
+ /etc/init.d/rpcd restart
+fi
+exit 0
+endef
+
+define Package/system-notification/postrm
+#!/bin/sh
+if [ -z "$${IPKG_INSTROOT}" ] && [ -x /etc/init.d/rpcd ]; then
+ /etc/init.d/rpcd restart
+fi
+exit 0
+endef
+
+define Package/system-notification/install
+ $(INSTALL_DIR) $(1)/usr/bin
+ $(INSTALL_BIN) ./files/usr/bin/system-notification \
+ $(1)/usr/bin/system-notification
+
+ $(INSTALL_DIR) $(1)/usr/libexec/rpcd
+ $(INSTALL_BIN) ./files/usr/libexec/rpcd/system.notification \
+ $(1)/usr/libexec/rpcd/
+endef
+
+$(eval $(call BuildPackage,system-notification))
diff --git
a/package/utils/system-notification/files/usr/bin/system-notification
b/package/utils/system-notification/files/usr/bin/system-notification
new file mode 100644
index 00..7a60985eaf
--- /dev/null
+++ b/package/utils/system-notification/files/usr/bin/system-notification
@@ -0,0 +1,105 @@
+#!/bin/sh
+# Copyright (C) 2021 TDT AG
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See https://www.gnu.org/licenses/gpl-2.0.txt for more information.
+#
+
+. /usr/share/libubox/jshn.sh
+
+remove() {
+ local uuid="$1"
+
+ json_init
+ json_add_string "uuid" "$uuid"
+ ubus call system.notification remove "$(json_dump)"
+ json_cleanup
+}
+
+list() {
+ local title description uuid timestamp
+
+ json_init
+ json_load "$(ubus call system.notification list)"
+
[PATCH] .gitignore: ignore link if target is included from feed
If an out of tree target is included via a feed, then there is a link with the name 'feed' in the target directory. Do not show this link in git. Signed-off-by: Florian Eckert --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index a80cdbbea3..84cfc99770 100644 --- a/.gitignore +++ b/.gitignore @@ -14,6 +14,7 @@ /feeds /feeds.conf /files +/target/linux/feeds /overlay /package/feeds /package/openwrt-packages -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] target.mk: silence CPU_TYPE doesn't correspond to a known type
Hello Petr On 2023-06-15 16:11, Petr Štetiar wrote: Following command: $ ./scripts/dump-target-info.pl targets currently generates bunch of following warnings: include/target.mk:269: CPU_TYPE "cortex-a15" doesn't correspond to a known type I've noticed that too. Could you please explain why does this happen? And why do we suppress the message now? I would expect to add the missing CPU_TYPS and not suppress the warning. --- Best regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mwan3 memory usage
Hello, Hi, We have enabled mwan3 (version 2.11.4) functionality with OpenWRT version 22.03 and we see that four mwan3rtmon processes are running, two each for IPv4 and IPv6. We made the change with the following commit: https://github.com/openwrt/packages/commit/566293d228a48d21a04ecbc815a7ae97e26eb319 I'm not sure, but I think we had before also two mwan3rtmon process one for ipv4 and the other for ipv6 so there is no difference. But during the change we switched to procd to control the rtmon services. Whereas with mwan3 (version 2.8.16) that came with OpenWRT version 19.07, has only one process for mwan3rtmon running for both IPv4 and IPv6. Sure? Or did only use the proto ipv4. This has caused an increased memory usage on OpenWRT version 22.03 by 3 times when compared to OpenWRT version 19.07. This is a huge concern for us as we have limited memory on our router product. Because of the fact, that mwan3 is written in shell I would not recommend to use this on small devices. On debugging further, we see that mwan3rtmon script is invoking a child process, the reason behind observing two processes per each IP type. Refer(line number 155) at https://github.com/openwrt/packages/blob/master/net/mwan3/files/usr/sbin/mwan3rtmon Can we know the reason behind creating child processes? Before that we polled for changes in the routing table. Now we use a event driven patter to update the routing table on routing changes. Because of this we need a subshell to get the events. To reduce memory usage, if we disable creation of child process, what functionality of mwan3 will be affected? This is not recommended. However, you can use the old mwan3rtmon for an older version to poll for changes. So you do not have a subshell for event handling. Also, is it recommended to use mwan3 (version 2.8.16) with OpenWRT version 22.03 as this has no child processes and only one mwan3rtmon process for both IPv4 and IPv6? I can't say anything about that because I haven't tried it yet. --- Kind regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH procd] ubus: add state measurement
Hello Oldrich,
+
+void procd_state_event(struct blob_buf *b)
+{
+ void *c, *s;
+ struct timespec *ts_start;
+ struct timespec *ts_stop;
+ struct timespec ts_active;
+ struct timespec ts_res;
+ double duration;
+
+ c = blobmsg_open_table(b, "state");
+
+ for (int i = 0; i < __STATE_MAX - 1; i++)
+ {
+ ts_start = _event[i].ts_event;
+ ts_stop = _event[i+1].ts_event;
Hi, this looks like out-of-bounds access for the last iteration.
I would say, this is ok, because the loop
'for (int i = 0; i < __STATE_MAX - 1; i++)' does 'i < __STATE_MAX - 1'
and so the STATE_HALT would never hit but could use the memory to read
ts_stop with 'ts_stop = _event[i+1].ts_event;'
Best regards
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH procd] ubus: add state measurement
Hello Christian I wonder if this kind of thing should be under a config flag? I do not see under system, with the command 'ubus -v list system' a section 'config'. I do not wanted to add a new section, so I decided to implement it under 'info' because this are runtime information as 'load', 'memory' ... Like I feel these kind of stats may be needed only for debug purpose? I do not use it only for debug purpose, but also for tracking changes on boot when enabling new services in production. I also use this for some function on my system to check if we have finished booting completly. These are just ideas, if your idea is to use these data for other purpose than checking process boot time and investigate some regression then it's totally fine to have this present by default. If it doesn't matter from your point of view whether we leave it there or move it somewhere else, then I plead that we leave it as it is. Otherwise, as already mentioned above, we would have to introduce a new function section under 'system', because all other sections unter 'system' have nothing to do with it. Best regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireguard: fix reload config on peer change
On 2023-03-14 16:17, Rafał Miłecki wrote: On 14.03.2023 16:12, Florian Eckert wrote: Hello Rafał, corresponding interface. The wireguard configuration is rewritten and reconfigured by the netif proto handler. Signed-off-by: Florian Eckert What has happened to this patch? It's marked as Superseded but I didn't see V2 or anything. It seems to be dealing with issue that WG users complain about, see: https://forum.openwrt.org/t/wiregurad-does-not-reload-wireguard-iface-section-on-change/47137 https://forum.openwrt.org/t/restart-wireguard-via-cli/51935 https://forum.openwrt.org/t/restart-wireguard-interface/58037 I think I set the patchset to supperseed and tried it via github [1]. But nobody wanted it there either. I have this patchset in my own openwrt build, which was rejected from upstream. And it is working as expected. --- Best regards Florian [1] https://github.com/openwrt/openwrt/pull/2625 I'm sorry to see how it ended up mishandled. Thanks for this GitHub link. No problem, that's just how business works. I was probably the only one with this problem at the time. Maybe it will go upstream now. Do you need support? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireguard: fix reload config on peer change
Hello Rafał, corresponding interface. The wireguard configuration is rewritten and reconfigured by the netif proto handler. Signed-off-by: Florian Eckert What has happened to this patch? It's marked as Superseded but I didn't see V2 or anything. It seems to be dealing with issue that WG users complain about, see: https://forum.openwrt.org/t/wiregurad-does-not-reload-wireguard-iface-section-on-change/47137 https://forum.openwrt.org/t/restart-wireguard-via-cli/51935 https://forum.openwrt.org/t/restart-wireguard-interface/58037 I think I set the patchset to supperseed and tried it via github [1]. But nobody wanted it there either. I have this patchset in my own openwrt build, which was rejected from upstream. And it is working as expected. --- Best regards Florian [1] https://github.com/openwrt/openwrt/pull/2625 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
On 2023-01-20 12:49, Felix Fietkau wrote: On 20.01.23 12:42, Florian Eckert wrote: Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. Thanks. I don't have a strong opinion one way or the other, but I think the code might be more readable without the explicit $(STAGING_DIR_HOST)/bin prefix. Your right It works regardless of whether the prefix is there or not. But I would just like to note that it is easier to see whether the tools are now used from staging or the build host. The tool mkisofs https://github.com/openwrt/openwrt/blob/master/target/linux/x86/image/Makefile#L100, for example, is used from the build host! There is indeed a guard here https://github.com/openwrt/openwrt/blob/master/target/linux/x86/Makefile. But I am not sure if this is the case everywhere and if it is clear to everyone which tool is now being used during development. I just wanted to say that I am more in favor of explicitly select which tool is now being used. - Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
Hello Felix, During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Why is this necessary? $STAGING_DIR_HOST/bin should already be in $PATH before the host system parts. I only noticed that the prefix $(STAGING_DIR_HOST) is missing for these tools on x86_64 image Makefile. If I look for this prefix in OpenWrt, it is found in some image Makefiles commands. For examples: - https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile - https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile If this is in the PATH through this line https://github.com/openwrt/openwrt/blob/master/Makefile, then this is not needed for the others? I only wanted to unify this with the change and make it clear that the tool from staging is used here. - Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir
During image generation, the host tools should not be used but the tools from the staging_dir. - mkfs.fat - sed - mmd - mcopy Signed-off-by: Florian Eckert --- target/linux/x86/image/Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile index 322131c2a4..66d914681d 100644 --- a/target/linux/x86/image/Makefile +++ b/target/linux/x86/image/Makefile @@ -59,7 +59,7 @@ endef define Build/grub-config rm -fR $@.boot $(INSTALL_DIR) $@.boot/boot/grub - sed \ + $(STAGING_DIR_HOST)/bin/sed \ -e 's#@SERIAL_CONFIG@#$(strip $(GRUB_SERIAL_CONFIG))#g' \ -e 's#@TERMINAL_CONFIG@#$(strip $(GRUB_TERMINAL_CONFIG))#g' \ -e 's#@ROOTPART@#root=$(ROOTPART) rootwait#g' \ @@ -91,9 +91,12 @@ define Build/iso > $@.boot/boot/grub/eltorito.img -$(CP) $(STAGING_DIR_ROOT)/boot/. $@.boot/boot/ $(if $(filter $(1),efi), - mkfs.fat -C $@.boot/boot/grub/isoboot.img -S 512 1440 - mmd -i $@.boot/boot/grub/isoboot.img ::/efi ::/efi/boot - mcopy -i $@.boot/boot/grub/isoboot.img \ + $(STAGING_DIR_HOST)/bin/mkfs.fat \ + -C $@.boot/boot/grub/isoboot.img -S 512 1440 + $(STAGING_DIR_HOST)/bin/mmd \ + -i $@.boot/boot/grub/isoboot.img ::/efi ::/efi/boot + $(STAGING_DIR_HOST)/bin/mcopy \ + -i $@.boot/boot/grub/isoboot.img \ $(STAGING_DIR_IMAGE)/grub2/iso-boot$(if $(CONFIG_x86_64),x64,ia32).efi \ ::/efi/boot/boot$(if $(CONFIG_x86_64),x64,ia32).efi ) -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: Add initrd generation to load SSDT tables via ACPI
Hi Florian. What is it you're asking for from me? I have seen that you also have a APUx board. So I thought you may also have the need to add an ACPI SSDT during boot via an initrd to use additional I2C devives via SMB bus. Does apica-unix need to be bumped? I already did this https://github.com/openwrt/packages/pull/20256 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel/x86: fix type
Fix typo for KernelPackage w83627hf-wdt. Signed-off-by: Florian Eckert --- target/linux/x86/modules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/x86/modules.mk b/target/linux/x86/modules.mk index 3173cf9e84..e0c3b4174f 100644 --- a/target/linux/x86/modules.mk +++ b/target/linux/x86/modules.mk @@ -184,7 +184,7 @@ define KernelPackage/w83627hf-wdt DEPENDS:=@TARGET_x86 KCONFIG:=\ CONFIG_W83627HF_WDT \ - ONFIG_WATCHDOG_CORE=y + CONFIG_WATCHDOG_CORE=y FILES:=$(LINUX_DIR)/drivers/watchdog/w83627hf_wdt.ko AUTOLOAD:=$(call AutoLoad,50,w83627hf-wdt,1) endef -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RFC: Add initrd generation to load SSDT tables via ACPI
Hello, I have an APU3. This has an I2C bus (SMBUS) to which additional devices can be connected. On my APU3 board, an IO expander mcp23s08 [1] is connected there. This IO expander provides additional GPIOs. This additional GPIOs are connected to LEDs. The whole thing worked until kernel version 5.4 of OpenWrt. But after updating to OpenWrt kernel version 5.10 (openwrt-22.03). I have made the additional LEDs known to the system via a platform driver, which then integrates these LEDs. The support for reading out the platform driver data for the driver mcp23s08 has been removed in the kernel with the commit [2]. I was unable to compile my platform device driver against kernel 5.10, because of the removed platform data support of the mcp23s08. I contacted the kernel developer Andy Shevchenko [3] who made this change. His suggestion was, that the data should be made known to the system via an additional SSDT table via ACPI [4]. Then everything should work like a system that supports device-tree. I have now played around with SSDT a bit and finally managed to get the driver responsible again for this device. I had to create a new SSDT file and compile it with a program from the acpica-unix package [5]. The file must be moved into an initrd, so this could be read by the kernel during boot. Now to my question: In order to load this new SSDT file, it must be made available to the kernel via an initrd. However, initrd handling is currently not supported by OpenWrt. Manually, it is no problem for me to load the GRUB initrd. But I would like to have a solution that is generally valid in OpenWrt during image generation. I have already prepared a pullrequest for openwrt [6] on my fork with the changes that are needed. But I am not sure if this is the right solution. Additional the acpica-unix package from the package feed [7] must also be build for the host, to compile the acpi asl source file into acpi aml files. Kind regards Florian [1] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/Kconfig#L305 [2] https://github.com/torvalds/linux/commit/6aba6ed879b3471903c8ada28ba968a268df6143 [3] https://github.com/andy-shev [4] https://lore.kernel.org/all/290741faab199d3e43b6255bf2282...@dev.tdt.de/ [5] https://www.acpica.org/documentation [6] https://github.com/TDT-AG/openwrt/tree/pr/20230110-config-kernel [7] https://github.com/openwrt/packages/blob/master/utils/acpica-unix/Makefile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] netifd: add debug options to uci
To simplify netifd development, the logging and debugging options should
be configured via uci, so we could set this also during boot.
New uci config options in '/etc/config/network':
config globals 'globals'
option mask '1'
option level '3'
The following options are available for the individual uci options and are
given when the service is started.
Option 'mask':
This option specifies which messages are output on the stderr.
* SYSTEM = 0
* DEVICE = 1
* INTERFACE = 2
* WIRELESS = 3
In order for the log messages to also appear in the syslog, the output
of the stderr must be redirected by the netifd.
Option 'level':
* L_CRIT = 0
* L_WARNING = 1
* L_NOTICE = 2
* L_INFO = 3
* L_DEBUG = 4
With this option the loglevel of the netifd can be changed. If nothing
is specified, the level is set to 'notice'.
Signed-off-by: Florian Eckert
---
.../network/config/netifd/files/etc/init.d/network| 11 +++
1 file changed, 11 insertions(+)
diff --git a/package/network/config/netifd/files/etc/init.d/network
b/package/network/config/netifd/files/etc/init.d/network
index dc208c4ce0..ffdf470e10 100755
--- a/package/network/config/netifd/files/etc/init.d/network
+++ b/package/network/config/netifd/files/etc/init.d/network
@@ -15,8 +15,19 @@ init_switch() {
start_service() {
init_switch
+ local mask level debug
+
+ config_load network
+ config_get level "globals" level
+ config_get mask "globals" mask
+
procd_open_instance
procd_set_param command /sbin/netifd
+ [ -z "${level}" ] || procd_append_param command -l "$level"
+ [ -z "${mask}" ] || {
+ procd_append_param command -d "$mask"
+ procd_set_param stderr 1
+ }
procd_set_param respawn
procd_set_param watch network.interface
[ -e /proc/sys/kernel/core_pattern ] && {
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] procd: add procd_unlock wrapper
Extend the procd shell wrapper lib with the missing funktion procd_unlock.
This could be used in scripts to unlock a previously locked section.
Signed-off-by: Florian Eckert
---
package/system/procd/files/procd.sh | 4
1 file changed, 4 insertions(+)
diff --git a/package/system/procd/files/procd.sh
b/package/system/procd/files/procd.sh
index e41117fb2c..c8e5fd0325 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -59,6 +59,10 @@ procd_lock() {
fi
}
+procd_unlock() {
+ flock -u 1000
+}
+
_procd_call() {
local old_cb
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH procd] ubus: add state measurement
Procd has different states during booting. When the system is
booted, it is in the 'running' state. This state is only exited when the
system is shut down cleanly. This state is called 'shutdown'. To find out
what state the system is in and how long it will take to complete this,
the commit adds a new section 'state' to the ubus call system info. There
you can read which state the procd is in and how long it has been in
this state or how long it has been running in the state.
command:
ubus call system info
output:
{
"localtime": 1666795909,
"state": {
"load": {
"active": false,
"duration": 42.667914
},
"early": {
"active": false,
"duration": 1.107519
},
"ubus": {
"active": false,
"duration": 0.536634
},
"init": {
"active": false,
"duration": 123.176279
},
"running": {
"active": true,
"duration": 226.491805
},
"shutdown": {
"active": false,
"duration": 0.00
}
},
Signed-off-by: Florian Eckert
---
This is a followup of pullrequest with the proposed changes.
https://github.com/openwrt/openwrt/pull/10937
procd.h | 2 ++
state.c | 82
system.c | 2 ++
3 files changed, 86 insertions(+)
diff --git a/procd.h b/procd.h
index fd29a12..3299b41 100644
--- a/procd.h
+++ b/procd.h
@@ -15,6 +15,7 @@
#ifndef __PROCD_H
#define __PROCD_H
+#include
#include
#include
#include
@@ -36,6 +37,7 @@ void ubus_init_system(struct ubus_context *ctx);
void procd_state_next(void);
void procd_state_ubus_connect(void);
+void procd_state_event(struct blob_buf *b);
void procd_shutdown(int event);
void procd_early(void);
void procd_preinit(void);
diff --git a/state.c b/state.c
index fb81248..acbcece 100644
--- a/state.c
+++ b/state.c
@@ -13,6 +13,7 @@
*/
#include
+#include
#include
#include
#include
@@ -20,6 +21,7 @@
#include
#include
#include
+#include
#include "container.h"
#include "procd.h"
@@ -43,6 +45,22 @@ enum {
static int state = STATE_NONE;
static int reboot_event;
+struct state_event {
+ struct timespec ts_event;
+ bool active;
+ const char *name;
+};
+
+static struct state_event s_event[__STATE_MAX] = {
+ [STATE_NONE] = {{0, 0}, true, "load" },
+ [STATE_EARLY] = {{0, 0}, false, "early" },
+ [STATE_UBUS] = {{0, 0}, false, "ubus" },
+ [STATE_INIT] = {{0, 0}, false, "init" },
+ [STATE_RUNNING] = {{0, 0}, false, "running" },
+ [STATE_SHUTDOWN] = {{0, 0}, false, "shutdown" },
+ [STATE_HALT] = {{0, 0}, false, "halt" },
+};
+
static void set_stdio(const char* tty)
{
if (chdir("/dev") ||
@@ -123,11 +141,23 @@ static void perform_halt()
sleep(1);
}
+static void update_state_event(void)
+{
+ // set previous state inactive
+ s_event[state-1].active = false;
+
+ s_event[state].active = true;
+ clock_gettime(CLOCK_BOOTTIME, _event[state].ts_event);
+}
+
static void state_enter(void)
{
char ubus_cmd[] = "/sbin/ubusd";
struct passwd *p;
+ if (state > STATE_NONE && state < __STATE_MAX)
+ update_state_event();
+
switch (state) {
case STATE_EARLY:
LOG("- early -\n");
@@ -228,3 +258,55 @@ void procd_shutdown(int event)
state = STATE_SHUTDOWN;
state_enter();
}
+
+void procd_state_event(struct blob_buf *b)
+{
+ void *c, *s;
+ struct timespec *ts_start;
+ struct timespec *ts_stop;
+ struct timespec ts_active;
+ struct timespec ts_res;
+ double duration;
+
+ c = blobmsg_open_table(b, "state");
+
+ for (int i = 0; i < __STATE_MAX - 1; i++)
+ {
+ ts_start = _event[i].ts_event;
+ ts_stop = _event[i+1].ts_event;
+
+ if (ts_stop->tv_sec > 0) {
+ ts_res.tv_sec = ts_stop->tv_sec - ts_start->tv_sec;
+ ts_res.tv_nsec = ts_stop->tv_nsec - ts_start->tv_nsec;
+ }
+ else if (s_event[i].active) {
+ clock_gettime(CLOCK_BOOTTIME, _active);
+ ts_res.tv_sec = ts_active.tv_sec - ts_start-&
Re: [PATCH firewall4] fw4: add support for include.d dir
Hi, Sorry for the late reply instead of introducing uci includes that configure nft includes, why not encode the chain/position etc. values directly into the path/filename and directly include the file if it exists at the expected location? I was just wondering why not use the new feature you added to give other packages the ability to add rules to fw4. The include feature was exactly what was missing for fw4 to add the posibility for other package adding firewall rules to fw4(nftables=. I think the above would be a lot more manageable since you'd just have to place partial .nft files which are then folded into the final ruleset on fw4 start/reload. Sorry, but I don't agree with the following reasons. Let me briefly explain why. All files under '/usr/share/firewall4/includes.d' are uci files. I can see all relevant options. I can set in the includes my own path. This is relevant for packages that updates the ruleset on events. If I do not want to be this rules persistent saved I could use a tmp file in the system (strongswan). Also the new include add by you already does have the state file feature. Which is relevant on reloading the ruleset. In addition, it would make the ruleset.uc file confusing if I added the same feature again. Also, I would have to add two sections on include to support temporary rules, which I would not have to store under '/usr/share/firewall4/includes.d/' but under '/tmp/firewall4/includes.d/' for example to support the not persistent feature. We also use the include to add the helpers. Last but not leased, if we now add an other possibility, then I don't think anyone knows where which file adds which rule! From my point of view, it makes sense to use the include function from you with my extension. So I think the include feature is the better and unified solution. Best Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] fstools: add uci fstab section to conffiles for package block-mount
The command 'opkg search /etc/config/fstab' does not return a package name for this config file. In order to know to which package this config file belongs to, a 'conffiles' entry was made for this file to package 'block-mount'. Signed-off-by: Florian Eckert --- package/system/fstools/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile index b97b79e324..8f39112191 100644 --- a/package/system/fstools/Makefile +++ b/package/system/fstools/Makefile @@ -75,6 +75,10 @@ define Package/snapshot-tool DEPENDS:=+libubox +fstools endef +define Package/block-mount/conffiles +/etc/config/fstab +endef + define Package/block-mount SECTION:=base CATEGORY:=Base system -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel/crypto: fix crypto-lib-curve25519 x86_64 build
On 2022-07-21 17:10, Stijn Tintel wrote: On 21/07/2022 15:17, Florian Eckert wrote: The crypto-lib-curve25519 dependency for x86_64 could not be met, because the package for for the architecture x86_64 was not added to crypto-lib-curve package. Also the package arch definition for x86/64 does not exist. It musst be change to x86_64 to get added. Can you please elaborate why this is needed? My x86/64 image contains curve25519_x86_64.ko without this change. Hello Stijn I am currently working on a target for integration in Openwrt (Lightning Mountain). This is a x86_64 architecture with 4 Atoms CPUs. I have added a new target (mxl) and subtarget (lgm) with $(ARCH) x86_64. But If I do it like this, then the module could not be build because, the dependency is not met. "Missing So far it only works now if I set the $(BOARD) value to x86 in the Makefile and I also have to add a $(SUBTARGET) 64 in my directory mxl which in my case does not fit. I also wanted to make it equal to the packages kmod-crypto-lib-poly1305. This package maps this via $(ARCH) and doesn't do any special handling. So I would prefer if we make it dependent on the $(ARCH) variable. Also in the linux kernel this is also under /arch/x86. I think we should also update [1] https://github.com/TDT-AG/openwrt/blob/master/package/kernel/linux/modules/crypto.mk#L464 Best regards Florian [1] https://github.com/TDT-AG/openwrt/blob/master/package/kernel/linux/modules/crypto.mk#L545 Thanks, Stijn [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/kernel.mk;h=001718d89d8b77bf7843c5cba77ef519f808e085;hb=HEAD#l213 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel/crypto: fix crypto-lib-curve25519 x86_64 build
The crypto-lib-curve25519 dependency for x86_64 could not be met, because the package for for the architecture x86_64 was not added to crypto-lib-curve package. Also the package arch definition for x86/64 does not exist. It musst be change to x86_64 to get added. Signed-off-by: Florian Eckert --- package/kernel/linux/modules/crypto.mk | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index ed4e51079e..f31c4d5949 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -526,11 +526,16 @@ define KernelPackage/crypto-lib-curve25519/config imply PACKAGE_kmod-crypto-kpp endef -define KernelPackage/crypto-lib-curve25519/x86/64 +define KernelPackage/crypto-lib-curve25519/x86_64 KCONFIG+=CONFIG_CRYPTO_CURVE25519_X86 FILES+=$(LINUX_DIR)/arch/x86/crypto/curve25519-x86_64.ko endef +ifdef KernelPackage/crypto-lib-curve25519/$(ARCH) + KernelPackage/crypto-lib-curve25519/$(CRYPTO_TARGET)=\ + $(KernelPackage/crypto-lib-curve25519/$(ARCH)) +endif + define KernelPackage/crypto-lib-curve25519/arm-neon KCONFIG+=CONFIG_CRYPTO_CURVE25519_NEON FILES+=$(LINUX_DIR)/arch/arm/crypto/curve25519-neon.ko -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH firewall4] fw4: add support for include.d dir
Creating a uci configuration is cumbersome and unmaintainable if other
packages want to use the new include feature.
If another package wants to use the include feature of fw4, it must copy
the uci configuration options to '/usr/share/firewall4/include.d'. This
include will then be used in fw4 without having to modify the uci config
under '/etc/config/firewall'.
In my case, this is about the firewall rules for the Strongswan. This
feature allows me to have the firewall add the strongswan rules on
reload or startup without having to change the firewall's uci
configuration.
Content of the include file for firewall rules needed by strongswan.
The content of the files are update by the strongswan updown script.
'/usr/share/firewall4/include.d/strongswan':
config include
option path '/tmp/strongswan/nftables.d/pre-input.nft'
option type 'nftables'
option position 'chain-pre'
option chain 'input'
config include
option path '/tmp/strongswan/nftables.d/pre-output.nft'
option type 'nftables'
option position 'chain-pre'
option chain 'output'
config include
option path '/tmp/strongswan/nftables.d/pre-forward.nft'
option type 'nftables'
option position 'chain-pre'
option chain 'forward'includes
Signed-off-by: Florian Eckert
---
root/usr/share/ucode/fw4.uc | 10 ++
1 file changed, 10 insertions(+)
diff --git a/root/usr/share/ucode/fw4.uc b/root/usr/share/ucode/fw4.uc
index 1b4764c..f46caa2 100644
--- a/root/usr/share/ucode/fw4.uc
+++ b/root/usr/share/ucode/fw4.uc
@@ -731,6 +731,16 @@ return {
//
this.cursor.foreach("firewall", "include", i =>
self.parse_include(i));
+ let dir = fs.opendir("/usr/share/firewall4/include.d");
+ if (dir) {
+ let file;
+ while ((file = dir.read()) != null) {
+ if ((file == '.') || (file == '..'))
+ continue;
+
this.cursor.load("/usr/share/firewall4/include.d/" + file);
+ this.cursor.foreach(file, "include", i =>
self.parse_include(i));
+ }
+ }
if (use_statefile) {
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firewall4] ruleset: add missing pre_* chains
Hello Jo-Philipp I found the following summary that describes my problem. See my link [1]. And why me need this pre_* hooks in fw4 as I suggested. I have found the following description about priority and accept. This is the paragraph: Base chain priority: Each nftables base chain is assigned a priority that defines its ordering among other base chains, flowtables, and Netfilter internal operations at the same hook. For example, a chain on the prerouting hook with priority -300 will be placed before connection tracking operations. NOTE: If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn't necessarily final. However, the same is not true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated. From my point of view it makes sense to add my changes in fw4, otherwise it won't work. When I read it like this then your suggestion does not work? Kind regards Florian [1] https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firewall4] ruleset: add missing pre_* chains
Hi,
can't you do the same by dropping a snippet into /etc/nftables.d/ which
simply
registers chain with lower priority hooks? In fact there already is an
example
[1].
Specifically, it's about the firewall rules that the strongswan sets
with the updown plugin on a connection SA up/down.
Currently, the iptables or ip6tables command is used on updown.
By using nft with fw4, iptables-nft or ip6tables-nft is now used
trancperently used.
Currently strongswan updown is broken when using fw4 with
iptables-nft/ip6tables-nft
So I rewrite the updown script to use native nft instead of
iptables-nft/ip6tables-nft.
So in order to achieve what you want, create an
`/etc/nftables.d/10-pre-chains.nft with the following contents:
-- 8< --
chain pre_input {
type filter hook input priority -1; policy accept;
}
chain pre_forward {
type filter hook forward priority -1; policy accept;
}
chain pre_output {
type filter hook output priority -1; policy accept;
}
-- >8 --
I have already seen that and I have also tried it and put my rules for
my task in separate toplevel chains as you suggest.
But this does not work as expected. The packages are recognized by my
new chain with a less priority.
However, they are then discarded by the next chain with a higher
priority of fw4.
Since nftables makes it easy to have many hooks, I doubt that such a
generic,
mostly unused facility is needed at all. If your package/process/use
case
requires staging custom rules before the default ones, drop a partial
into
/etc/nftables.d/ which declares own chains with lower priority hooks
along
with the rules you need.
Rules for strongswan in seperate chains with lower priority (not
working):
chain s_pre_input {
type filter hook input priority filter - 1; policy
accept;
iifname "eth0" meta ipsec exists ipsec in reqid 1 ip
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment
"!strongswan: reqid in 1 input"
}
chain s_pre_forward {
type filter hook forward priority filter - 1; policy
accept;
iifname "eth0" meta ipsec exists ipsec in reqid 1 ip
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment
"!strongswan: reqid in 1 forward"
oifname "eth0" meta ipsec exists ipsec out reqid 1 ip
saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment
"!strongswan: reqid out 1 forward"
}
chain s_pre_output {
type filter hook output priority filter - 1; policy
accept;
oifname "eth0" ipsec out reqid 1 ip saddr
192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment "!strongswan:
reqid out 1 output"
}
chain s_pre_srcnat {
type nat hook postrouting priority srcnat - 1; policy
accept;
ip saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept
comment "!strongswan: reqid none 1 srcnat"
}
Rules for strongswan in a pre chain with a jump (working):
chain pre_input {
iifname "eth0" meta ipsec exists ipsec in reqid 1 ip
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment
"!strongswan: reqid in 1 input"
}
chain input {
type filter hook input priority filter; policy drop;
iifname "lo" accept comment "!fw4: Accept traffic from
loopback"
jump pre_input
ct state established,related accept comment "!fw4: Allow
inbound established and related flows"
tcp flags syn / fin,syn,rst,ack jump syn_flood comment
"!fw4: Rate limit TCP syn packets"
iifname "eth1" jump input_lan comment "!fw4: Handle lan
IPv4/IPv6 input traffic"
iifname "eth0" jump input_wan comment "!fw4: Handle wan
IPv4/IPv6 input traffic"
jump handle_reject
}
chain pre_forward {
iifname "eth0" meta ipsec exists ipsec in reqid 1 ip
saddr 192.168.17.0/24 ip daddr 192.168.99.0/24 accept comment
"!strongswan: reqid in 1 forward"
oifname "eth0" meta ipsec exists ipsec out reqid 1 ip
saddr 192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment
"!strongswan: reqid out 1 forward"
}
chain forward {
type filter hook forward priority filter; policy drop;
jump pre_forward
ct state established,related accept comment "!fw4: Allow
forwarded established and related flows"
iifname "eth1" jump forward_lan comment "!fw4: Handle
lan IPv4/IPv6 forward traffic"
iifname "eth0" jump forward_wan comment "!fw4: Handle
wan IPv4/IPv6 forward traffic"
jump handle_reject
}
chain pre_output {
oifname "eth0" ipsec out reqid 1 ip saddr
192.168.99.0/24 ip daddr 192.168.17.0/24 accept comment "!strongswan:
reqid out 1 output"
}
chain pre_srcnat {
ip saddr
[PATCH firewall4] ruleset: add missing pre_* chains
There is the option to add a user change, but if the rule applies, the
fw4 rules are still processed. This is because these chains are
top-level chains that only have a different priority.
This priority indicates whether they are processed before or after the
fw4 chains.
So that rules can also be processed in the context of the fw4 and are
not passed on to the next toplevel chain in the event of an apply. The
rule must be processed in the context of the fw4 tables. This commit
adds a pre chain for input, output and forward.
Firewall rules, that are not handeled by the fw4 can then be hooked into
this, which are then processed in the context of the fw4 and are thus
allowed through by the fw4 in the event of an accept.
Signed-off-by: Florian Eckert
(cherry picked from commit 596f9f7973560210a8ccf386d7017aaa07ea77d2)
---
root/usr/share/firewall4/templates/ruleset.uc | 15 +++
1 file changed, 15 insertions(+)
diff --git a/root/usr/share/firewall4/templates/ruleset.uc
b/root/usr/share/firewall4/templates/ruleset.uc
index 0142d5a..79401d2 100644
--- a/root/usr/share/firewall4/templates/ruleset.uc
+++ b/root/usr/share/firewall4/templates/ruleset.uc
@@ -67,11 +67,16 @@ table inet fw4 {
# Filter rules
#
+ chain pre_input {
+
+ }
+
chain input {
type filter hook input priority filter; policy {{
fw4.input_policy(true) }};
iifname "lo" accept comment "!fw4: Accept traffic from loopback"
+ jump pre_input
ct state established,related accept comment "!fw4: Allow
inbound established and related flows"
{% if (fw4.default_option("drop_invalid")): %}
ct state invalid drop comment "!fw4: Drop flows with invalid
conntrack state"
@@ -90,9 +95,14 @@ table inet fw4 {
{% endif %}
}
+ chain pre_forward {
+
+ }
+
chain forward {
type filter hook forward priority filter; policy {{
fw4.forward_policy(true) }};
+ jump pre_forward
{% if (length(flowtable_devices) > 0): %}
meta l4proto { tcp, udp } flow offload @ft;
{% endif %}
@@ -111,11 +121,16 @@ table inet fw4 {
{% endif %}
}
+ chain pre_output {
+
+ }
+
chain output {
type filter hook output priority filter; policy {{
fw4.output_policy(true) }};
oifname "lo" accept comment "!fw4: Accept traffic towards
loopback"
+ jump pre_output
ct state established,related accept comment "!fw4: Allow
outbound established and related flows"
{% if (fw4.default_option("drop_invalid")): %}
ct state invalid drop comment "!fw4: Drop flows with invalid
conntrack state"
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] build: add logging output for host build
The output of the build log is very confusing. In order to better
distinguish the individual steps during debugging, this commit writes a
logging mark into the build log.
- *** Calling Host/Configure/Default ()
- *** Calling Host/Compile/Default ()
- *** Calling Host/Install/Default ()
Signed-off-by: Florian Eckert
---
include/host-build.mk | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/host-build.mk b/include/host-build.mk
index 7f76eb1a2f..b31bf93b30 100644
--- a/include/host-build.mk
+++ b/include/host-build.mk
@@ -82,6 +82,7 @@ ifeq ($(HOST_OS),Darwin)
endif
define Host/Configure/Default
+ @echo '*** Calling Host/Configure/Default ($(PKG_NAME)) ***'
$(if $(HOST_CONFIGURE_PARALLEL),+)(cd $(HOST_BUILD_DIR)/$(3); \
if [ -x configure ]; then \
$(CP) $(SCRIPT_DIR)/config.{guess,sub}
$(HOST_BUILD_DIR)/$(3)/ && \
@@ -95,10 +96,11 @@ define Host/Configure/Default
endef
define Host/Configure
- $(call Host/Configure/Default)
+ $(call Host/Configure/Default)
endef
define Host/Compile/Default
+ @echo '*** Calling Host/Compile/Default ($(PKG_NAME)) ***'
+$(HOST_MAKE_VARS) \
$(MAKE) $(HOST_JOBS) -C $(HOST_BUILD_DIR) \
$(HOST_MAKE_FLAGS) \
@@ -106,18 +108,18 @@ define Host/Compile/Default
endef
define Host/Compile
- $(call Host/Compile/Default)
+ $(call Host/Compile/Default)
endef
define Host/Install/Default
+ @echo '*** Calling Host/Install/Default ($(PKG_NAME)) ***'
$(call Host/Compile/Default,install)
endef
define Host/Install
- $(call Host/Install/Default,$(HOST_BUILD_PREFIX))
+ $(call Host/Install/Default)
endef
-
ifneq ($(if $(HOST_QUILT),,$(CONFIG_AUTOREBUILD)),)
define HostHost/Autoclean
$(call rdep,${CURDIR} $(PKG_FILE_DEPENDS),$(HOST_STAMP_PREPARED))
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] build: add Uninstall for host build
Currently there is no possibility for host package to cleanly remove the
installed files in staging.
There is the possibility to call an uninstall make target, but if this
is not implemented, and so nothing happens.
For debugging, it makes sense to know what is being installed. With this
change, the install process is called twice.
Once to create a .host-install file and once to install the package files
into the staging directory. If the tool is removed, the .host-install file
is used to remove all files from the staging dirctories.
This only works for the generic autotools install and uninstall target.
Signed-off-by: Florian Eckert
---
include/host-build.mk | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/include/host-build.mk b/include/host-build.mk
index b31bf93b30..d0f1a3eda5 100644
--- a/include/host-build.mk
+++ b/include/host-build.mk
@@ -113,13 +113,37 @@ endef
define Host/Install/Default
@echo '*** Calling Host/Install/Default ($(PKG_NAME)) ***'
- $(call Host/Compile/Default,install)
+ +$(HOST_MAKE_VARS) \
+ $(MAKE) $(HOST_JOBS) -C $(HOST_BUILD_DIR) \
+ DESTDIR="$(HOST_INSTALL_DIR)" \
+ $(HOST_MAKE_FLAGS) \
+ install
+ cd $(HOST_INSTALL_DIR) && \
+ find . | sed 's|^.||' > $(HOST_BUILD_DIR)/.host-install && \
+ rm -rf $(HOST_INSTALL_DIR)
+ +$(HOST_MAKE_VARS) \
+ $(MAKE) $(HOST_JOBS) -C $(HOST_BUILD_DIR) \
+ $(HOST_MAKE_FLAGS) \
+ install
endef
define Host/Install
$(call Host/Install/Default)
endef
+define Host/Uninstall/Default
+ @echo '*** Calling Host/Uninstall/Default ($(PKG_NAME)) ***'
+ if [ -f "$(HOST_BUILD_DIR)/.host-install" ]; then \
+ $(XARGS) $(RM) < $(HOST_BUILD_DIR)/.host-install; \
+ $(FIND) $(STAGING_DIR_HOST) -type d -empty -print -delete; \
+ $(FIND) $(STAGING_DIR_HOSTPKG) -type d -empty -print -delete; \
+ fi
+endef
+
+define Host/Uninstall
+ $(call Host/Uninstall/Default)
+endef
+
ifneq ($(if $(HOST_QUILT),,$(CONFIG_AUTOREBUILD)),)
define HostHost/Autoclean
$(call rdep,${CURDIR} $(PKG_FILE_DEPENDS),$(HOST_STAMP_PREPARED))
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] mac80211: add ath10k ledtrigger abstraction
This change adds an application trigger ath10k under
"/usr/libexec/led-trigger". The kernel LED API of the ath10k does not
behave like the netdev trigger. For the netdev trigger, the interface to
use can be set under /sys/class/leds//device_name. For the
LED ath10k, the interface is added to the supported trigger name.
So we have for one interface (phy0) the following triggers for each LED.
- phy0rx
- phy0tx
- phy0assoc
- phy0radio
- phy0tpt
To make it easier for us to configure this, there is now an application
trigger. This has additional uci options.
- device: which interface we want to use (phyX)
- function: which trigger function we want to use (rx|tx|assoc|radio|tpt)
The trigger now behaves the same way again netdev trigger.
This change is backwards compatible. If the kernel trigger names are
used (phyrx | phytx | phyassoc | phyradio | phytpt)
this will continue to work.
With this change it is now easier to create a LUCI configuration page
without Javascript magic.
Signed-off-by: Florian Eckert
---
package/kernel/mac80211/ath.mk| 8 +++
.../files/usr/libexec/led-trigger/ath10k | 24 +++
2 files changed, 32 insertions(+)
create mode 100644 package/kernel/mac80211/files/usr/libexec/led-trigger/ath10k
diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk
index 50b1eed9c8..b42a693b8a 100644
--- a/package/kernel/mac80211/ath.mk
+++ b/package/kernel/mac80211/ath.mk
@@ -289,6 +289,14 @@ define KernelPackage/ath10k-smallbuffers
VARIANT:=smallbuffers
endef
+ifdef CONFIG_ATH10K_LEDS
+define KernelPackage/ath10k/install
+ $(INSTALL_DIR) $(1)/usr/libexec/led-trigger
+ $(INSTALL_DATA) ./files/usr/libexec/led-trigger/ath10k \
+ $(1)/usr/libexec/led-trigger
+endef
+endif #CONFIG_ATH10K_LEDS
+
define KernelPackage/carl9170
$(call KernelPackage/mac80211/Default)
TITLE:=Driver for Atheros AR9170 USB sticks
diff --git a/package/kernel/mac80211/files/usr/libexec/led-trigger/ath10k
b/package/kernel/mac80211/files/usr/libexec/led-trigger/ath10k
new file mode 100644
index 00..7abee76d04
--- /dev/null
+++ b/package/kernel/mac80211/files/usr/libexec/led-trigger/ath10k
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+main() {
+ . /lib/functions.sh
+ local led="$1"
+
+ local device="$(uci_get system "$led" device)"
+ local function="$(uci_get system "$led" function)"
+ local sysfs="$(uci_get system "$led" sysfs)"
+
+ [ -f "/sys/class/leds/${sysfs}/trigger" ] || {
+ logger -t "leds/ath10k" -p "warning" "LED '${sysfs}' not found"
+ return 0
+ }
+
+ [ "$(cat "/sys/class/leds/${sysfs}/trigger" | grep -q
"${device}${function}")" ] && {
+ logger -t "leds/ath10k" -p "warning" "Trigger
'${device}${function}' not found"
+ return 0
+ }
+
+ echo "${device}${function}" > /sys/class/leds/${sysfs}/trigger
+}
+
+main "$@"
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] base-files: add uci section name for application led trigger handling
In order to read out additional options from the uci section in the
called led trigger script, this section must also be add as a argument
to the application led trigger script.
Signed-off-by: Florian Eckert
---
package/base-files/files/etc/init.d/led | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/base-files/files/etc/init.d/led
b/package/base-files/files/etc/init.d/led
index 51cb8b5178..80db46f4f8 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -33,7 +33,7 @@ load_led() {
# execute application led trigger
[ -f "/usr/libexec/led-trigger/${trigger}" ] && {
- . "/usr/libexec/led-trigger/${trigger}"
+ . "/usr/libexec/led-trigger/${trigger}" "$1"
return 0
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: add uci section name for application led trigger handling
In order to read out additional options from the uci section in the
called led trigger script, this section must also be add as a argument
to the application led trigger script.
Signed-off-by: Florian Eckert
---
package/base-files/files/etc/init.d/led | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/base-files/files/etc/init.d/led
b/package/base-files/files/etc/init.d/led
index 51cb8b5178..80db46f4f8 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -33,7 +33,7 @@ load_led() {
# execute application led trigger
[ -f "/usr/libexec/led-trigger/${trigger}" ] && {
- . "/usr/libexec/led-trigger/${trigger}"
+ . "/usr/libexec/led-trigger/${trigger}" "$1"
return 0
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipset: update to 7.15
Update to the latest upstream version. In this version there is a new
tool with which you we convert ipsets into nftables sets. Since we are
now using nftables as default firewall, this could be a useful tool for
porting ipsets to nftables sets.
Signed-off-by: Florian Eckert
---
package/network/utils/ipset/Makefile | 5 +++--
.../patches/0001-lib-ipset-fix-printf-warning.patch | 11 +++
2 files changed, 14 insertions(+), 2 deletions(-)
create mode 100644
package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
diff --git a/package/network/utils/ipset/Makefile
b/package/network/utils/ipset/Makefile
index bc4945e0f6..7b8d035198 100644
--- a/package/network/utils/ipset/Makefile
+++ b/package/network/utils/ipset/Makefile
@@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=ipset
-PKG_VERSION:=7.6
+PKG_VERSION:=7.15
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=http://ipset.netfilter.org
-PKG_HASH:=0e7d44caa9c153d96a9b5f12644fbe35a632537a5a7f653792b72e53d9d5c2db
+PKG_HASH:=0a5545aaadb640142c1f888d366a78ddf8724799967fa20686a70053bd621751
PKG_MAINTAINER:=Jo-Philipp Wich
PKG_LICENSE:=GPL-2.0
@@ -62,6 +62,7 @@ endef
define Package/ipset/install
$(INSTALL_DIR) $(1)/usr/sbin
$(CP) $(PKG_INSTALL_DIR)/usr/sbin/ipset $(1)/usr/sbin/
+ $(CP) $(PKG_INSTALL_DIR)/usr/sbin/ipset-translate $(1)/usr/sbin/
endef
define Package/libipset/install
diff --git
a/package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
b/package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
new file mode 100644
index 00..90dfacab8f
--- /dev/null
+++
b/package/network/utils/ipset/patches/0001-lib-ipset-fix-printf-warning.patch
@@ -0,0 +1,11 @@
+--- a/lib/ipset.c
b/lib/ipset.c
+@@ -1847,7 +1847,7 @@ static int ipset_xlate(struct ipset *ips
+ return -1;
+ case IPSET_CMD_LIST:
+ if (!set) {
+- printf("list sets %s\n",
++ printf("list sets %s %s\n",
+ ipset_xlate_family(family), table);
+ } else {
+ printf("list set %s %s %s\n",
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] x86: geode: fix package nameing kmod-crypto-ebc does not exist
This commit fixes the package naming that was added by commit: e1e4cbde5ceb228e60fff1fc752cb90d9a7df2ab Signed-off-by: Florian Eckert --- target/linux/x86/image/geode.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/x86/image/geode.mk b/target/linux/x86/image/geode.mk index ce5e93a2c5..91851b90ca 100644 --- a/target/linux/x86/image/geode.mk +++ b/target/linux/x86/image/geode.mk @@ -1,7 +1,7 @@ define Device/generic DEVICE_VENDOR := Generic DEVICE_MODEL := x86/Geode - DEVICE_PACKAGES += kmod-crypto-cbc kmod-crypto-ebc kmod-crypto-hw-geode \ + DEVICE_PACKAGES += kmod-crypto-cbc kmod-crypto-ecb kmod-crypto-hw-geode \ kmod-ledtrig-gpio GRUB2_VARIANT := legacy endef -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 7/7] lantiq: add renesas USB3 support
On 2022-02-02 11:39, Torsten Duwe wrote: Enable the USB_XHCI_PCI_RENESAS config option on lantiq and note the usb3 dependency. The XHCI host controller requires a firmware blob, see https://forum.openwrt.org/t/2071 Signed-off-by: Torsten Duwe --- package/kernel/linux/modules/usb.mk | 1 + target/linux/lantiq/config-5.10 | 2 ++ 2 files changed, 3 insertions(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index f74c02a99f..72bdce4bd8 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -1713,6 +1713,7 @@ define KernelPackage/usb3 +TARGET_bcm53xx:kmod-phy-bcm-ns-usb3 \ +TARGET_ramips_mt7621:kmod-usb-xhci-mtk \ +(TARGET_apm821xx_nand&_5_10):kmod-usb-xhci-pci-renesas \ + +TARGET_lantiq:kmod-usb-xhci-pci-renesas \ +TARGET_mvebu_cortexa9:kmod-usb-xhci-pci-renesas KCONFIG:= \ CONFIG_USB_PCI=y \ diff --git a/target/linux/lantiq/config-5.10 b/target/linux/lantiq/config-5.10 index a830689e23..9e7874bd5d 100644 --- a/target/linux/lantiq/config-5.10 +++ b/target/linux/lantiq/config-5.10 @@ -220,5 +220,7 @@ CONFIG_SYS_SUPPORTS_VPE_LOADER=y CONFIG_TARGET_ISA_REV=2 CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_TINY_SRCU=y +CONFIG_USB_XHCI_PCI=y +CONFIG_USB_XHCI_PCI_RENESAS=y That would switch on the driver for all lantiq SOC. Doesn't that only make sense for the xrx200? CONFIG_USE_OF=y CONFIG_WATCHDOG_CORE=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
I have now been persuaded to share my thoughts on the subject as well. Since this is a major change. In itself, I think it is good that thought is being given to unification. Github was the first web-based source code management tool. So I think it's just that most of user are also on github. However, since Microsoft has joined the game, I am in worry about the transparency. Yes, Mircosoft has improved in that aspect. But it always depends on the company philosophy if they love or hate FOSS :-) Why not gitlab? Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them. And if necessary, we can also host everything ourselves. What I like is the CI handling with the gitlabrunners. We can take the ones from Gitlab or we can configure gitlabrunners running on our own hardware. Somewhere in the thread @arprcar I read that gitlab is not an option. Unfortunately, it didn't say why. Did you mean hosting it yourself? Best Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 1/1] netifd: add devtype to ubus call
Every network device has a type. There is no standard interface here.
The type can be determined either from the file
'/sys/class/net//uevent' or, if no information is found
there, from the file '/sys/class/net//type'.
This new function first checks whether there is a DEVTYPE= sring
in the 'uevent' file and uses it. If it does not find this information,
the 'type' is used as a fallback and mapped the number to a character
sequence.
This new 'devtype' information can be found in the network.device ubus
call.
Command:
ubus call network.device status
Output:
{
"eth0": {
"devtype": "ethernet",
Signed-off-by: Florian Eckert
---
v2:
- Remove debug log output
v3:
- Use the information mainly from file 'uevent'.
- If 'uevent' does not provide the information use file 'type'
v4:
- Fix coding style
- Merge arrays
system-linux.c | 47
system.h | 65 ++
2 files changed, 112 insertions(+)
diff --git a/system-linux.c b/system-linux.c
index e768853..e44058e 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -2395,6 +2395,51 @@ system_if_force_external(const char *ifname)
return stat(dev_sysfs_path(ifname, "phy80211"), ) == 0;
}
+static const char *
+system_netdevtype_name(unsigned short dev_type)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(netdev_types); i++)
+ if (netdev_types[i].id == dev_type)
+ return netdev_types[i].name;
+ /* the last key is used by default */
+ i = ARRAY_SIZE(netdev_types) - 1;
+ return netdev_types[i].name;
+}
+
+static void
+system_add_devtype(struct blob_buf *b, const char *ifname)
+{
+ char buf[100];
+ bool found = false;
+
+ if (!system_get_dev_sysfs("uevent", ifname, buf, sizeof(buf))) {
+ const char *info = "DEVTYPE=";
+ char *context = NULL;
+ const char *line = strtok_r(buf, "\r\n", );
+ while (line != NULL) {
+ char *index = strstr(line, info);
+ if (index != NULL) {
+ blobmsg_add_string(b, "devtype", index +
strlen(info));
+ found = true;
+ break;
+ }
+ line = strtok_r(NULL, "\r\n", );
+ }
+ }
+
+ if (!found) {
+ unsigned short number = 0;
+ const char *name = NULL;
+ if (!system_get_dev_sysfs("type", ifname, buf, sizeof(buf))) {
+ number = strtoul(buf, NULL, 0);
+ name = system_netdevtype_name(number);
+ blobmsg_add_string(b, "devtype", name);
+ }
+ }
+}
+
int
system_if_dump_info(struct device *dev, struct blob_buf *b)
{
@@ -2430,6 +2475,8 @@ system_if_dump_info(struct device *dev, struct blob_buf
*b)
blobmsg_add_u8(b, "autoneg", !!ecmd.autoneg);
}
+ system_add_devtype(b, dev->ifname);
+
return 0;
}
diff --git a/system.h b/system.h
index 1f7037d..40ef2fe 100644
--- a/system.h
+++ b/system.h
@@ -23,6 +23,71 @@
#include "iprule.h"
#include "utils.h"
+struct netdev_type {
+ unsigned short id;
+ const char *name;
+};
+
+static const struct netdev_type netdev_types[] = {
+ {ARPHRD_NETROM, "netrom"},
+ {ARPHRD_ETHER, "ethernet"},
+ {ARPHRD_EETHER, "eethernet"},
+ {ARPHRD_AX25, "ax25"},
+ {ARPHRD_PRONET, "pronet"},
+ {ARPHRD_CHAOS, "chaos"},
+ {ARPHRD_IEEE802, "ieee802"},
+ {ARPHRD_ARCNET, "arcnet"},
+ {ARPHRD_APPLETLK, "appletlk"},
+ {ARPHRD_DLCI, "dlci"},
+ {ARPHRD_ATM, "atm"},
+ {ARPHRD_METRICOM, "metricom"},
+ {ARPHRD_IEEE1394, "ieee1394"},
+ {ARPHRD_EUI64, "eui64"},
+ {ARPHRD_INFINIBAND, "infiniband"},
+ {ARPHRD_SLIP, "slip"},
+ {ARPHRD_CSLIP, "cslip"},
+ {ARPHRD_SLIP6, "slip6"},
+ {ARPHRD_CSLIP6, "cslip6"},
+ {ARPHRD_RSRVD, "rsrvd"},
+ {ARPHRD_ADAPT, "adapt"},
+ {ARPHRD_ROSE, "rose"},
+ {ARPHRD_X25, "x25"},
+ {ARPHRD_HWX25, "hwx25"},
+ {ARPHRD_PPP, "ppp"},
+ {ARPHRD_CISCO, "cisco"},
+ {ARPHRD_LAPB, "lapb"},
+ {ARPHRD_DDCMP, "ddcmp"},
+ {ARPHRD_RAWHDLC, "rawhdlc"},
+ {ARPHRD_TUNNEL, "tunnel"},
+ {ARPHRD_TUNNEL6, "tunnel6"},
+ {ARPHRD_FRAD, "frad"},
+ {ARPHRD_SK
libubus-lua: Wrong conversion for negative numbers on 64bit systems
Hello,
The commit [1] added a regression for negative numbers in the ubus lua
binding on 64bit systems.
This is was also backported to openwrt-19.07 branch with this commit
[2].
I have noticed this on my Apu3 x86_64 system and I do not see this error
on my 32 bit system.
I assume that this error occurs with every 64bit system.
This issue can be reproduced in the following way:
LUA Test-Script (lua /root/test.lua):
```
local util = require "luci.util"
local status = util.ubus("luci.test", "dump", {})
luci.util.dumptable(status)
```
LUA Test-Service (lua /root/luci.test):
```
#!/usr/bin/env lua
local ubus = require "ubus"
local uloop = require "uloop"
uloop.init()
local conn = ubus.connect()
if not conn then
error("Failed to connect to ubus")
end
local name = "luci.test"
local ubus_objects = { }
ubus_objects[name] = {
dump = {
function(req, msg)
local result = {}
local string = "This is a test"
local on = true
local off = false
local positiv = 5
local negativ = -55
result["string"] = string
result["on"] = on
result["off"] = off
result["positiv"] = positiv
result["negativ"] = negativ
conn:reply(req, result);
end, {}
}
}
conn:add( ubus_objects )
print("Objects added, starting loop")
uloop.run()
```
Incorrect output (lua /root/test.lua):
```
negativ 1.844674407371e+19
string This is a test
positiv 5
on true
off false
```
Correct output if I revert the commit (lua /root/test.lua):
```
negativ -55
string This is a test
positiv 5
on true
off false
```
I think the conversion is wrong here.
I think it must be checked beforehand whether it is a negative number,
otherwise the typecast is wrong here if this is not taken into account.
Can someone please confirm this!
Best Regards
Florian
[1]
https://git.openwrt.org/?p=project/ubus.git;a=commit;h=171469e3138cce191892e20b6fd35b52c9368064
[2]
https://git.openwrt.org/?p=project/ubus.git;a=commit;h=9ec9cfc6574a197ea934489de056594f44088352
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] netifd: add devtype to ubus call
Hello Hans,
thanks for you review.
+--- a/system.h
b/system.h
+@@ -23,6 +23,42 @@
+ #include "iprule.h"
+ #include "utils.h"
+
++static const unsigned short netdev_type_number[] = {
++ ARPHRD_NETROM, ARPHRD_ETHER, ARPHRD_EETHER, ARPHRD_AX25,
++ ARPHRD_PRONET, ARPHRD_CHAOS, ARPHRD_IEEE802, ARPHRD_ARCNET,
++ ARPHRD_APPLETLK, ARPHRD_DLCI, ARPHRD_ATM, ARPHRD_METRICOM,
++ ARPHRD_IEEE1394, ARPHRD_EUI64, ARPHRD_INFINIBAND, ARPHRD_SLIP,
++ ARPHRD_CSLIP, ARPHRD_SLIP6, ARPHRD_CSLIP6, ARPHRD_RSRVD,
++ ARPHRD_ADAPT, ARPHRD_ROSE, ARPHRD_X25, ARPHRD_HWX25,
++ ARPHRD_PPP, ARPHRD_CISCO, ARPHRD_LAPB, ARPHRD_DDCMP,
++ ARPHRD_RAWHDLC, ARPHRD_TUNNEL, ARPHRD_TUNNEL6, ARPHRD_FRAD,
++ ARPHRD_SKIP, ARPHRD_LOOPBACK, ARPHRD_LOCALTLK, ARPHRD_FDDI,
++ ARPHRD_BIF, ARPHRD_SIT, ARPHRD_IPDDP, ARPHRD_IPGRE,
++ ARPHRD_PIMREG, ARPHRD_HIPPI, ARPHRD_ASH, ARPHRD_ECONET,
++ ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
++ ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
++ ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
++ ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE
++};
++
++static const char *const netdev_type_name[] = {
++ "netrom", "ethernet", "eethernet", "ax25",
++ "pronet", "chaos", "ieee802", "arcnet",
++ "appletlk", "dlci", "atm", "metricom",
++ "ieee1394", "eui64", "infiniband", "slip",
++ "cslip", "slip6", "cslip6", "rsrvd",
++ "adapt", "rose", "x25", "hwx25",
++ "ppp", "cisco", "lapb", "ddcmp",
++ "rawhdlc", "tunnel", "tunnel6", "frad",
++ "skip", "loopback", "localtlk", "fddi",
++ "bif", "sit", "ipddp", "ipgre",
++ "pimreg", "hippi", "ash", "econet",
++ "irda", "fcpp", "fcal", "fcpl",
++ "fcfabric", "ieee80211", "ie80211-prism",
++ "ieee80211-radiotap", "phonet", "phonet-pipe",
++ "ieee802154", "void", "none"
++};
Merge these two arrays into one array, each entry having the netdev
type number and the corresponding string.
Implement a function which uses the array and takes as argument the
netdev type number and returns the corresponding string
I am not quite sure if I have understood this correctly.
If you take a look at the include where the ARPHRD are defined.
https://elixir.bootlin.com/linux/v5.16-rc1/source/include/uapi/linux/if_arp.h
Then the array must have 65535 entries ARPHRD_VOID is at position
0x.
That's quite a lot for the fact that there are 58 ids.
This is the code I would use?
static const char * const netdev_type[] = {
[ARPHRD_NETROM] = "netrom",
[ARPHRD_ETHER] = "ethernet",
...
...
};
Or should I define an array of netdev_type structs?
struct netdev_type {
const char *name;
unsigned short number;
};
#define DEV_TYPE(_name, _number) \
{\
.name = _name, \
.number = _number \
}\
static const struct netdev_type netdev_types[] = {
{
DEV_TYPE("netrom", ARPHRD_NETROM),
DEV_TYPE("ethernet", ARPHRD_ETHER),
...
...
};
Best Regards
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CPU_TYPE "xxx" doesn't correspond to a known type
Hello Philip Yeah, it's intentional. It was meant to be a sentinel for bitrot. I was already aware that this warning was intentional. I have expressed that incorrectly sorry. You don't want to have an empty expansion of CPU_CLFAGS_* as these are usually important platform-specific values that cause the correct instruction set to be emitted for the particulars of the CPU type. See the preceding lines for -march and -mcpu values per platform. But that would mean we would have to do something, wouldn't it? I have seen that it mainly affects arm cpu's. Best regards Florian Output: /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a15" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a5" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm926ej-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm1176jzf-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a72" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "fa526" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a15" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "xscale" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a72" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm926ej-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a8" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm926ej-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "mpcore" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a8" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type apm821xx/nand powerpc_464fp apm821xx/sata powerpc_464fp arc770/generic arc_arc700 archs38/generic arc_archs armvirt/32 arm_cortex-a15_neon-vfpv4 armvirt/64 aarch64_cortex-a53 at91/sam9x arm_arm926ej-s at91/sama5 arm_cortex-a5_vfpv4 ath25/generic mips_mips32 ath79/generic mips_24kc ath79/mikrotik mips_24kc ath79/nand mips_24kc ath79/tiny mips_24kc bcm27xx/bcm2708 arm_arm1176jzf-s_vfp bcm27xx/bcm2709 arm_cortex-a7_neon-vfpv4 bcm27xx/bcm2710 aarch64_cortex-a53 bcm27xx/bcm2711 aarch64_cortex-a72 bcm47xx/generic mipsel_mips32 bcm47xx/legacy mipsel_mips32 bcm47xx/mips74k mipsel_74kc bcm4908/generic aarch64_cortex-a53 bcm53xx/generic arm_cortex-a9 bcm63xx/generic mips_mips32 bcm63xx/smp mips_mips32 gemini/generic arm_fa526 imx/cortexa7 arm_cortex-a7_neon-vfpv4 imx/cortexa9 arm_cortex-a9_neon ipq40xx/generic arm_cortex-a7_neon-vfpv4 ipq40xx/mikrotik arm_cortex-a7_neon-vfpv4 ipq806x/generic arm_cortex-a15_neon-vfpv4 kirkwood/generic arm_xscale lantiq/ase mips_mips32 lantiq/xrx200 mips_24kc lantiq/xway mips_24kc lantiq/xway_legacy mips_24kc layerscape/armv7 arm_cortex-a7_neon-vfpv4 layerscape/armv8_64b aarch64_generic malta/be mips_24kc mediatek/mt7622 aarch64_cortex-a53 mediatek/mt7623 arm_cortex-a7_neon-vfpv4 mediatek/mt7629 arm_cortex-a7 mpc85xx/p1010 powerpc_8540 mpc85xx/p1020 powerpc_8540 mpc85xx/p2020 powerpc_8540 mvebu/cortexa53 aarch64_cortex-a53 mvebu/cortexa72 aarch64_cortex-a72 mvebu/cortexa9 arm_cortex-a9_vfpv3-d16 mxs/generic arm_arm926ej-s octeon/generic mips64_octeonplus octeontx/generic aarch64_generic omap/generic arm_cortex-a8_vfpv3 oxnas/ox820 arm_mpcore pistachio/generic mipsel_24kc_24kf ramips/mt7620
CPU_TYPE "xxx" doesn't correspond to a known type
Hello, If I execute the following command in the openwrt project: ./scripts/dump-target-info.pl targets I get the this output! I don't know if this is a mistake or if it is intentional. The warning was added by this commit https://gitlab.dev.tdt.de/dev/sys6/upstream/openwrt/-/commit/d3bc11857af788e185e8a3ece26ce40757cf3965 Output: /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a15" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a5" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm926ej-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm1176jzf-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a72" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "fa526" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a15" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "xscale" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a72" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm926ej-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a8" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "arm926ej-s" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "mpcore" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a8" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a7" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type /home/feckert/openwrt/include/target.mk:256: CPU_TYPE "cortex-a9" doesn't correspond to a known type apm821xx/nand powerpc_464fp apm821xx/sata powerpc_464fp arc770/generic arc_arc700 archs38/generic arc_archs armvirt/32 arm_cortex-a15_neon-vfpv4 armvirt/64 aarch64_cortex-a53 at91/sam9x arm_arm926ej-s at91/sama5 arm_cortex-a5_vfpv4 ath25/generic mips_mips32 ath79/generic mips_24kc ath79/mikrotik mips_24kc ath79/nand mips_24kc ath79/tiny mips_24kc bcm27xx/bcm2708 arm_arm1176jzf-s_vfp bcm27xx/bcm2709 arm_cortex-a7_neon-vfpv4 bcm27xx/bcm2710 aarch64_cortex-a53 bcm27xx/bcm2711 aarch64_cortex-a72 bcm47xx/generic mipsel_mips32 bcm47xx/legacy mipsel_mips32 bcm47xx/mips74k mipsel_74kc bcm4908/generic aarch64_cortex-a53 bcm53xx/generic arm_cortex-a9 bcm63xx/generic mips_mips32 bcm63xx/smp mips_mips32 gemini/generic arm_fa526 imx/cortexa7 arm_cortex-a7_neon-vfpv4 imx/cortexa9 arm_cortex-a9_neon ipq40xx/generic arm_cortex-a7_neon-vfpv4 ipq40xx/mikrotik arm_cortex-a7_neon-vfpv4 ipq806x/generic arm_cortex-a15_neon-vfpv4 kirkwood/generic arm_xscale lantiq/ase mips_mips32 lantiq/xrx200 mips_24kc lantiq/xway mips_24kc lantiq/xway_legacy mips_24kc layerscape/armv7 arm_cortex-a7_neon-vfpv4 layerscape/armv8_64b aarch64_generic malta/be mips_24kc mediatek/mt7622 aarch64_cortex-a53 mediatek/mt7623 arm_cortex-a7_neon-vfpv4 mediatek/mt7629 arm_cortex-a7 mpc85xx/p1010 powerpc_8540 mpc85xx/p1020 powerpc_8540 mpc85xx/p2020 powerpc_8540 mvebu/cortexa53 aarch64_cortex-a53 mvebu/cortexa72 aarch64_cortex-a72 mvebu/cortexa9 arm_cortex-a9_vfpv3-d16 mxs/generic arm_arm926ej-s octeon/generic mips64_octeonplus octeontx/generic aarch64_generic omap/generic arm_cortex-a8_vfpv3 oxnas/ox820 arm_mpcore pistachio/generic mipsel_24kc_24kf ramips/mt7620 mipsel_24kc ramips/mt7621 mipsel_24kc ramips/mt76x8 mipsel_24kc ramips/rt288x mipsel_24kc ramips/rt305x mipsel_24kc ramips/rt3883 mipsel_74kc realtek/generic mips_4kec rockchip/armv8 aarch64_generic sunxi/cortexa53 aarch64_cortex-a53 sunxi/cortexa7
[PATCH v3] netifd: add devtype to ubus call
Every network device has a type. There is no standard interface here.
The type can be determined either from the file
'/sys/class/net//uevent' or, if no information is found
there, from the file '/sys/class/net//type'.
This new function first checks whether there is a DEVTYPE= sring in
the 'uevent' file and uses it. If it does not find this information,
the 'type' is used as a fallback and mapped the number to a character
sequence.
This new 'devtype' information can be found in the network.device ubus
call.
Command:
ubus call network.device status
Output:
{
"eth0": {
"devtype": "ethernet",
Signed-off-by: Florian Eckert
---
v2:
- Remove debug log output
v3:
- Use the information mainly from file 'uevnet'.
- If 'uevent' does not provide the information use file 'type'
...-system-linux-add-interface-protocol.patch | 107 ++
1 file changed, 107 insertions(+)
create mode 100644
package/network/config/netifd/patches/001-system-linux-add-interface-protocol.patch
diff --git
a/package/network/config/netifd/patches/001-system-linux-add-interface-protocol.patch
b/package/network/config/netifd/patches/001-system-linux-add-interface-protocol.patch
new file mode 100644
index 00..62662b3df3
--- /dev/null
+++
b/package/network/config/netifd/patches/001-system-linux-add-interface-protocol.patch
@@ -0,0 +1,107 @@
+--- a/system-linux.c
b/system-linux.c
+@@ -2395,6 +2395,50 @@ system_if_force_external(const char *ifn
+ return stat(dev_sysfs_path(ifname, "phy80211"), ) == 0;
+ }
+
++static inline unsigned short
++system_netdevtype_to_pos(unsigned short dev_type)
++{
++ int i;
++
++ for (i = 0; i < ARRAY_SIZE(netdev_type_number); i++)
++ if (netdev_type_number[i] == dev_type)
++ return i;
++ /* the last key is used by default */
++ return ARRAY_SIZE(netdev_type_number) - 1;
++}
++
++static void
++system_add_devtype(struct blob_buf *b, const char *ifname)
++{
++ char buf[100];
++ bool found = false;
++
++ if (!system_get_dev_sysfs("uevent", ifname, buf, sizeof(buf))) {
++ const char *info = "DEVTYPE=";
++ char* context = NULL;
++ const char *line = strtok_r(buf, "\r\n", );
++ while( line != NULL ) {
++ char *index = strstr(line, info);
++ if(index != NULL) {
++ blobmsg_add_string(b, "devtype", index +
strlen(info));
++ found = true;
++ break;
++ }
++ line = strtok_r(NULL, "\r\n", );
++ }
++ }
++
++ if (!found) {
++ int i;
++ unsigned short number = 0;
++ if (!system_get_dev_sysfs("type", ifname, buf, sizeof(buf))) {
++ number = strtoul(buf, NULL, 0);
++ i = system_netdevtype_to_pos(number);
++ blobmsg_add_string(b, "devtype", netdev_type_name[i]);
++ }
++ }
++}
++
+ int
+ system_if_dump_info(struct device *dev, struct blob_buf *b)
+ {
+@@ -2430,6 +2474,8 @@ system_if_dump_info(struct device *dev,
+ blobmsg_add_u8(b, "autoneg", !!ecmd.autoneg);
+ }
+
++ system_add_devtype(b, dev->ifname);
++
+ return 0;
+ }
+
+--- a/system.h
b/system.h
+@@ -23,6 +23,42 @@
+ #include "iprule.h"
+ #include "utils.h"
+
++static const unsigned short netdev_type_number[] = {
++ ARPHRD_NETROM, ARPHRD_ETHER, ARPHRD_EETHER, ARPHRD_AX25,
++ ARPHRD_PRONET, ARPHRD_CHAOS, ARPHRD_IEEE802, ARPHRD_ARCNET,
++ ARPHRD_APPLETLK, ARPHRD_DLCI, ARPHRD_ATM, ARPHRD_METRICOM,
++ ARPHRD_IEEE1394, ARPHRD_EUI64, ARPHRD_INFINIBAND, ARPHRD_SLIP,
++ ARPHRD_CSLIP, ARPHRD_SLIP6, ARPHRD_CSLIP6, ARPHRD_RSRVD,
++ ARPHRD_ADAPT, ARPHRD_ROSE, ARPHRD_X25, ARPHRD_HWX25,
++ ARPHRD_PPP, ARPHRD_CISCO, ARPHRD_LAPB, ARPHRD_DDCMP,
++ ARPHRD_RAWHDLC, ARPHRD_TUNNEL, ARPHRD_TUNNEL6, ARPHRD_FRAD,
++ ARPHRD_SKIP, ARPHRD_LOOPBACK, ARPHRD_LOCALTLK, ARPHRD_FDDI,
++ ARPHRD_BIF, ARPHRD_SIT, ARPHRD_IPDDP, ARPHRD_IPGRE,
++ ARPHRD_PIMREG, ARPHRD_HIPPI, ARPHRD_ASH, ARPHRD_ECONET,
++ ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
++ ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
++ ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
++ ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE
++};
++
++static const char *const netdev_type_name[] = {
++ "netrom", "ethernet", "eethernet", "ax25",
++ "pronet", "chaos", "ieee802", "arcnet",
++ "appletlk", "dlci", "atm", "metricom",
++ "ieee13
Re: [PATCH] netifd: system-linux: add dev_type info for ubus network.device status
Hello Jo imho these types are not that useful in practice (e.g. tap devices etc. are all reported as "ethernet". Maybe expose /sys/class/net/$devname/uevent DEVTYP= instead. I have now taken a look at your suggestion. Unfortunately, I found that not all network interfaces have set the DEVTYPE attribute set in their uevent file. I have not yet found any information who sets this value. Does this do the driver or the subsystem? I need to do some more research The following devices does have this DEVTYPE attribute set on my targets root@st-dev-07 /sys/class/net # cat docker0/uevent DEVTYPE=bridge INTERFACE=docker0 IFINDEX=16 root@st-dev-07 /sys/class/net # cat wlan0/uevent DEVTYPE=wlan INTERFACE=wlan0 IFINDEX=14 root@st-dev-07 /sys/class/net # cat wwan0/uevent DEVTYPE=wwan INTERFACE=wwan0 IFINDEX=5 root@VR2-120770 ~ # cat /sys/class/net/pppoe-xdsl/uevent DEVTYPE=ppp INTERFACE=pppoe-xdsl IFINDEX=2285 root@VR2-120770 ~ # The following devices does *not* have this DEVTYPE attribute set on my targets: root@st-dev-07 /sys/class/net # cat eth0/uevent INTERFACE=eth0 IFINDEX=2 root@st-dev-07 /sys/class/net # cat sit0/uevent INTERFACE=sit0 IFINDEX=7 root@st-dev-07 /sys/class/net # cat ip6_vti0/uevent INTERFACE=ip6_vti0 IFINDEX=9 The question now if this DEVTYPE is not set what should we do? Set now `dev_type` value in the ubus output til we update this in the Kernel? Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] netifd: system-linux: add dev_type info for ubus network.device status
Every network device has a type. This is stored in the sysfs under
'/sys/class/net//type' as a number and can be queried.
This commit adds this information as a string to the ubus.
'ubus call network.device status'
{
...
"eth0": {
"dev_type": "ETHER",
...
}
Signed-off-by: Florian Eckert
---
v2: remove debug log output
system-linux.c | 20
system.h | 36
2 files changed, 56 insertions(+)
diff --git a/system-linux.c b/system-linux.c
index e768853..a1728ab 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -2395,6 +2395,17 @@ system_if_force_external(const char *ifname)
return stat(dev_sysfs_path(ifname, "phy80211"), ) == 0;
}
+static inline unsigned short netdev_type_pos(unsigned short dev_type)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(netdev_type_number); i++)
+ if (netdev_type_number[i] == dev_type)
+ return i;
+ /* the last key is used by default */
+ return ARRAY_SIZE(netdev_type_number) - 1;
+}
+
int
system_if_dump_info(struct device *dev, struct blob_buf *b)
{
@@ -2402,6 +2413,9 @@ system_if_dump_info(struct device *dev, struct blob_buf
*b)
struct ifreq ifr;
char *s;
void *c;
+ unsigned short dev_type = 0;
+ int i;
+ char buf[10];
memset(, 0, sizeof(ecmd));
memset(, 0, sizeof(ifr));
@@ -2430,6 +2444,12 @@ system_if_dump_info(struct device *dev, struct blob_buf
*b)
blobmsg_add_u8(b, "autoneg", !!ecmd.autoneg);
}
+ if (!system_get_dev_sysfs("type", dev->ifname, buf, sizeof(buf))) {
+ dev_type = strtoul(buf, NULL, 0);
+ i = netdev_type_pos(dev_type);
+ blobmsg_add_string(b, "dev_type", netdev_type_name[i]);
+ }
+
return 0;
}
diff --git a/system.h b/system.h
index 1f7037d..fdd8a64 100644
--- a/system.h
+++ b/system.h
@@ -23,6 +23,42 @@
#include "iprule.h"
#include "utils.h"
+static const unsigned short netdev_type_number[] = {
+ ARPHRD_NETROM, ARPHRD_ETHER, ARPHRD_EETHER, ARPHRD_AX25,
+ ARPHRD_PRONET, ARPHRD_CHAOS, ARPHRD_IEEE802, ARPHRD_ARCNET,
+ ARPHRD_APPLETLK, ARPHRD_DLCI, ARPHRD_ATM, ARPHRD_METRICOM,
+ ARPHRD_IEEE1394, ARPHRD_EUI64, ARPHRD_INFINIBAND, ARPHRD_SLIP,
+ ARPHRD_CSLIP, ARPHRD_SLIP6, ARPHRD_CSLIP6, ARPHRD_RSRVD,
+ ARPHRD_ADAPT, ARPHRD_ROSE, ARPHRD_X25, ARPHRD_HWX25,
+ ARPHRD_PPP, ARPHRD_CISCO, ARPHRD_LAPB, ARPHRD_DDCMP,
+ ARPHRD_RAWHDLC, ARPHRD_TUNNEL, ARPHRD_TUNNEL6, ARPHRD_FRAD,
+ ARPHRD_SKIP, ARPHRD_LOOPBACK, ARPHRD_LOCALTLK, ARPHRD_FDDI,
+ ARPHRD_BIF, ARPHRD_SIT, ARPHRD_IPDDP, ARPHRD_IPGRE,
+ ARPHRD_PIMREG, ARPHRD_HIPPI, ARPHRD_ASH, ARPHRD_ECONET,
+ ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
+ ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
+ ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
+ ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE
+};
+
+static const char *const netdev_type_name[] = {
+ "NETROM", "ETHER", "EETHER", "AX25",
+ "PRONET", "CHAOS", "IEEE802", "ARCNET",
+ "APPLETLK", "DLCI", "ATM", "METRICOM",
+ "IEEE1394", "EUI64", "INFINIBAND", "SLIP",
+ "CSLIP", "SLIP6", "CSLIP6", "RSRVD",
+ "ADAPT", "ROSE", "X25", "HWX25",
+ "PPP", "CISCO", "LAPB", "DDCMP",
+ "RAWHDLC", "TUNNEL", "TUNNEL6", "FRAD",
+ "SKIP", "LOOPBACK", "LOCALTLK", "FDDI",
+ "BIF", "SIT", "IPDDP", "IPGRE",
+ "PIMREG", "HIPPI", "ASH", "ECONET",
+ "IRDA", "FCPP", "FCAL", "FCPL",
+ "FCFABRIC", "IEEE80211", "IEEE80211_PRISM",
+ "IEEE80211_RADIOTAP", "PHONET", "PHONET_PIPE",
+ "IEEE802154", "VOID", "NONE"
+};
+
enum tunnel_param {
TUNNEL_ATTR_TYPE,
TUNNEL_ATTR_REMOTE,
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] netifd: system-linux: add dev_type info for ubus network.device status
Every network device has a type. This is stored in the sysfs under
'/sys/class/net//type' as a number and can be queried.
This commit adds this information as a string to the ubus.
'ubus call network.device status'
{
...
"eth0": {
"dev_type": "ETHER",
...
}
Signed-off-by: Florian Eckert
---
system-linux.c | 21 +
system.h | 36
2 files changed, 57 insertions(+)
diff --git a/system-linux.c b/system-linux.c
index e768853..4ac34cc 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -2395,6 +2395,17 @@ system_if_force_external(const char *ifname)
return stat(dev_sysfs_path(ifname, "phy80211"), ) == 0;
}
+static inline unsigned short netdev_type_pos(unsigned short dev_type)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(netdev_type_number); i++)
+ if (netdev_type_number[i] == dev_type)
+ return i;
+ /* the last key is used by default */
+ return ARRAY_SIZE(netdev_type_number) - 1;
+}
+
int
system_if_dump_info(struct device *dev, struct blob_buf *b)
{
@@ -2402,6 +2413,9 @@ system_if_dump_info(struct device *dev, struct blob_buf
*b)
struct ifreq ifr;
char *s;
void *c;
+ unsigned short dev_type = 0;
+ int i;
+ char buf[10];
memset(, 0, sizeof(ecmd));
memset(, 0, sizeof(ifr));
@@ -2430,6 +2444,13 @@ system_if_dump_info(struct device *dev, struct blob_buf
*b)
blobmsg_add_u8(b, "autoneg", !!ecmd.autoneg);
}
+ if (!system_get_dev_sysfs("type", dev->ifname, buf, sizeof(buf))) {
+ dev_type = strtoul(buf, NULL, 0);
+ i = netdev_type_pos(dev_type);
+ blobmsg_add_string(b, "dev_type", netdev_type_name[i]);
+ netifd_log_message(L_CRIT, "Interface type %s detected\n",
netdev_type_name[i]);
+ }
+
return 0;
}
diff --git a/system.h b/system.h
index 1f7037d..fdd8a64 100644
--- a/system.h
+++ b/system.h
@@ -23,6 +23,42 @@
#include "iprule.h"
#include "utils.h"
+static const unsigned short netdev_type_number[] = {
+ ARPHRD_NETROM, ARPHRD_ETHER, ARPHRD_EETHER, ARPHRD_AX25,
+ ARPHRD_PRONET, ARPHRD_CHAOS, ARPHRD_IEEE802, ARPHRD_ARCNET,
+ ARPHRD_APPLETLK, ARPHRD_DLCI, ARPHRD_ATM, ARPHRD_METRICOM,
+ ARPHRD_IEEE1394, ARPHRD_EUI64, ARPHRD_INFINIBAND, ARPHRD_SLIP,
+ ARPHRD_CSLIP, ARPHRD_SLIP6, ARPHRD_CSLIP6, ARPHRD_RSRVD,
+ ARPHRD_ADAPT, ARPHRD_ROSE, ARPHRD_X25, ARPHRD_HWX25,
+ ARPHRD_PPP, ARPHRD_CISCO, ARPHRD_LAPB, ARPHRD_DDCMP,
+ ARPHRD_RAWHDLC, ARPHRD_TUNNEL, ARPHRD_TUNNEL6, ARPHRD_FRAD,
+ ARPHRD_SKIP, ARPHRD_LOOPBACK, ARPHRD_LOCALTLK, ARPHRD_FDDI,
+ ARPHRD_BIF, ARPHRD_SIT, ARPHRD_IPDDP, ARPHRD_IPGRE,
+ ARPHRD_PIMREG, ARPHRD_HIPPI, ARPHRD_ASH, ARPHRD_ECONET,
+ ARPHRD_IRDA, ARPHRD_FCPP, ARPHRD_FCAL, ARPHRD_FCPL,
+ ARPHRD_FCFABRIC, ARPHRD_IEEE80211, ARPHRD_IEEE80211_PRISM,
+ ARPHRD_IEEE80211_RADIOTAP, ARPHRD_PHONET, ARPHRD_PHONET_PIPE,
+ ARPHRD_IEEE802154, ARPHRD_VOID, ARPHRD_NONE
+};
+
+static const char *const netdev_type_name[] = {
+ "NETROM", "ETHER", "EETHER", "AX25",
+ "PRONET", "CHAOS", "IEEE802", "ARCNET",
+ "APPLETLK", "DLCI", "ATM", "METRICOM",
+ "IEEE1394", "EUI64", "INFINIBAND", "SLIP",
+ "CSLIP", "SLIP6", "CSLIP6", "RSRVD",
+ "ADAPT", "ROSE", "X25", "HWX25",
+ "PPP", "CISCO", "LAPB", "DDCMP",
+ "RAWHDLC", "TUNNEL", "TUNNEL6", "FRAD",
+ "SKIP", "LOOPBACK", "LOCALTLK", "FDDI",
+ "BIF", "SIT", "IPDDP", "IPGRE",
+ "PIMREG", "HIPPI", "ASH", "ECONET",
+ "IRDA", "FCPP", "FCAL", "FCPL",
+ "FCFABRIC", "IEEE80211", "IEEE80211_PRISM",
+ "IEEE80211_RADIOTAP", "PHONET", "PHONET_PIPE",
+ "IEEE802154", "VOID", "NONE"
+};
+
enum tunnel_param {
TUNNEL_ATTR_TYPE,
TUNNEL_ATTR_REMOTE,
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/1] build: scripts/config - update to kconfig-v5.14
Hello Eneas, On 2021-11-24 22:25, Eneas U de Queiroz wrote: I'm updating the Kconfig programs in scripts/config, from Linux 5.6 to 5.14. The changes are not crytical to openwrt, but regular updates ease the transition to an eventual newer version with more desirable features. I've been looking at this too and wanted to update. Since I wasn't there from the beginning, I don't know what all OpenWrt changes. Hence my suggestion: Can't we put the changes OpenWrt makes to the source code into a patch directory and then patch that with 'quilt' like we do with all the other packages? That would make the task easier for others too update this too. I am ready to help you there Best regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] firewall3: fix locking issue
Hello I found an interesting article about this topic on stackoverflow. https://stackoverflow.com/questions/17708885/flock-removing-locked-file-without-race-condition Beset regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firewall3: fix locking issue
By calling the command 'fw3 reload' several times at the same time, I
noticed that the locking was not working properly. It happened from time
to time that some firewall rules were present twice in the system!
By removing the 'unlink' systemcall, this error no longer occurred on my
systems.
Since fw3 does not run as a service, it makes no sense to delete this
lock file every time a filehandler is no longer open on this lock file,
because fw3 binary is not running.
If fw3 does run as a service then we can remove this lock file on
service stop. But this is not the case for fw3.
Signed-off-by: Florian Eckert
---
utils.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/utils.c b/utils.c
index 17d5bf9..92e966c 100644
--- a/utils.c
+++ b/utils.c
@@ -397,7 +397,6 @@ fw3_unlock_path(int *fd, const char *lockpath)
warn("Cannot release exclusive lock: %s", strerror(errno));
close(*fd);
- unlink(FW3_LOCKFILE);
*fd = -1;
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH procd 1/1] system: add diskfree infos to ubus
This change adds the missing information about how much space is available
on the root directory and in the temp directory. I took this
implementation from the luci2 repository and adapted it for the procd
service.
Signed-off-by: Florian Eckert
---
system.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/system.c b/system.c
index 83aea42..a671f5d 100644
--- a/system.c
+++ b/system.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -239,6 +240,12 @@ static int system_board(struct ubus_context *ctx, struct
ubus_object *obj,
return UBUS_STATUS_OK;
}
+static unsigned long
+kscale(unsigned long b, unsigned long bs)
+{
+ return (b * (unsigned long long) bs + 1024/2) / 1024;
+}
+
static int system_info(struct ubus_context *ctx, struct ubus_object *obj,
struct ubus_request_data *req, const char *method,
struct blob_attr *msg)
@@ -252,6 +259,12 @@ static int system_info(struct ubus_context *ctx, struct
ubus_object *obj,
char *key, *val;
unsigned long long available, cached;
FILE *f;
+ int i;
+ struct statvfs s;
+ const char *fslist[] = {
+ "/","root",
+ "/tmp", "tmp",
+ };
if (sysinfo())
return UBUS_STATUS_UNKNOWN_ERROR;
@@ -311,6 +324,23 @@ static int system_info(struct ubus_context *ctx, struct
ubus_object *obj,
blobmsg_add_u64(, "cached", cached);
blobmsg_close_table(, c);
+ for (i = 0; i < sizeof(fslist) / sizeof(fslist[0]); i += 2) {
+ if (statvfs(fslist[i], ))
+ continue;
+
+ c = blobmsg_open_table(, fslist[i+1]);
+
+ if (!s.f_frsize)
+ s.f_frsize = s.f_bsize;
+
+ blobmsg_add_u64(, "total", kscale(s.f_blocks, s.f_frsize));
+ blobmsg_add_u64(, "free", kscale(s.f_bfree, s.f_frsize));
+ blobmsg_add_u64(, "used", kscale(s.f_blocks - s.f_bfree,
s.f_frsize));
+ blobmsg_add_u64(, "avail", kscale(s.f_bavail, s.f_frsize));
+
+ blobmsg_close_table(, c);
+ }
+
c = blobmsg_open_table(, "swap");
blobmsg_add_u64(, "total",
(uint64_t)info.mem_unit * (uint64_t)info.totalswap);
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] vti: squash vtiv4 and vtiv6 packages into vti
This change adds the same package behaviour as gre package. Signed-off-by: Florian Eckert --- package/network/config/vti/Makefile | 43 + 1 file changed, 7 insertions(+), 36 deletions(-) diff --git a/package/network/config/vti/Makefile b/package/network/config/vti/Makefile index 292ab111e5..548b8f951f 100644 --- a/package/network/config/vti/Makefile +++ b/package/network/config/vti/Makefile @@ -8,47 +8,28 @@ include $(TOPDIR)/rules.mk PKG_NAME:=vti -PKG_RELEASE:=4 +PKG_RELEASE:=5 PKG_LICENSE:=GPL-2.0 include $(INCLUDE_DIR)/package.mk define Package/vti/Default - SECTION:=net - CATEGORY:=Network - MAINTAINER:=Andre Valentin - PKGARCH:=all endef define Package/vti -$(call Package/vti/Default) + SECTION:=net + CATEGORY:=Network + MAINTAINER:=Andre Valentin TITLE:=Virtual IPsec Tunnel Interface config support + DEPENDS:=+kmod-ip-vti +IPV6:kmod-ip6-vti + PROVIDES:=vtiv4 vtiv6 + PKGARCH:=all endef define Package/vti/description Virtual IPsec Tunnel Interface config support (IPv4 and IPv6) in /etc/config/network. endef -define Package/vtiv4 -$(call Package/vti/Default) - TITLE:=Virtual IPsec Tunnel Interface (IPv4) config support - DEPENDS:=@(PACKAGE_vti) +kmod-ip-vti -endef - -define Package/vtiv4/description - Virtual IPsec Tunnel Interface config support (IPv4) in /etc/config/network. -endef - -define Package/vtiv6 -$(call Package/vti/Default) - TITLE:=Virtual IPsec Tunnel Interface (IPv6) config support - DEPENDS:=@(PACKAGE_vti) @IPV6 +kmod-ip6-vti -endef - -define Package/vtiv6/description - Virtual IPsec Tunnel Interface config support (IPv6) in /etc/config/network. -endef - define Build/Compile endef @@ -60,14 +41,4 @@ define Package/vti/install $(INSTALL_BIN) ./files/vti.sh $(1)/lib/netifd/proto/vti.sh endef -define Package/vtiv4/install - : -endef - -define Package/vtiv6/install - : -endef - $(eval $(call BuildPackage,vti)) -$(eval $(call BuildPackage,vtiv4)) -$(eval $(call BuildPackage,vtiv6)) -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: toolchain for building eBPF modules within the OpenWrt build system
I'd suggest to require a preinstalled host toolchain for the time being. How about requiring a preinstalled host toolchain by default, but building it from source on buildbot? I wouldn't make it dependent on whether openwrt compiles on the buildbot or not. I am not using this build option CONFIG_BUILDBOT on my own builds. Either use llvm from the buildhost (distribution), or let the openwrt buildsystem build its own llvm in the tool directory as you suggest. @nbd thank you for looking at this, would have needed the ebpf before :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] buildsystem: add CONFIG_SECCOMP
Until now, this feature was switched on via the kernel configuration option KERNEL_SECCOMP. The follwing change a7f794cd2aa104fdbd4c6e38f9b76373bf9b96e1 now requires that the package procd-seccomp must also enabled for buildinmg. However, this is not the case we have no dependency and the imagebuilder cannot build the image, because of the implicit package selection. This change adds a new configuration option CONFIG_SECCOMP. The new option has the same behaviour as the configuration option CONFIG_SELINUX. If the CONFIG_SECCOMP is selected then the package procd-seccomp and KERNEL_SECCOMP is enabled for this build. Signed-off-by: Florian Eckert --- v2: Enable CONFIG_SECCOMP by default config/Config-build.in| 12 include/target.mk | 2 +- package/system/procd/Makefile | 3 +-- 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/config/Config-build.in b/config/Config-build.in index f0e1aaa695..ca6f513450 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -386,4 +386,16 @@ menu "Global build settings" endchoice + config SECCOMP + bool "Enable SECCOMP" + select KERNEL_SECCOMP + select PACKAGE_procd-seccomp + depends on (aarch64 || arm || armeb || mips || mipsel || i386 || powerpc || x86_64) + depends on !TARGET_uml + default y + help + This option enables seccomp kernel features to safely + execute untrusted bytecode and selects the seccomp-variants + of procd + endmenu diff --git a/include/target.mk b/include/target.mk index 03192d3ebe..60760bf602 100644 --- a/include/target.mk +++ b/include/target.mk @@ -39,7 +39,7 @@ DEFAULT_PACKAGES+=procd-ujail endif # include seccomp ld-preload hooks if kernel supports it -ifneq ($(CONFIG_KERNEL_SECCOMP),) +ifneq ($(CONFIG_SECCOMP),) DEFAULT_PACKAGES+=procd-seccomp endif diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile index 6f506423f8..4c76045062 100644 --- a/package/system/procd/Makefile +++ b/package/system/procd/Makefile @@ -82,8 +82,7 @@ endef define Package/procd-seccomp SECTION:=base CATEGORY:=Base system - DEPENDS:=@(aarch64||arm||armeb||mips||mipsel||i386||powerpc||x86_64) @!TARGET_uml \ - @KERNEL_SECCOMP +libubox +libblobmsg-json + DEPENDS:=@SECCOMP +libubox +libblobmsg-json TITLE:=OpenWrt process seccomp helper + utrace endef -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] buildsystem: add CONFIG_SECCOMP
Until now, this feature was switched on via the kernel configuration option KERNEL_SECCOMP. The follwing change a7f794cd2aa104fdbd4c6e38f9b76373bf9b96e1 now requires that the package procd-seccomp must also enabled for the build. However, this is not the case we have no dependency to enable this package. Also the imagebuilder cannot build the image, because of the implicit package selection. This change adds a new configuration option CONFIG_SECCOMP like the CONFIG_SELINUX option. If the CONFIG_SECCOMP is selected then the package procd-seccomp and KERNEL_SECCOMP is enabled for this build. Signed-off-by: Florian Eckert --- config/Config-build.in| 11 +++ include/target.mk | 2 +- package/system/procd/Makefile | 3 +-- 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/config/Config-build.in b/config/Config-build.in index f0e1aaa695..5887d1a9c4 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -386,4 +386,15 @@ menu "Global build settings" endchoice + config SECCOMP + bool "Enable SECCOMP" + select KERNEL_SECCOMP + select PACKAGE_procd-seccomp + depends on (aarch64 || arm || armeb || mips || mipsel || i386 || powerpc || x86_64) + depends on !TARGET_uml + help + This option enables seccomp kernel features to safely + execute untrusted bytecode and selects the seccomp-variants + of procd + endmenu diff --git a/include/target.mk b/include/target.mk index 03192d3ebe..60760bf602 100644 --- a/include/target.mk +++ b/include/target.mk @@ -39,7 +39,7 @@ DEFAULT_PACKAGES+=procd-ujail endif # include seccomp ld-preload hooks if kernel supports it -ifneq ($(CONFIG_KERNEL_SECCOMP),) +ifneq ($(CONFIG_SECCOMP),) DEFAULT_PACKAGES+=procd-seccomp endif diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile index 6f506423f8..4c76045062 100644 --- a/package/system/procd/Makefile +++ b/package/system/procd/Makefile @@ -82,8 +82,7 @@ endef define Package/procd-seccomp SECTION:=base CATEGORY:=Base system - DEPENDS:=@(aarch64||arm||armeb||mips||mipsel||i386||powerpc||x86_64) @!TARGET_uml \ - @KERNEL_SECCOMP +libubox +libblobmsg-json + DEPENDS:=@SECCOMP +libubox +libblobmsg-json TITLE:=OpenWrt process seccomp helper + utrace endef -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
initramfs for ACPI tables on x86
Since the update of kernel from 5.4 to 5.10 in the openwrt master branch [1], I have problems with additional hardware on the I2C (SMBus) of my APU3. The Linux upstream removed the platform data support for my I2C IO-Expander mcp23s08 [3]. Because of this change I could not use my own written platform device specification anymore. This is common for this kind of device on x86 which does not support device-tree. See for exaple the platform init on the x86 geode board.[5] If the device supports ACPI, this is now the why to do this [6]. I am still in the process of building the SSDT ACPI table for the i2c mcp23s08 device connect to the SMBus. As I now know we could load these SSTD into the kernel during operation or via an initrd on boot. As far as I have seen, no initrd is loaded during normal operation [4] on OpenWrt. Is there any way to create an initrd to load the ACPI tables and then mount the initrd so the kernel can load this kind of files? What would this look like in OpenWrt? On other target we have the device-tree but on X86 this is not possible and we could only use ACPI for this kind of task. To do this the acpica package is needed to generate an SSDT [7] The initramfs that are created now run completely in RAM and are intended for development purposes only. Does anyone have any experience or has already deal with this topic of ACPI and inird in OpenWrt? I would be happy if someone shares their thoughts with me. -- Regards Florian [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/x86/Makefile;h=fbad527e0ac3239647a9d1eabcaf8fd751396973;hp=0ab322d8bc4fd31a75cb16dba8665b1db315398f;hb=64be0eadc17988f29d0a4b89569840d917746498;hpb=c9042202ad39e447a21afd91ec777bbc6cc8b72c [2] https://pcengines.ch/apu.htm [3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pinctrl/pinctrl-mcp23s08.c?h=v5.10.70=6aba6ed879b3471903c8ada28ba968a268df6143 [4] https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86/image/grub-pc.cfg;hb=fa13dd658f59df41b9184d4dc15a5b29530e7c2c [5] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/platform/geode/alix.c?h=v5.10.70 [6] https://www.youtube.com/watch?v=nlKjUAv3RL0_channel=OSDNConf [7] https://github.com/openwrt/packages/pull/16775 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uci: unnecessary write accesses
Thanks for your feedback I have written a small shell script, to track write access to the '/etc/config' directory. For this task I am using the inotify-tool package [1]. I am using the inotifywait tool to add the watchers [2] with a small shell script and log them to the syslog. If I change a 'uci' option with the the 'uci' commands, then I get create and write events for a temporary file in the '/etc/config/' directory. I didn't expect it to be like this. For example, if I now change a file using the 'uci' command, a tmp file is created under '/etc/config'. Is this correct? Or do we have a problem there. AFAIK tmp config are written in /tmp... But if I read this correctly, what inotifywait does, then these are events that happen in '/etc/config' and not in '/tmp'. I have not added a inotify to '/tmp'. I already thought that these are temporary files. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uci: unnecessary write accesses
I have written a small shell script, to track write access to the
'/etc/config' directory.
For this task I am using the inotify-tool package [1].
I am using the inotifywait tool to add the watchers [2] with a small
shell script and log them to the syslog.
If I change a 'uci' option with the the 'uci' commands, then I get
create and write events for a temporary file in the '/etc/config/'
directory.
I didn't expect it to be like this.
For example, if I now change a file using the 'uci' command, a tmp file
is created under '/etc/config'.
Is this correct? Or do we have a problem there.
I have always thought that for embedded systems with flashes it is
important to make as few write accesses as possible.
Shell commands to change uci config:
root@st-dev-07 ~ # uci set system.led_Power.trigger=none
root@st-dev-07 ~ # uci commit system
Log output of my Script:
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CREATE","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":"system","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"ATTRIB","time":"09/21/21
12:50:38"}
I am bothered about the file '.system.uci-fEGgbp'?
To do this without my script on the console, the following command can
be used on the shell:
inotifywait --quiet --monitor -e
"create,delete,modify,close_write,attrib" /etc/config
Then you will get the following output if you change an option with uci:
/etc/config/ CREATE .system.uci-lOlFid
/etc/config/ MODIFY .system.uci-lOlFid
/etc/config/ MODIFY .system.uci-lOlFid
/etc/config/ CLOSE_WRITE,CLOSE .system.uci-lOlFid
/etc/config/ CLOSE_WRITE,CLOSE system
/etc/config/ ATTRIB .system.uci-lOlFid
---
Florian
[1]
https://github.com/openwrt/packages/blob/master/utils/inotify-tools/Makefile
[2] https://www.man7.org/linux/man-pages/man1/inotifywait.1.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: make os-release symbolic link absolute
* resolv.conf -> /tmp/resolv.conf * /tmp/TZmtab -> /proc/mounts For consistency, this should also apply to `/usr/lib/os-release`. Is there any other reason than consistency to change this? Yes, I have to elaborate on that. I have a small script that boots the system into a called it "sandbox" mode. If I do not save the sandbox config changes the system boots with old configuration. This means that the changes to the configurations under /etc/ are not permanently saved, because I put a tmpfs over the /etc/. For this to work, however, I have to copy the data somewhere else beforehand and then mount it. mkdir -p /tmp/permetc mount --bind /etc /tmp/permetc mount -t tmpfs -o size="3M" none /etc cp -r /tmp/permetc/* /etc Now I can configure the system as I need it. If I make a mistake, I can reboot the system and the old configuration will be reloaded. So if I want to check what has changed (sandbox config vs. bootup config). I display a diff with the command diff -Naur /etc/permetc/ /etc The problem now is that the file "../usr/lib/os-release" is always shown as not existing, because it is a relative path and the file under /tmp/permetc/../usr/lib/os-release/ does not exist. I prefer relative links because they also work when the file system is accessed by the build system like Paul said. But if that is the case, could we not write the data into the target file under /usr/lib/os-release and not into the linked file? This would make such simple changes possible. The normal case should be that the folder structure should look like on the target system just as we need it. By the way, this is the only link that is relative (at least on my system) all others are absolute. However thanks for the feedback and your time -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: make os-release symbolic link absolute
The file `/etc/os-release` is currently a relative link to `../usr/lib/os-release`. The follwing links on my `/etc` are also absolute: * localtime -> /tmp/localtime * resolv.conf -> /tmp/resolv.conf * /tmp/TZmtab -> /proc/mounts For consistency, this should also apply to `/usr/lib/os-release`. Signed-off-by: Florian Eckert --- package/base-files/files/etc/os-release | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/base-files/files/etc/os-release b/package/base-files/files/etc/os-release index c4c75b419c..d98fc7a7ac 12 --- a/package/base-files/files/etc/os-release +++ b/package/base-files/files/etc/os-release @@ -1 +1 @@ -../usr/lib/os-release \ No newline at end of file +/usr/lib/os-release \ No newline at end of file -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel/modules: prevent bonding driver to create default bond0 interface
When loading the bonding driver, bonding interface are automatically created on bonding module load. > ip a s bond0 > 14: bond0: mtu 1500 qdisc noop state DOWN > group default qlen 1000 >link/ether a6:f2:20:64:c1:b9 brd ff:ff:ff:ff:ff:ff This is not necessary in openwrt as we do not use this created interface. The netifd creates a bonding interface based on its network configuration name and configures this over the netifd bonding proto handler. In order to keep the overview of the interfaces clear, bonding interfaces should not be created automatically when loading this module, because they are not used anyway. Signed-off-by: Florian Eckert --- package/kernel/linux/modules/netsupport.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 62d79db51e..166172dbf3 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -48,6 +48,7 @@ define KernelPackage/bonding KCONFIG:=CONFIG_BONDING FILES:=$(LINUX_DIR)/drivers/net/bonding/bonding.ko AUTOLOAD:=$(call AutoLoad,40,bonding) + MODPARAMS.bonding:=max_bonds=0 endef define KernelPackage/bonding/description -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/4] target/imagebuilder: change help text for image build
Unify the help text for the image makefile target. That it looks unifrom as with the otheer help texts. Signed-off-by: Florian Eckert --- target/imagebuilder/files/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/imagebuilder/files/Makefile b/target/imagebuilder/files/Makefile index c232d510a6..da7c422296 100644 --- a/target/imagebuilder/files/Makefile +++ b/target/imagebuilder/files/Makefile @@ -36,7 +36,7 @@ Available Commands: image: Build an image (see below for more information). package_depends: Show installation dependency of the package -Building images: +image: By default 'make image' will create an image with the default target profile and package set. You can use the following parameters to change that: -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/4] target/imagebuilder: add help text and rename whatdepends to package_whatdepens
Add the missing help text for the package_whatdepends makefile target. Signed-off-by: Florian Eckert --- target/imagebuilder/files/Makefile | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/target/imagebuilder/files/Makefile b/target/imagebuilder/files/Makefile index 8d02b8752d..1d8bf9526e 100644 --- a/target/imagebuilder/files/Makefile +++ b/target/imagebuilder/files/Makefile @@ -35,6 +35,7 @@ Available Commands: clean: Remove images and temporary build files image: Build an image (see below for more information). manifest: Show all package that will be installed into to image + package_whatdepends: Show which packages have a dependency on this package_depends: Show installation dependency of the package image: @@ -58,6 +59,13 @@ manifest: make manifest PACKAGES=" [ [ ...]]" # include extra packages make manifest STRIP_ABI=1 # remove ABI version from printed package names + +package_whatdepends: + List "all" packages that have a dependency on this package + You can use the following parameters: + + make package_whatdepends PACKAGE="" + package_depends: List "all" packages dependency of the package You can use the following parameters: @@ -261,7 +269,7 @@ manifest: FORCE $(if $(PROFILE),USER_PROFILE="$(PROFILE_FILTER)") \ $(if $(PACKAGES),USER_PACKAGES="$(PACKAGES)")) -whatdepends: FORCE +package_whatdepends: FORCE ifeq ($(PACKAGE),) @echo 'Variable `PACKAGE` is not set but required by `whatdepends`' @exit 1 @@ -278,4 +286,4 @@ endif @$(OPKG) depends -A $(PACKAGE) -.SILENT: help info image manifest whatdepends package_depends +.SILENT: help info image manifest package_whatdepends package_depends -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/4] target/imagebuilder: update help text for manifest target
Add missing help text for manifest makefile target in the quick overview help output. Also unify the help text for the manifest makefile target, so that it looks uniform like the other help texts. Signed-off-by: Florian Eckert --- target/imagebuilder/files/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/imagebuilder/files/Makefile b/target/imagebuilder/files/Makefile index da7c422296..8d02b8752d 100644 --- a/target/imagebuilder/files/Makefile +++ b/target/imagebuilder/files/Makefile @@ -34,6 +34,7 @@ Available Commands: info: Show a list of available target profiles clean: Remove images and temporary build files image: Build an image (see below for more information). + manifest: Show all package that will be installed into to image package_depends: Show installation dependency of the package image: @@ -49,7 +50,7 @@ image: make image DISABLED_SERVICES=" [ [ ..]]" # Which services in /etc/init.d/ should be disabled make image ADD_LOCAL_KEY=1 # store locally generated signing key in built images -Print manifest: +manifest: List "all" packages which get installed into the image. You can use the following parameters: -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/4] target/imagebuilder: add depends target to show all package that gets installed
This commits adds the makefile targets `package_depends` this wrapper is a call to `opkg depends`. This command shows what install dependencies exist when the package is installed into the image Signed-off-by: Florian Eckert --- target/imagebuilder/files/Makefile | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/target/imagebuilder/files/Makefile b/target/imagebuilder/files/Makefile index aeae98aacd..c232d510a6 100644 --- a/target/imagebuilder/files/Makefile +++ b/target/imagebuilder/files/Makefile @@ -34,6 +34,7 @@ Available Commands: info: Show a list of available target profiles clean: Remove images and temporary build files image: Build an image (see below for more information). + package_depends: Show installation dependency of the package Building images: By default 'make image' will create an image with the default @@ -56,6 +57,12 @@ Print manifest: make manifest PACKAGES=" [ [ ...]]" # include extra packages make manifest STRIP_ABI=1 # remove ABI version from printed package names +package_depends: + List "all" packages dependency of the package + You can use the following parameters: + + make package_depends PACKAGE="" + endef $(eval $(call shexport,Helptext)) @@ -261,4 +268,13 @@ endif @$(MAKE) -s package_reload @$(OPKG) whatdepends -A $(PACKAGE) -.SILENT: help info image manifest whatdepends +package_depends: FORCE +ifeq ($(PACKAGE),) + @echo 'Variable `PACKAGE` is not set but required by `package_depends`' + @exit 1 +endif + @$(MAKE) -s package_reload + @$(OPKG) depends -A $(PACKAGE) + + +.SILENT: help info image manifest whatdepends package_depends -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] target/x86: add grub2-bios-setup to DEFAULT_PACKAGES
With the commit 5876d6a62fc0ae5799e7d9c896356f75c99a6f0a the command under `/usr/sbin/grub-bios-setup` has been moved to its own package named `grub-bios-setup`. The script `81_upgrade_bootloader` under `/lib/preinit` is used by all x86 targets to update the bootloader. The script is using the command `grub-bios-setup` for this. I get the following output at the first boot after the upgrade. `/etc/preinit: line 9: /usr/sbin/grub-bios-setup: not found`. To fix this, the DEFAULT_PACKAGES dependency is extended by the entry `grub2-bios-setup` so that the missing command is installed again. Signed-off-by: Florian Eckert --- target/linux/x86/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile index 0ab322d8bc..b1891de0ce 100644 --- a/target/linux/x86/Makefile +++ b/target/linux/x86/Makefile @@ -17,7 +17,10 @@ KERNELNAME:=bzImage include $(INCLUDE_DIR)/target.mk -DEFAULT_PACKAGES += partx-utils mkf2fs e2fsprogs kmod-button-hotplug +DEFAULT_PACKAGES += \ + partx-utils mkf2fs \ + e2fsprogs kmod-button-hotplug \ + grub2-bios-setup $(eval $(call BuildTarget)) -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
grub2-editenv: does depend since recently on liblzma
Hello Dirk, I have build a fresh master branch recently, Since your last change [1] on grub2, I have now a new dependency on liblzma for the install package grub2-editenv. root@st-dev-07 /usr/lib # ldd /root/grub-editenv /lib/ld-musl-x86_64.so.1 (0x7f684b088000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x7f684b06d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f684b059000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7f684b088000) This was not the case before your update. root@st-dev-07 /usr/sbin # ldd /usr/sbin/grub-editenv /lib/ld-musl-x86_64.so.1 (0x7fd970176000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fd970162000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7fd970176000) My build complains that it cannot satisfy the runtime package dependency for grub2-editenv. install -d -m0755 /home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/grub-pc/grub-2.06~rc1/ipkg-x86_64/grub2-editenv/usr/sbin install -m0755 /home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/grub-pc/grub-2.06~rc1/grub-editenv /home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/grub-pc/grub-2.06~rc1/ipkg-x86_64/grub2-editenv/usr/sbin/ find /home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/build_dir/target-x86_64_musl/linux-x86_64/grub-pc/grub-2.06~rc1/ipkg-x86_64/grub2-editenv -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs -r rm -rf Package grub2-editenv is missing dependencies for the following libraries: liblzma.so.5 make[2]: *** [Makefile:166: /home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/bin/APOS/feckert/master/master-Maggie-455-ga5edc0e8e/x86_64/targets/x86/64/packages/grub2-editenv_2.06~rc1-1_x86_64.ipk] Error 1 make[2]: Leaving directory '/home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/package/boot/grub2' time: package/boot/grub2/pc/compile#78.64#9.79#83.88 ERROR: package/boot/grub2 failed to build (build variant: pc). make[1]: *** [package/Makefile:116: package/boot/grub2/compile] Error 1 make[1]: Leaving directory '/home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt' make: *** [/home/feckert/workspace/openwrt/LDM-master-x86_64/build/openwrt/include/toplevel.mk:230: package/boot/grub2/compile] Error 2 This is because it lacks dependency on liblzma during build package install. If I add the following changes to the package all works as expected. diff --git a/package/boot/grub2/Makefile b/package/boot/grub2/Makefile index b3cb5e076f..885be65dc6 100644 --- a/package/boot/grub2/Makefile +++ b/package/boot/grub2/Makefile @@ -46,7 +46,7 @@ define Package/grub2-editenv SUBMENU:=Boot Loaders TITLE:=Grub2 Environment editor URL:=http://www.gnu.org/software/grub/ - DEPENDS:=@TARGET_x86 + DEPENDS:=@TARGET_x86 +liblzma VARIANT:=pc endef This is a hotfix but I dont´t think this is the final solution, because lzma is provided by the package xz. And This is maintained in the package feed [2]. A dependency from a core package to the package feed is not allowed as I know? The best would be to move xz to openwrt core. But as far as I know this was the case before, but then it was moved to the package feed for reasons I don't know. What is your opinion on this or how can we solve this in another way? Or do you not have this problem? Best regards Florian [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e74d81ece2e2932a4f370d8e6d180061a6a2c229 [2] https://github.com/openwrt/packages/tree/master/utils/xz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] uqmi: fix network registration loop
On 2021-05-08 12:33, Baptiste Jonglez wrote:
Applied, thanks.
Does this need to be backported to 21.02 or even 19.07?
yes that would not be bad at least for openwrt-21.02
On openwrt-19.07 there are additional commits needed.
Thanks for take care
Baptiste
On 20-04-21, thomas.rich...@kontron.com wrote:
From: Thomas Richard
With some debug in qmi.sh using following patch, some errors are
visible
in the registration step
@@ -29,6 +29,7 @@ proto_qmi_init_config() {
}
proto_qmi_setup() {
+ set -x
local interface="$1"
local dataformat connstat plmn_mode mcc mnc
local device apn auth username password pincode delay modes
pdptype
@@ -224,6 +225,8 @@ proto_qmi_setup() {
fi
done
+ registration=$(uqmi -s -d "$device" --get-serving-system)
+
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes
"$modes" > /dev/null 2>&1
echo "Starting network $interface"
During the boot of the system, modem could not start automatically its
network registration.
netifd: wan (9235): + echo 'Waiting for network registration'
netifd: wan (9235): Waiting for network registration
netifd: wan (9235): + local 'registration_timeout=0'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): + grep '"searching"'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): +
registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
netifd: wan (9235): + '[' -n ]
netifd: wan (9235): + echo 'Starting network wan'
As the while loop checks only "searching" pattern, uqmi.sh script
quits
searching loop and continues whereas the modem is not registered
Other issue, after X seconds modem stops searching.
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
netifd: wan (9213): + let registration_timeout++
netifd: wan (9213): + sleep 1
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + registration='{"registration":"not_registered"}'
netifd: wan (9213): + '[' -n ]
netifd: wan (9213): + echo 'Starting network wan'
netifd: wan (9213): Starting network wan
If registration_timeout is not expired, registration can be restarted
Signed-off-by: Thomas Richard
---
package/network/utils/uqmi/Makefile| 2 +-
.../utils/uqmi/files/lib/netifd/proto/qmi.sh | 35
--
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/package/network/utils/uqmi/Makefile
b/package/network/utils/uqmi/Makefile
index 68958a3729..da54ba0f46 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uqmi
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index a6c785eb56..c0134f44dd 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -209,19 +209,36 @@ proto_qmi_setup() {
uqmi -s -d "$device" --sync > /dev/null 2>&1
+ uqmi -s -d "$device" --network-register > /dev/null 2>&1
+
echo "Waiting for network registration"
+ sleep 1
local registration_timeout=0
- while uqmi -s -d "$device" --get-serving-system | grep '"searching"'
> /dev/null; do
- [ -e "$device" ] || return 1
- if [ "$registration_timeout" -lt "$timeout" -o "$timeout" = "0" ];
then
- let registration_timeout++
- sleep 1;
+ local registration_state=""
+ while true; do
+ registration_state=$(uqmi -s -d "$device" --get-serving-system
2>/dev/null | jsonfilter -e "@.registration" 2>/dev/null)
+
+ [ "$registration_state" = "registered" ] && break
+
+ if [ "$registration_state" = "searching" ] || [
"$registration_state" = "not_registered" ]; then
+ if [ "$registration_timeout" -lt "$timeout" ] || [ "$timeout" =
"0" ]; then
+ [ "$registration_state" = "searching" ] || {
+ echo "Device stopped network registration. Restart network
registration"
+ uqmi -s -d "$device" --network-register >
/dev/null 2>&1
+ }
+ let registration_timeout++
+ sleep 1
+ continue
+ fi
+ echo "Network registration failed, registration timeout
reached"
Re: [PATCH 0/3] Engine configuration series
Hello Eneas, On 2021-04-28 14:17, Eneas U de Queiroz wrote: This series builds upon what was first started by Daniel Danzberger, with some suggestions by Florian Eckert to enable the engines when they are installed. The series split is subject to discussion: - the first commit does a patch cleanup proposed by Rosen Penev, and also splits the configuration from one monolithic file to one file per engine, and also an engines list. - the sencond implements my first proposal, of enabling engines during their installation. It introduces an engine.mk file that provides menu placement, basic dependencies and the postinst, postrm functions for engine packages, and can be used for out of tree engine packages. - the third commit introduces uci configuration, and does the engines list generation during startup, or when an engine package is installed or removed. The first commit received basic testing on mvebu running master, covering afalg and devcrpto engines built as modules. The second and third commits had testing expanded to checking built-in engine builds. I have not squashed the commits, but I do think that 2 and 3 may be squashed if 3 is merged. The first one is just cleanup, and the second adds complexity that ended up being removed by the third commit. Nonetheless, all of them result in a working package. I thought about expanding uci support to include other configuration commands, but it would drop the documentation provided by the current config files. Besides, each engine has its own options, which would add complexity to config generation if you are to actually verify them. Passing unknown commands straight from uci to the config files would be simple and work, but it would be hard to find what options are available, compared to just reading the example configs provided otherwise. I think the uci config options are great, you can build on them and make the configuration for openssl better and can finally be configured with the uci. openssl engine -vv would show the commands, with some basic description of them, but getting the supported arguments may not be straightforward. For example, gost engine has "CRYPT_PARAMS: OID of default GOST 28147-89 parameters". All I could do to help was to point to a header file where the actual list of supported parameters is defined. The only thing I have to say is that if the configuration no longer fits, then we have a non-functioning openssl! You just have to know what you are doing when you change the openssl configuration. After this is merged, I will adapt the two engines in the packages feed. I think we have to validate the uci options in the future in the openssl service on startup. Regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] openssl: configure engines with uci
Hello Eneas,
Nice work.
My remarks or suggestions see inline.
define Package/libopenssl-conf/conffiles
/etc/ssl/openssl.cnf
-/etc/ssl/engines.cnf.d/engines.cnf
$(if
CONFIG_OPENSSL_ENGINE_BUILTIN_DEVCRYPTO,/etc/ssl/engines.cnf.d/devcrypto.cnf)
$(if
CONFIG_OPENSSL_ENGINE_BUILTIN_PADLOCK,/etc/ssl/engines.cnf.d/padlock.cnf)
I think AFALG is missing there?
endef
@@ -378,15 +377,17 @@ define Package/libopenssl/install
endef
define Package/libopenssl-conf/install
- $(INSTALL_DIR) $(1)/etc/ssl/engines.cnf.d
+ $(INSTALL_DIR) $(1)/etc/ssl/engines.cnf.d $(1)/etc/config
$(1)/etc/init.d
$(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/
- $(CP) ./files/engines.cnf $(1)/etc/ssl/engines.cnf.d/
+ $(INSTALL_BIN) ./files/openssl.init $(1)/etc/init.d/openssl
+ $(SED) 's!%ENGINES_DIR%!/usr/lib/$(ENGINES_DIR)!'
$(1)/etc/init.d/openssl
I do not understand that waht you are doing there.
+ touch $(1)/etc/config/openssl
$(if $(CONFIG_OPENSSL_ENGINE_BUILTIN_DEVCRYPTO),
$(CP) ./files/devcrypto.cnf $(1)/etc/ssl/engines.cnf.d/
- echo devcrypto=devcrypto >>
$(1)/etc/ssl/engines.cnf.d/engines.cnf)
+ echo -e "config engine 'devcrypto'\n\toption enabled '1'" >>
$(1)/etc/config/openssl)
$(if $(CONFIG_OPENSSL_ENGINE_BUILTIN_PADLOCK),
$(CP) ./files/padlock.cnf $(1)/etc/ssl/engines.cnf.d/
- echo padlock=padlock >> $(1)/etc/ssl/engines.cnf.d/engines.cnf)
+ echo -e "\nconfig engine 'padlock'\n\toption enabled '1'" >>
$(1)/etc/config/openssl)
What about AFALG?
endef
define Package/openssl-util/install
diff --git a/package/libs/openssl/engine.mk
b/package/libs/openssl/engine.mk
index 482b5ad5e8..efa46d7214 100644
--- a/package/libs/openssl/engine.mk
+++ b/package/libs/openssl/engine.mk
@@ -23,60 +23,20 @@ define Package/openssl/add-engine
define Package/$$(OSSL_ENG_PKG)/postinst :=
#!/bin/sh
-# 1 == non-empty: suggest reinstall
-error_out() {
-[ "$1" ] && cat <<- EOF
- Reinstalling the libopenssl-conf package may fix this:
+OPENSSL_UCI="{IPKG_INSTROOT}/etc/config/openssl"
- opkg install --force-reinstall libopenssl-conf
- EOF
-cat <<- EOF
+if [ -n "{IPKG_INSTROOT}" ] || ! uci -q get openssl.$(1)
>/dev/null; then
+cat << EOF >> "{OPENSSL_UCI}"
- Then, you will have to reinstall this package, and any other engine
package you have
- you have previously installed to ensure they are enabled:
-
- opkg install --force-reinstall $$(OSSL_ENG_PKG)
[OTHER_ENGINE_PKG]...
-
- EOF
-exit 1
-}
-ENGINES_CNF="{IPKG_INSTROOT}/etc/ssl/engines.cnf.d/engines.cnf"
-OPENSSL_CNF="{IPKG_INSTROOT}/etc/ssl/openssl.cnf"
-if [ ! -f "{OPENSSL_CNF}" ]; then
-echo -e "ERROR: File {OPENSSL_CNF} not found."
-error_out reinstall
-fi
-if ! grep -q "^.include /etc/ssl/engines.cnf.d" "{OPENSSL_CNF}";
then
-cat <<- EOF
- Your /etc/ssl/openssl.cnf file is not loading engine configuration
files from
- /etc/ssl/engines.cnf.d. You should consider start with a fresh,
updated OpenSSL config by
- running:
-
- opkg install --force-reinstall --force-maintainer libopenssl-conf
-
- The above command will overwrite any changes you may have made to
both /etc/ssl/openssl.cnf
- and /etc/ssl/engines.cnf.d/engines.cnf files, so back them up first!
- EOF
-error_out
-fi
-if [ ! -f "{ENGINES_CNF}" ]; then
-echo "Can't configure $$(OSSL_ENG_PKG): File {ENGINES_CNF} not
found."
-error_out reinstall
-fi
-if grep -q "$(1)=$(1)" "{ENGINES_CNF}"; then
-echo "$$(OSSL_ENG_PKG): $(1) engine was already configured.
Nothing to be done."
-else
-echo "$(1)=$(1)" >> "{ENGINES_CNF}"
-echo "$$(OSSL_ENG_PKG): $(1) engine enabled. All done!"
+config engine '$(1)'
+ option enabled '1'
+EOF
From my point of view, I think it would be better if we used the uci cli
command directly here.
to add the config engine section and enable this engine.
fi
+[ -z "{IPKG_INSTROOT}" ] && /etc/init.d/openssl reload
endef
- define Package/$$(OSSL_ENG_PKG)/prerm :=
+ define Package/$$(OSSL_ENG_PKG)/postrm :=
#!/bin/sh
-ENGINES_CNF="{IPKG_INSTROOT}/etc/ssl/engines.cnf.d/engines.cnf"
-[ -f "{ENGINES_CNF}" ] || exit 0
-sed -e '/$(1)=$(1)/d' -i "{ENGINES_CNF}"
+[ -z "{IPKG_INSTROOT}" ] && /etc/init.d/openssl reload
Should we not also remove the uci option on an uninstall wit the uci
command?
endef
endef
-
-
diff --git a/package/libs/openssl/files/openssl-engines.init
b/package/libs/openssl/files/openssl-engines.init
new file mode 100644
index 00..050a96f70a
--- /dev/null
+++ b/package/libs/openssl/files/openssl-engines.init
@@ -0,0 +1,19 @@
+#!/bin/sh /etc/rc.common
Is the init script also switched on at the first boot?
So that the service runs immediately?
Not that the service has to be switched on in
Re: [PATCH] package: openssl: Enable built engines per default
Hello Eneas
How about if we create a uci default script and check on the running
system what is installed?
And then we could generate a file and add or remove an include line
form
the openssl.cnf [1]?
Hi Florian, Daniel
I think we can manage something like that. The .include option can
load all files in a directory (/etc/ssl/engines.d/), and won't fail if
there aren't any files--the directory itself must exist. Each engine
package can install its own file there, ahd have a post-install script
that adds a line to an "engines.cnf" file if there isn't any:
add_engine() {
# $1 = engine name (engine .so file without the .so extension)
grep -q "$1=$1" /etc/ssl/engines.d/engines.cnf && return
echo "$1=$1" >> /etc/ssl/engines.d/engines.cnf
}
/etc/ssl/engines.d/engines.cnf would start out with just the [engines]
header and some comments explaining its use and warning not to edit
something that would break things.
What do you think?
The plan sounds good :+1:
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] package: openssl: Enable built engines per default
Hello Daniel, Hello Eneas, On 2021-04-23 01:36, Eneas U de Queiroz wrote: On Thu, Apr 22, 2021 at 3:55 AM Daniel Danzberger wrote: Automatically enable an engine in the openssl.cnf if it has been build. Before this change, /etc/openssl.cnf had to be edited manually on the system to enable the engine. +define Package/libopenssl-conf/enable + $(if $(CONFIG_PACKAGE_libopenssl-$(2)),sed -i s/^\#*$(2)=$(2)/$(2)=$(2)/ $(1)/etc/ssl/openssl.cnf) +endef define Package/libopenssl-conf/install $(INSTALL_DIR) $(1)/etc/ssl $(CP) $(PKG_INSTALL_DIR)/etc/ssl/openssl.cnf $(1)/etc/ssl/ + $(call Package/libopenssl-conf/enable,$(1),devcrypto) + $(call Package/libopenssl-conf/enable,$(1),afalg) + $(call Package/libopenssl-conf/enable,$(1),padlock) I do like the idea, though. My first thought was to add an install script to the engine packages. The problem is that the config file may have been changed in a way that sed may produce unwanted results. How about if we create a uci default script and check on the running system what is installed? And then we could generate a file and add or remove an include line form the openssl.cnf [1]? Another option, which may be the easiest and safest, is to use your approach, but only uncomment the engines built into the firmware (=y), and not the ones built as modules. I think this is not an option, because not all want to have all engines installed. That is my opinion. Thanks florian [1] https://github.com/openssl/openssl/blob/master/apps/openssl.cnf#L10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] uqmi: fix network registration loop
On 2021-04-20 16:49, thomas.rich...@kontron.com wrote:
From: Thomas Richard
With some debug in qmi.sh using following patch, some errors are
visible
in the registration step
@@ -29,6 +29,7 @@ proto_qmi_init_config() {
}
proto_qmi_setup() {
+ set -x
local interface="$1"
local dataformat connstat plmn_mode mcc mnc
local device apn auth username password pincode delay modes
pdptype
@@ -224,6 +225,8 @@ proto_qmi_setup() {
fi
done
+ registration=$(uqmi -s -d "$device" --get-serving-system)
+
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes
"$modes" > /dev/null 2>&1
echo "Starting network $interface"
During the boot of the system, modem could not start automatically its
network registration.
netifd: wan (9235): + echo 'Waiting for network registration'
netifd: wan (9235): Waiting for network registration
netifd: wan (9235): + local 'registration_timeout=0'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): + grep '"searching"'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): +
registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
netifd: wan (9235): + '[' -n ]
netifd: wan (9235): + echo 'Starting network wan'
As the while loop checks only "searching" pattern, uqmi.sh script quits
searching loop and continues whereas the modem is not registered
Other issue, after X seconds modem stops searching.
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
netifd: wan (9213): + let registration_timeout++
netifd: wan (9213): + sleep 1
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + registration='{"registration":"not_registered"}'
netifd: wan (9213): + '[' -n ]
netifd: wan (9213): + echo 'Starting network wan'
netifd: wan (9213): Starting network wan
If registration_timeout is not expired, registration can be restarted
Signed-off-by: Thomas Richard
Tested-by: Florian Eckert
Works as expected.
Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: fix network registration loop
On 2021-04-20 08:20, Florian Eckert wrote:
On 2021-04-19 19:46, thomas.rich...@kontron.com wrote:
From: Thomas Richard
Instrumenting qmi.sh script with following patch, some errors are
visible.
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -29,6 +29,7 @@ proto_qmi_init_config() {
}
proto_qmi_setup() {
+ set -x
local interface="$1"
local dataformat connstat plmn_mode mcc mnc
local device apn auth username password pincode delay modes
pdptype
@@ -224,6 +225,8 @@ proto_qmi_setup() {
fi
done
+ registration=$(uqmi -s -d "$device" --get-serving-system)
+
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes
"$modes" > /dev/null 2>&1
echo "Starting network $interface"
During the boot of the system, modem could not start automatically its
network registration.
netifd: wan (9235): + echo 'Waiting for network registration'
netifd: wan (9235): Waiting for network registration
netifd: wan (9235): + local 'registration_timeout=0'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): + grep '"searching"'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): +
registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
netifd: wan (9235): + '[' -n ]
netifd: wan (9235): + echo 'Starting network wan'
As the while loop checks only "searching" pattern, uqmi.sh script
quits searching loop and continues whereas the modem is not registered
Other issue, after X seconds modem stop searching.
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
netifd: wan (9213): + let registration_timeout++
netifd: wan (9213): + sleep 1
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + registration='{"registration":"not_registered"}'
netifd: wan (9213): + '[' -n ]
netifd: wan (9213): + echo 'Starting network wan'
netifd: wan (9213): Starting network wan
If registration_timeout is not expired, registration can be restarted
Signed-off-by: Thomas Richard
Tested-by: Florian Eckert
Works as expected.
Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: fix network registration loop
On 2021-04-19 19:46, thomas.rich...@kontron.com wrote:
From: Thomas Richard
Instrumenting qmi.sh script with following patch, some errors are
visible.
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -29,6 +29,7 @@ proto_qmi_init_config() {
}
proto_qmi_setup() {
+ set -x
local interface="$1"
local dataformat connstat plmn_mode mcc mnc
local device apn auth username password pincode delay modes
pdptype
@@ -224,6 +225,8 @@ proto_qmi_setup() {
fi
done
+ registration=$(uqmi -s -d "$device" --get-serving-system)
+
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes
"$modes" > /dev/null 2>&1
echo "Starting network $interface"
During the boot of the system, modem could not start automatically its
network registration.
netifd: wan (9235): + echo 'Waiting for network registration'
netifd: wan (9235): Waiting for network registration
netifd: wan (9235): + local 'registration_timeout=0'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): + grep '"searching"'
netifd: wan (9235): + uqmi -s -d /dev/cdc-wdm1 --get-serving-system
netifd: wan (9235): +
registration='{"registration":"not_registered","plmn_mcc":208,"plmn_mnc":20,"plmn_description":"","roaming":true}'
netifd: wan (9235): + '[' -n ]
netifd: wan (9235): + echo 'Starting network wan'
As the while loop checks only "searching" pattern, uqmi.sh script
quits searching loop and continues whereas the modem is not registered
Other issue, after X seconds modem stop searching.
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + '[' -e /dev/cdc-wdm0 ]
netifd: wan (9213): + '[' 3 -lt 0 -o 0 '=' 0 ]
netifd: wan (9213): + let registration_timeout++
netifd: wan (9213): + sleep 1
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + grep '"searching"'
netifd: wan (9213): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
netifd: wan (9213): + registration='{"registration":"not_registered"}'
netifd: wan (9213): + '[' -n ]
netifd: wan (9213): + echo 'Starting network wan'
netifd: wan (9213): Starting network wan
If registration_timeout is not expired, registration can be restarted
Signed-off-by: Thomas Richard
---
package/network/utils/uqmi/Makefile| 2 +-
.../utils/uqmi/files/lib/netifd/proto/qmi.sh | 35
--
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/package/network/utils/uqmi/Makefile
b/package/network/utils/uqmi/Makefile
index 68958a3729..da54ba0f46 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uqmi
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uqmi.git
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
index a6c785eb56..c29187cfbf 100755
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -209,19 +209,36 @@ proto_qmi_setup() {
uqmi -s -d "$device" --sync > /dev/null 2>&1
+ uqmi -s -d "$device" --network-register > /dev/null 2>&1
+
echo "Waiting for network registration"
+ sleep 1
local registration_timeout=0
- while uqmi -s -d "$device" --get-serving-system | grep '"searching"'
> /dev/null; do
- [ -e "$device" ] || return 1
- if [ "$registration_timeout" -lt "$timeout" -o "$timeout" = "0" ];
then
Could we please use not -o or -a?
In OpenWrt we prefer && or || pattern
- let registration_timeout++
- sleep 1;
+ local registration_state=""
+ while true; do
+ registration_state=$(uqmi -s -d "$device" --get-serving-system
2>/dev/null | jsonfilter -e "@.registration" 2>/dev/null)
+
+ [ "$registration_state" = "registered" ] && break
+
+ if [ "$registration_state" = "searching" -o
"$registration_state" =
"not_registered" ]; then
+ [ "$registration_timeout" -lt "$timeout" -o "$timeout" = "0" ]
&& {
+ [ "$registration_state" = "searching" ] || {
+ echo "Device stopped network
registration. Restart
network registration"
+ uqmi -s -d "$device" --network-register >
/dev/null 2>&1
+ }
+ let registration_timeout++
+ sleep 1
+ continue
+ }
+ echo "Network registration failed, registration timeout
reached"
else
-
Re: OpenWrt 21.02-rc1
Hello, If there are some other bugs in the 21.02 branch which are fixed in master, we can backport the fixed as long as they are not so big. If there is something missing, just ask on the mainling list. Since last weekend the following patch was merged into master. The patch extends ltq-vdsl ubus interface with the missing state_num and power_state_num values. https://github.com/openwrt/openwrt/commit/4407d45d9667ab3d376ad4a6b760e07f4dd43e49#diff-ff00a3f4f318bb11684e008813bd876f0865ce6c2c681ec26b0bf178b4e83163 Could we please backport this to the branch openwrt-21.02 before rc1 stable release? Thanks Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v6 1/1] ltq-vdsl-app: extent dsl metrics with state_num and power_state_num
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit adds the missing information.
For this the internal values are mapped to numbers.
* additional JSON output for state_num:
"state_num":
Since not all values are meaningful only the following values are
implemented, this can be extended if the future.
* LSTATE_MAP_NOT_INITIALIZED
* LSTATE_MAP_EXCEPTION
* LSTATE_MAP_IDLE
* LSTATE_MAP_SILENT
* LSTATE_MAP_HANDSHAKE
* LSTATE_MAP_FULL_INIT
* LSTATE_MAP_SHOWTIME_NO_SYNC
* LSTATE_MAP_SHOWTIME_TC_SYNC
* LSTATE_MAP_RESYNC
* additinal JSON output for power_level:
"power_state_num": ,
Since there are not so many here, all are mapped.
* PSTATE_MAP_NA,
* PSTATE_MAP_L0,
* PSTATE_MAP_L1,
* PSTATE_MAP_L2,
* PSTATE_MAP_L3,
Signed-off-by: Florian Eckert
v6:
Add state LSTATE_MAP_NOT_INITILIZED at the beginning of the list
Start the list LSTATE_MAP with -1
---
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 72 +++
1 file changed, 58 insertions(+), 14 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 52b2be20e1..91f36b18a7 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -34,6 +34,12 @@
str = text; \
break;
+#define STR_CASE_MAP(id, text, number) \
+ case id: \
+ str = text; \
+ map = number; \
+ break;
+
#define IOCTL(type, request) \
type out; \
memset(, 0, sizeof(type)); \
@@ -99,6 +105,34 @@ typedef enum {
PROFILE_35B,
} profile_t;
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ LSTATE_MAP_UNKNOWN = -1,
+ LSTATE_MAP_NOT_INITIALIZED,
+ LSTATE_MAP_EXCEPTION,
+ LSTATE_MAP_IDLE,
+ LSTATE_MAP_SILENT,
+ LSTATE_MAP_HANDSHAKE,
+ LSTATE_MAP_FULL_INIT,
+ LSTATE_MAP_SHOWTIME_NO_SYNC,
+ LSTATE_MAP_SHOWTIME_TC_SYNC,
+ LSTATE_MAP_RESYNC,
+};
+
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ PSTATE_MAP_UNKNOWN = -2,
+ PSTATE_MAP_NA,
+ PSTATE_MAP_L0,
+ PSTATE_MAP_L1,
+ PSTATE_MAP_L2,
+ PSTATE_MAP_L3,
+};
+
static DSL_CPE_ThreadCtrl_t thread;
static struct ubus_context *ctx;
static struct blob_buf b;
@@ -306,32 +340,33 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ int map = LSTATE_MAP_UNKNOWN;
const char *str;
switch (out.data.nLineState) {
- STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
- STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
+ STR_CASE_MAP(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized",
LSTATE_MAP_NOT_INITIALIZED)
+ STR_CASE_MAP(DSL_LINESTATE_EXCEPTION, "Exception", LSTATE_MAP_EXCEPTION)
STR_CASE(DSL_LINESTATE_NOT_UPDATED, "Not updated")
STR_CASE(DSL_LINESTATE_IDLE_REQUEST, "Idle request")
- STR_CASE(DSL_LINESTATE_IDLE, "Idle")
+ STR_CASE_MAP(DSL_LINESTATE_IDLE, "Idle", LSTATE_MAP_IDLE)
STR_CASE(DSL_LINESTATE_SILENT_REQUEST, "Silent request")
- STR_CASE(DSL_LINESTATE_SILENT, "Silent")
- STR_CASE(DSL_LINESTATE_HANDSHAKE, "Handshake")
+ STR_CASE_MAP(DSL_LINESTATE_SILENT, "Silent", LSTATE_MAP_SILENT)
+ STR_CASE_MAP(DSL_LINESTATE_HANDSHAKE, "Handshake", LSTATE_MAP_HANDSHAKE)
STR_CASE(DSL_LINESTATE_BONDING_CLR, "Bonding CLR")
- STR_CASE(DSL_LINESTATE_FULL_INIT, "Full init")
+ STR_CASE_MAP(DSL_LINESTATE_FULL_INIT, "Full init", LSTATE_MAP_FULL_INIT)
STR_CASE(DSL_LINESTATE_SHORT_INIT_ENTRY, "Short init entry")
STR_CASE(DSL_LINESTATE_DISCOVERY, "Discovery")
STR_CASE(DSL_LINESTATE_TRAINING, "Training")
STR_CASE(DSL_LINESTATE_ANALYSIS, "Analysis")
STR_CASE(DSL_LINESTATE_EXCHANGE, "Exchange")
- STR_CASE(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync")
- STR_CASE(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer sync")
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync", LSTATE_MAP_SHOWTIME_NO_SYNC)
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer
sync", LSTATE_MAP_SHOWTIME_TC_SYNC)
STR_CASE(DSL_LINESTATE_FASTRETRAIN, "Fastretrain")
STR_CASE(DSL_LINESTATE_LOWPOWER_L2, "Lowpower L2")
STR_CASE(DSL_LINESTATE_LOOPDIAGNOSTIC_
Re: [PATCH v5 1/1] ltq-vdsl-app: extent dsl metrics with state_num and power_state_num
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ LSTATE_MAP_UNKNOWN = 0,
+ LSTATE_MAP_EXCEPTION,
+ LSTATE_MAP_IDLE,
+ LSTATE_MAP_SILENT,
+ LSTATE_MAP_HANDSHAKE,
+ LSTATE_MAP_FULL_INIT,
+ LSTATE_MAP_SHOWTIME_NO_SYNC,
+ LSTATE_MAP_SHOWTIME_TC_SYNC,
+ LSTATE_MAP_RESYNC,
+ LSTATE_MAP_NOT_INITIALIZED,
Except for the last entry, the order matches lantiq's DSL_LineState_t.
Doesn't really matter as long as we don't change these values, but was
there a reason for that?
No there is no particular reason for that.
Should I then send a v6?
Where this value then comes after LSTATE_MAP_UNKNOWN?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v5 1/1] ltq-vdsl-app: extent dsl metrics with state_num and power_state_num
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit adds the missing information.
For this the internal values are mapped to numbers.
* additional JSON output for state_num:
"state_num":
Since not all values are meaningful only the following values are
implemented, this can be extended if the future.
* LSTATE_MAP_EXCEPTION
* LSTATE_MAP_IDLE
* LSTATE_MAP_SILENT
* LSTATE_MAP_HANDSHAKE
* LSTATE_MAP_FULL_INIT
* LSTATE_MAP_SHOWTIME_NO_SYNC
* LSTATE_MAP_SHOWTIME_TC_SYNC
* LSTATE_MAP_RESYNC
* LSTATE_MAP_NOT_INITIALIZED
* additinal JSON output for power_level:
"power_state_num": ,
Since there are not so many here, all are mapped.
* PSTATE_MAP_NA,
* PSTATE_MAP_L0,
* PSTATE_MAP_L1,
* PSTATE_MAP_L2,
* PSTATE_MAP_L3,
Signed-off-by: Florian Eckert
---
v5:
After a discussion off the mailing list with Andre Heider, this is now
the favored solution. All other versions have been marked in the patchwork
as superseded.
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 72 +++
1 file changed, 58 insertions(+), 14 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 52b2be20e1..dafa45f77c 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -34,6 +34,12 @@
str = text; \
break;
+#define STR_CASE_MAP(id, text, number) \
+ case id: \
+ str = text; \
+ map = number; \
+ break;
+
#define IOCTL(type, request) \
type out; \
memset(, 0, sizeof(type)); \
@@ -99,6 +105,34 @@ typedef enum {
PROFILE_35B,
} profile_t;
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ LSTATE_MAP_UNKNOWN = 0,
+ LSTATE_MAP_EXCEPTION,
+ LSTATE_MAP_IDLE,
+ LSTATE_MAP_SILENT,
+ LSTATE_MAP_HANDSHAKE,
+ LSTATE_MAP_FULL_INIT,
+ LSTATE_MAP_SHOWTIME_NO_SYNC,
+ LSTATE_MAP_SHOWTIME_TC_SYNC,
+ LSTATE_MAP_RESYNC,
+ LSTATE_MAP_NOT_INITIALIZED,
+};
+
+/* These values are exported via ubus and backwards compability
+ * needs to be kept!
+ */
+enum {
+ PSTATE_MAP_UNKNOWN = -2,
+ PSTATE_MAP_NA,
+ PSTATE_MAP_L0,
+ PSTATE_MAP_L1,
+ PSTATE_MAP_L2,
+ PSTATE_MAP_L3,
+};
+
static DSL_CPE_ThreadCtrl_t thread;
static struct ubus_context *ctx;
static struct blob_buf b;
@@ -306,32 +340,33 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ int map = LSTATE_MAP_UNKNOWN;
const char *str;
switch (out.data.nLineState) {
- STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
- STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
+ STR_CASE_MAP(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized",
LSTATE_MAP_NOT_INITIALIZED)
+ STR_CASE_MAP(DSL_LINESTATE_EXCEPTION, "Exception", LSTATE_MAP_EXCEPTION)
STR_CASE(DSL_LINESTATE_NOT_UPDATED, "Not updated")
STR_CASE(DSL_LINESTATE_IDLE_REQUEST, "Idle request")
- STR_CASE(DSL_LINESTATE_IDLE, "Idle")
+ STR_CASE_MAP(DSL_LINESTATE_IDLE, "Idle", LSTATE_MAP_IDLE)
STR_CASE(DSL_LINESTATE_SILENT_REQUEST, "Silent request")
- STR_CASE(DSL_LINESTATE_SILENT, "Silent")
- STR_CASE(DSL_LINESTATE_HANDSHAKE, "Handshake")
+ STR_CASE_MAP(DSL_LINESTATE_SILENT, "Silent", LSTATE_MAP_SILENT)
+ STR_CASE_MAP(DSL_LINESTATE_HANDSHAKE, "Handshake", LSTATE_MAP_HANDSHAKE)
STR_CASE(DSL_LINESTATE_BONDING_CLR, "Bonding CLR")
- STR_CASE(DSL_LINESTATE_FULL_INIT, "Full init")
+ STR_CASE_MAP(DSL_LINESTATE_FULL_INIT, "Full init", LSTATE_MAP_FULL_INIT)
STR_CASE(DSL_LINESTATE_SHORT_INIT_ENTRY, "Short init entry")
STR_CASE(DSL_LINESTATE_DISCOVERY, "Discovery")
STR_CASE(DSL_LINESTATE_TRAINING, "Training")
STR_CASE(DSL_LINESTATE_ANALYSIS, "Analysis")
STR_CASE(DSL_LINESTATE_EXCHANGE, "Exchange")
- STR_CASE(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync")
- STR_CASE(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer sync")
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_NO_SYNC, "Showtime without TC-Layer
sync", LSTATE_MAP_SHOWTIME_NO_SYNC)
+ STR_CASE_MAP(DSL_LINESTATE_SHOWTIME_TC_SYNC, "Showtime with TC-Layer
sync", LSTATE_MAP_SHOWTIME_TC_SYNC)
STR_CASE(DSL_LINESTATE_FASTRETRAIN, "Fastretrain")
STR_CASE(DSL_LINESTATE_LOWPOWER_L2, "Lowpower L
[PATCH v4 1/1] ltq-vdsl-app: extent dsl metrics with power_level and state_detail
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit adds the missing information to the JSON output.
* additional JSON output for state_detail:
"state_detail": {
"exception": false,
"idle": false,
"silent": false,
"handshake": false,
"full-init": false,
"showtime-without-sync": false,
"showtime-with-sync": true,
"resync": false,
"not-initialized": false,
},
* additinal JSON output for power_level:
"power_level": ,
Possible values are if the information is available:
0: L0
1: L1
2: L2
3: L3
Signed-off-by: Florian Eckert
---
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 34 +--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 8eefdfe4d5..d8ebbb584c 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -306,6 +306,7 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ void *c;
const char *str;
switch (out.data.nLineState) {
STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
@@ -351,8 +352,21 @@ static void line_state(int fd) {
str = NULL;
break;
};
- if (str)
+
+ if (str) {
m_str("state", str);
+ c = blobmsg_open_table(, "state_detail");
+ m_bool("exception", out.data.nLineState ==
DSL_LINESTATE_EXCEPTION);
+ m_bool("idle", out.data.nLineState == DSL_LINESTATE_IDLE);
+ m_bool("silent", out.data.nLineState == DSL_LINESTATE_SILENT);
+ m_bool("handshake", out.data.nLineState ==
DSL_LINESTATE_HANDSHAKE);
+ m_bool("full-init", out.data.nLineState ==
DSL_LINESTATE_FULL_INIT);
+ m_bool("showtime-without-sync", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_NO_SYNC);
+ m_bool("showtime-with-sync", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_TC_SYNC);
+ m_bool("resync", out.data.nLineState == DSL_LINESTATE_RESYNC);
+ m_bool("not-initialized", out.data.nLineState ==
DSL_LINESTATE_NOT_INITIALIZED);
+ blobmsg_close_table(, c);
+ }
m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
}
@@ -388,8 +402,24 @@ static void g997_power_management_status(int fd) {
str = NULL;
break;
};
- if (str)
+
+ if (str) {
m_str("power_state", str);
+ switch (out.data.nPowerManagementStatus) {
+ case DSL_G997_PMS_L0:
+ m_u32("power_level", 0);
+ break;
+ case DSL_G997_PMS_L1:
+ m_u32("power_level", 1);
+ break;
+ case DSL_G997_PMS_L2:
+ m_u32("power_level", 2);
+ break;
+ case DSL_G997_PMS_L3:
+ m_u32("power_level", 3);
+ break;
+ }
+ }
}
static void g997_xtu_system_enabling(int fd, standard_t *standard) {
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 1/1] ltq-vdsl-app: extent dsl metrics with boolean power and line states
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit changes the following JSON output.
Instead of outputting the "line_state" and "power_state" numbers directly, the
values is now printed as boolean. This has the advantage that the
internal numbers are not shown, which can change in the future.
* current JSON output for state:
"state": "Showtime with TC-Layer sync"
* new JSON output for state:
"line_state": {
"exception": false,
"idle": false,
"silent": false,
"handshake": false,
"full-init": false,
"showtime-without-sync": false,
"showtime-with-sync": true,
"resync": false,
"not-initialized": false,
"string": "Showtime with TC-Layer sync"
},
* current JSON output for power_state:
"power_state": "L0 - Synchronized"
* new JSON outpug for power_state:
"power_state": {
"NA": false,
"L0": true,
"L1": false,
"L2": false,
"L3": false,
"string": "L0 - Synchronized"
}
Signed-off-by: Florian Eckert
---
package/network/config/ltq-vdsl-app/Makefile | 2 +-
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 32 ---
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/Makefile
b/package/network/config/ltq-vdsl-app/Makefile
index 0823a0e7e9..f5c561078d 100644
--- a/package/network/config/ltq-vdsl-app/Makefile
+++ b/package/network/config/ltq-vdsl-app/Makefile
@@ -9,7 +9,7 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=ltq-vdsl-app
PKG_VERSION:=4.17.18.6
-PKG_RELEASE:=8
+PKG_RELEASE:=9
PKG_BASE_NAME:=dsl_cpe_control
PKG_SOURCE:=$(PKG_BASE_NAME)_vrx-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=@OPENWRT
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 8eefdfe4d5..2ab35ac056 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -306,6 +306,7 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ void *c;
const char *str;
switch (out.data.nLineState) {
STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
@@ -351,8 +352,21 @@ static void line_state(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "line_state");
+ m_bool("exception", out.data.nLineState ==
DSL_LINESTATE_EXCEPTION);
+ m_bool("idle", out.data.nLineState == DSL_LINESTATE_IDLE);
+ m_bool("silent", out.data.nLineState == DSL_LINESTATE_SILENT);
+ m_bool("handshake", out.data.nLineState ==
DSL_LINESTATE_HANDSHAKE);
+ m_bool("full-init", out.data.nLineState ==
DSL_LINESTATE_FULL_INIT);
+ m_bool("showtime-without-sync", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_NO_SYNC);
+ m_bool("showtime-with-sync", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_TC_SYNC);
+ m_bool("resync", out.data.nLineState == DSL_LINESTATE_RESYNC);
+ m_bool("not-initialized", out.data.nLineState ==
DSL_LINESTATE_NOT_INITIALIZED);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
}
@@ -377,6 +391,7 @@ static void g997_line_inventory(int fd) {
static void g997_power_management_status(int fd) {
IOCTL(DSL_G997_PowerManagementStatus_t,
DSL_FIO_G997_POWER_MANAGEMENT_STATUS_GET)
+ void *c;
const char *str;
switch (out.data.nPowerManagementStatus) {
STR_CASE(DSL_G997_PMS_NA, "Power management state is not available")
@@ -388,8 +403,17 @@ static void g997_power_management_status(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("power_state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "power_state");
+ m_bool("NA", out.data.nPowerManagementStatus ==
DSL_G997_PMS_NA);
+ m_bool("L0", out.data.nPowerManagementStatus ==
DSL_G997_PMS_L0);
+ m_bool("L1", out.data.nPowerManagementStatus ==
DSL_G997_PMS_L1);
+ m_bool("L2", out.data.nPowerManagementStatus ==
DSL_G997_PMS_L2);
+ m_bool("L3", out.data.nPowerManagementStatus ==
DSL_G997_PMS_L3);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
}
static void g997_xtu_system_enabling(int fd, standard_t *standard) {
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
netifd: Send permission denied for syslog after proto misconfiguration
Hello Hans, I have had the problem for a long time that I see the following message in the syslog. Tue Apr 2 10:50:23 2019 daemon.notice netifd: wwan (11146): Command failed: Permission denied This message in the syslog is written when the interface makes a teardown after a misconfiguration. According to my researches, it must be related to this commit [1]. In the proto handler uqmi [2] and I think also in umbim [3] these are the function calls that generate this message in the log. It's not bad but it's not clean. How can we stop this message to get written to the syslog? Is it enough to send it to /dev/null? I also wonder why we need this call at all. The proto is cleaned up by the calls to uqmi and umbim binaries. I'm missing the connections, can you help me? Or does this have something to do with the dhcp? Kind regards Florian [1] https://git.openwrt.org/?p=project/netifd.git;a=commit;h=99cfef35370b274352934c2f85a9de83ac537036 [2] https://github.com/openwrt/openwrt/blob/master/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh#L449 [3] https://github.com/openwrt/openwrt/blob/master/package/network/utils/umbim/files/lib/netifd/proto/mbim.sh#L177 PS: Can you please also look at this patch. https://patchwork.ozlabs.org/project/openwrt/patch/20201124071800.9080-1...@dev.tdt.de/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/1] ltq-vdsl-app: add line_state number and power_state number
Hello Andre
We already talked about it, but once again for the list:
Here are my thoughts on why I would like to have this for the
mailinglist.
I skipped both of these numeric state values when porting this to
ubus/C, because those are internal and lantiq implementation specific.
I'd like to avoid exposing those if possible.
So far we only have the lantiq DSL implementation.
The only thing I can think of is that Broadcom also has DSL.
But they have a strange licensing policy and are therefore negligible.
I have also not yet seen a target that has this DSL frontend from
broadcom.
With the old implementation, we also exported the numbers via the UBUS.
I already used this data for the collectd to also record the line_state
and the power_state over time.
There is already a pullrequest pending to integrate this into collectd
[0] with some other datas
I've only seen very few of all of those actually happening.
That's right, I've only seen a handful so far too
But I can't tell which ones are important or negligible.
Can we not expose new metrics instead of these internal numbers?
We can do that.
The only question is which data we want to export.
I definitely can not save strings in an RRD database.
Like there's already "up":
m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
If you care e.g. about showtime you could just add:
m_bool("showtime", out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_NO_SYNC || out.data.nLineState ==
DSL_LINESTATE_SHOWTIME_TC_SYNC);
That would be a possibility.
The collectd db type would be a bool.
From my point of view, the following values would be important.
I am currently evaluating this.
All other values are saved as unknown and so -1 in ma rrd database
0 -> Not initialized
1 -> Exception
256 -> Idle
512 -> Silent
768 -> Handshake
896 -> Full init
1280 -> Training
2048 -> Showtime without TC-Layer sync
2049 -> Showtime without TC-Layer sync
3328 -> Resync
What is also added is the power_state. However, these are not many
values.
Kind regards
Florian
[0] https://github.com/openwrt/packages/pull/12175
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/1] ltq-vdsl-app: add line_state number and power_state number
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit changes the following JSON output.
* current JSON output for state:
"state": "Showtime with TC-Layer sync"
* new JSON output for state:
"line_state": {
"number": 2049,
"string": "Showtime with TC-Layer sync"
},
* current JSON output for power_state:
"power_state": "L0 - Synchronized"
new JSON outpug for power_state:
"power_state": {
"number": 0,
"string": "L0 - Synchronized"
}
Signed-off-by: Florian Eckert
---
v2:
* Fixed typo
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 22 +++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 52b2be20e1..4629620a90 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -306,7 +306,9 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ void *c;
const char *str;
+
switch (out.data.nLineState) {
STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
@@ -351,8 +353,13 @@ static void line_state(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "line_state");
+ m_u32("number", out.data.nLineState);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
}
@@ -377,7 +384,9 @@ static void g997_line_inventory(int fd) {
static void g997_power_management_status(int fd) {
IOCTL(DSL_G997_PowerManagementStatus_t,
DSL_FIO_G997_POWER_MANAGEMENT_STATUS_GET)
+ void *c;
const char *str;
+
switch (out.data.nPowerManagementStatus) {
STR_CASE(DSL_G997_PMS_NA, "Power management state is not available")
STR_CASE(DSL_G997_PMS_L0, "L0 - Synchronized")
@@ -388,8 +397,13 @@ static void g997_power_management_status(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("power_state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "power_state");
+ m_u32("number", out.data.nPowerManagementStatus);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
}
static void g997_xtu_system_enabling(int fd, standard_t *standard) {
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] ltq-vdsl-app: add line_state number and power_state number
With the old ubus dsl API, the numbers for the individual line_states and
power_states were also returned. These were not ported to the new DSL
C-API. This commit changes the following JSON output.
* current JSON output for state:
"state": "Showtime with TC-Layer sync"
* new JSON output for state:
"line_state": {
"mumber": 2049,
"string": "Showtime with TC-Layer sync"
},
* current JSON output for power_state:
"power_state": "L0 - Synchronized"
new JSON outpug for power_state:
"power_state": {
"mumber": 0,
"string": "L0 - Synchronized"
}
Signed-off-by: Florian Eckert
---
.../ltq-vdsl-app/src/src/dsl_cpe_ubus.c | 22 +++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
index 52b2be20e1..9d78b61188 100644
--- a/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
+++ b/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c
@@ -306,7 +306,9 @@ static void version_information(int fd) {
static void line_state(int fd) {
IOCTL(DSL_LineState_t, DSL_FIO_LINE_STATE_GET)
+ void *c;
const char *str;
+
switch (out.data.nLineState) {
STR_CASE(DSL_LINESTATE_NOT_INITIALIZED, "Not initialized")
STR_CASE(DSL_LINESTATE_EXCEPTION, "Exception")
@@ -351,8 +353,13 @@ static void line_state(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "line_state");
+ m_u32("mumber", out.data.nLineState);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
m_bool("up", out.data.nLineState == DSL_LINESTATE_SHOWTIME_TC_SYNC);
}
@@ -377,7 +384,9 @@ static void g997_line_inventory(int fd) {
static void g997_power_management_status(int fd) {
IOCTL(DSL_G997_PowerManagementStatus_t,
DSL_FIO_G997_POWER_MANAGEMENT_STATUS_GET)
+ void *c;
const char *str;
+
switch (out.data.nPowerManagementStatus) {
STR_CASE(DSL_G997_PMS_NA, "Power management state is not available")
STR_CASE(DSL_G997_PMS_L0, "L0 - Synchronized")
@@ -388,8 +397,13 @@ static void g997_power_management_status(int fd) {
str = NULL;
break;
};
- if (str)
- m_str("power_state", str);
+
+ if (str) {
+ c = blobmsg_open_table(, "power_state");
+ m_u32("mumber", out.data.nPowerManagementStatus);
+ m_str("string", str);
+ blobmsg_close_table(, c);
+ }
}
static void g997_xtu_system_enabling(int fd, standard_t *standard) {
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Unnecessary extension of default packeges for x86 generic
Hello Alberto, Thank you for the explanation. If that is so then we should also remove the vmware driver as a kmod package [1]. That makes no sense if this is then already in the kernel enabled [2]. Kind Regards Florian [1] https://github.com/openwrt/openwrt/blob/master/package/kernel/linux/modules/netdevices.mk#L1007 [2] https://github.com/openwrt/openwrt/blob/1ca5de13a153061feae260864d73d96f7c463785/target/linux/x86/64/config-5.4#L440 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Unnecessary extension of default packeges for x86 generic
Hello, Is it really necessary that we keep expanding the default package here [1]? The problem is, for example, that I don't need the whole AWS stuff. But now the whole package gets installed. If this is the case, then we should also install the vmware needed driver as default package. Maybe someone (like me) would like to run the image in a vmware environment. But I do not want to install this per default. I think this are all special image. Therefore it would be a good idea to create individual images. For example * define Device/aws * define Device/vmware Also, binary blobs are currently already get installed as a dependency that the default drivers work. Therefore I have changed the line before this change as following. So no binary blob dependency gets installed. I am also not clear why we need kmod-bnx2, kmod-forcedeth and kmod-r8169 as default, which have the binary blob dependency. --- a/target/linux/x86/image/64.mk +++ b/target/linux/x86/image/64.mk @@ -1,7 +1,6 @@ define Device/generic DEVICE_TITLE := Generic x86/64 - DEVICE_PACKAGES += kmod-bnx2 kmod-e1000e kmod-e1000 kmod-forcedeth kmod-igb \ - kmod-ixgbe kmod-r8169 + DEVICE_PACKAGES += kmod-e1000e kmod-e1000 kmod-igb kmod-ixgbe GRUB2_VARIANT := generic endef TARGET_DEVICES += generic -- From my point of view, these are the minimum packets needed to make the generic image to work. Kind Regards Florian [1] https://github.com/openwrt/openwrt/commit/788ec9a7cfc843c8e46451331521cdc7d81866bd ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iperf3: move over to packages.git
That package is not required for building OpenWrt so the maintenance should happen over at packages.git. Sounds about right. I think most people prefer to use iperf anyway... But then I would also move the iperf package to the package feed. CC: Felix Fietkau Signed-off-by: Paul Spooren Reviewed-by: Rosen Penev Reviewed-by: Florian Eckert --- package/network/utils/iperf3/Makefile | 83 --- 1 file changed, 83 deletions(-) delete mode 100644 package/network/utils/iperf3/Makefile diff --git a/package/network/utils/iperf3/Makefile b/package/network/utils/iperf3/Makefile deleted file mode 100644 index 6f90bc9221..00 --- a/package/network/utils/iperf3/Makefile +++ /dev/null @@ -1,83 +0,0 @@ -# -# Copyright (C) 2007-2010 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# - -include $(TOPDIR)/rules.mk - -PKG_NAME:=iperf -PKG_VERSION:=3.9 -PKG_RELEASE:=1 - -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=https://downloads.es.net/pub/iperf -PKG_HASH:=24b63a26382325f759f11d421779a937b63ca1bc17c44587d2fcfedab60ac038 - -PKG_MAINTAINER:=Felix Fietkau -PKG_LICENSE:=BSD-3-Clause - -PKG_BUILD_PARALLEL:=1 -PKG_INSTALL:=1 - -PKG_FIXUP:=autoreconf - -include $(INCLUDE_DIR)/package.mk - -DISABLE_NLS:= - -define Package/iperf3/default - SECTION:=net - CATEGORY:=Network - TITLE:=Internet Protocol bandwidth measuring tool - URL:=https://github.com/esnet/iperf -endef - -define Package/iperf3 -$(call Package/iperf3/default) - VARIANT:=nossl -endef - -define Package/iperf3-ssl -$(call Package/iperf3/default) - TITLE+= with iperf_auth support - VARIANT:=ssl - DEPENDS:= +libopenssl -endef - -TARGET_CFLAGS += -D_GNU_SOURCE -CONFIGURE_ARGS += --disable-shared - -ifeq ($(BUILD_VARIANT),ssl) - CONFIGURE_ARGS += --with-openssl="$(STAGING_DIR)/usr" -else - CONFIGURE_ARGS += --without-openssl -endif - -MAKE_FLAGS += noinst_PROGRAMS= - -define Package/iperf3/description - Iperf is a modern alternative for measuring TCP and UDP bandwidth - performance, allowing the tuning of various parameters and - characteristics. -endef - -# autoreconf fails if the README file isn't present -define Build/Prepare - $(call Build/Prepare/Default) - touch $(PKG_BUILD_DIR)/README -endef - -define Package/iperf3/install - $(INSTALL_DIR) $(1)/usr/bin - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/iperf3 $(1)/usr/bin/ -endef - -define Package/iperf3-ssl/install - $(INSTALL_DIR) $(1)/usr/bin - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/iperf3 $(1)/usr/bin/ -endef - -$(eval $(call BuildPackage,iperf3)) -$(eval $(call BuildPackage,iperf3-ssl)) -- 2.29.2 ___ 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
Add package version dependency for point releases
I would like to add a dependency to mwan3 on a specific kernel version. In the master branch it does not matter, but I have a use case for this, especial for the stable release openwrt-19.07. I just realized (thanks to @brianjmurrell [1]) that in a stable release, this is quite important. The problem is, that a bug fix has been added to the kernel, which makes a workaround in mwan3 superfluous. This workaround in the mwan3 I have now reverted. Since this is no longer needed. Because of my revert now mwan3 tracking no longer works on IPv6 with older kernel version on openwrt-19.07, which do not have at least the kernel version from the 19.07.5 point release. I was also not aware that the packages in the feeds for the point release are not pinned to the version that was in the repository when the tagging was on. Only openwrt core is pinned. The feeds always use the latest stable snapshot builds from 19.07 and so are rolling. The fix now would be to check the version of the kernel when installing the package and only install or update the package if the correct version is installed. But how can I do that? This is not a build dependency. Or does anyone have another suggestion See discussion on github [2]. Best regards Florian [1] https://github.com/brianjmurrell [2] https://github.com/openwrt/packages/commit/6bd3f5c3777c5cbad4ac9156fa5b0fda26af14a9 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/5] ubus: extend the service object with a restart method
This patchset adds the new method "restart" to the ubus service object. This method is called on a service restart, if it is managed by procd. I have noticed that during a firewall restart the mwan3 rules have all disappeared and I have to restart my service as well. I did not expected this. So that I don't have to do this extra step, an event should be generated during a service restart, so other service could subscribe to this event. All services that want to react to this event can create a callback script. The same applies to a config change. As an example I used the firewall here, because I came across the problem here. So if the firewall gets restart, then a event es generated. Full discussion hat taken place at this URL. https://github.com/openwrt/packages/pull/13931 A pull request is already staged to use this new funcionality. https://github.com/openwrt/packages/pull/14215 v2: - As requested by John Chrispin, I wrapped the new `_procd_add_service_trigger` with the function `_procd_add_restart_service_trigger` to make it a one-liner to use this functionality. Florian Eckert (5): procd: add restart ubus call base-files: add restart function wrapper firewall: fix whitespace firewall: use new restart_service callback procd: add api wrapper package/base-files/files/etc/rc.common| 13 .../config/firewall/files/firewall.init | 4 +- package/system/procd/files/procd.sh | 33 ++ .../patches/0010-add-restart-event.patch | 64 +++ 4 files changed, 112 insertions(+), 2 deletions(-) create mode 100644 package/system/procd/patches/0010-add-restart-event.patch -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 5/5] procd: add api wrapper
This commit adds the functions `procd_add_service_trigger` and
`procd_add_restart_service_trigger`. In order for the service to be
triggered by another service during a restart, only the function
procd_add_restart_service_trigger is needed.
Example:
service_trigger() {
procd add_restart_service_trigger 'firewall'
}
If the firewall is restarted, the specified will be executed.
Signed-off-by: Florian Eckert
---
package/system/procd/files/procd.sh | 33 +
1 file changed, 33 insertions(+)
diff --git a/package/system/procd/files/procd.sh
b/package/system/procd/files/procd.sh
index d86b7219da..007c99fca0 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -329,6 +329,37 @@ _procd_add_config_trigger() {
json_close_array
}
+_procd_add_service_trigger() {
+ json_add_array
+ _procd_add_array_data "$1"
+ shift
+
+ json_add_array
+ _procd_add_array_data "if"
+
+ json_add_array
+ _procd_add_array_data "eq" "service" "$1"
+ shift
+ json_close_array
+
+ json_add_array
+ _procd_add_array_data "run_script" "$@"
+ json_close_array
+
+ json_close_array
+ _procd_add_timeout
+ json_close_array
+}
+
+_procd_add_restart_service_trigger() {
+ local service=$1
+ shift
+
+ _procd_open_trigger
+ _procd_add_service_trigger "service.restart" "$service" "$@"
+ _procd_close_trigger
+}
+
_procd_add_raw_trigger() {
json_add_array
_procd_add_array_data "$1"
@@ -559,6 +590,8 @@ _procd_wrapper \
procd_add_instance \
procd_add_raw_trigger \
procd_add_config_trigger \
+ procd_add_service_trigger \
+ procd_add_restart_service_trigger \
procd_add_interface_trigger \
procd_add_reload_trigger \
procd_add_reload_interface_trigger \
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/5] base-files: add restart function wrapper
Thies commit add the new wrapper function to rc.common to execute the new ubus
service method "restart" on a service restart.
Signed-off-by: Florian Eckert
---
package/base-files/files/etc/rc.common | 13 +
1 file changed, 13 insertions(+)
diff --git a/package/base-files/files/etc/rc.common
b/package/base-files/files/etc/rc.common
index f39b69464e..ad5af4b7a1 100755
--- a/package/base-files/files/etc/rc.common
+++ b/package/base-files/files/etc/rc.common
@@ -139,6 +139,19 @@ extra_command "enabled" "Check if service is started on
boot"
fi
}
+ restart() {
+ if eval "type restart_service" 2>/dev/null >/dev/null; then
+ restart_service "$@"
+ else
+ trap '' TERM
+ stop "$@"
+ trap - TERM
+ start "$@"
+ fi
+ procd_open_service "$(basename ${basescript:-$initscript})"
"$initscript"
+ procd_close_service "restart"
+ }
+
trace() {
TRACE_SYSCALLS=1
start "$@"
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/5] procd: add restart ubus call
To allow other services to respsond to a restart event from a procd initialised
service, a new ubus method "restart" in the ubus "service" path is needed
to trigger a ubus notify and also execute the installed service triggers.
Cc: Aaron Goodman
Signed-off-by: Florian Eckert
The original implementation is by Aaron Goodman.
---
.../patches/0010-add-restart-event.patch | 64 +++
1 file changed, 64 insertions(+)
create mode 100644 package/system/procd/patches/0010-add-restart-event.patch
diff --git a/package/system/procd/patches/0010-add-restart-event.patch
b/package/system/procd/patches/0010-add-restart-event.patch
new file mode 100644
index 00..86ec3d38e1
--- /dev/null
+++ b/package/system/procd/patches/0010-add-restart-event.patch
@@ -0,0 +1,64 @@
+--- a/service/service.c
b/service/service.c
+@@ -204,6 +204,17 @@ static const struct blobmsg_policy servi
+ };
+
+ enum {
++ SERVICE_RESTART_ATTR_NAME,
++ SERVICE_RESTART_ATTR_INSTANCE,
++ __SERVICE_RESTART_ATTR_MAX,
++};
++
++static const struct blobmsg_policy
service_restart_attrs[__SERVICE_RESTART_ATTR_MAX] = {
++ [SERVICE_RESTART_ATTR_NAME] = { "name", BLOBMSG_TYPE_STRING },
++ [SERVICE_RESTART_ATTR_INSTANCE] = { "instance", BLOBMSG_TYPE_STRING },
++};
++
++enum {
+ SERVICE_DEL_ATTR_NAME,
+ SERVICE_DEL_ATTR_INSTANCE,
+ __SERVICE_DEL_ATTR_MAX,
+@@ -681,6 +692,35 @@ service_handle_update(struct ubus_contex
+ return 0;
+ }
+
++static int
++service_handle_restart(struct ubus_context *ctx, struct ubus_object *obj,
++ struct ubus_request_data *req, const char *method,
++ struct blob_attr *msg)
++{
++ struct blob_attr *tb[__SERVICE_RESTART_ATTR_MAX], *cur;
++ struct service *s = NULL;
++ const char *name;
++
++ blobmsg_parse(service_set_attrs, __SERVICE_RESTART_ATTR_MAX, tb,
blobmsg_data(msg), blobmsg_data_len(msg));
++ cur = tb[SERVICE_RESTART_ATTR_NAME];
++ if (!cur)
++ return UBUS_STATUS_INVALID_ARGUMENT;
++
++ name = blobmsg_data(cur);
++
++ s = avl_find_element(, name, s, avl);
++ if (!s)
++ return UBUS_STATUS_INVALID_ARGUMENT;
++
++ blob_buf_init(, 0);
++ blobmsg_add_string(, "service", s->name);
++ trigger_event("service.restart", b.head);
++
++ service_event("service.restart", s->name, NULL);
++
++ return UBUS_STATUS_OK;
++}
++
+ static void ubus_event_bcast(const char *type, const char *param1, const char
*val1,
+const char *param2, const char *val2)
+ {
+@@ -951,6 +991,7 @@ static struct ubus_method main_object_me
+ UBUS_METHOD("add", service_handle_set, service_set_attrs),
+ UBUS_METHOD("list", service_handle_list, service_list_attrs),
+ UBUS_METHOD("delete", service_handle_delete, service_del_attrs),
++ UBUS_METHOD("restart", service_handle_restart, service_restart_attrs),
+ UBUS_METHOD("signal", service_handle_signal, service_signal_attrs),
+ UBUS_METHOD("update_start", service_handle_update, service_attrs),
+ UBUS_METHOD("update_complete", service_handle_update, service_attrs),
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 4/5] firewall: use new restart_service callback
In order that the prcod restart service can also be triggered during a
firewall restart, this call function must be changed.
Signed-off-by: Florian Eckert
---
package/network/config/firewall/files/firewall.init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/config/firewall/files/firewall.init
b/package/network/config/firewall/files/firewall.init
index 4c2fb7b617..089b02bb4c 100755
--- a/package/network/config/firewall/files/firewall.init
+++ b/package/network/config/firewall/files/firewall.init
@@ -37,7 +37,7 @@ service_triggers() {
procd_close_validate
}
-restart() {
+restart_service() {
fw3 restart
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
