Re: [PATCH] cfg80211: send regulatory beacon hint events to userspace

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 4297 bytes --]

On Mon, 2009-03-30 at 23:57 -0400, Luis R. Rodriguez wrote:

> + * @NL80211_CMD_REG_BEACON_HINT: indicates to userspace that an AP beacon
> + * 	has been found while world roaming thus enabling active scan or
> + * 	any mode of operation that initiates TX (beacons) on a channel
> + * 	where we would not have been able to do either before. As an example
> + * 	if you are world roaming (regulatory domain set to world or if your
> + * 	driver is using a custom world roaming regulatory domain) and while
> + * 	doing a passive scan on the 5 GHz band you find an AP there (if not
> + * 	on a DFS channel) you will now be able to actively scan for that AP
> + * 	or use AP mode on your card on that same channel. Note that this will
> + * 	never be used for channels 1-11 on the 2 GHz band as they are always
> + * 	enabled world wide. This beacon hint is only sent if your device had
> + * 	either disabled active scanning or beaconing on a channel. We send to
> + * 	userspace the wiphy on which we removed a restriction from
> + * 	(%NL80211_ATTR_WIPHY) and the channel on which this occured

occurred

> + * 	(%NL80211_ATTR_WIPHY_FREQ) before and after the beacon hint was applied.
> + * 	We send the two channels on a frequency nestered attribute

nested

>   * @NL80211_CMD_AUTHENTICATE: authentication request and notification.
>   *	This command is used both as a command (request to authenticate) and
> @@ -254,6 +273,7 @@ enum nl80211_commands {
>  	NL80211_CMD_SCAN_ABORTED,
>  
>  	NL80211_CMD_REG_CHANGE,
> +	NL80211_CMD_REG_BEACON_HINT,
>  
>  	NL80211_CMD_AUTHENTICATE,
>  	NL80211_CMD_ASSOCIATE,

No go for adding in the middle.

> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -3391,6 +3391,93 @@ void nl80211_send_rx_disassoc(struct cfg80211_registered_device *rdev,
>  				NL80211_CMD_DISASSOCIATE);
>  }
>  
> +void nl80211_send_beacon_hint_event(struct wiphy *wiphy,
> +				    struct ieee80211_channel *channel_before,
> +				    struct ieee80211_channel *channel_after)
> +{
> +	struct sk_buff *msg;
> +	void *hdr;
> +	enum ieee80211_band band;
> +	struct nlattr *nl_bands, *nl_band, *nl_freqs, *nl_freq;
> +	struct ieee80211_channel *chan;
> +	unsigned int i;
> +
> +	msg = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
> +	if (!msg)
> +		return;
> +
> +	hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_REG_BEACON_HINT);
> +	if (!hdr) {
> +		nlmsg_free(msg);
> +		return;
> +	}
> +
> +	/*
> +	 * Since we are applying the beacon hint to a wiphy we know its
> +	 * wiphy_idx is valid
> +	 */
> +	NLA_PUT_U32(msg, NL80211_ATTR_WIPHY, get_wiphy_idx(wiphy));
> +
> +	band = channel_after->band;
> +	if (WARN_ON(!wiphy->bands[band]))
> +		goto nla_put_failure;
> +
> +	/* Unforunately this is needed */
> +	nl_bands = nla_nest_start(msg, NL80211_ATTR_WIPHY_BANDS);
> +	if (!nl_bands)
> +		goto nla_put_failure;
> +	nl_band = nla_nest_start(msg, band);
> +	if (!nl_band)
> +		goto nla_put_failure;
> +
> +	/*
> +	 * Our hack is to piggy back the channel prior to beacon hint
> +	 * and after the beacon hint so userspace can analyze the
> +	 * differences. Right now only no-ibss and passive-scan flags
> +	 * can change as that's the only thing we expect to learn out
> +	 * of a beacon for now. By re-using these attributes we can
> +	 * avoid introducing new structs.
> +	 */
> +	nl_freqs = nla_nest_start(msg, NL80211_BAND_ATTR_FREQS);
> +	if (!nl_freqs)
> +		goto nla_put_failure;
> +
> +	for (i = 0; i <= 1; i++) {
> +		nl_freq = nla_nest_start(msg, i);
> +		if (!nl_freq)
> +			goto nla_put_failure;
> +
> +		chan = (i == 0) ? channel_before : channel_after;
> +
> +		NLA_PUT_U32(msg, NL80211_FREQUENCY_ATTR_FREQ,
> +			    chan->center_freq);
> +
> +		if (chan->flags & IEEE80211_CHAN_PASSIVE_SCAN)
> +			NLA_PUT_FLAG(msg, NL80211_FREQUENCY_ATTR_PASSIVE_SCAN);
> +		if (chan->flags & IEEE80211_CHAN_NO_IBSS)
> +			NLA_PUT_FLAG(msg, NL80211_FREQUENCY_ATTR_NO_IBSS);
> +
> +		nla_nest_end(msg, nl_freq);
> +	}

I don't think I like this -- it's confusing to userspace code that wants
to use a unified message parser.

Do we really need that before/after thing anyway? I think if we really
need this then we should add new attributes.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]