linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Sarada Prasanna Garnayak <sarada.prasanna.garnayak@intel.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v1] cfg80211/nl80211: add support for AID assignment by driver
Date: Thu, 13 Dec 2018 11:23:39 +0100	[thread overview]
Message-ID: <703d7c377a5a1ea5b0b4ee77bbfd01d8f2dfd8d2.camel@sipsolutions.net> (raw)
In-Reply-To: <20181212180928.42117-1-sarada.prasanna.garnayak@intel.com>

Hi,

On Wed, 2018-12-12 at 23:39 +0530, Sarada Prasanna Garnayak wrote:
> Add support for getting and free association ID if the station
> association ID management handled by the WLAN driver/firmware.
> 
> Add cfg80211 driver ops and nl80211 API and CMD to request
> the WLAN driver to assign an AID for a station during association
> and release the AID of the station from the WLAN driver/firmware
> station database on disassociation from the AP.

I think this should state why it's needed - i.e. why the implied "use
lowest possible AID" assignment scheme isn't sufficient for some/your
driver(s). That scheme has advantages in the TIM Element for example, so
deviating from it might cause other issues.

> + * @get_sta_aid: Get an AID for the station from the driver if AID assignment
> + *	is managed by the WLAN driver/hardware/firmware.

This seems reasonable, but let me think about it more below.

> + * @free_sta_aid: Release the AID of the station from the station database
> + *	on disassociation from the AP if AID assignment is managed by
> + *	the WLAN driver/hardware/firmware.

I'm not convinced this makes sense. The station entry will be freed by
hostapd anyway, and in that case the AID is freed implicitly. I see no
reason to split these operations.

In fact, I'm not sure we need an allocation operation either, since we
should be able to assign one when the station entry is added.

> +	int (*get_sta_aid)(struct wiphy *wiphy, struct net_device *dev,
> +			   u16 *sta_aid, const u8 *mac_addr);

If we do this, we should probably *return* the AID, that doesn't overlap
with error return values since AIDs are positive and error codes
negative.

> + * @NL80211_CMD_GET_STA_AID: Request association ID for a station if the station
> + *	association ID management handled by the driver/firmware/hardware
> + *	specified by %NL80211_ATTR_MAC and %NL80211_ATTR_STA_AID.
> + *
> + * @NL80211_CMD_FREE_STA_AID: Free association ID of a station if the station
> + *	association ID management handled by the driver/firmware/hardware
> + *	with specified by %NL80211_ATTR_STA_AID.

Same comments as above of course apply to the nl80211 API.

However, in any case, I don't really see why we need this at all.

Normally, the flow (nowadays) is to add a station when it authenticates,
and so at that point the AID could be assigned by the driver in the
station entry. We need to think about the capabilities for this, and how
to force hostapd to actually do this flow (or have the driver accept
AIDs from hostapd if it's an old version?)

johannes


  parent reply	other threads:[~2018-12-13 10:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 18:09 [RFC PATCH v1] cfg80211/nl80211: add support for AID assignment by driver Sarada Prasanna Garnayak
2018-12-13  9:25 ` Kalle Valo
2018-12-13 10:23 ` Johannes Berg [this message]
2018-12-12 18:12 Sarada Prasanna Garnayak
2018-12-19 13:19 ` Sergey Matyukevich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=703d7c377a5a1ea5b0b4ee77bbfd01d8f2dfd8d2.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sarada.prasanna.garnayak@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).