On Tue, Mar 31, 2009 at 12:48 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Mon, 2009-03-30 at 23:57 -0400, Luis R. Rodriguez wrote:
>> * @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.
Eh, that's what I get for just rebasing and not looking at the order,
sorry yeah, not the intention.
>> --- 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.
I know the feeling, more on this below.
> Do we really need that before/after thing anyway? I think if we really
> need this then we should add new attributes.
Well we can definitely add new attributes, but remember we still have
to pass the center of freq. The cleanest solution is to define an
attribute with a center-freq, if-passive-lifted, if-beaconing-enabled
flags. But that ends up adding all that for something we already have
attributes for. I chose to use what we have.
Let me know what you think.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
