cfg80211: add a callback for querying the operating frequency and export it through nl80211

PATCH In review Felix Fietkau 4 participants 14 messages Jan 17, 2010 – Jan 20, 2010

Subsystems (2)

mac80211 802.11 (including cfg80211/NL80211)

lore

Share & tools

lore

Felix Fietkau

author

2010-01-17 19:55 UTC #0 lore raw

PATCH 1/2 cfg80211: add a callback for querying the operating frequency and export it through nl80211

Signed-off-by Felix Fietkau <[email protected]>

---

include/net/cfg80211.h +6 -0

@@ -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);

net/wireless/nl80211.c +8 -1

@@ -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;

Felix Fietkau

author

2010-01-17 19:55 UTC #1 lore raw

PATCH 2/2 mac80211: implement the callback for querying the operating frequency

Signed-off-by Felix Fietkau <[email protected]>

---

net/mac80211/cfg.c +13 -0

@@ -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,

Johannes Berg

maintainer

2010-01-17 19:57 UTC #2 lore raw

In reply to Felix Fietkau

include/net/cfg80211.h struct cfg80211_ops { · line 1086

Quoted 3 lines · Felix Fietkau

include/net/cfg80211.h +3 -0

+	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

Johannes Berg

maintainer

2010-01-17 20:00 UTC #3 lore raw

Quoted 8 lines · Johannes Berg

include/net/cfg80211.h struct cfg80211_ops { · line 1086
Quoted 3 lines · Felix Fietkau
include/net/cfg80211.h +3 -0
+	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

Felix Fietkau

author

2010-01-17 20:12 UTC #4 lore raw

Quoted 10 lines · Johannes Berg

Quoted 8 lines · Johannes Berg
include/net/cfg80211.h struct cfg80211_ops { · line 1086
Quoted 3 lines · Felix Fietkau
include/net/cfg80211.h +3 -0
+	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.

Quoted 5 lines

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

Johannes Berg

maintainer

2010-01-17 20:14 UTC #5 lore raw

Quoted 6 lines · Felix Fietkau

Quoted 1 line
If you have an IBSS or managed mode then you know from the BSS info
what
Quoted 2 lines
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

Felix Fietkau

author

2010-01-17 20:23 UTC #6 lore raw

Quoted 4 lines · Johannes Berg

Quoted 2 lines · Felix Fietkau
Quoted 1 line
If you have an IBSS or managed mode then you know from the BSS info
what

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
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

Johannes Berg

maintainer

2010-01-17 20:48 UTC #7 lore raw

Quoted 4 lines · Felix Fietkau

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

Felix Fietkau

author

2010-01-17 21:01 UTC #8 lore raw

Quoted 9 lines · Johannes Berg

Quoted 4 lines · Felix Fietkau
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.

Quoted 3 lines

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

Felix Fietkau

author

2010-01-17 21:03 UTC #9 lore raw

Quoted 8 lines · Felix Fietkau

Quoted 7 lines · Johannes Berg
Quoted 4 lines · Felix Fietkau
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.

Quoted 6 lines

Quoted 2 lines
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

Johannes Berg

maintainer

2010-01-17 21:05 UTC #10 lore raw

In reply to Felix Fietkau

Quoted 10 lines · Felix Fietkau

Quoted 2 lines
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

Quoted 6 lines

Quoted 1 line
The problem with this is that not all drivers will be able to
support
Quoted 2 lines
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

Luis R. Rodriguez

2010-01-19 17:39 UTC #11 lore raw

Quoted 25 lines · Johannes Berg

Quoted 10 lines · Felix Fietkau
Quoted 2 lines
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
Quoted 6 lines
Quoted 1 line
The problem with this is that not all drivers will be able to
support
Quoted 2 lines
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.

Quoted 6 lines

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

Holger Schurig

2010-01-20 07:32 UTC #12 lore raw

In reply to Johannes Berg

Quoted 3 lines

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.

Signature · 1 line

http://www.holgerschurig.de

Johannes Berg

maintainer

2010-01-20 09:49 UTC #13 lore raw

Quoted 11 lines · Holger Schurig

Quoted 3 lines
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.

Quoted 4 lines

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