Signed-off-by: Felix Fietkau <[email protected]>
---
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -954,6 +954,8 @@ struct cfg80211_pmksa {
*
* @set_txq_params: Set TX queue parameters
*
+ * @get_channel: Get operating channel
+ *
* @set_channel: Set channel
*
* @scan: Request to do a scan. If returning zero, the scan request is given
@@ -1079,6 +1081,10 @@ struct cfg80211_ops {
int (*set_txq_params)(struct wiphy *wiphy,
struct ieee80211_txq_params *params);
+ int (*get_channel)(struct wiphy *wiphy,
+ struct ieee80211_channel **chan,
+ enum nl80211_channel_type *channel_type);
+
int (*set_channel)(struct wiphy *wiphy,
struct ieee80211_channel *chan,
enum nl80211_channel_type channel_type);
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -427,7 +427,8 @@ static int nl80211_send_wiphy(struct sk_
struct nlattr *nl_modes;
struct nlattr *nl_cmds;
enum ieee80211_band band;
- struct ieee80211_channel *chan;
+ struct ieee80211_channel *chan = NULL;
+ enum nl80211_channel_type chan_type;
struct ieee80211_rate *rate;
int i;
u16 ifmodes = dev->wiphy.interface_modes;
@@ -465,6 +466,12 @@ static int nl80211_send_wiphy(struct sk_
NLA_PUT_U8(msg, NL80211_ATTR_MAX_NUM_PMKIDS,
dev->wiphy.max_num_pmkids);
+ if (dev->ops->get_channel &&
+ dev->ops->get_channel(&dev->wiphy, &chan, &chan_type) == 0) {
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_FREQ, chan->center_freq);
+ NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_CHANNEL_TYPE, chan_type);
+ }
+
nl_modes = nla_nest_start(msg, NL80211_ATTR_SUPPORTED_IFTYPES);
if (!nl_modes)
goto nla_put_failure;
On Sun, 2010-01-17 at 20:54 +0100, Felix Fietkau wrote:
> + int (*get_channel)(struct wiphy *wiphy,
> + struct ieee80211_channel **chan,
> + enum nl80211_channel_type *channel_type);
Can you do that per netdev, please? We'll eventually get into having to
support different channels on different netdevs.
johannes
On Sun, 2010-01-17 at 20:57 +0100, Johannes Berg wrote:
> On Sun, 2010-01-17 at 20:54 +0100, Felix Fietkau wrote:
>
> > + int (*get_channel)(struct wiphy *wiphy,
> > + struct ieee80211_channel **chan,
> > + enum nl80211_channel_type *channel_type);
>
> Can you do that per netdev, please? We'll eventually get into having
> to support different channels on different netdevs.
OTOH, where is this really needed?
If you have an IBSS or managed mode then you know from the BSS info what
channel you should be on... APs are completely userspace controlled
anyway, so are monitors.
johannes
On 2010-01-17 9:14 PM, Johannes Berg wrote:
> On Sun, 2010-01-17 at 21:12 +0100, Felix Fietkau wrote:
>
>> > If you have an IBSS or managed mode then you know from the BSS info
>> what
>> > channel you should be on... APs are completely userspace controlled
>> > anyway, so are monitors.
>> I was thinking about scanning, but then again, that's not handled by
>> my patch series either. I'll simplify it and make it per-netdev.
>
> But scanning isn't really interesting, it might be firmware controlled
> or whatever. What do you need the whole thing for? Why export the
> channel at all?
I want to be able to have some status info without having to go through
hostapd or wpa_supplicant to get it. Currently the channel is exported
by wext, but not nl80211, so I want to fix that.
- Felix
On Sun, Jan 17, 2010 at 1:05 PM, Johannes Berg
<[email protected]> wrote:
> On Sun, 2010-01-17 at 22:01 +0100, Felix Fietkau wrote:
>
>> > But like I said, you already have that information in the relevant
>> > cases. hostapd you can just look in the config file for it...
>
>> Nope, hostapd can deviate from the config, e.g. in the HT40 case.
>> It'll
>> switch primary and secondary channel, if necessary, or switch from
>> HT40
>> to HT20 entirely if there are overlapping BSSs. And what about STA
>> mode?
>> The channel won't be in the config in that case.
>
> In STA and IBSS modes you already have the information from the BSS
> info.
>
> The channel type might be more interesting, but even then
>
>> > The problem with this is that not all drivers will be able to
>> support
>> > it, and that you will be exporting stale information say in the case
>> > where we're not connected at all.
>> If we document the exported channel for the netdev as 'last configured
>> channel', it should be fine, IMHO.
>
> I really don't think we should do that. And it will not be possible to
> ever have iwm/rndis/orinoco etc. export such information.
>
> In any case I have a feeling you're trying to use the kernel as a
> database for something you already know, just don't have quite as
> readily available as you'd like.
So a good use case is when we do automatic channel selection for AP
mode of operation. We currently don't support that on hostapd but
eventually we could and IMHO should. How we go about it remains to be
seen but querying the actual channel used by an 802.11 device is
useful in those cases. You can get that information by looking at
hostapd logs but that seems overkill.
Luis
> In any case I have a feeling you're trying to use the kernel as
> a database for something you already know, just don't have
> quite as readily available as you'd like.
I have a device where the current channel is shown to user-space,
e.g. the operator. We used that to find out on what channel the
current AP is. Or, when the channel is constantly changing, that
the system is still searching for a matching access-point.
I know that for both things there are other ways to query the
same information, but it's convenient nethertheless.
But one thing for which is no other way is to see the actual
channel-changes due to the search for a new AP. If such a thing
would be important (it isn't for me), maybe a nl80211 broadcast
would be better than, thought.
--
http://www.holgerschurig.de
Signed-off-by: Felix Fietkau <[email protected]>
---
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1154,6 +1154,18 @@ static int ieee80211_set_txq_params(stru
return 0;
}
+static int ieee80211_get_oper_channel(struct wiphy *wiphy,
+ struct ieee80211_channel **chan,
+ enum nl80211_channel_type *channel_type)
+{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+
+ *chan = local->oper_channel;
+ *channel_type = local->oper_channel_type;
+
+ return 0;
+}
+
static int ieee80211_set_channel(struct wiphy *wiphy,
struct ieee80211_channel *chan,
enum nl80211_channel_type channel_type)
@@ -1494,6 +1506,7 @@ struct cfg80211_ops mac80211_config_ops
#endif
.change_bss = ieee80211_change_bss,
.set_txq_params = ieee80211_set_txq_params,
+ .get_channel = ieee80211_get_oper_channel,
.set_channel = ieee80211_set_channel,
.suspend = ieee80211_suspend,
.resume = ieee80211_resume,
On Sun, 2010-01-17 at 21:23 +0100, Felix Fietkau wrote:
> I want to be able to have some status info without having to go
> through
> hostapd or wpa_supplicant to get it. Currently the channel is exported
> by wext, but not nl80211, so I want to fix that.
But like I said, you already have that information in the relevant
cases. hostapd you can just look in the config file for it...
The problem with this is that not all drivers will be able to support
it, and that you will be exporting stale information say in the case
where we're not connected at all.
johannes
On Sun, 2010-01-17 at 22:01 +0100, Felix Fietkau wrote:
> > But like I said, you already have that information in the relevant
> > cases. hostapd you can just look in the config file for it...
> Nope, hostapd can deviate from the config, e.g. in the HT40 case.
> It'll
> switch primary and secondary channel, if necessary, or switch from
> HT40
> to HT20 entirely if there are overlapping BSSs. And what about STA
> mode?
> The channel won't be in the config in that case.
In STA and IBSS modes you already have the information from the BSS
info.
The channel type might be more interesting, but even then
> > The problem with this is that not all drivers will be able to
> support
> > it, and that you will be exporting stale information say in the case
> > where we're not connected at all.
> If we document the exported channel for the netdev as 'last configured
> channel', it should be fine, IMHO.
I really don't think we should do that. And it will not be possible to
ever have iwm/rndis/orinoco etc. export such information.
In any case I have a feeling you're trying to use the kernel as a
database for something you already know, just don't have quite as
readily available as you'd like.
johannes
On 2010-01-17 9:48 PM, Johannes Berg wrote:
> On Sun, 2010-01-17 at 21:23 +0100, Felix Fietkau wrote:
>
>> I want to be able to have some status info without having to go
>> through
>> hostapd or wpa_supplicant to get it. Currently the channel is exported
>> by wext, but not nl80211, so I want to fix that.
>
> But like I said, you already have that information in the relevant
> cases. hostapd you can just look in the config file for it...
Nope, hostapd can deviate from the config, e.g. in the HT40 case. It'll
switch primary and secondary channel, if necessary, or switch from HT40
to HT20 entirely if there are overlapping BSSs. And what about STA mode?
The channel won't be in the config in that case.
> The problem with this is that not all drivers will be able to support
> it, and that you will be exporting stale information say in the case
> where we're not connected at all.
If we document the exported channel for the netdev as 'last configured
channel', it should be fine, IMHO.
- Felix
On 2010-01-17 9:00 PM, Johannes Berg wrote:
> On Sun, 2010-01-17 at 20:57 +0100, Johannes Berg wrote:
>> On Sun, 2010-01-17 at 20:54 +0100, Felix Fietkau wrote:
>>
>> > + int (*get_channel)(struct wiphy *wiphy,
>> > + struct ieee80211_channel **chan,
>> > + enum nl80211_channel_type *channel_type);
>>
>> Can you do that per netdev, please? We'll eventually get into having
>> to support different channels on different netdevs.
>
> OTOH, where is this really needed?
>
> If you have an IBSS or managed mode then you know from the BSS info what
> channel you should be on... APs are completely userspace controlled
> anyway, so are monitors.
I was thinking about scanning, but then again, that's not handled by my
patch series either. I'll simplify it and make it per-netdev.
- Felix
On Wed, 2010-01-20 at 08:32 +0100, Holger Schurig wrote:
> > In any case I have a feeling you're trying to use the kernel as
> > a database for something you already know, just don't have
> > quite as readily available as you'd like.
>
> I have a device where the current channel is shown to user-space,
> e.g. the operator. We used that to find out on what channel the
> current AP is. Or, when the channel is constantly changing, that
> the system is still searching for a matching access-point.
>
> I know that for both things there are other ways to query the
> same information, but it's convenient nethertheless.
I realise that. But all this is complicated with the planned move to
allow different virtual interfaces to use different channels with
time-multiplexing.
> But one thing for which is no other way is to see the actual
> channel-changes due to the search for a new AP. If such a thing
> would be important (it isn't for me), maybe a nl80211 broadcast
> would be better than, thought.
That's actually impossible with a lot of hardware, so I really don't see
the point.
johannes
On 2010-01-17 10:01 PM, Felix Fietkau wrote:
> On 2010-01-17 9:48 PM, Johannes Berg wrote:
>> On Sun, 2010-01-17 at 21:23 +0100, Felix Fietkau wrote:
>>
>>> I want to be able to have some status info without having to go
>>> through
>>> hostapd or wpa_supplicant to get it. Currently the channel is exported
>>> by wext, but not nl80211, so I want to fix that.
>>
>> But like I said, you already have that information in the relevant
>> cases. hostapd you can just look in the config file for it...
> Nope, hostapd can deviate from the config, e.g. in the HT40 case. It'll
> switch primary and secondary channel, if necessary, or switch from HT40
> to HT20 entirely if there are overlapping BSSs. And what about STA mode?
> The channel won't be in the config in that case.
Sorry, overlooked the part about STA mode in the last email, but for AP
mode it's still valid, IMHO.
- Felix
On Sun, 2010-01-17 at 21:12 +0100, Felix Fietkau wrote:
> > If you have an IBSS or managed mode then you know from the BSS info
> what
> > channel you should be on... APs are completely userspace controlled
> > anyway, so are monitors.
> I was thinking about scanning, but then again, that's not handled by
> my patch series either. I'll simplify it and make it per-netdev.
But scanning isn't really interesting, it might be firmware controlled
or whatever. What do you need the whole thing for? Why export the
channel at all?
johannes