Message ID | 20221209152836.1667196-1-alvin@pqrs.dk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp841085wrr; Fri, 9 Dec 2022 07:29:41 -0800 (PST) X-Google-Smtp-Source: AA0mqf43tdf+jCfD5d8vQy8b5cPGmC58q+uQeU90N44ER67J121GpkWNDHYul7oAIK+nVyyOhKhi X-Received: by 2002:aa7:c944:0:b0:45c:834b:f28c with SMTP id h4-20020aa7c944000000b0045c834bf28cmr4851413edt.9.1670599780857; Fri, 09 Dec 2022 07:29:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670599780; cv=none; d=google.com; s=arc-20160816; b=GY4Z33Gi877HRrL3OwvYHEUgzpwgM09C4gzCfWPV1Th88cGCDPk/mR9CR25lpnpJ4c bz4tacSFaKXiRUCLTe9BEY56iBU4gJ3mfEH17MmPi8O+Rqk2en7bA+JqO7pcQJQ7rcEQ RHbw/c/xhB6Gf1HZQsXcr5eorVoK5UV/iMKN6aw1jeg5lDH+Cai+GDyOGq00zdSv9I/Q 0nWiJ5beCVohriW5qb6o4AedM+4cbbLxPrEHvZYiW7m4sEGlefxOZZ3Uzq3fpcKsA0jk XDskHfQkq3U/8g51nY9kIeXrJudmvdCV4NLIZQLUw6OHHBa1/OQtJIktYZUIpYzy63Kr 1xzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=/CBIx7WhayGl8L5UnKkWTZlh8ccP3yQ9V2VOk1LDfuU=; b=abqJX1AMI37ssF4GB5uzqSL3NQZJOGZLbkujMsfVed2VeeS9QZEKKCwS0X/l+J90AA 99E+WcJDEMO1RIGc8sOpb3o4UwFyT0WUTOTm2+UGvuuxbUn3/P+75ElDJQx9TGj9uNr9 x0W0LvwgmQUz6q9wQbtOCMTUI/6c0Fm0IVs67JBxoASrAS4rw0vJWrTDVGSyzZnDBH3/ tnP61pSOUcY5b8LESLT4VqK8vkPmKJhS2oqJLuN35HF3Hp1yYxlISTDeUB/PXAMWgSig Sf1hgTwtPbLRQPoSMmc0R71qzw7E1H18Q45zTizZJv52Fcqy202eXG7SAMfEiNAo61nE Wpzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@pqrs.dk header.s=google header.b=g3vLufSX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b4-20020aa7c6c4000000b0046cf113b9c0si1250253eds.550.2022.12.09.07.29.17; Fri, 09 Dec 2022 07:29:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@pqrs.dk header.s=google header.b=g3vLufSX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229761AbiLIP3H (ORCPT <rfc822;sophiezhao968@gmail.com> + 99 others); Fri, 9 Dec 2022 10:29:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229631AbiLIP2x (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 9 Dec 2022 10:28:53 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC330CE7 for <linux-kernel@vger.kernel.org>; Fri, 9 Dec 2022 07:28:50 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id x22so12285712ejs.11 for <linux-kernel@vger.kernel.org>; Fri, 09 Dec 2022 07:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pqrs.dk; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=/CBIx7WhayGl8L5UnKkWTZlh8ccP3yQ9V2VOk1LDfuU=; b=g3vLufSXkk6Bd3BbnBSvYEhasj4ZRFzeqITPpY1spDMrZTTsgQWtZjx0r+YQmw17sX ZMkDKy6mms6/tQjTrYstAp0/HovfK/Wdhi7W+nl3VNNxpyBkOEG+0tB0gUOQ2tzglGPc dYprSHDOKFiY7kDDop4pYjHpFp/ylftdANH3w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/CBIx7WhayGl8L5UnKkWTZlh8ccP3yQ9V2VOk1LDfuU=; b=vSRwGYr8X/SAVWIs5LI7FalU7yicsGn5JcQtskEvkbmgU4wdPF1A5a2IGBC8a+BVmr QDeGdm//IP6tvjdAmebz/2cmqtXwzJHHe+T37mkate7fXTH7vUi5bmCuG3BuUJksKbO+ CEJ5UMXSQkhUVzRW7tdXu/irwsZoPmHttRXGVSxXRqnSSCaJbLmlYu2uTE6C15xaV1l8 BR2TABIpH0CSDuLkh1B3XRJsgjuSTbdZcDr+r8Du5CQpTLcIuSXtHzUBDQ/jwTHlHCtD TcKRe9APPVfQEOarj1TJN+ehL9xKZxEgGFhi5twjzOPt9JIgDssxTlZT1QsXLeLtHMU0 +u7w== X-Gm-Message-State: ANoB5pmaYchoqg11U/CtYP1Kd1PjjuZQZdea9PG5THF+1W1VF9bGfu+j UxbghtFu0jKOmFCcX/XEVZyM6g== X-Received: by 2002:a17:906:2881:b0:7ad:d835:e822 with SMTP id o1-20020a170906288100b007add835e822mr4899301ejd.42.1670599729472; Fri, 09 Dec 2022 07:28:49 -0800 (PST) Received: from localhost.localdomain (80.71.142.18.ipv4.parknet.dk. [80.71.142.18]) by smtp.gmail.com with ESMTPSA id o20-20020a170906769400b0077a11b79b9bsm24901ejm.133.2022.12.09.07.28.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Dec 2022 07:28:49 -0800 (PST) From: =?utf-8?q?Alvin_=C5=A0ipraga?= <alvin@pqrs.dk> To: Johannes Berg <johannes@sipsolutions.net>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: =?utf-8?q?Alvin_=C5=A0ipraga?= <alsi@bang-olufsen.dk>, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH next] wifi: nl80211: emit CMD_START_AP on multicast group when an AP is started Date: Fri, 9 Dec 2022 16:28:36 +0100 Message-Id: <20221209152836.1667196-1-alvin@pqrs.dk> X-Mailer: git-send-email 2.37.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751750835663388195?= X-GMAIL-MSGID: =?utf-8?q?1751750835663388195?= |
Series |
[next] wifi: nl80211: emit CMD_START_AP on multicast group when an AP is started
|
|
Commit Message
Alvin Šipraga
Dec. 9, 2022, 3:28 p.m. UTC
From: Alvin Šipraga <alsi@bang-olufsen.dk> Userspace processes such as network daemons may wish to be informed when any AP interface is brought up on the system, for example to initiate a (re)configuration of IP settings or to start a DHCP server. Currently nl80211 does not broadcast any such event on its multicast groups, leaving userspace only two options: 1. the process must be the one that actually issued the NL80211_CMD_START_AP request, so that it can react on the response to that request; 2. the process must react to RTM_NEWLINK events indicating a change in carrier state, and may query for further information about the AP and react accordingly. Option (1) is robust, but it does not cover all scenarios. It is easy to imagine a situation where this is not the case (e.g. hostapd + systemd-networkd). Option (2) is not robust, because RTM_NEWLINK events may be silently discarded by the linkwatch logic (cf. linkwatch_fire_event()). Concretely, consider a scenario in which the carrier state flip-flops in the following way: ^ carrier state (high/low = carrier/no carrier) | | _______ _______ ... | | | | | ______| "foo" |____| "bar" (SSID in "quotes") | +-------A-------B----C---------> time If the time interval between (A) and (C) is less than 1 second, then linkwatch may emit only a single RTM_NEWLINK event indicating carrier gain. This is problematic because it is possible that the network configuration that should be applied is a function of the AP's properties such as SSID (cf. SSID= in systemd.network(5)). As illustrated in the above diagram, it may be that the AP with SSID "bar" ends up being configured as though it had SSID "foo". Address the above issue by having nl80211 emit an NL80211_CMD_START_AP message on the MLME nl80211 multicast group. This allows for arbitrary processes to be reliably informed. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> --- net/wireless/nl80211.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
Comments
On Fri, 2022-12-09 at 16:28 +0100, Alvin Šipraga wrote: > > This is problematic because it is possible that the network > configuration that should be applied is a function of the AP's > properties such as SSID (cf. SSID= in systemd.network(5)). As > illustrated in the above diagram, it may be that the AP with SSID "bar" > ends up being configured as though it had SSID "foo". > You might not care if you want the SSID, but it still seems wrong: > +static void nl80211_send_ap_started(struct wireless_dev *wdev) > +{ > + struct wiphy *wiphy = wdev->wiphy; > + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); > + struct sk_buff *msg; > + void *hdr; > + > + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL); > + if (!msg) > + return; > + > + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_START_AP); > + if (!hdr) > + goto out; > + > + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) || > + nla_put_u32(msg, NL80211_ATTR_IFINDEX, wdev->netdev->ifindex) || > + nla_put_u64_64bit(msg, NL80211_ATTR_WDEV, wdev_id(wdev), > + NL80211_ATTR_PAD) || > + (wdev->u.ap.ssid_len && > + nla_put(msg, NL80211_ATTR_SSID, wdev->u.ap.ssid_len, > + wdev->u.ap.ssid))) > + goto out; > + > + genlmsg_end(msg, hdr); > + > + genlmsg_multicast_netns(&nl80211_fam, wiphy_net(wiphy), msg, 0, > + NL80211_MCGRP_MLME, GFP_KERNEL); > + return; > +out: > + nlmsg_free(msg); > +} This has no indication of the link, but with multi-link you could actually be sending this event multiple times to userspace on the same netdev. > static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) > { > struct cfg80211_registered_device *rdev = info->user_ptr[0]; > @@ -6050,6 +6083,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) > > if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) > wdev->conn_owner_nlportid = info->snd_portid; > + > + nl80211_send_ap_started(wdev); > } because this can be called multiple times, once for each link. Seems like you should include the link ID or something? johannes
Hi Johannes, On Wed, Jan 18, 2023 at 05:26:19PM +0100, Johannes Berg wrote: > On Fri, 2022-12-09 at 16:28 +0100, Alvin Šipraga wrote: > > > > This is problematic because it is possible that the network > > configuration that should be applied is a function of the AP's > > properties such as SSID (cf. SSID= in systemd.network(5)). As > > illustrated in the above diagram, it may be that the AP with SSID "bar" > > ends up being configured as though it had SSID "foo". > > > > You might not care if you want the SSID, but it still seems wrong: > > > +static void nl80211_send_ap_started(struct wireless_dev *wdev) > > +{ > > + struct wiphy *wiphy = wdev->wiphy; > > + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); > > + struct sk_buff *msg; > > + void *hdr; > > + > > + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL); > > + if (!msg) > > + return; > > + > > + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_START_AP); > > + if (!hdr) > > + goto out; > > + > > + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) || > > + nla_put_u32(msg, NL80211_ATTR_IFINDEX, wdev->netdev->ifindex) || > > + nla_put_u64_64bit(msg, NL80211_ATTR_WDEV, wdev_id(wdev), > > + NL80211_ATTR_PAD) || > > + (wdev->u.ap.ssid_len && > > + nla_put(msg, NL80211_ATTR_SSID, wdev->u.ap.ssid_len, > > + wdev->u.ap.ssid))) > > + goto out; > > + > > + genlmsg_end(msg, hdr); > > + > > + genlmsg_multicast_netns(&nl80211_fam, wiphy_net(wiphy), msg, 0, > > + NL80211_MCGRP_MLME, GFP_KERNEL); > > + return; > > +out: > > + nlmsg_free(msg); > > +} > > This has no indication of the link, but with multi-link you could > actually be sending this event multiple times to userspace on the same > netdev. > > > static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) > > { > > struct cfg80211_registered_device *rdev = info->user_ptr[0]; > > @@ -6050,6 +6083,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) > > > > if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) > > wdev->conn_owner_nlportid = info->snd_portid; > > + > > + nl80211_send_ap_started(wdev); > > } > > because this can be called multiple times, once for each link. > > Seems like you should include the link ID or something? Thanks for your review, you are quite right. I didn't give much thought to MLO as I am not too familiar with it. Is something like the below what you are looking for? Speaking of which: I drew inspiration from nl80211_send_ap_stopped() which see also doesn't include the link ID. Would you like me to include a second patch in v2 which adds the link ID to that function along the same lines? Kind regards, Alvin -------------->8---------------------------------- diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index ba4965f035b2..5720ffcbecc4 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -5770,7 +5770,7 @@ static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rdev, } } -static void nl80211_send_ap_started(struct wireless_dev *wdev) +static void nl80211_send_ap_started(struct wireless_dev *wdev, unsigned int link_id) { struct wiphy *wiphy = wdev->wiphy; struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); @@ -5791,7 +5791,9 @@ static void nl80211_send_ap_started(struct wireless_dev *wdev) NL80211_ATTR_PAD) || (wdev->u.ap.ssid_len && nla_put(msg, NL80211_ATTR_SSID, wdev->u.ap.ssid_len, - wdev->u.ap.ssid))) + wdev->u.ap.ssid)) || + (wdev->valid_links && + nla_put_u8(msg, NL80211_ATTR_MLO_LINK_ID, link_id))) goto out; genlmsg_end(msg, hdr); @@ -6084,7 +6086,7 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) wdev->conn_owner_nlportid = info->snd_portid; - nl80211_send_ap_started(wdev); + nl80211_send_ap_started(wdev, link_id); } out_unlock: wdev_unlock(wdev);
Hi, > > Seems like you should include the link ID or something? > > Thanks for your review, you are quite right. I didn't give much thought > to MLO as I am not too familiar with it. Is something like the below > what you are looking for? Yes, that looks good. > Speaking of which: I drew inspiration from nl80211_send_ap_stopped() > which see also doesn't include the link ID. Would you like me to include > a second patch in v2 which adds the link ID to that function along the > same lines? Maybe have that as a separate patch, but yeah, good idea - thanks for looking! johannes
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 33a82ecab9d5..323b7e40d855 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -5770,6 +5770,39 @@ static bool nl80211_valid_auth_type(struct cfg80211_registered_device *rdev, } } +static void nl80211_send_ap_started(struct wireless_dev *wdev) +{ + struct wiphy *wiphy = wdev->wiphy; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + struct sk_buff *msg; + void *hdr; + + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL); + if (!msg) + return; + + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_START_AP); + if (!hdr) + goto out; + + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) || + nla_put_u32(msg, NL80211_ATTR_IFINDEX, wdev->netdev->ifindex) || + nla_put_u64_64bit(msg, NL80211_ATTR_WDEV, wdev_id(wdev), + NL80211_ATTR_PAD) || + (wdev->u.ap.ssid_len && + nla_put(msg, NL80211_ATTR_SSID, wdev->u.ap.ssid_len, + wdev->u.ap.ssid))) + goto out; + + genlmsg_end(msg, hdr); + + genlmsg_multicast_netns(&nl80211_fam, wiphy_net(wiphy), msg, 0, + NL80211_MCGRP_MLME, GFP_KERNEL); + return; +out: + nlmsg_free(msg); +} + static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) { struct cfg80211_registered_device *rdev = info->user_ptr[0]; @@ -6050,6 +6083,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info) if (info->attrs[NL80211_ATTR_SOCKET_OWNER]) wdev->conn_owner_nlportid = info->snd_portid; + + nl80211_send_ap_started(wdev); } out_unlock: wdev_unlock(wdev);