Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5922955ybp; Tue, 8 Oct 2019 10:12:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqyWrRDBBXwE0aOK2jgXhSBgUi8zlcy7Onf19BHdrk//JyMbD916nQnHyWFcIDC4ESkRTRvI X-Received: by 2002:a50:ea8c:: with SMTP id d12mr35093672edo.87.1570554767316; Tue, 08 Oct 2019 10:12:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570554767; cv=none; d=google.com; s=arc-20160816; b=ymYbu6zm9L6k7dFBh2PsQxwqvGaPsl0sRYmq8KRswlkgIIkhYJnTpkPByZpLYiZgIB jpaaW8Iw7tKQSIAz6ivWF1Cx83R9QIfROc3pq1X7PafF3nvf1dFI9AmmWKtdKapY1la8 VrYkRZgNOfPWh77MTJyl5x6b2R15KaP1DJCR+NwNYF/QSTgq0t0vCnEyXIB1yLJ86bUw o7+sVcpVxyY438GD4Ao6nBBmTSQWpj+uRKzr2ZwNhPXgXKyuXw/TRArCnUt6w5Ma637Y 1r9n9lYEAHDcU9Wi3GIfrXDVSl0yhP/wrKv3u8OHNWcBj05rVop4+0GVXreS63Mr4Gy+ wH0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:to:from:subject:message-id; bh=4suCifWu6ZjRFm7XaA+BLc5njgG8G7/nNUkLbV6k7Qs=; b=HsCZ5Av+IC0VyidiXPLFMssLDQCYhhdR6xLsQo8WLz67kIqhE8wdEEKiCClssPqSX6 ot0bHqo4PyI77wmtxZZJUuIGvc1FMtXP2yKbpeBVNWSqcPkdhpAUaKAGUyuZwBB9bgEh TLoEU2w5tiWIya6ypeKmtRW4Ct9Nf5i2JG2MJj9i5d9SULqjZS+SXbf5g7ZwMhHP3PFh /zKZzT8foGKPsfMquagMtrbfH//ZXv9ITSzRC1NLw5W09ruuSovHjyEsi4o6UhhGaQgA P2KISdxaVJfjzslSwbkDczeaj5St4HTUq5dKZt/cXGvvAFLrH1/xBO/5YM5t0pdSQceC aN8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n17si9673446edo.143.2019.10.08.10.12.14; Tue, 08 Oct 2019 10:12:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727220AbfJHRIc (ORCPT + 99 others); Tue, 8 Oct 2019 13:08:32 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:43520 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726253AbfJHRIc (ORCPT ); Tue, 8 Oct 2019 13:08:32 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.2) (envelope-from ) id 1iHsyN-00054j-1u; Tue, 08 Oct 2019 19:08:31 +0200 Message-ID: Subject: Re: [PATCH 2/2] mac80211: Support LIVE_ADDRESS_CHANGE feature From: Johannes Berg To: Denis Kenzior , James Prestwood , linux-wireless@vger.kernel.org Date: Tue, 08 Oct 2019 19:08:28 +0200 In-Reply-To: <1bb5450b-bc4e-8c83-f99e-fc7e739b08f0@gmail.com> (sfid-20191008_183311_878473_B38C04A4) References: <20190913195908.7871-1-prestwoj@gmail.com> <20190913195908.7871-2-prestwoj@gmail.com> <90ae00044bc0834d87d3f9fb75ce63dce4cfadd5.camel@gmail.com> <0b57c1288016310050ccd6233dda886fc4a89b02.camel@gmail.com> <6fa34e4c-5c81-4875-da29-cada1a078e2c@gmail.com> <6530a6b06176790c5a6949d6ffccf37b506975bd.camel@sipsolutions.net> <864267ec-9158-940d-6e0e-db84a395888e@gmail.com> <1bb5450b-bc4e-8c83-f99e-fc7e739b08f0@gmail.com> (sfid-20191008_183311_878473_B38C04A4) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org > > > > No, this typically cannot be fixed, and it doesn't really make sense. > > > > The NIC cannot possibly do two scans at a time since it has only a > > > > single radio resource :-) > > > > > > So why is the scan request not per phy then? And should mac address > > > even affect the ongoing scan? Can we simply change it with the scan > > > ongoing? > > > > There are things that affect the scan from the interface, e.g. > > capability overrides, (extended) capabilities, the MAC address is used > > unless randomization is requested, etc. > > > > But they shouldn't change due a mac address change? I wonder if we can > further relax the requirements to allow mac change if > NL80211_SCAN_FLAG_RANDOM_ADDR was used? No, at least with HW scan that would completely confuse the driver - since from the driver's POV we'd remove the interface it's currently managing the scan for. johannes