cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
/*
|
|
|
|
|
* mac80211 - channel management
|
|
|
|
|
*/
|
|
|
|
|
|
2010-05-05 21:28:27 +08:00
|
|
|
#include <linux/nl80211.h>
|
mac80211: Don't let regulatory make us deaf
When regulatory information changes our HT behavior (e.g,
when we get a country code from the AP we have just associated
with), we should use this information to change the power with
which we transmit, and what channels we transmit. Sometimes
the channel parameters we derive from regulatory information
contradicts the parameters we used in association. For example,
we could have associated specifying HT40, but the regulatory
rules we apply may forbid HT40 operation.
In the situation above, we should reconfigure ourselves to
transmit in HT20 only, however it makes no sense for us to
disable receive in HT40, since if we associated with these
parameters, the AP has every reason to expect we can and
will receive packets this way. The code in mac80211 does
not have the capability of sending the appropriate action
frames to signal a change in HT behaviour so the AP has
no clue we can no longer receive frames encoded this way.
In some broken AP implementations, this can leave us
effectively deaf if the AP never retries in lower HT rates.
This change breaks up the channel_type parameter in the
ieee80211_enable_ht function into a separate receive and
transmit part. It honors the channel flags set by regulatory
in order to configure the rate control algorithm, but uses
the capability flags to configure the channel on the radio,
since these were used in association to set the AP's transmit
rate.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Luis R Rodriguez <mcgrof@frijolero.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-13 22:46:18 +08:00
|
|
|
#include <net/cfg80211.h>
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
#include "ieee80211_i.h"
|
|
|
|
|
|
2010-05-28 20:26:23 +08:00
|
|
|
static enum ieee80211_chan_mode
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
__ieee80211_get_channel_mode(struct ieee80211_local *local,
|
|
|
|
|
struct ieee80211_sub_if_data *ignore)
|
|
|
|
|
{
|
|
|
|
|
struct ieee80211_sub_if_data *sdata;
|
|
|
|
|
|
2010-09-15 19:28:15 +08:00
|
|
|
lockdep_assert_held(&local->iflist_mtx);
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
|
|
|
|
|
list_for_each_entry(sdata, &local->interfaces, list) {
|
|
|
|
|
if (sdata == ignore)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!ieee80211_sdata_running(sdata))
|
|
|
|
|
continue;
|
|
|
|
|
|
2012-01-09 20:57:36 +08:00
|
|
|
switch (sdata->vif.type) {
|
|
|
|
|
case NL80211_IFTYPE_MONITOR:
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
continue;
|
2012-01-09 20:57:36 +08:00
|
|
|
case NL80211_IFTYPE_STATION:
|
|
|
|
|
if (!sdata->u.mgd.associated)
|
|
|
|
|
continue;
|
|
|
|
|
break;
|
|
|
|
|
case NL80211_IFTYPE_ADHOC:
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
if (!sdata->u.ibss.ssid_len)
|
|
|
|
|
continue;
|
|
|
|
|
if (!sdata->u.ibss.fixed_channel)
|
|
|
|
|
return CHAN_MODE_HOPPING;
|
2012-01-09 20:57:36 +08:00
|
|
|
break;
|
|
|
|
|
case NL80211_IFTYPE_AP_VLAN:
|
|
|
|
|
/* will also have _AP interface */
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
continue;
|
2012-01-09 20:57:36 +08:00
|
|
|
case NL80211_IFTYPE_AP:
|
|
|
|
|
if (!sdata->u.ap.beacon)
|
|
|
|
|
continue;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
cfg80211/mac80211: better channel handling
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
The second userland API change is the introduction
of a per virtual interface SET_CHANNEL command, that
hostapd should use going forward to make it easier
to understand what's going on (it can automatically
detect a kernel with this command).
Other than mac80211, no existing cfg80211 drivers
are affected by this change because they only allow
a single virtual interface.
mac80211, however, now needs to be aware that the
channel settings are per interface now, and needs
to disallow (for now) real multi-channel operation,
which is another important part of this patch.
One of the immediate benefits is that you can now
start hostapd to operate on a hardware that already
has a connection on another virtual interface, as
long as you specify the same channel.
Note that two things are left unhandled (this is an
improvement -- not a complete fix):
* different HT/no-HT modes
currently you could start an HT AP and then
connect to a non-HT network on the same channel
which would configure the hardware for no HT;
that can be fixed fairly easily
* CSA
An AP we're connected to on a virtual interface
might indicate switching channels, and in that
case we would follow it, regardless of how many
other interfaces are operating; this requires
more effort to fix but is pretty rare after all
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-05-05 21:25:02 +08:00
|
|
|
|
|
|
|
|
return CHAN_MODE_FIXED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return CHAN_MODE_UNDEFINED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
enum ieee80211_chan_mode
|
|
|
|
|
ieee80211_get_channel_mode(struct ieee80211_local *local,
|
|
|
|
|
struct ieee80211_sub_if_data *ignore)
|
|
|
|
|
{
|
|
|
|
|
enum ieee80211_chan_mode mode;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&local->iflist_mtx);
|
|
|
|
|
mode = __ieee80211_get_channel_mode(local, ignore);
|
|
|
|
|
mutex_unlock(&local->iflist_mtx);
|
|
|
|
|
|
|
|
|
|
return mode;
|
|
|
|
|
}
|
2010-05-05 21:28:27 +08:00
|
|
|
|
|
|
|
|
bool ieee80211_set_channel_type(struct ieee80211_local *local,
|
|
|
|
|
struct ieee80211_sub_if_data *sdata,
|
|
|
|
|
enum nl80211_channel_type chantype)
|
|
|
|
|
{
|
|
|
|
|
struct ieee80211_sub_if_data *tmp;
|
|
|
|
|
enum nl80211_channel_type superchan = NL80211_CHAN_NO_HT;
|
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&local->iflist_mtx);
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(tmp, &local->interfaces, list) {
|
|
|
|
|
if (tmp == sdata)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!ieee80211_sdata_running(tmp))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
switch (tmp->vif.bss_conf.channel_type) {
|
|
|
|
|
case NL80211_CHAN_NO_HT:
|
|
|
|
|
case NL80211_CHAN_HT20:
|
2011-03-12 04:45:51 +08:00
|
|
|
if (superchan > tmp->vif.bss_conf.channel_type)
|
|
|
|
|
break;
|
|
|
|
|
|
2010-05-05 21:28:27 +08:00
|
|
|
superchan = tmp->vif.bss_conf.channel_type;
|
|
|
|
|
break;
|
|
|
|
|
case NL80211_CHAN_HT40PLUS:
|
|
|
|
|
WARN_ON(superchan == NL80211_CHAN_HT40MINUS);
|
|
|
|
|
superchan = NL80211_CHAN_HT40PLUS;
|
|
|
|
|
break;
|
|
|
|
|
case NL80211_CHAN_HT40MINUS:
|
|
|
|
|
WARN_ON(superchan == NL80211_CHAN_HT40PLUS);
|
|
|
|
|
superchan = NL80211_CHAN_HT40MINUS;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (superchan) {
|
|
|
|
|
case NL80211_CHAN_NO_HT:
|
|
|
|
|
case NL80211_CHAN_HT20:
|
|
|
|
|
/*
|
|
|
|
|
* allow any change that doesn't go to no-HT
|
|
|
|
|
* (if it already is no-HT no change is needed)
|
|
|
|
|
*/
|
|
|
|
|
if (chantype == NL80211_CHAN_NO_HT)
|
|
|
|
|
break;
|
|
|
|
|
superchan = chantype;
|
|
|
|
|
break;
|
|
|
|
|
case NL80211_CHAN_HT40PLUS:
|
|
|
|
|
case NL80211_CHAN_HT40MINUS:
|
|
|
|
|
/* allow smaller bandwidth and same */
|
|
|
|
|
if (chantype == NL80211_CHAN_NO_HT)
|
|
|
|
|
break;
|
|
|
|
|
if (chantype == NL80211_CHAN_HT20)
|
|
|
|
|
break;
|
|
|
|
|
if (superchan == chantype)
|
|
|
|
|
break;
|
|
|
|
|
result = false;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
local->_oper_channel_type = superchan;
|
|
|
|
|
|
|
|
|
|
if (sdata)
|
|
|
|
|
sdata->vif.bss_conf.channel_type = chantype;
|
|
|
|
|
|
|
|
|
|
result = true;
|
|
|
|
|
out:
|
|
|
|
|
mutex_unlock(&local->iflist_mtx);
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
mac80211: Don't let regulatory make us deaf
When regulatory information changes our HT behavior (e.g,
when we get a country code from the AP we have just associated
with), we should use this information to change the power with
which we transmit, and what channels we transmit. Sometimes
the channel parameters we derive from regulatory information
contradicts the parameters we used in association. For example,
we could have associated specifying HT40, but the regulatory
rules we apply may forbid HT40 operation.
In the situation above, we should reconfigure ourselves to
transmit in HT20 only, however it makes no sense for us to
disable receive in HT40, since if we associated with these
parameters, the AP has every reason to expect we can and
will receive packets this way. The code in mac80211 does
not have the capability of sending the appropriate action
frames to signal a change in HT behaviour so the AP has
no clue we can no longer receive frames encoded this way.
In some broken AP implementations, this can leave us
effectively deaf if the AP never retries in lower HT rates.
This change breaks up the channel_type parameter in the
ieee80211_enable_ht function into a separate receive and
transmit part. It honors the channel flags set by regulatory
in order to configure the rate control algorithm, but uses
the capability flags to configure the channel on the radio,
since these were used in association to set the AP's transmit
rate.
Signed-off-by: Paul Stewart <pstew@chromium.org>
Cc: Sam Leffler <sleffler@chromium.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Luis R Rodriguez <mcgrof@frijolero.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-13 22:46:18 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* ieee80211_get_tx_channel_type returns the channel type we should
|
|
|
|
|
* use for packet transmission, given the channel capability and
|
|
|
|
|
* whatever regulatory flags we have been given.
|
|
|
|
|
*/
|
|
|
|
|
enum nl80211_channel_type ieee80211_get_tx_channel_type(
|
|
|
|
|
struct ieee80211_local *local,
|
|
|
|
|
enum nl80211_channel_type channel_type)
|
|
|
|
|
{
|
|
|
|
|
switch (channel_type) {
|
|
|
|
|
case NL80211_CHAN_HT40PLUS:
|
|
|
|
|
if (local->hw.conf.channel->flags &
|
|
|
|
|
IEEE80211_CHAN_NO_HT40PLUS)
|
|
|
|
|
return NL80211_CHAN_HT20;
|
|
|
|
|
break;
|
|
|
|
|
case NL80211_CHAN_HT40MINUS:
|
|
|
|
|
if (local->hw.conf.channel->flags &
|
|
|
|
|
IEEE80211_CHAN_NO_HT40MINUS)
|
|
|
|
|
return NL80211_CHAN_HT20;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return channel_type;
|
|
|
|
|
}
|