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;
Subject: Re: [RFC 6/7] nl80211: add KHz frequency offset for most wifi
 commands
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless <linux-wireless@vger.kernel.org>
References: <20200401062150.3324-1-thomas@adapt-ip.com>
 <20200401062150.3324-7-thomas@adapt-ip.com>
 <a2fe2cad3c93ae8516568b6a8f5395dae6d9ba30.camel@sipsolutions.net>
From:   Thomas Pedersen <thomas@adapt-ip.com>
Message-ID: <f7140580-d6fa-95f2-abeb-6b5523725383@adapt-ip.com>
Date:   Wed, 1 Apr 2020 11:15:20 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <a2fe2cad3c93ae8516568b6a8f5395dae6d9ba30.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 4/1/20 12:10 AM, Johannes Berg wrote:
> On Tue, 2020-03-31 at 23:21 -0700, Thomas Pedersen wrote:
>>
>> TODO: several of these commands will eventually just
>> ignore the _OFFSET component, like _JOIN_MESH,
>> _CMD_RADAR_DETECT, etc. Should return an error to give
>> user a hint things won't work as expected?
> 
> Wouldn't most of them already require that a channel with the given
> frequency exists, and thus fail anyway?

Well I was thinking of the case where you have:

ch 2: 903MHz
ch 3: 903.5Mhz

userspace tries to eg. join a mesh on channel 3 by sending 903MHz +
500KHz, the (old) kernel interprets this as channel 2 and happily joins
on the wrong channel. However this only applies on a new band which
doesn't even exist yet, and if we return an error for commands which
have not yet been tested with frequency offset nothing unexpected will
happen.

-- 
thomas