[PATCH 1/2] libnl: add libnl-cli library
--- package/libs/libnl/Makefile | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile index db0c65c7a7..3b9bad4533 100644 --- a/package/libs/libnl/Makefile +++ b/package/libs/libnl/Makefile @@ -52,16 +52,26 @@ $(call Package/libnl/default) DEPENDS:=+libnl-route endef +define Package/libnl-cli +$(call Package/libnl/default) + TITLE:=Netlink Library CLI + DEPENDS:=+libnl-genl +libnl-route +libnl-nf +endef + define Package/libnl $(call Package/libnl/default) TITLE:=Full Netlink Library - DEPENDS:=+libnl-genl +libnl-route +libnl-nf + DEPENDS:=+libnl-genl +libnl-route +libnl-nf +libnl-cli endef define Package/libnl-core/description Common code for all netlink libraries endef +define Package/libnl-cli/description + CLI Netlink Library Functions +endef + define Package/libnl-genl/description Generic Netlink Library Functions endef @@ -92,6 +102,7 @@ define Build/InstallDev # Copy symlinks $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so $(1)/usr/lib/libnl.so + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so $(1)/usr/lib/libnl.so $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so $(1)/usr/lib/libnl-genl.so $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so $(1)/usr/lib/libnl-nf.so $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so $(1)/usr/lib/libnl-route.so @@ -102,6 +113,11 @@ define Package/libnl-core/install $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-3.so.* $(1)/usr/lib/ endef +define Package/libnl-cli/install + $(INSTALL_DIR) $(1)/usr/lib + $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so.* $(1)/usr/lib/ +endef + define Package/libnl-genl/install $(INSTALL_DIR) $(1)/usr/lib $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so.* $(1)/usr/lib/ @@ -122,6 +138,7 @@ define Package/libnl/install endef $(eval $(call BuildPackage,libnl-core)) +$(eval $(call BuildPackage,libnl-cli)) $(eval $(call BuildPackage,libnl-genl)) $(eval $(call BuildPackage,libnl-route)) $(eval $(call BuildPackage,libnl-nf)) -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] libteam: add library to control team devices
--- package/network/services/libteam/Makefile | 30 + .../0001-fix-build-on-OpenWRT-musl-libc.patch | 43 +++ 2 files changed, 73 insertions(+) create mode 100644 package/network/services/libteam/Makefile create mode 100644 package/network/services/libteam/patches/0001-fix-build-on-OpenWRT-musl-libc.patch diff --git a/package/network/services/libteam/Makefile b/package/network/services/libteam/Makefile new file mode 100644 index 00..367134656b --- /dev/null +++ b/package/network/services/libteam/Makefile @@ -0,0 +1,30 @@ +include $(TOPDIR)/rules.mk + +PKG_NAME := libteam +PKG_FIXUP := autoreconf +PKG_BUILD_DEPENDS := libdaemon jansson +PKG_INSTALL := 1 + +PKG_SOURCE_PROTO:=git +PKG_SOURCE_URL=https://github.com/jpirko/libteam.git +PKG_SOURCE_DATE:=2021-01-12 +PKG_SOURCE_VERSION:=61efd6de2fbb8ee077863ee5a355ac3dfd9365b9 + +PKG_LICENSE:=LGPL-2.1 + +include $(INCLUDE_DIR)/package.mk + +define Package/libteam + SECTION := base + CATEGORY := Network + DEPENDS := +libnl +libnl-cli +libnl-core +libnl-genl +libnl-nf +libnl-route +libdaemon +jansson + TITLE := Library for controlling team network device + URL := http://libteam.org/ +endef + +define Package/libteam/install + $(INSTALL_DIR) $(1)/ + $(CP) $(PKG_INSTALL_DIR)/. $(1)/ +endef + +$(eval $(call BuildPackage,libteam)) diff --git a/package/network/services/libteam/patches/0001-fix-build-on-OpenWRT-musl-libc.patch b/package/network/services/libteam/patches/0001-fix-build-on-OpenWRT-musl-libc.patch new file mode 100644 index 00..71b2b8abba --- /dev/null +++ b/package/network/services/libteam/patches/0001-fix-build-on-OpenWRT-musl-libc.patch @@ -0,0 +1,43 @@ +From 5a5825708ba0bfcb7700a9fba4ea9f8c41c1ae6c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Pavel=20=C5=A0imerda?= +Date: Tue, 5 Jan 2021 22:13:06 +0100 +Subject: [PATCH] fix build on OpenWRT/musl-libc +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Signed-off-by: Pavel Šimerda +--- + teamd/teamd_runner_lacp.c | 2 -- + utils/teamnl.c| 1 + + 2 files changed, 1 insertion(+), 2 deletions(-) + +diff --git a/teamd/teamd_runner_lacp.c b/teamd/teamd_runner_lacp.c +index 9437f05..f524be2 100644 +--- a/teamd/teamd_runner_lacp.c b/teamd/teamd_runner_lacp.c +@@ -23,9 +23,7 @@ + #include + #include + #include +-#include + #include +-#include + #include + #include + #include +diff --git a/utils/teamnl.c b/utils/teamnl.c +index c53345d..ec2b435 100644 +--- a/utils/teamnl.c b/utils/teamnl.c +@@ -24,6 +24,7 @@ + #include + #include + #include ++#include + #include + #include + #include +-- +2.29.2 + -- 2.29.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
Ben, seems to me, that at least "firmware-5-ct-full-community-12.bin-lede.013" is still not recovered. File is there, but contains only 0x00. This seems to cause my fresh build of 19.07.5 to fail. + curl -f --connect-timeout 20 --retry 5 --location --insecure https:// www.candelatech.com/downloads/ath10k-10-4b/firmware-5-ct-full- community-12.bin-lede.013 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 548k 100 548k0 0 985k 0 --:--:-- --:--:-- --:--:-- 985k Hash of the downloaded file does not match (file: 6a95c4323e008499af8d3549513c8a128c69b97296888a4c4b642e6c14a65508, requested: 6fa74a3fc87cba97dbc4a7213b760f8d997cd9c5f11900d47d387b23764cf20a) - deleting download. Can you check please? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 00/10] kernel: mtdsplit_uimage: use device tree properties for non-standard uimage parsing
Hi, On Mon, 2020-11-30 at 23:19 +0100, Bjørn Mork wrote: > Bjørn Mork (10): > dt-bindings: mtd: partitions: add OpenWrt defined U-Boot Image > kernel: mtdsplit_uimage: read extralen from device tree > kernel: mtdsplit_uimage: replace "fonfxc" and "sge" parsers > kernel: mtdsplit_uimage: add "openwrt,ih-magic" device-tree > property > kernel: mtdsplit_uimage: replace "openwrt,okli" parser > kernel: mtdsplit_uimage: replace "allnet,uimage" parser > kernel: mtdsplit_uimage: add "openwrt,ih-type" device-tree property > kernel: mtdsplit_uimage: replace "netgear,uimage" parser > kernel: mtdsplit_uimage: add "openwrt,offset" and > "openwrt,partition-magic" > kernel: mtdsplit_uimage: replace "edimax,uimage" parser Using Petr's builds and my own builds, I've run-tested this on my WNDR3700v2 (ath79/generic). Flashing first Petr's build, I ended up in a boot loop, although booting only failed after the partitions were correctly processed, similar to [1]. My own build and a second flash with ynezz's test build have produced no issues, so I think the boot- loop is unrelated to the patches. Tested-by: Sander Vanheule [1] https://bugs.openwrt.org/index.php?do=details_id=478 Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SELinux status report and call to action
On 1/13/21 5:42 PM, David Lang wrote: > OpenWRT uses different commands than other distros for manipulating > configs, so those different programs are going to need to be given > appropriate permissions. UCI should already be addressed barring any loose ends (LuCI coverage is still rough though) > > Who is going to do that work? Who is going to field all the issues that > will come up because the permissions are not correct for some user's > setup (and how many people will be able to figure out that SELinux > caused the problem as opposed to "OpenWRT doesn't work") UCI should be covered and the README in my repository clearly states: "Contributing Thank you for considering contributing! Please send patches with git-send-email to dominick.gr...@defensec.nl and sign your work." I suppose I should clarify that bug reports can also be directed to the above email address. If you have better ideas then please let us know. I guess people can also report github issues for the "selinux-policy" packages. I am monitoring github as well so if something shows up i will probably be on top of it. > > If it's just enabled with a permissive ruleset, what's the advantage of > the additional overhead (both from the permission checking, and the > logging of the results)? It is currently *not* enabled with a permissive ruleset. But i think that, for now, it might be a good idea to leave SELinux in permisisve mode. There are two reasons for this: 1. SELinux will be in detection only mode rather than prevention mode so that stuff just works but events that would have been prevented if SELinux were enforcing are still logged. 2. This will make it so that SELinux doesnt actively block (for now) so that we can identify any permissions that are needed (because SELinux will print any events that it would have blocked and those events can be feed back to me so that i can append the needed rules) Then after a while we can switch to enforcing mode. Ofcourse any of you OpenWrt devs can just modify the package to make SELinux permissive yourself easily (its easy, but if making it permissive for now by default helps people get to try it then we might want to default to permisisve) > > Yes other distros had to go through this same pain, but that doesn't > mean that the pain isn't there for OpenWRT as well. The difference is that we had a chance to learn from their "mistakes". I went to great lengths to make it proof. Also OpenWrt is not like other distro's. It is *much* simpler. LuCI poses a challenge though. There are various components involved and to address it in a meaningful way is rather intrusive. (however one can build the policy without the LuCI aspects which simplifies things a great deal. LuCI is also very modular, and al these modules have to be addressed. Otherwise you end up with LuCI where various spokes do not show up or if they show up the will not be allowed to function. I addressed most of the basic LuCI apects. So the basics work but again there are many optional modules that have to be supported and then tested. > > David Lang > > On Wed, 13 Jan 2021, Dac Override wrote: > >> Date: Wed, 13 Jan 2021 17:34:56 +0100 >> From: Dac Override >> To: openwrt-devel@lists.openwrt.org >> Subject: Re: Re: SELinux status report and call to action >> >> Hello Alberto, >> >> Thanks for you input. I agree that leveraging SELinux is, like for >> example leveraging Linux netfilter, not trivial. >> SELinux is however well documenting and with the exception of OpenWrt >> specifics it might not be productive to yet again document aspects >> that are already published elsewhere. >> >> I have created a document that explains how to build and edit the >> OpenWrt policy and I have also enclosed a link to the policy language >> used to write the OpenWrt policy: >> >> https://git.defensec.nl/?p=selinux-policy.git;a=summary >> >> 1. The CIL used to write OpenWrt policy: >> https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md >> >> 2. OpenWrt policy customization and testing: >> https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md >> >> Generally one should not have to interact with SELinux in OpenWrt but >> there are some exceptions >> >> 1. Some commands might be "targeted" by default and *if* a command >> cannot operate properly because it is targeted then you can manually >> run the command "unconfined": For example: you want to use `iw` but >> SELinux blocks it, then you can run iw from a shell with `runcon -t >> sys.subj -- iw` to by pass the SELinux restrictions. >> >> 2. Some commands might *not* be targeted by default and *if* you want >> to run that command with "basic" set of restrictions then you can run >> the command in a "SELinux sandbox". For example you want to run `bmon` >> with restricted permissions but SELinux does not target it by default >> then you can run bmon from a shell with `runcon -t sandbox.subj -- >> bmon` or `runcon -t sandbox.net,subj --
Re: Re: SELinux status report and call to action
OpenWRT uses different commands than other distros for manipulating configs, so those different programs are going to need to be given appropriate permissions. Who is going to do that work? Who is going to field all the issues that will come up because the permissions are not correct for some user's setup (and how many people will be able to figure out that SELinux caused the problem as opposed to "OpenWRT doesn't work") If it's just enabled with a permissive ruleset, what's the advantage of the additional overhead (both from the permission checking, and the logging of the results)? Yes other distros had to go through this same pain, but that doesn't mean that the pain isn't there for OpenWRT as well. David Lang On Wed, 13 Jan 2021, Dac Override wrote: Date: Wed, 13 Jan 2021 17:34:56 +0100 From: Dac Override To: openwrt-devel@lists.openwrt.org Subject: Re: Re: SELinux status report and call to action Hello Alberto, Thanks for you input. I agree that leveraging SELinux is, like for example leveraging Linux netfilter, not trivial. SELinux is however well documenting and with the exception of OpenWrt specifics it might not be productive to yet again document aspects that are already published elsewhere. I have created a document that explains how to build and edit the OpenWrt policy and I have also enclosed a link to the policy language used to write the OpenWrt policy: https://git.defensec.nl/?p=selinux-policy.git;a=summary 1. The CIL used to write OpenWrt policy: https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md 2. OpenWrt policy customization and testing: https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md Generally one should not have to interact with SELinux in OpenWrt but there are some exceptions 1. Some commands might be "targeted" by default and *if* a command cannot operate properly because it is targeted then you can manually run the command "unconfined": For example: you want to use `iw` but SELinux blocks it, then you can run iw from a shell with `runcon -t sys.subj -- iw` to by pass the SELinux restrictions. 2. Some commands might *not* be targeted by default and *if* you want to run that command with "basic" set of restrictions then you can run the command in a "SELinux sandbox". For example you want to run `bmon` with restricted permissions but SELinux does not target it by default then you can run bmon from a shell with `runcon -t sandbox.subj -- bmon` or `runcon -t sandbox.net,subj -- bmon` (you can also execute a restricted shell or tmux session this way (runcon -t sandbox.net.subj -- sh or runcon -t sandbox.net.subj -- tmux) 3. If a file for some reason ends up with a bad label (SELinux associates labels with inodes using the security.selinux security extended attribute) then you can use restorecon command. I have many video's on youtube with casual demonstrations on how to address various SELinux/OpenWrt issues and other case studies: For example: chronyd recently (in november last year) enhanced configuration and packaging, and so I had to adjust the policy so that the changes work. I documented the whole process here: https://www.youtube.com/watch?v=xC-YrlCR7iU Here is a demonstration of the SELinux openwrt sandbox functionality: https://www.youtube.com/watch?v=Ic_k9qknh_Q Filesystem management with SELinux and OpenWrt (zram example with f2fs): https://www.youtube.com/watch?v=R1wyv_poN4U There are various other videos on my channel with casual demo's and ramblings: Here is approx. 3 hours of SELinux with OpenWrt ramble touching on various topic: https://www.youtube.com/watch?v=Q4_SWTAcQSY Maybe we should create a Wiki page on the OpenWrt website where we can bundle these resources. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: SELinux status report and call to action
Hello Alberto, Thanks for you input. I agree that leveraging SELinux is, like for example leveraging Linux netfilter, not trivial. SELinux is however well documenting and with the exception of OpenWrt specifics it might not be productive to yet again document aspects that are already published elsewhere. I have created a document that explains how to build and edit the OpenWrt policy and I have also enclosed a link to the policy language used to write the OpenWrt policy: https://git.defensec.nl/?p=selinux-policy.git;a=summary 1. The CIL used to write OpenWrt policy: https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md 2. OpenWrt policy customization and testing: https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md Generally one should not have to interact with SELinux in OpenWrt but there are some exceptions 1. Some commands might be "targeted" by default and *if* a command cannot operate properly because it is targeted then you can manually run the command "unconfined": For example: you want to use `iw` but SELinux blocks it, then you can run iw from a shell with `runcon -t sys.subj -- iw` to by pass the SELinux restrictions. 2. Some commands might *not* be targeted by default and *if* you want to run that command with "basic" set of restrictions then you can run the command in a "SELinux sandbox". For example you want to run `bmon` with restricted permissions but SELinux does not target it by default then you can run bmon from a shell with `runcon -t sandbox.subj -- bmon` or `runcon -t sandbox.net,subj -- bmon` (you can also execute a restricted shell or tmux session this way (runcon -t sandbox.net.subj -- sh or runcon -t sandbox.net.subj -- tmux) 3. If a file for some reason ends up with a bad label (SELinux associates labels with inodes using the security.selinux security extended attribute) then you can use restorecon command. I have many video's on youtube with casual demonstrations on how to address various SELinux/OpenWrt issues and other case studies: For example: chronyd recently (in november last year) enhanced configuration and packaging, and so I had to adjust the policy so that the changes work. I documented the whole process here: https://www.youtube.com/watch?v=xC-YrlCR7iU Here is a demonstration of the SELinux openwrt sandbox functionality: https://www.youtube.com/watch?v=Ic_k9qknh_Q Filesystem management with SELinux and OpenWrt (zram example with f2fs): https://www.youtube.com/watch?v=R1wyv_poN4U There are various other videos on my channel with casual demo's and ramblings: Here is approx. 3 hours of SELinux with OpenWrt ramble touching on various topic: https://www.youtube.com/watch?v=Q4_SWTAcQSY Maybe we should create a Wiki page on the OpenWrt website where we can bundle these resources. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: base-files: flush kernel memory cache during sysupgrade
Stijn Segers kirjoitti 13.1.2021 klo 0.48: Have tested this on a few low-RAM devices, among which a TL-WR841N v7 (32 MiB) and a WNDR3700 v2 (64 MiB). No idea if this is still necessary/wanted but would be nice to see this end up in master (and trickle down to 21.xx :-D ). Tested-by: Stijn Segers Hi Stijn, this has been merged already in December as commit 3d12b4798: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3d12b47985fc1983849925d2dc23430f55210c80 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/12] add ubus support to ltq-[v|a]dsl-app
On 2021-01-09 09:40, Andre Heider wrote: Hi, (cc'ed some recent commiters for lantiq) On 15/12/2020 10:35, Andre Heider wrote: v2: - drop 0002-ltq-vdsl-app-fix-Wundef-warnings.patch - use "/dev/dsl_cpe_api" without the "0" suffix for the adsl daemon: package/kernel/lantiq/ltq-adsl/patches/100-dsl_compat.patch:+ device_create(dsl_class, NULL, MKDEV(DRV_DSL_CPE_API_DEV_MAJOR, 0), NULL, "dsl_cpe_api"); package/kernel/lantiq/ltq-vdsl/patches/100-compat.patch:+ device_create(dsl_class, NULL, dsl_devt, NULL, "dsl_cpe_api0"); - use callDSLMetrics() for luci, per jo - add Tested-by tags This is to significantly speed up the generation of the metrics. The motivation comes from the fact that ~2.6s is just way too ineffcient for interval based metric collectors like prometheus or collectd. The luci status page also loads/refreshes alot faster. $ time /etc/init.d/dsl_control dslstat real0m 2.66s user0m 0.90s sys 0m 1.76s $ time ubus call dsl metrics real0m 0.02s user0m 0.00s sys 0m 0.01s The ltq-adsl-app changes are only compile time tested. who do I need to convince to review this? ;) I would also like this great work to be merged. Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firmware-utils: bcm4908img: tool adding BCM4908 image tail
From: Rafał Miłecki
Flashing image with BCM4908 CFE bootloader requires specific firmware
format. It needs 20 extra bytes with magic numbers and CRC32 appended.
This tools allows appending such a tail to the specified image and also
verifying CRC32 of existing BCM4908 image.
Signed-off-by: Rafał Miłecki
---
tools/firmware-utils/Makefile | 1 +
tools/firmware-utils/src/bcm4908img.c | 379 ++
2 files changed, 380 insertions(+)
create mode 100644 tools/firmware-utils/src/bcm4908img.c
diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index a8c6ab4f65..055082593b 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -27,6 +27,7 @@ define Host/Compile
$(call cc,add_header)
$(call cc,addpattern)
$(call cc,asustrx)
+ $(call cc,bcm4908img,-Wall)
$(call cc,bcm4908kernel,-Wall)
$(call cc,buffalo-enc buffalo-lib,-Wall)
$(call cc,buffalo-tag buffalo-lib,-Wall)
diff --git a/tools/firmware-utils/src/bcm4908img.c
b/tools/firmware-utils/src/bcm4908img.c
new file mode 100644
index 00..86a187b146
--- /dev/null
+++ b/tools/firmware-utils/src/bcm4908img.c
@@ -0,0 +1,379 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 Rafał Miłecki
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#if !defined(__BYTE_ORDER)
+#error "Unknown byte order"
+#endif
+
+#if __BYTE_ORDER == __BIG_ENDIAN
+#define cpu_to_le32(x) bswap_32(x)
+#define le32_to_cpu(x) bswap_32(x)
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
+#define cpu_to_le32(x) (x)
+#define le32_to_cpu(x) (x)
+#else
+#error "Unsupported endianness"
+#endif
+
+struct bcm4908img_tail {
+ uint32_t crc32;
+ uint32_t unk1;
+ uint32_t family;
+ uint32_t unk2;
+ uint32_t unk3;
+};
+
+char *pathname;
+static size_t prefix_len;
+static size_t suffix_len;
+
+static inline size_t bcm4908img_min(size_t x, size_t y) {
+ return x < y ? x : y;
+}
+
+/**
+ * CRC32
+ **/
+
+static const uint32_t crc32_tbl[] = {
+ 0x, 0x77073096, 0xee0e612c, 0x990951ba,
+ 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
+ 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
+ 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
+ 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+ 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
+ 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
+ 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
+ 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
+ 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+ 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
+ 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
+ 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
+ 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
+ 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+ 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
+ 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
+ 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
+ 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
+ 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+ 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
+ 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
+ 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
+ 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
+ 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+ 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
+ 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
+ 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
+ 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
+ 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+ 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
+ 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
+ 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
+ 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
+ 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+ 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
+ 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
+ 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
+ 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
+ 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+ 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
+ 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
+ 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
+ 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
+ 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
+ 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
+ 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
+ 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
+ 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
+ 0x9c0906a9, 0xeb0e363f,
Re: SELinux status report and call to action
On 12/01/21 18:27, Dominick Grift wrote: - My question to the reader is: why haven't you enabled SELinux yet on your test builds at least? Or maybe you have but you havent given any feedback. Why is that? Thanks, Lack of documentation. Selinux is not an easy topic even on a normal Linux distro, and there is little if any info on how to use it (or why use it) in OpenWrt. I think a necessary first step for adoption is writing some docs about what it is, and how to use it in the wiki/site openwrt.org Since I know very little about it, I can't do that. But you said you gave a talk about this topic in a large conference, maybe you can write some documentation? -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SELinux status report and call to action
On 1/12/21 6:27 PM, Dominick Grift wrote: > > Community, > > Optional SELinux support has been added to OpenWrt for a while now and I > gave a talk about the status at "Battle of the meshes 13th edition". > > There was a comment mentioning that there was an impression that > "rolling out SELinux on OpenWrt" would still require lots of work and > that there are still lots of "loose ends". I failed to ask the person > what work and what loose ends he still see's. > > Regardless in the few months that have passed I have had give or take three > times feedback on SELinux in OpenWrt: > > 1. dangole tests bootstrap every once in a while and if needed he > provides me with information and contributions needed to get and keep > that to work on atleast devices and configurations he is using. > > 2. I had one person e-mailing me mentioning that, i guess, WPA > enterprise, does not work and that wpa_supplicant needs to be able to > connect to a radius server for this (i addressed that issue to the > best of my ability but havent heared from the person since and I am not > sure whether that means that its is fixed or that the person hasnt > tested it since the fixed trickled down) > > 3. jow gave some casual feedback on running services on alternate > network ports and i addressed this issue as well although the fix for > that might not have trickled down yet. > > I was hoping for a little more exposure and feedback than this. The way > i see it, it should not be much of an extra burden for OpenWrt devs to > build their systems with SELinux support and to report any obvious > issues back so that the effort can evolve instead of face early death. > > My question to the reader is: why haven't you enabled SELinux yet on > your test builds at least? Or maybe you have but you havent given any > feedback. Why is that? > > Is it too much of a burden? If that is the case we could for now > consider shipping a "permissive" policy so that SELinux will never > be in your way if that helps. > > Can you please consider just enabling SELinux on your tests? If there > are any observations and SELinux related messages in the logs then > please report those to me via email or IRC? > > If you have objections then please let me know what those objections are > so that I can identify whether those objections can be addressed. > > I did not, and do not expect that SELinux adoption would be popular but > for developers that are very familiar with OpenWrt I do not see much of > a reason not to enable it on test builds/systems either. Your feedback > is valuable and is important to help improve the experience. > > SELinux on OpenWrt works great for me and to be honest that is my first > priority but with a little more involvement and interest from others > there is much more room for improvement. > > If you just build your systems with SELinux enabled and then provide > feedback if there is something to report then that would be > appreciated. If something is stopping you and if there is something i > can do to make it easier then please let it be known. > > Thanks, > I received some feedback off-list and there was some chatter on IRC. This reminds me that I should mention that LuCI integration is known to have a lot of rough edges (although, with the exception of sysupgrade and package management, most of the *LuCI-basics* should work). To be honest I did not expect it that aside from LuCI developers, users of this list would be using LuCI on development snapshots. Nevertheless, be aware that LuCI has known rough edges and that I see LuCI as a separate optional layer. I am not trying to justify the issues there (and I do also appreciate any LuCI feedback), but LuCI needs a lot more work. Please do not let that stand in the way of testing the remainder of OpenWrt. Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
This allows configuration of multicast_to_unicast and per_sta_vif options.
- multicast_to_unicast requests multicast-to-unicast conversion.
- per_sta_vif assigns each station its own AP_VLAN interface.
Signed-off-by: Etan Kissling
---
package/network/services/hostapd/Makefile | 2 +-
package/network/services/hostapd/files/hostapd.sh | 15 ++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/package/network/services/hostapd/Makefile
b/package/network/services/hostapd/Makefile
index f57b072974..a6d56d1433 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=hostapd
-PKG_RELEASE:=23
+PKG_RELEASE:=24
PKG_SOURCE_URL:=http://w1.fi/hostap.git
PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 7d9ee5121e..cee9a8eaa2 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -331,6 +331,8 @@ hostapd_common_add_bss_config() {
config_add_array airtime_sta_weight
config_add_int airtime_bss_weight airtime_bss_limit
+ config_add_boolean multicast_to_unicast per_sta_vif
+
config_add_array hostapd_bss_options
}
@@ -480,7 +482,8 @@ hostapd_set_bss_options() {
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key
skip_inactivity_poll \
- airtime_bss_weight airtime_bss_limit airtime_sta_weight
+ airtime_bss_weight airtime_bss_limit airtime_sta_weight \
+ multicast_to_unicast per_sta_vif
set_default isolate 0
set_default maxassoc 0
@@ -942,6 +945,16 @@ hostapd_set_bss_options() {
json_for_each_item append_operator_icon operator_icon
fi
+ set_default multicast_to_unicast 0
+ if [ "$multicast_to_unicast" -gt 0 ]; then
+ append bss_conf "multicast_to_unicast=$multicast_to_unicast"
"$N"
+ fi
+
+ set_default per_sta_vif 0
+ if [ "$per_sta_vif" -gt 0 ]; then
+ append bss_conf "per_sta_vif=$per_sta_vif" "$N"
+ fi
+
json_get_values opts hostapd_bss_options
for val in $opts; do
append bss_conf "$val" "$N"
--
2.21.1 (Apple Git-122.3)
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
