Re: [PATCH 4/4] hostapd: support MBO in bss_transition_request
On 28/06/2022 02:05, Strontium wrote: Hi Stijn, I am wanting to test these patches on an AP. Is this a case of applying this, configure MBO enabled, and it just works? I ask, because it looks like a daemon of some kind needs to manage the MBO transitions of the attached STA using UBUS transition requests, is that correct? This patch merely adds support for MBO to the existing ubus method bss_transition_request. This method is used by [1] and [2] to steer clients between different BSSes in an ESS, but does nothing on its own. Once this patch is in OpenWrt, these daemons could be updated to make use of the new MBO attributes for improved steering. Stijn [1] https://git.openwrt.org/?p=project/usteer.git [2] https://github.com/berlin-open-wireless-lab/DAWN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/4] hostapd: support MBO in bss_transition_request
Hi Stijn,
I am wanting to test these patches on an AP. Is this a case of applying
this, configure MBO enabled, and it just works? I ask, because it looks
like a daemon of some kind needs to manage the MBO transitions of the
attached STA using UBUS transition requests, is that correct?
On 21/6/22 20:36, Stijn Tintel wrote:
Support the use of MBO in the bss_transition_request ubus method.
Signed-off-by: Stijn Tintel
---
package/network/services/hostapd/README.md| 3 +
.../services/hostapd/src/src/ap/ubus.c| 61 ++-
2 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/package/network/services/hostapd/README.md
b/package/network/services/hostapd/README.md
index bd347c61dd..2150863306 100644
--- a/package/network/services/hostapd/README.md
+++ b/package/network/services/hostapd/README.md
@@ -29,6 +29,9 @@ Initiate an 802.11v transition request.
| neighbors | array | no | BSS Transition Candidate List |
| abridged | bool | no | prefer APs in the BSS Transition Candidate List |
| dialog_token | int32 | no | identifier for the request/report transaction |
+| mbo_reason | int32 | no | MBO Transition Reason Code Attribute |
+| cell_pref | int32 | no | MBO Cellular Data Connection Preference Attribute |
+| reassoc_delay | int32 | no | MBO Re-association retry delay |
### example
`ubus call hostapd.wl5-fb bss_transition_request '{ "addr": "68:2F:67:8B:98:ED", "disassociation_imminent": false,
"disassociation_timer": 0, "validity_period": 30, "neighbors": ["b6a7b9cbeebabf598064090603026a00"],
"abridged": 1 }'`
diff --git a/package/network/services/hostapd/src/src/ap/ubus.c
b/package/network/services/hostapd/src/src/ap/ubus.c
index 1199098b1e..182aae7d05 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -1454,7 +1454,7 @@ void hostapd_ubus_handle_link_measurement(struct
hostapd_data *hapd, const u8 *d
static int
hostapd_bss_tr_send(struct hostapd_data *hapd, u8 *addr, bool
disassoc_imminent, bool abridged,
u16 disassoc_timer, u8 validity_period, u8 dialog_token,
- struct blob_attr *neighbors)
+ struct blob_attr *neighbors, u8 mbo_reason, u8 cell_pref,
u8 reassoc_delay)
{
struct blob_attr *cur;
struct sta_info *sta;
@@ -1462,6 +1462,8 @@ hostapd_bss_tr_send(struct hostapd_data *hapd, u8 *addr,
bool disassoc_imminent,
int rem;
u8 *nr = NULL;
u8 req_mode = 0;
+ u8 mbo[10];
+ size_t mbo_len = 0;
sta = ap_get_sta(hapd, addr);
if (!sta)
@@ -1513,8 +1515,37 @@ hostapd_bss_tr_send(struct hostapd_data *hapd, u8 *addr,
bool disassoc_imminent,
if (disassoc_imminent)
req_mode |= WNM_BSS_TM_REQ_DISASSOC_IMMINENT;
+#ifdef CONFIG_MBO
+ u8 *mbo_pos = mbo;
+
+ if (mbo_reason > MBO_TRANSITION_REASON_PREMIUM_AP)
+ return UBUS_STATUS_INVALID_ARGUMENT;
+
+ if (cell_pref != 0 && cell_pref != 1 && cell_pref != 255)
+ return UBUS_STATUS_INVALID_ARGUMENT;
+
+ if (reassoc_delay > 65535 || (reassoc_delay && !disassoc_imminent))
+ return UBUS_STATUS_INVALID_ARGUMENT;
+
+ *mbo_pos++ = MBO_ATTR_ID_TRANSITION_REASON;
+ *mbo_pos++ = 1;
+ *mbo_pos++ = mbo_reason;
+ *mbo_pos++ = MBO_ATTR_ID_CELL_DATA_PREF;
+ *mbo_pos++ = 1;
+ *mbo_pos++ = cell_pref;
+
+ if (reassoc_delay) {
+ *mbo_pos++ = MBO_ATTR_ID_ASSOC_RETRY_DELAY;
+ *mbo_pos++ = 2;
+ WPA_PUT_LE16(mbo_pos, reassoc_delay);
+ mbo_pos += 2;
+ }
+
+ mbo_len = mbo_pos - mbo;
+#endif
+
if (wnm_send_bss_tm_req(hapd, sta, req_mode, disassoc_timer,
validity_period, NULL,
- dialog_token, NULL, nr, nr_len, NULL, 0))
+ dialog_token, NULL, nr, nr_len, mbo_len ? mbo :
NULL, mbo_len))
return UBUS_STATUS_UNKNOWN_ERROR;
return 0;
@@ -1528,6 +1559,11 @@ enum {
BSS_TR_NEIGHBORS,
BSS_TR_ABRIDGED,
BSS_TR_DIALOG_TOKEN,
+#ifdef CONFIG_MBO
+ BSS_TR_MBO_REASON,
+ BSS_TR_CELL_PREF,
+ BSS_TR_REASSOC_DELAY,
+#endif
__BSS_TR_DISASSOC_MAX
};
@@ -1539,6 +1575,11 @@ static const struct blobmsg_policy bss_tr_policy[__BSS_TR_DISASSOC_MAX] = {
[BSS_TR_NEIGHBORS] = { "neighbors", BLOBMSG_TYPE_ARRAY },
[BSS_TR_ABRIDGED] = { "abridged", BLOBMSG_TYPE_BOOL },
[BSS_TR_DIALOG_TOKEN] = { "dialog_token", BLOBMSG_TYPE_INT32 },
+#ifdef CONFIG_MBO
+ [BSS_TR_MBO_REASON] = { "mbo_reason", BLOBMSG_TYPE_INT32 },
+ [BSS_TR_CELL_PREF] = { "cell_pref", BLOBMSG_TYPE_INT32 },
+ [BSS_TR_REASSOC_DELAY] = { "reassoc_delay", BLOBMSG_TYPE_INT32 },
+#endif
};
static int
@@ -1555,6 +1596,9 @@ hostapd_bss_transition_request(struct ubus_context *ctx,
struct ubus_object *obj
[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
Fwd: [PATCH] netifd: fix WPA3 enterprise ciphers
[Resending due to previous response being rejected by the list due to being an HTML e-mail] Hi NIck, take a look at the Cisco link you have sent, there is an interoperability table at the end. GCMP with Suite B 1x is basically supported by none of the STA. If you use wpa3 as the encryption setting in OpenWRT, in the code we'll set auth_type=eap192, which in turn will set wpa_key_mgmt=WPA-EAP-SUITE-B-192 in hostapd.conf. So it enables Suite B with 192bit, which in turn requires wpa-cipher=GCMP-256. Aruba says something similar here: https://www.arubanetworks.com/techdocs/Instant_86_WebHelp/Content/instant-ug/authentication/wpa3.htm Best Regards, Joerg On Sun, Jun 26, 2022 at 8:39 PM Nick Lowe wrote: > > Hi Joerg, > > Where is this stated? > > If I check the following Cisco link, this is not constrained in this way on > their products: > > https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/wpa3-dep-guide-og.html > > If I check the Wi-Fi alliance spec at > https://www.wi-fi.org/file/wpa3-specification , this states the following, > and a requirement for GCMP does not appear to be mentioned: > > 3 > WPA3-Enterprise > WPA3-Enterprise applies to enterprise network settings. > > 3.1 > Modes of operation > WPA3-Enterprise modes are defined as follows: > • WPA3-Enterprise only mode > • WPA3-Enterprise transition mode > • WPA3-Enterprise 192-bit mode > > 3.2 > WPA3-Enterprise only mode > When operating in WPA3-Enterprise only mode: > • An AP shall enable at least AKM suite selector 00-0F-AC:5 (IEEE 802.1X with > SHA-256) in the BSS > • A STA shall allow at least AKM suite selector 00-0F-AC:5 to be selected for > an association > • An AP shall not enable AKM suite selector: 00-0F-AC:1 (IEEE 802.1X with > SHA-1) > • A STA shall not allow AKM suite selector 00-0F-AC:1 to be selected for an > association > • An AP shall set MFPC to 1, MFPR to 1 > • A STA shall set MFPC to 1, MFPR to 1 > • A STA shall not enable WEP and TKIP > > 3.3 > WPA3-Enterprise transition mode > When operating in WPA3-Enterprise transition mode: > • An AP shall enable at least AKM suite selectors 00-0F-AC:1 (IEEE 802.1X > with SHA-1) and 00-0F-AC:5 (IEEE 802.1X with SHA-256) in the BSS > • A STA shall allow at least AKM suite selectors 00-0F-AC:1 and 00-0F-AC:5 to > be selected for an association > • An AP shall set MFPC to 1, MFPR to 0 > • A STA shall set MFPC to 1, MFPR to 0 > > 3.4 > Additional Requirements on WPA3-Enterprise modes > The following additional requirements apply to all WPA3-Enterprise modes: > 1. An AP shall not enable WPA version 1 on the same BSS with WPA3-Enterprise > 2. An AP shall not enable WEP and TKIP on the same BSS as WPA3-Enterprise > > 3.5 > WPA3-Enterprise 192-bit mode > WPA3-Enterprise 192-bit mode is well suited for deployments in sensitive > enterprise environments to further protect Wi- Fi® networks with higher > security requirements such as government, defense, and industrial. > When operating in WPA3-Enterprise 192-bit mode: > 1. When WPA3-Enterprise 192-bit mode is used by an AP, PMF shall be set to > required (MFPR bit in the RSN Capabilities field shall be set to 1 in the > RSNE transmitted by the AP). > 2. When WPA3-Enterprise 192-bit mode is used by a STA, PMF shall be set to > required (MFPR bit in the RSN Capabilities field shall be set to 1 in the > RSNE transmitted by the STA). > 3. Permitted EAP cipher suites for use with WPA3-Enterprise 192-bit mode are: > ▪ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > - ECDHE and ECDSA using the 384-bit prime modulus curve P-384 > ▪ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > - ECDHE using the 384-bit prime modulus curve P-384 > - RSA ≥ 3072-bit modulus > ▪ TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > - RSA ≥ 3072-bit modulus - DHE ≥ 3072-bit modulus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
