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:
signature.asc
Description: This is a digitally signed message part
