Re: [PATCH firewall4] fw4: add support for include.d dir
Hi,
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?
A potential pattern could be
"[0-9][0-9]_{ruleset_pre,ruleset_post,table_pre,table_post,chain_pre_*,chain_post_*}_*.nft".
Taking the example from your mail, these *.nft includes would be stored at
/usr/share/firewall4/include.d/01_chain_pre_input_strongswan.nft
/usr/share/firewall4/include.d/02_chain_pre_output_strongswan.nft
/usr/share/firewall4/include.d/03_chain_pre_forward_strongswan.nft
Alternatively, the hooks could be moved into a subdirectory structure for
better clarity:
/usr/share/firewall4/includes.d/
+ ruleset-pre/
+ 99_custom_named_set_declarations.nft
+ ruleset-post/
+ ...
+ table-pre/
+ ...
+ table-post/
+ ...
+ chain-pre/
+ input/
+ 29_strongswan.nft
+ output/
+ 29_strongswan.nft
+ forward/
+ 29_strongswan.nft
+ chain-post/
+ mangle_output/
+ 99_custom_dscp_fiddling.nft
(The numeric prefixes carry no semantic meaning in this structure, they'd just
be there to enforce a certain order within a given hook directory)
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.
~ Jo
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [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] mac80211: parse the correct set of HE capabilities for AP mode
From: Sultan Alsawaf
It is common for 802.11ax NICs to support more than just AP mode, which
results in there being a distinct set of HE capabilities for each mode. As
(bad) luck would have it, iw prints out info for each HE mode in sequential
order according to `enum nl80211_iftype`, and AP mode isn't always first.
As a result, the wrong set of HE capabilities can be parsed if an AP NIC
supports station (managed) mode or any other mode preceding AP mode, since
only the first set of HE capabilities printed by iw is parsed from awk's
output.
This has a noticeable impact on beamforming for example, since managed mode
usually doesn't have beamformer capabilities enabled, while AP mode does.
Hostapd won't be set up with the configs to enable beamformer capabilities
in this scenario, causing hostapd to disable beamforming to HE stations
even when it's supported by the AP.
Always parse the correct set of HE capabilities for AP mode to fix this.
This is achieved by trimming all of iw's output prior to the AP mode
capabilities, which ensures that the first set of HE capabilities are
always for AP mode.
Signed-off-by: Sultan Alsawaf
---
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 5d6ca7c0e3..035739b8ac 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -420,9 +420,9 @@ mac80211_hostapd_setup_base() {
he_spr_non_srg_obss_pd_max_offset:1 \
he_bss_color
- he_phy_cap=$(iw phy "$phy" info | awk -F "[()]" '/HE PHY
Capabilities/ { print $2 }' | head -1)
+ he_phy_cap=$(iw phy "$phy" info | sed -n '/HE Iftypes: AP/,$p'
| awk -F "[()]" '/HE PHY Capabilities/ { print $2 }' | head -1)
he_phy_cap=${he_phy_cap:2}
- he_mac_cap=$(iw phy "$phy" info | awk -F "[()]" '/HE MAC
Capabilities/ { print $2 }' | head -1)
+ he_mac_cap=$(iw phy "$phy" info | sed -n '/HE Iftypes: AP/,$p'
| awk -F "[()]" '/HE MAC Capabilities/ { print $2 }' | head -1)
he_mac_cap=${he_mac_cap:2}
append base_cfg "ieee80211ax=1" "$N"
--
2.37.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
