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;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Thu, 30 Jul 2020 14:17:46 -0700
From:   Aloka Dixit <alokad@codeaurora.org>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org,
        linux-wireless-owner@vger.kernel.org
Subject: Re: [PATCH v4 1/2] nl80211: Add FILS discovery support
In-Reply-To: <c3dbcc3e4ee2d3596625e8c1226325180444a961.camel@sipsolutions.net>
References: <20200618050427.5891-1-alokad@codeaurora.org>
 <20200618050427.5891-2-alokad@codeaurora.org>
 <c3dbcc3e4ee2d3596625e8c1226325180444a961.camel@sipsolutions.net>
Message-ID: <2b1ea1c4baedcb119f4e632b26399071@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 2020-07-30 07:43, Johannes Berg wrote:
> On Wed, 2020-06-17 at 22:04 -0700, Aloka Dixit wrote:
>> + * @NL80211_FILS_DISCOVERY_TMPL: Optional FILS discovery template.
>> + *	It has contents of IEEE Std 802.11ai-2016 9.6.8.36 FILS discovery 
>> frame
>> + *	(Figure 9-687a).
> 
> Is that
> 
> "It has (contents of ... FILS discovery frame) ..."
> 
> or
> 
> "It has contents of (... FILS discovery frame) ..."?
> 
> I mean, is that with or without headers? The wording doesn't seem
> entirely clear to me.
> 
> OTOH, if it's with headers, how could it be optional? In fact, either
> way, how is it optional?
> 

Template has management frame headers as well. Will change the wording 
accordingly.
I made the template optional because FILS discovery may or may not be 
offloaded to FW.
Another way would be to make it mandatory here.

>> +static int nl80211_parse_fils_discovery(struct nlattr *attrs,
>> +					struct cfg80211_ap_settings *params)
>> +{
>> +	struct nlattr *tmpl;
>> +	struct nlattr *tb[NL80211_FILS_DISCOVERY_MAX + 1];
>> +	int ret;
>> +	struct cfg80211_fils_discovery *fd = &params->fils_discovery;
>> +
>> +	ret = nla_parse_nested(tb, NL80211_FILS_DISCOVERY_MAX, attrs,
>> +			       fils_discovery_policy, NULL);
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (!tb[NL80211_FILS_DISCOVERY_INT_MIN] ||
>> +	    !tb[NL80211_FILS_DISCOVERY_INT_MAX])
>> +		return -EINVAL;
>> +
>> +	fd->min_interval = nla_get_u32(tb[NL80211_FILS_DISCOVERY_INT_MIN]);
>> +	fd->max_interval = nla_get_u32(tb[NL80211_FILS_DISCOVERY_INT_MAX]);
>> +
>> +	tmpl = tb[NL80211_FILS_DISCOVERY_TMPL];
>> +	if (tmpl) {
>> +		fd->tmpl = nla_data(tmpl);
>> +		fd->tmpl_len = nla_len(tmpl);
> 
> And if it's with headers, it should have some kind of minimum length
> too? You've only put a maximum length into the policy.
> 
> (Which reminds me I wanted to have an NLA_POLICY_RANGE(NLA_BINARY, min,
> max) but haven't done that yet ...)
> 

Yeah, I looked through existing examples for NLA_BINARY, those provide 
only the higher bound for length.
But I can modify it to range once that is added.

> johannes