Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3016518ybt; Mon, 29 Jun 2020 13:00:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiZuepIF+irP9FO0m/4XkleyOzWRj7GbkuGNnCtnHCCIwPV4/5B++LK7CcjRRP/04uY+zD X-Received: by 2002:a17:906:f298:: with SMTP id gu24mr15188064ejb.302.1593460859821; Mon, 29 Jun 2020 13:00:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593460859; cv=none; d=google.com; s=arc-20160816; b=I5SsTQ84UoEnEfJT64gSDgNL8IGk/cqsDF6VZwPpYDCEy4qPO2gdHRj52e2NSSrvfn 62un0jEKrAja6+chCNg5FpK8xENLVZzWblFxfkK3yT834N5jiUMRsPPGML1Tf4Kid7Pd xTRPA6QaC4WMD9kWBb9Ke5yK7F5cIx1Ui2ZYFwCS4Fh8xF4ALhJBaUBHIrpJX5o4Ed4k TVKYt0pFEEc2bXx4wSwafgj6qer6obSmjErm0AwFJaGrlTOWumsK5eR0aOL7ElG97Ohl kZ+gNQjw2PT2fD8390LYXEZMNXBJFfr5LxVgui8hRJ+OhcejQ0K7v9l83mch4Wvw9vba aXpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=JhvCWCcdEWr/9KOIo5ec2zHvJqAS90k6nslKyeSa2cg=; b=TYXMMVu6E93INLMX1OsboGqy9rsf5gLWYFb3/V37q8l3v9nNXZZeO6FkZQCfrbEp0R 0X+4svs47dCVIpPM0BhtDdV0g+KmQQbA5+o+geZUfiKs5KY/9CbecZyB0sGgAdgeA6cN PlUS66LdjIlfqmk5C7FPJAXMAaXlyIQrubj7QESknQjmd/vcDZUF3bJ9dea0Pjko6COF IfgHR4RDg4lwWhrybslzBjRs4czT8qx9ar8ApGUMoszxzVqseIgFmcgaY+T+rZHKv7dN W3kzPDbbYN1lGqw/D/lyxbTLuZb0GPx7dz4T6KxGHtyZq1ddZPcjwtnYzvXEqyObh1Xn hLvA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k8si347384ejc.257.2020.06.29.13.00.34; Mon, 29 Jun 2020 13:00:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388177AbgF2UAT (ORCPT + 99 others); Mon, 29 Jun 2020 16:00:19 -0400 Received: from smail.rz.tu-ilmenau.de ([141.24.186.67]:51012 "EHLO smail.rz.tu-ilmenau.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388573AbgF2UAI (ORCPT ); Mon, 29 Jun 2020 16:00:08 -0400 Received: from [192.168.178.24] (unknown [91.53.47.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id AAFFB580076; Mon, 29 Jun 2020 22:00:06 +0200 (CEST) Subject: Re: RFC: Remote Off-Channel CAC for DFS To: Johannes Berg , linux-wireless@vger.kernel.org References: <99ae192566a7c5ae91c6ee92b8c4ddb41a29e34e.camel@sipsolutions.net> From: Markus Theil Message-ID: <9f36bb56-8aa6-e759-5024-cfe5e58e41cf@tu-ilmenau.de> Date: Mon, 29 Jun 2020 22:00:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <99ae192566a7c5ae91c6ee92b8c4ddb41a29e34e.camel@sipsolutions.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 6/29/20 9:35 PM, Johannes Berg wrote: > Hi, > > On Mon, 2020-06-29 at 19:40 +0200, Markus Theil wrote: >> When using DFS channels, it would be nice, if I could dedicate a small >> amount of interfaces only to CAC checking channels and set them >> available or unavailable on multiple other remote APs/Mesh Points in >> order to use them, when switching to lower utilized channels without >> going through a full CAC. >> >> Whats the opinion on the mailing list about adding a new command to >> nl80211 in order to set the DFS state of a currently not used channel >> after a Off-Channel CAC on another device nearby, but not on the same >> host? The parameters would roughly be the same as for a channel switch >> and an additional DFS channel state. Internally, I would trigger the DFS >> state sync code between multiple interfaces. > But wait, don't we already sync this within the kernel? Yes, the kernel already syncs this between interfaces on the same host. I'd just like to sync between multiple hosts, in order to make use of fast switches to other DFS channels in a mesh network (in my case), if some other node nearby already had performed a DFS CAC of a particular channel and sync this state between hosts. > johannes >