* [PATCH 2/8] mac80211: fix various components for the new 5 and 10 MHz widths
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368123036-22721-1-git-send-email-a>
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
This is a collection of minor fixes:
* don't allow HT IEs in IBSS for 5/10 MHz
* don't allow HT IEs in Mesh for 5/10 MHz
* consider 5 and 10 MHz channels when downgrading
* don't try HT rates for 5 and 10 MHz channels when selecting rates
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/ibss.c | 2 ++
net/mac80211/mesh.c | 4 +++-
net/mac80211/mesh_plink.c | 8 +++++++-
net/mac80211/mlme.c | 12 ++++++++++++
net/mac80211/rate.c | 8 +++++++-
5 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 170f9a7..4e1fb81 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -176,6 +176,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
/* add HT capability and information IEs */
if (chandef.width != NL80211_CHAN_WIDTH_20_NOHT &&
+ chandef.width != NL80211_CHAN_WIDTH_5 &&
+ chandef.width != NL80211_CHAN_WIDTH_10 &&
sband->ht_cap.ht_supported) {
pos = ieee80211_ie_build_ht_cap(pos, &sband->ht_cap,
sband->ht_cap.cap);
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 6952760..5227b73 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -417,7 +417,9 @@ int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata,
sband = local->hw.wiphy->bands[band];
if (!sband->ht_cap.ht_supported ||
- sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT)
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 ||
+ sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_10)
return 0;
if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 09bebed..02c05fa 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -154,8 +154,14 @@ static u32 mesh_set_ht_prot_mode(struct ieee80211_sub_if_data *sdata)
u16 ht_opmode;
bool non_ht_sta = false, ht20_sta = false;
- if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT)
+ switch (sdata->vif.bss_conf.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
return 0;
+ default:
+ break;
+ }
rcu_read_lock();
list_for_each_entry_rcu(sta, &local->sta_list, list) {
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2bfcdda..07cb2f3 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -224,6 +224,12 @@ static u32 chandef_downgrade(struct cfg80211_chan_def *c)
c->width = NL80211_CHAN_WIDTH_20_NOHT;
ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
break;
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
+ WARN_ON_ONCE(1);
+ /* keep c->width */
+ ret = IEEE80211_STA_DISABLE_HT | IEEE80211_STA_DISABLE_VHT;
+ break;
}
WARN_ON_ONCE(!cfg80211_chandef_valid(c));
@@ -3850,6 +3856,12 @@ static int ieee80211_prep_channel(struct ieee80211_sub_if_data *sdata,
*/
ret = ieee80211_vif_use_channel(sdata, &chandef,
IEEE80211_CHANCTX_SHARED);
+
+ /* don't downgrade for 5 and 10 MHz channels, though. */
+ if (chandef.width == NL80211_CHAN_WIDTH_5 ||
+ chandef.width == NL80211_CHAN_WIDTH_10)
+ return ret;
+
while (ret && chandef.width != NL80211_CHAN_WIDTH_20_NOHT) {
ifmgd->flags |= chandef_downgrade(&chandef);
ret = ieee80211_vif_use_channel(sdata, &chandef,
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index d3f414f..dbbcd57 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -397,8 +397,14 @@ static void rate_idx_match_mask(struct ieee80211_tx_rate *rate,
return;
/* if HT BSS, and we handle a data frame, also try HT rates */
- if (chan_width == NL80211_CHAN_WIDTH_20_NOHT)
+ switch (chan_width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
return;
+ default:
+ break;
+ }
alt_rate.idx = 0;
/* keep protection flags */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/8] ath9k: convert to chandef, enable support for 5/10 MHz channels
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368123036-22721-1-git-send-email-a>
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
To enable support for 5/10 MHz, also some internal functions must be
converted from using the (old) channel_type to chandef. This is a good
chance to change all remaining occurences.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath9k/common.c | 67 +++++++++++++++----------
drivers/net/wireless/ath/ath9k/common.h | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 4 +-
drivers/net/wireless/ath/ath9k/main.c | 8 ++-
drivers/net/wireless/ath/ath9k/rc.c | 4 +-
6 files changed, 51 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 344fdde..d3063c2 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -49,37 +49,40 @@ int ath9k_cmn_get_hw_crypto_keytype(struct sk_buff *skb)
}
EXPORT_SYMBOL(ath9k_cmn_get_hw_crypto_keytype);
-static u32 ath9k_get_extchanmode(struct ieee80211_channel *chan,
- enum nl80211_channel_type channel_type)
+static u32 ath9k_get_extchanmode(struct cfg80211_chan_def *chandef)
{
u32 chanmode = 0;
- switch (chan->band) {
+ switch (chandef->chan->band) {
case IEEE80211_BAND_2GHZ:
- switch (channel_type) {
- case NL80211_CHAN_NO_HT:
- case NL80211_CHAN_HT20:
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
chanmode = CHANNEL_G_HT20;
break;
- case NL80211_CHAN_HT40PLUS:
- chanmode = CHANNEL_G_HT40PLUS;
+ case NL80211_CHAN_WIDTH_40:
+ if (chandef->center_freq1 > chandef->chan->center_freq)
+ chanmode = CHANNEL_G_HT40PLUS;
+ else
+ chanmode = CHANNEL_G_HT40MINUS;
break;
- case NL80211_CHAN_HT40MINUS:
- chanmode = CHANNEL_G_HT40MINUS;
+ default:
break;
}
break;
case IEEE80211_BAND_5GHZ:
- switch (channel_type) {
- case NL80211_CHAN_NO_HT:
- case NL80211_CHAN_HT20:
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
chanmode = CHANNEL_A_HT20;
break;
- case NL80211_CHAN_HT40PLUS:
- chanmode = CHANNEL_A_HT40PLUS;
+ case NL80211_CHAN_WIDTH_40:
+ if (chandef->center_freq1 > chandef->chan->center_freq)
+ chanmode = CHANNEL_A_HT40PLUS;
+ else
+ chanmode = CHANNEL_A_HT40MINUS;
break;
- case NL80211_CHAN_HT40MINUS:
- chanmode = CHANNEL_A_HT40MINUS;
+ default:
break;
}
break;
@@ -94,13 +97,12 @@ static u32 ath9k_get_extchanmode(struct ieee80211_channel *chan,
* Update internal channel flags.
*/
void ath9k_cmn_update_ichannel(struct ath9k_channel *ichan,
- struct ieee80211_channel *chan,
- enum nl80211_channel_type channel_type)
+ struct cfg80211_chan_def *chandef)
{
- ichan->channel = chan->center_freq;
- ichan->chan = chan;
+ ichan->channel = chandef->chan->center_freq;
+ ichan->chan = chandef->chan;
- if (chan->band == IEEE80211_BAND_2GHZ) {
+ if (chandef->chan->band == IEEE80211_BAND_2GHZ) {
ichan->chanmode = CHANNEL_G;
ichan->channelFlags = CHANNEL_2GHZ | CHANNEL_OFDM;
} else {
@@ -108,8 +110,22 @@ void ath9k_cmn_update_ichannel(struct ath9k_channel *ichan,
ichan->channelFlags = CHANNEL_5GHZ | CHANNEL_OFDM;
}
- if (channel_type != NL80211_CHAN_NO_HT)
- ichan->chanmode = ath9k_get_extchanmode(chan, channel_type);
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_5:
+ ichan->channelFlags |= CHANNEL_QUARTER;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ ichan->channelFlags |= CHANNEL_HALF;
+ break;
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ break;
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_40:
+ ichan->chanmode = ath9k_get_extchanmode(chandef);
+ break;
+ default:
+ WARN_ON(1);
+ }
}
EXPORT_SYMBOL(ath9k_cmn_update_ichannel);
@@ -125,8 +141,7 @@ struct ath9k_channel *ath9k_cmn_get_curchannel(struct ieee80211_hw *hw,
chan_idx = curchan->hw_value;
channel = &ah->channels[chan_idx];
- ath9k_cmn_update_ichannel(channel, curchan,
- cfg80211_get_chandef_type(&hw->conf.chandef));
+ ath9k_cmn_update_ichannel(channel, &hw->conf.chandef);
return channel;
}
diff --git a/drivers/net/wireless/ath/ath9k/common.h b/drivers/net/wireless/ath/ath9k/common.h
index 207d069..e039bcb 100644
--- a/drivers/net/wireless/ath/ath9k/common.h
+++ b/drivers/net/wireless/ath/ath9k/common.h
@@ -44,8 +44,7 @@
int ath9k_cmn_get_hw_crypto_keytype(struct sk_buff *skb);
void ath9k_cmn_update_ichannel(struct ath9k_channel *ichan,
- struct ieee80211_channel *chan,
- enum nl80211_channel_type channel_type);
+ struct cfg80211_chan_def *chandef);
struct ath9k_channel *ath9k_cmn_get_curchannel(struct ieee80211_hw *hw,
struct ath_hw *ah);
int ath9k_cmn_count_streams(unsigned int chainmask, int max);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..8c25c7a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1194,16 +1194,13 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
if ((changed & IEEE80211_CONF_CHANGE_CHANNEL) || chip_reset) {
struct ieee80211_channel *curchan = hw->conf.chandef.chan;
- enum nl80211_channel_type channel_type =
- cfg80211_get_chandef_type(&hw->conf.chandef);
int pos = curchan->hw_value;
ath_dbg(common, CONFIG, "Set channel: %d MHz\n",
curchan->center_freq);
ath9k_cmn_update_ichannel(&priv->ah->channels[pos],
- hw->conf.chandef.chan,
- channel_type);
+ &hw->conf.chandef);
if (ath9k_htc_set_channel(priv, hw, &priv->ah->channels[pos]) < 0) {
ath_err(common, "Unable to set channel\n");
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 3be2eb0..0959729 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -684,13 +684,15 @@ static void ath9k_init_band_txpower(struct ath_softc *sc, int band)
struct ieee80211_supported_band *sband;
struct ieee80211_channel *chan;
struct ath_hw *ah = sc->sc_ah;
+ struct cfg80211_chan_def chandef;
int i;
sband = &sc->sbands[band];
for (i = 0; i < sband->n_channels; i++) {
chan = &sband->channels[i];
ah->curchan = &ah->channels[chan->hw_value];
- ath9k_cmn_update_ichannel(ah->curchan, chan, NL80211_CHAN_HT20);
+ cfg80211_chandef_create(&chandef, chan, NL80211_CHAN_HT20);
+ ath9k_cmn_update_ichannel(ah->curchan, &chandef);
ath9k_hw_set_txpowerlimit(ah, MAX_RATE_POWER, true);
}
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a383483..6804f4f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1189,8 +1189,6 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
if ((changed & IEEE80211_CONF_CHANGE_CHANNEL) || reset_channel) {
struct ieee80211_channel *curchan = hw->conf.chandef.chan;
- enum nl80211_channel_type channel_type =
- cfg80211_get_chandef_type(&conf->chandef);
int pos = curchan->hw_value;
int old_pos = -1;
unsigned long flags;
@@ -1198,8 +1196,8 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
if (ah->curchan)
old_pos = ah->curchan - &ah->channels[0];
- ath_dbg(common, CONFIG, "Set channel: %d MHz type: %d\n",
- curchan->center_freq, channel_type);
+ ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
+ curchan->center_freq, hw->conf.chandef.width);
/* update survey stats for the old channel before switching */
spin_lock_irqsave(&common->cc_lock, flags);
@@ -1214,7 +1212,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
ath9k_hw_getnf(ah, ah->curchan);
ath9k_cmn_update_ichannel(&sc->sc_ah->channels[pos],
- curchan, channel_type);
+ &conf->chandef);
/*
* If the operating channel changes, change the survey in-use flags
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index aa4d368..ed57d57 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -1327,8 +1327,8 @@ static void ath_rate_update(void *priv, struct ieee80211_supported_band *sband,
ath_rc_init(sc, priv_sta);
ath_dbg(ath9k_hw_common(sc->sc_ah), CONFIG,
- "Operating HT Bandwidth changed to: %d\n",
- cfg80211_get_chandef_type(&sc->hw->conf.chandef));
+ "Operating Bandwidth changed to: %d\n",
+ &sc->hw->conf.chandef->width);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/8] mac80211: change IBSS channel state to chandef
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368123036-22721-1-git-send-email-a>
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
This should make some parts cleaner and is also required for handling
5/10 MHz properly.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/ibss.c | 22 +++++++++++-----------
net/mac80211/ieee80211_i.h | 3 +--
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 4e1fb81..ef07b65 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -81,7 +81,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
- cfg80211_chandef_create(&chandef, chan, ifibss->channel_type);
+ chandef = ifibss->chandef;
if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
chandef.width = NL80211_CHAN_WIDTH_20;
chandef.center_freq1 = chan->center_freq;
@@ -514,7 +514,9 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
set_sta_flag(sta, WLAN_STA_WME);
if (sta && elems->ht_operation && elems->ht_cap_elem &&
- sdata->u.ibss.channel_type != NL80211_CHAN_NO_HT) {
+ sdata->u.ibss.chandef.width != NL80211_CHAN_WIDTH_20_NOHT &&
+ sdata->u.ibss.chandef.width != NL80211_CHAN_WIDTH_5 &&
+ sdata->u.ibss.chandef.width != NL80211_CHAN_WIDTH_10) {
/* we both use HT */
struct ieee80211_ht_cap htcap_ie;
struct cfg80211_chan_def chandef;
@@ -529,8 +531,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
* fall back to HT20 if we don't use or use
* the other extension channel
*/
- if (cfg80211_get_chandef_type(&chandef) !=
- sdata->u.ibss.channel_type)
+ if (chandef.center_freq1 !=
+ sdata->u.ibss.chandef.center_freq1)
htcap_ie.cap_info &=
cpu_to_le16(~IEEE80211_HT_CAP_SUP_WIDTH_20_40);
@@ -569,7 +571,7 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
/* different channel */
if (sdata->u.ibss.fixed_channel &&
- sdata->u.ibss.channel != cbss->channel)
+ sdata->u.ibss.chandef.chan != cbss->channel)
goto put_bss;
/* different SSID */
@@ -757,7 +759,7 @@ static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
sdata->drop_unencrypted = 0;
__ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
- ifibss->channel, ifibss->basic_rates,
+ ifibss->chandef.chan, ifibss->basic_rates,
capability, 0, true);
}
@@ -789,7 +791,7 @@ static void ieee80211_sta_find_ibss(struct ieee80211_sub_if_data *sdata)
if (ifibss->fixed_bssid)
bssid = ifibss->bssid;
if (ifibss->fixed_channel)
- chan = ifibss->channel;
+ chan = ifibss->chandef.chan;
if (!is_zero_ether_addr(ifibss->bssid))
bssid = ifibss->bssid;
cbss = cfg80211_get_bss(local->hw.wiphy, chan, bssid,
@@ -1059,9 +1061,7 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
sdata->vif.bss_conf.beacon_int = params->beacon_interval;
- sdata->u.ibss.channel = params->chandef.chan;
- sdata->u.ibss.channel_type =
- cfg80211_get_chandef_type(¶ms->chandef);
+ sdata->u.ibss.chandef = params->chandef;
sdata->u.ibss.fixed_channel = params->channel_fixed;
if (params->ie) {
@@ -1124,7 +1124,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
if (ifibss->privacy)
capability |= WLAN_CAPABILITY_PRIVACY;
- cbss = cfg80211_get_bss(local->hw.wiphy, ifibss->channel,
+ cbss = cfg80211_get_bss(local->hw.wiphy, ifibss->chandef.chan,
ifibss->bssid, ifibss->ssid,
ifibss->ssid_len, WLAN_CAPABILITY_IBSS |
WLAN_CAPABILITY_PRIVACY,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 44be28c..1079c27 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -505,8 +505,7 @@ struct ieee80211_if_ibss {
u8 ssid[IEEE80211_MAX_SSID_LEN];
u8 ssid_len, ie_len;
u8 *ie;
- struct ieee80211_channel *channel;
- enum nl80211_channel_type channel_type;
+ struct cfg80211_chan_def chandef;
unsigned long ibss_join_req;
/* probe response/beacon for IBSS */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/8] mac80211: fix timing for 5 MHz and 10 MHz channels
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368123036-22721-1-git-send-email-a>
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
according to IEEE 802.11-2012 section 18, various timings change
when using 5 MHz and 10 MHz. Reflect this by using a "divisor" when
calculating durations.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/ieee80211_i.h | 42 ++++++++++++++++++++++++++++++++++-
net/mac80211/rc80211_minstrel.c | 14 +++++++-----
net/mac80211/rc80211_minstrel_ht.c | 8 ++++---
net/mac80211/tx.c | 10 ++++++---
net/mac80211/util.c | 43 +++++++++++++++++++++++++-----------
5 files changed, 92 insertions(+), 25 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 1079c27..e9d3da9 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -792,6 +792,45 @@ ieee80211_get_sdata_band(struct ieee80211_sub_if_data *sdata)
return band;
}
+static inline int
+ieee80211_vif_get_divisor(struct ieee80211_vif *vif)
+{
+ struct ieee80211_chanctx_conf *chanctx_conf;
+ int divisor = 1;
+
+ rcu_read_lock();
+ chanctx_conf = rcu_dereference(vif->chanctx_conf);
+ if (chanctx_conf) {
+ switch (chanctx_conf->def.width) {
+ case NL80211_CHAN_WIDTH_5:
+ divisor = 4;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ divisor = 2;
+ break;
+ default:
+ divisor = 1;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return divisor;
+}
+
+static inline int
+ieee80211_hw_get_divisor(struct ieee80211_hw *hw)
+{
+ switch (hw->conf.chandef.width) {
+ case NL80211_CHAN_WIDTH_5:
+ return 4;
+ case NL80211_CHAN_WIDTH_10:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
enum sdata_queue_type {
IEEE80211_SDATA_QUEUE_TYPE_FRAME = 0,
IEEE80211_SDATA_QUEUE_AGG_START = 1,
@@ -1448,7 +1487,8 @@ extern void *mac80211_wiphy_privid; /* for wiphy privid */
u8 *ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len,
enum nl80211_iftype type);
int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
- int rate, int erp, int short_preamble);
+ int rate, int erp, int short_preamble,
+ int divisor);
void mac80211_ev_michael_mic_failure(struct ieee80211_sub_if_data *sdata, int keyidx,
struct ieee80211_hdr *hdr, const u8 *tsc,
gfp_t gfp);
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index ac7ef54..3fe134a 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -382,14 +382,17 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
static void
calc_rate_durations(enum ieee80211_band band,
struct minstrel_rate *d,
- struct ieee80211_rate *rate)
+ struct ieee80211_rate *rate,
+ struct minstrel_priv *mp)
{
int erp = !!(rate->flags & IEEE80211_RATE_ERP_G);
d->perfect_tx_time = ieee80211_frame_duration(band, 1200,
- rate->bitrate, erp, 1);
+ rate->bitrate, erp, 1,
+ ieee80211_hw_get_divisor(mp->hw));
d->ack_time = ieee80211_frame_duration(band, 10,
- rate->bitrate, erp, 1);
+ rate->bitrate, erp, 1,
+ ieee80211_hw_get_divisor(mp->hw));
}
static void
@@ -430,7 +433,8 @@ minstrel_rate_init(void *priv, struct ieee80211_supported_band *sband,
ctl_rate = &sband->bitrates[mi->lowest_rix];
mi->sp_ack_dur = ieee80211_frame_duration(sband->band, 10,
ctl_rate->bitrate,
- !!(ctl_rate->flags & IEEE80211_RATE_ERP_G), 1);
+ !!(ctl_rate->flags & IEEE80211_RATE_ERP_G), 1,
+ ieee80211_hw_get_divisor(mp->hw));
memset(mi->max_tp_rate, 0, sizeof(mi->max_tp_rate));
mi->max_prob_rate = 0;
@@ -448,7 +452,7 @@ minstrel_rate_init(void *priv, struct ieee80211_supported_band *sband,
mr->rix = i;
mr->bitrate = sband->bitrates[i].bitrate / 5;
- calc_rate_durations(sband->band, mr, &sband->bitrates[i]);
+ calc_rate_durations(sband->band, mr, &sband->bitrates[i], mp);
/* calculate maximum number of retransmissions before
* fallback (based on maximum segment size) */
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 5b2d301..f05eeff 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -844,7 +844,7 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
u16 sta_cap = sta->ht_cap.cap;
int n_supported = 0;
- int ack_dur;
+ int ack_dur, divisor;
int stbc;
int i;
@@ -861,8 +861,10 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
mi->sta = sta;
mi->stats_update = jiffies;
- ack_dur = ieee80211_frame_duration(sband->band, 10, 60, 1, 1);
- mi->overhead = ieee80211_frame_duration(sband->band, 0, 60, 1, 1) + ack_dur;
+ divisor = ieee80211_hw_get_divisor(mp->hw);
+ ack_dur = ieee80211_frame_duration(sband->band, 10, 60, 1, 1, divisor);
+ mi->overhead = ieee80211_frame_duration(sband->band, 0, 60, 1, 1,
+ divisor) + ack_dur;
mi->overhead_rtscts = mi->overhead + 2 * ack_dur;
mi->avg_ampdu_len = MINSTREL_FRAC(1, 1);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 4a5fbf8..4bed9fd 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -40,7 +40,7 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
struct sk_buff *skb, int group_addr,
int next_frag_len)
{
- int rate, mrate, erp, dur, i;
+ int rate, mrate, erp, dur, i, divisor;
struct ieee80211_rate *txrate;
struct ieee80211_local *local = tx->local;
struct ieee80211_supported_band *sband;
@@ -153,6 +153,8 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
rate = mrate;
}
+ divisor = ieee80211_vif_get_divisor(&tx->sdata->vif);
+
/* Don't calculate ACKs for QoS Frames with NoAck Policy set */
if (ieee80211_is_data_qos(hdr->frame_control) &&
*(ieee80211_get_qos_ctl(hdr)) & IEEE80211_QOS_CTL_ACK_POLICY_NOACK)
@@ -162,7 +164,8 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
* (10 bytes + 4-byte FCS = 112 bits) plus SIFS; rounded up
* to closest integer */
dur = ieee80211_frame_duration(sband->band, 10, rate, erp,
- tx->sdata->vif.bss_conf.use_short_preamble);
+ tx->sdata->vif.bss_conf.use_short_preamble,
+ divisor);
if (next_frag_len) {
/* Frame is fragmented: duration increases with time needed to
@@ -171,7 +174,8 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data *tx,
/* next fragment */
dur += ieee80211_frame_duration(sband->band, next_frag_len,
txrate->bitrate, erp,
- tx->sdata->vif.bss_conf.use_short_preamble);
+ tx->sdata->vif.bss_conf.use_short_preamble,
+ divisor);
}
return cpu_to_le16(dur);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 27e0715..ad03800 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -107,7 +107,8 @@ void ieee80211_tx_set_protected(struct ieee80211_tx_data *tx)
}
int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
- int rate, int erp, int short_preamble)
+ int rate, int erp, int short_preamble,
+ int divisor)
{
int dur;
@@ -118,6 +119,13 @@ int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
*
* rate is in 100 kbps, so divident is multiplied by 10 in the
* DIV_ROUND_UP() operations.
+ *
+ * divisor may be 4 for 5 MHz channels or 2 for 1 MHz channels, and
+ * is assumed to be 1 otherwise. For 5 and 10 MHz channels, the
+ * according 20 MHz rates are assumed. For example, a datarate of
+ * 1.5mbps in a 5 MHz channel would be reported as rate == 60,
+ * because the corresponding datarate in 20mbps with the same
+ * modulation would be 6 mbps.
*/
if (band == IEEE80211_BAND_5GHZ || erp) {
@@ -130,15 +138,21 @@ int ieee80211_frame_duration(enum ieee80211_band band, size_t len,
* TXTIME = T_PREAMBLE + T_SIGNAL + T_SYM x N_SYM + Signal Ext
*
* T_SYM = 4 usec
- * 802.11a - 17.5.2: aSIFSTime = 16 usec
+ * 802.11a - 18.5.2: aSIFSTime = 16 usec
* 802.11g - 19.8.4: aSIFSTime = 10 usec +
* signal ext = 6 usec
*/
dur = 16; /* SIFS + signal ext */
- dur += 16; /* 17.3.2.3: T_PREAMBLE = 16 usec */
- dur += 4; /* 17.3.2.3: T_SIGNAL = 4 usec */
+ dur += 16; /* IEEE 802.11-2012 18.3.2.4: T_PREAMBLE = 16 usec */
+ dur += 4; /* IEEE 802.11-2012 18.3.2.4: T_SIGNAL = 4 usec */
dur += 4 * DIV_ROUND_UP((16 + 8 * (len + 4) + 6) * 10,
4 * rate); /* T_SYM x N_SYM */
+
+ /* IEEE 802.11-2012 18.3.2.4: all values above are:
+ * * times 4 for 5 MHz
+ * * times 2 for 10 MHz
+ */
+ dur *= divisor;
} else {
/*
* 802.11b or 802.11g with 802.11b compatibility:
@@ -168,7 +182,7 @@ __le16 ieee80211_generic_frame_duration(struct ieee80211_hw *hw,
{
struct ieee80211_sub_if_data *sdata;
u16 dur;
- int erp;
+ int erp, divisor = 1;
bool short_preamble = false;
erp = 0;
@@ -177,10 +191,11 @@ __le16 ieee80211_generic_frame_duration(struct ieee80211_hw *hw,
short_preamble = sdata->vif.bss_conf.use_short_preamble;
if (sdata->flags & IEEE80211_SDATA_OPERATING_GMODE)
erp = rate->flags & IEEE80211_RATE_ERP_G;
+ divisor = ieee80211_vif_get_divisor(vif);
}
dur = ieee80211_frame_duration(band, frame_len, rate->bitrate, erp,
- short_preamble);
+ short_preamble, divisor);
return cpu_to_le16(dur);
}
@@ -194,7 +209,7 @@ __le16 ieee80211_rts_duration(struct ieee80211_hw *hw,
struct ieee80211_rate *rate;
struct ieee80211_sub_if_data *sdata;
bool short_preamble;
- int erp;
+ int erp, divisor = 1;
u16 dur;
struct ieee80211_supported_band *sband;
@@ -210,17 +225,18 @@ __le16 ieee80211_rts_duration(struct ieee80211_hw *hw,
short_preamble = sdata->vif.bss_conf.use_short_preamble;
if (sdata->flags & IEEE80211_SDATA_OPERATING_GMODE)
erp = rate->flags & IEEE80211_RATE_ERP_G;
+ divisor = ieee80211_vif_get_divisor(vif);
}
/* CTS duration */
dur = ieee80211_frame_duration(sband->band, 10, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
/* Data frame duration */
dur += ieee80211_frame_duration(sband->band, frame_len, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
/* ACK duration */
dur += ieee80211_frame_duration(sband->band, 10, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
return cpu_to_le16(dur);
}
@@ -235,7 +251,7 @@ __le16 ieee80211_ctstoself_duration(struct ieee80211_hw *hw,
struct ieee80211_rate *rate;
struct ieee80211_sub_if_data *sdata;
bool short_preamble;
- int erp;
+ int erp, divisor = 1;
u16 dur;
struct ieee80211_supported_band *sband;
@@ -250,15 +266,16 @@ __le16 ieee80211_ctstoself_duration(struct ieee80211_hw *hw,
short_preamble = sdata->vif.bss_conf.use_short_preamble;
if (sdata->flags & IEEE80211_SDATA_OPERATING_GMODE)
erp = rate->flags & IEEE80211_RATE_ERP_G;
+ divisor = ieee80211_vif_get_divisor(vif);
}
/* Data frame duration */
dur = ieee80211_frame_duration(sband->band, frame_len, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
if (!(frame_txctl->flags & IEEE80211_TX_CTL_NO_ACK)) {
/* ACK duration */
dur += ieee80211_frame_duration(sband->band, 10, rate->bitrate,
- erp, short_preamble);
+ erp, short_preamble, divisor);
}
return cpu_to_le16(dur);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/8] ath9k: announce that ath9k supports 5/10 MHz
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368123036-22721-1-git-send-email-a>
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath9k/init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 0959729..30c3ddf 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -794,6 +794,7 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS;
hw->wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
+ hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_5_10_MHZ;
#ifdef CONFIG_PM_SLEEP
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/8] nl80211: allow 5 and 10 MHz channels for IBSS
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1368123036-22721-1-git-send-email-a>
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Whether the wiphy supports it or not is already checked, so what is left
is to enable these channel types.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/wireless/nl80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f67d825..fbbb639 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6335,6 +6335,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
switch (ibss.chandef.width) {
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
case NL80211_CHAN_WIDTH_20_NOHT:
break;
case NL80211_CHAN_WIDTH_20:
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/8] Add support for 5 and 10 MHz channels
From: a @ 2013-05-09 18:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Mathias Kretschmer, Simon Wunderlich
From: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
and enables support in ath5k and ath9k, which already support this feature
on the driver side. 5 and 10 MHz wide channels might be useful for:
* long shot links, as the transmissions are more robust
* future support for 802.11y which allows some 5 and 10 MHz channels in
3.6 GHz range
* future support for 802.11p which uses 10 MHz in 5.9 GHz range
* ... and more "special" applications.
Note that the transmissions are only defined for the OFDM PHY in the
standard and are therefore limited to 5 GHz, no HT or MIMO here. However,
at least my AR5K and AR9K based chips seem to support this mode on 2.4 GHz
as well. Datarates are halfed or quartered, leaving up to 27 Mbit/s or
13.5 Mbit/s gross rates respectively.
Some benchmark results (IBSS, iperf, ath9k on AR9220, ath5k on AR5213A):
* ath5k -> ath5k:
5.23 Mbit/s @ 5 MHz
10.8 Mbit/s @ 10 MHz
19.1 Mbit/s @ 20 MHz (NOHT mode)
* ath9k -> ath9k:
5.24 Mbit/s @ 5 MHz
10.9 Mbit/s @ 10 MHz
16.4 Mbit/s @ 20 MHz (NOHT mode, appears to be a little bit low though)
Comments:
* Is there any special requirement for handling beacons? For example,
rates are halfed or quartered, but some rates could not be represented
in the rate IEs. For example, 2.25 mbit/s can not be represented as
multiple of 500 kbps.
* therefore, all rates are handled like the corresponding 20 MHz rates
internally, which makes a lot of things easier (no changes required
for rc-algos, beacon creation, etc...). We might consider adjusting the
output of rates for nl80211 or radiotap, though.
As always, any comments are appreciated!
Cheers,
Simon
Simon Wunderlich (8):
nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag
mac80211: fix various components for the new 5 and 10 MHz widths
mac80211: change IBSS channel state to chandef
mac80211: fix timing for 5 MHz and 10 MHz channels
nl80211: allow 5 and 10 MHz channels for IBSS
ath9k: convert to chandef, enable support for 5/10 MHz channels
ath9k: announce that ath9k supports 5/10 MHz
ath5k: enable support for 5 MHz and 10 MHz channels
drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
drivers/net/wireless/ath/ath5k/base.c | 25 +++++++--
drivers/net/wireless/ath/ath5k/base.h | 2 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
drivers/net/wireless/ath/ath9k/common.c | 67 +++++++++++++++----------
drivers/net/wireless/ath/ath9k/common.h | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 5 +-
drivers/net/wireless/ath/ath9k/main.c | 8 ++-
drivers/net/wireless/ath/ath9k/rc.c | 4 +-
include/net/cfg80211.h | 2 +
include/uapi/linux/nl80211.h | 4 ++
net/mac80211/ibss.c | 24 +++++----
net/mac80211/ieee80211_i.h | 45 +++++++++++++++--
net/mac80211/mesh.c | 4 +-
net/mac80211/mesh_plink.c | 8 ++-
net/mac80211/mlme.c | 12 +++++
net/mac80211/rate.c | 8 ++-
net/mac80211/rc80211_minstrel.c | 14 ++++--
net/mac80211/rc80211_minstrel_ht.c | 8 +--
net/mac80211/tx.c | 10 ++--
net/mac80211/util.c | 43 +++++++++++-----
net/wireless/chan.c | 29 +++++++++++
net/wireless/nl80211.c | 23 +++++++--
24 files changed, 266 insertions(+), 90 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH] ath9k: Disable spectral scan code to fix crash on rmmod.
From: Ben Greear @ 2013-05-09 17:40 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <20875.13834.615920.337442@gargle.gargle.HOWL>
On 05/08/2013 10:37 PM, Sujith Manoharan wrote:
> greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> With CONFIG_ATH9K_DEBUGFS enabled, and slub memory poisoning
>> enabled, I see this crash on rmmod of ath9k. I'm not sure how
>> to fix this properly, but in the meantime, this patch to disable
>> the spectral scan code works around the problem for me.
>>
>> With memory poisoning and the verify_mem_not_deleted code
>> below added, the crash looks as follows... The dentry
>> is not *always* freed at this point, probably because rcu
>> callbacks haven't completed. You still get a crash soon
>> after, however.
>
> The relay file should probably be closed before calling ieee80211_unregister_hw().
> The ath9k debugfs directory is created inside the phy#/ directory and that would
> get cleaned up when the wiphy is unregistered.
>
> Does this help ?
This fixes the problem for me, and certainly is less of a hack than
what I posted.
I did several module unloads with memory poisoning enabled, system
remains stable.
Tested-by: Ben Greear <greearb@candelatech.com>
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Fun with QoS in AP mode.
From: Krishna Chaitanya @ 2013-05-09 17:00 UTC (permalink / raw)
To: Ben Greear
Cc: Sujith Manoharan, Cyril Segretain, linux-wireless@vger.kernel.org
In-Reply-To: <518BD13D.1030504@candelatech.com>
On Thu, May 9, 2013 at 10:09 PM, Ben Greear <greearb@candelatech.com> wrote:
>
> On 05/09/2013 09:32 AM, Sujith Manoharan wrote:
>>
>> Ben Greear wrote:
>>>
>>> I suspect we need to set up rules with 'tc' and maybe iptables.
>>>
>>> I'm not having any luck finding any examples out on the web, but
>>> surely the info is somewhere w/out having to fully understand 'tc'.
>>
>>
>> DSCP can be used...
>>
>> Something like "iptables -t mangle -A OUTPUT -p tcp --dport 5005 -j DSCP --set-dscp-class "CS6""
>> (Change the class for other priorities).
>
>
> In my case, I'd like to match on the ToS set in the IP headers.
>
> Basically, just map ToS 192 to VO, for instance.
Talking about rules, Are you able to see the ToS marked in the IP header in
the sniffer and not in the 802.11 header? Then we can concentrate on
marking the packet (or) mapping in the driver?
^ permalink raw reply
* Re: Fun with QoS in AP mode.
From: Ben Greear @ 2013-05-09 16:39 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: Cyril Segretain, linux-wireless@vger.kernel.org
In-Reply-To: <20875.53161.157603.680374@gargle.gargle.HOWL>
On 05/09/2013 09:32 AM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> I suspect we need to set up rules with 'tc' and maybe iptables.
>>
>> I'm not having any luck finding any examples out on the web, but
>> surely the info is somewhere w/out having to fully understand 'tc'.
>
> DSCP can be used...
>
> Something like "iptables -t mangle -A OUTPUT -p tcp --dport 5005 -j DSCP --set-dscp-class "CS6""
> (Change the class for other priorities).
In my case, I'd like to match on the ToS set in the IP headers.
Basically, just map ToS 192 to VO, for instance.
Thanks,
Ben
>
> Sujith
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Fun with QoS in AP mode.
From: Sujith Manoharan @ 2013-05-09 16:32 UTC (permalink / raw)
To: Ben Greear; +Cc: Cyril Segretain, linux-wireless@vger.kernel.org
In-Reply-To: <518BCE45.1060704@candelatech.com>
Ben Greear wrote:
> I suspect we need to set up rules with 'tc' and maybe iptables.
>
> I'm not having any luck finding any examples out on the web, but
> surely the info is somewhere w/out having to fully understand 'tc'.
DSCP can be used...
Something like "iptables -t mangle -A OUTPUT -p tcp --dport 5005 -j DSCP --set-dscp-class "CS6""
(Change the class for other priorities).
Sujith
^ permalink raw reply
* Re: Fun with QoS in AP mode.
From: Ben Greear @ 2013-05-09 16:26 UTC (permalink / raw)
To: Cyril Segretain; +Cc: Sujith Manoharan, linux-wireless@vger.kernel.org
In-Reply-To: <CAJu560hVBcdJ67uNprj0TOY6rWNd-iT8f7QNaE64=ENz91yj6w@mail.gmail.com>
On 05/09/2013 08:42 AM, Cyril Segretain wrote:
> Hello,
> I have the same issue but it's with Video streaming, all the frames are in Best_Effort Access Category.
> I work with ath9k driver and hostapd for the AP.
> STA1 <- - - - > AP <--------> Server
> Same software and hardware for STA and AP, WMM enabled in hostapd, hardware support WMM, I don't know where is the problem...
> If you have any idea.
I suspect we need to set up rules with 'tc' and maybe iptables.
I'm not having any luck finding any examples out on the web, but
surely the info is somewhere w/out having to fully understand 'tc'.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
From: Larry Finger @ 2013-05-09 15:36 UTC (permalink / raw)
To: Norbert Preining; +Cc: linux-wireless, linux-kernel, hostap
In-Reply-To: <20130509115630.GC5111@gamma.logic.tuwien.ac.at>
On 05/09/2013 06:56 AM, Norbert Preining wrote:
> in the current state, that is release 3.9.0, but the same happened
> in earlier kernels, this driver and/or NM is completely useless
> at times. At times it just works, at times it does nothing.
> In this case, now the 5th day in series ...
Nice long rant. Too bad we don't have a soapbox.
With all the information you provided, you forgot one detail that is absolutely
critical, namely the PCI ID. There are at least three varieties of RTL8191SE
chip, and I have no idea which one you have.
I also recommend that you try either the wireless-testing git repo or the
mainline git repo. There are a lot of changes that cannot be backported.
Larry
^ permalink raw reply
* Re: Fun with QoS in AP mode.
From: Ben Greear @ 2013-05-09 14:43 UTC (permalink / raw)
To: Sujith Manoharan; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20875.12412.946993.203664@gargle.gargle.HOWL>
On 05/08/2013 10:13 PM, Sujith Manoharan wrote:
> Ben Greear wrote:
>> Yes, both AP and Station machine are ath9k, 3.9.0+, etc....
>>
>> Basically identicaly hardware and software loads..just one is acting as AP
>> and one as station(s) in this scenario.
>
> Works okay here.
>
> STA1 <-> AP <-> STA2 (ath9k stations, ath9k AP running OpenWrt trunk).
We're running Fedora 17..maybe we have to configure some more routing/QoS
logic to enable the feature on the AP side...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
From: Oleksij Rempel @ 2013-05-09 12:18 UTC (permalink / raw)
To: Norbert Preining; +Cc: linux-wireless, linux-kernel, hostap, Larry Finger
In-Reply-To: <20130509115630.GC5111@gamma.logic.tuwien.ac.at>
Hi Norbert,
you should contact Larry Finger <Larry.Finger@lwfinger.net> (i CC him),
hi is working on RTL devices so far it is possible. And probably he is
only person who doing that :(
You should understand that Realtek provide only closed source firmware
and, so far i know, no documentation. This makes it hard to support them.
Visit this page, and see Hardware_Donations:
http://wireless.kernel.org/en/users/Drivers/rtl819x#Hardware_Donations
Am 09.05.2013 13:56, schrieb Norbert Preining:
> Dear all,
>
> here is a short status report on my experiences with:
> kernel 3.9.0
> wpa_supplicant 1.0
> hardware RTL191SEvB
> Debian/sid
>
> Short summary: broken to the degree that internet connection is impossible
>
> Sorry for the long mail, I tried to reduce to the essentials only.
>
> Contents:
> =========
> 0) hardware and software description
> 1) during connection permanent break off
> 2) connection seems established according to kernel and NM, but nothing works
> 3) if connection is working, ping times are crazy and connection breaks down suddenly
> 4) conclusion
>
>
> 0) hardware and software description
> ====================================
> Hardware:
> Lenovo Thinkpad Edge
> WLAN:
> 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. Device e020
> Flags: bus master, fast devsel, latency 0, IRQ 17
> I/O ports at 2000 [size=256]
> Memory at f0500000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Legacy Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
> Kernel driver in use: rtl8192se
>
> Debian unstable up to date
> kernel 3.9.0
> # wpa_supplicant -v
> wpa_supplicant v1.0
> Copyright (c) 2003-2012, Jouni Malinen <j@w1.fi> and contributors
>
> Debian version: 1.0-3+b2
>
> Please note: during all the following experiments at times
> two other computers (iPhone, WinXP) very connected without
> any problems (of course on different IPs).
>
>
> ad 1) during connection permanent break off
> ============================================
>
> typical dmesg output:
> many times:
> May 8 20:54:59 tofuschnitzel NetworkManager[4878]: <info> (wlan0): supplicant interface state: disconnected -> scanning
> May 8 20:54:59 tofuschnitzel wpa_supplicant[5513]: wlan0: SME: Trying to authenticate with 00:3a:9d:b4:54:5a (SSID='norbujp' fr
> eq=2447 MHz)
> kernel: [19070.021021] wlan0: authenticate with 00:3a:9d:b4:54:5a
> NetworkManager[4878]: <info> (wlan0): supplicant interface state: scanning -> authenticating
> kernel: [19070.040313] wlan0: send auth to 00:3a:9d:b4:54:5a (try 1/3)
> kernel: [19070.144143] wlan0: send auth to 00:3a:9d:b4:54:5a (try 2/3)
> kernel: [19070.248113] wlan0: send auth to 00:3a:9d:b4:54:5a (try 3/3)
> wpa_supplicant[5513]: wlan0: Trying to associate with 00:3a:9d:b4:54:5a (SSID='norbujp' freq=2447 MHz)
> kernel: [19070.286906] wlan0: authenticated
> kernel: [19070.288224] wlan0: associate with 00:3a:9d:b4:54:5a (try 1/3)
> NetworkManager[4878]: <info> (wlan0): supplicant interface state: authenticating -> associating
> kernel: [19070.392185] wlan0: associate with 00:3a:9d:b4:54:5a (try 2/3)
> kernel: [19070.496204] wlan0: associate with 00:3a:9d:b4:54:5a (try 3/3)
> kernel: [19070.600253] wlan0: association with 00:3a:9d:b4:54:5a timed out
> NetworkManager[4878]: <info> (wlan0): supplicant interface state: associating -> disconnected
>
> after several of these I get one of the following:
> kernel: [19073.340075] wlan0: associated
> kernel: [19073.340155] cfg80211: Calling CRDA for country: JP
> NetworkManager[4878]: <info> (wlan0): supplicant interface state: associating -> 4-way handshake
> kernel: [19073.347635] cfg80211: Regulatory domain changed to country: JP
> kernel: [19073.347643] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> kernel: [19073.347648] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> kernel: [19073.347652] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> kernel: [19073.347656] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> ...
> dbus[4074]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
> dbus[4074]: [system] Successfully activated service 'org.freedesktop.PackageKit'
> kernel: [19077.405951] wlan0: deauthenticated from 00:3a:9d:b4:54:5a (Reason: 2)
> wpa_supplicant[5513]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
> wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> kernel: [19077.416143] cfg80211: Calling CRDA to update world regulatory domain
> NetworkManager[4878]: <info> (wlan0): supplicant interface state: 4-way handshake -> disconnected
> NetworkManager[4878]: <info> Activation (wlan0/wireless): disconnected during association, asking for new key.
>
> but it is the correct key! Anyway, then the above game restarts ...
>
> sometimes, after many many many tries, the kernel/NM seems to believe
> it got a connection:
>
> 2) connection seems established according to kernel and NM, but nothing works
> =============================================================================
> it starts as before, but then succeeds - in some way:
> wpa_supplicant[5513]: wlan0: WPA: Key negotiation completed with 00:3a:9d:b4:54:5a [PTK=CCMP GTK=CCMP]
> wpa_supplicant[5513]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:3a:9d:b4:54:5a completed (reauth) [id=0 id_str=]
> NetworkManager[4878]: <info> (wlan0): supplicant interface state: 4-way handshake -> completed
> NetworkManager[4878]: <info> Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'norbujp'.
> NetworkManager[4878]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
> NetworkManager[4878]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
> NetworkManager[4878]: <info> (wlan0): device state change: config -> ip-config (reason 'none') [50 70 0]
> NetworkManager[4878]: <info> Activation (wlan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
> NetworkManager[4878]: <info> dhclient started with pid 30807
> NetworkManager[4878]: nm_utils_do_sysctl: assertion `path != NULL' failed
> NetworkManager[4878]: <info> Activation (wlan0) Beginning IP6 addrconf.
> NetworkManager[4878]: <warn> sysctl: failed to open '/proc/sys/net/ipv6/conf/wlan0/disable_ipv6': (2) No such file or directory
> NetworkManager[4878]: <warn> sysctl: failed to open '/proc/sys/net/ipv6/conf/wlan0/disable_ipv6': (2) No such file or directory
> NetworkManager[4878]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
> dhclient: Internet Systems Consortium DHCP Client 4.2.4
> dhclient: Copyright 2004-2012 Internet Systems Consortium.
> dhclient: All rights reserved.
> dhclient: For info, please visit https://www.isc.org/software/dhcp/
> dhclient:
> NetworkManager[4878]: <info> (wlan0): DHCPv4 state changed nbi -> preinit
> dhclient: Listening on LPF/wlan0/88:9f:fa:f9:07:28
> dhclient: Sending on LPF/wlan0/88:9f:fa:f9:07:28
> dhclient: Sending on Socket/fallback
> dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
> dhclient: DHCPACK from 192.168.0.1
> dhclient: bound to 192.168.0.5 -- renewal in 37312 seconds.
> NetworkManager[4878]: <info> (wlan0): DHCPv4 state changed preinit -> reboot
> NetworkManager[4878]: <info> address 192.168.0.5
> NetworkManager[4878]: <info> prefix 24 (255.255.255.0)
> NetworkManager[4878]: <info> gateway 192.168.0.1
> NetworkManager[4878]: <info> nameserver '192.168.0.1'
> NetworkManager[4878]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
> NetworkManager[4878]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) started...
> NetworkManager[4878]: <info> (wlan0): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
> NetworkManager[4878]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.
> NetworkManager[4878]: <info> (wlan0): device state change: secondaries -> activated (reason 'none') [90 100 0]
> NetworkManager[4878]: <info> Policy set 'Auto norbujp' (wlan0) as default for IPv4 routing and DNS.
> NetworkManager[4878]: <info> Activation (wlan0) successful, device activated.
> dbus[4074]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
> dbus[4074]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
> ntpd[4779]: Listen normally on 5 wlan0 192.168.0.5 UDP 123
> ntpd[4779]: peers refreshed
> nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' took too long; killing it.
> May 8 20:45:22 tofuschnitzel NetworkManager[4878]: <warn> Dispatcher script timed out: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' timed out.
> May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> (wlan0): IP6 addrconf timed out or failed.
> May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
> May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) started...
> May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
>
> But although both kernel as well as NM believe that all is fine:
> $ ifconfig wlan0
> wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28
> inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:205848 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4519 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:44049656 (42.0 MiB) TX bytes:750906 (733.3 KiB)
> $ iwconfig wlan0
> wlan0 IEEE 802.11bgn ESSID:"norbujp"
> Mode:Managed Frequency:2.447 GHz Access Point: 00:3A:9D:B4:54:5A
> Bit Rate=150 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr=2347 B Fragment thr:off
> Power Management:off
> Link Quality=70/70 Signal level=-35 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:6 Missed beacon:0
>
> absolutely nothing works: Examples:
> [~] ping 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
> From 192.168.0.5 icmp_seq=1 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=2 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=5 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=7 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=39 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=40 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=41 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=42 Destination Host Unreachable
> ...
> --- 192.168.0.1 ping statistics ---
> 88 packets transmitted, 0 received, +43 errors, 100% packet loss, time 87233ms pipe 4
>
> absolutely nothing goes out - at least it seems so.
>
>
> Sometimes, though, whoever decided to speak to me, and pings started
> to get returned, but then ...
>
> 3) if connection is working, ping times are crazy and connection breaks down suddenly
> =====================================================================================
>
> pinging my own gateway results in things like:
> 64 bytes from 192.168.0.1: icmp_req=35 ttl=255 time=119395 ms
>
> or
> From 192.168.0.5 icmp_seq=118 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=119 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=120 Destination Host Unreachable
> 64 bytes from 192.168.0.1: icmp_req=31 ttl=255 time=91863 ms
> 64 bytes from 192.168.0.1: icmp_req=32 ttl=255 time=91151 ms
> From 192.168.0.5 icmp_seq=121 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=122 Destination Host Unreachable
>
> or
> [~] ping 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
> 64 bytes from 192.168.0.1: icmp_req=3 ttl=255 time=44447 ms
> 64 bytes from 192.168.0.1: icmp_req=7 ttl=255 time=41123 ms
> 64 bytes from 192.168.0.1: icmp_req=11 ttl=255 time=55627 ms
> 64 bytes from 192.168.0.1: icmp_req=14 ttl=255 time=69027 ms
> 64 bytes from 192.168.0.1: icmp_req=15 ttl=255 time=68046 ms
> 64 bytes from 192.168.0.1: icmp_req=19 ttl=255 time=75636 ms
> 64 bytes from 192.168.0.1: icmp_req=24 ttl=255 time=109967 ms
> ....
>
> big up and down in ping times:
> 4 bytes from 192.168.0.1: icmp_req=442 ttl=255 time=1.51 ms
> 64 bytes from 192.168.0.1: icmp_req=443 ttl=255 time=1.61 ms
> 64 bytes from 192.168.0.1: icmp_req=444 ttl=255 time=2.77 ms
> 64 bytes from 192.168.0.1: icmp_req=445 ttl=255 time=37.0 ms
> 64 bytes from 192.168.0.1: icmp_req=446 ttl=255 time=1.53 ms
> 64 bytes from 192.168.0.1: icmp_req=447 ttl=255 time=469 ms
> 64 bytes from 192.168.0.1: icmp_req=448 ttl=255 time=116 ms
> 64 bytes from 192.168.0.1: icmp_req=449 ttl=255 time=1.73 ms
> 64 bytes from 192.168.0.1: icmp_req=450 ttl=255 time=1.58 ms
> 64 bytes from 192.168.0.1: icmp_req=451 ttl=255 time=6916 ms
> 64 bytes from 192.168.0.1: icmp_req=452 ttl=255 time=6632 ms
> 64 bytes from 192.168.0.1: icmp_req=453 ttl=255 time=5654 ms
> 64 bytes from 192.168.0.1: icmp_req=454 ttl=255 time=4716 ms
> 64 bytes from 192.168.0.1: icmp_req=455 ttl=255 time=3896 ms
> 64 bytes from 192.168.0.1: icmp_req=456 ttl=255 time=2897 ms
> 64 bytes from 192.168.0.1: icmp_req=457 ttl=255 time=1899 ms
> 64 bytes from 192.168.0.1: icmp_req=458 ttl=255 time=901 ms
> 64 bytes from 192.168.0.1: icmp_req=459 ttl=255 time=1.25 ms
> 64 bytes from 192.168.0.1: icmp_req=460 ttl=255 time=116 ms
> 64 bytes from 192.168.0.1: icmp_req=461 ttl=255 time=1.48 ms
> ...
> 64 bytes from 192.168.0.1: icmp_req=483 ttl=255 time=1.24 ms
> 64 bytes from 192.168.0.1: icmp_req=485 ttl=255 time=10910 ms
> 64 bytes from 192.168.0.1: icmp_req=486 ttl=255 time=9913 ms
> 64 bytes from 192.168.0.1: icmp_req=487 ttl=255 time=8913 ms
> 64 bytes from 192.168.0.1: icmp_req=488 ttl=255 time=7913 ms
> 64 bytes from 192.168.0.1: icmp_req=489 ttl=255 time=6913 ms
> ...
> 64 bytes from 192.168.0.1: icmp_req=494 ttl=255 time=1915 ms
> 64 bytes from 192.168.0.1: icmp_req=495 ttl=255 time=915 ms
> From 192.168.0.5 icmp_seq=530 Destination Host Unreachable
> From 192.168.0.5 icmp_seq=531 Destination Host Unreachable
> ...
> From 192.168.0.5 icmp_seq=581 Destination Host Unreachable
> 64 bytes from 192.168.0.1: icmp_req=497 ttl=255 time=87064 ms
> From 192.168.0.5 icmp_seq=582 Destination Host Unreachable
> ...
> From 192.168.0.5 icmp_seq=598 Destination Host Unreachable
> 64 bytes from 192.168.0.1: icmp_req=498 ttl=255 time=105208 ms
> ping: sendmsg: No buffer space available
> From 192.168.0.5 icmp_seq=623 Destination Host Unreachable
> ...
>
>
> Looking into the reasons why disconnects happen I see:
> [~] grep reason= /var/log/syslog
> May 8 20:43:57 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:44:04 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:45:02 tofuschnitzel kernel: [18472.914329] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
> May 8 20:45:02 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> May 8 20:47:34 tofuschnitzel kernel: [18624.597387] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
> May 8 20:47:34 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> May 8 20:48:27 tofuschnitzel kernel: [18677.928400] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
> May 8 20:48:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> May 8 20:48:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:48:52 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:49:15 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:49:25 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:49:41 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:49:50 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:49:57 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:53:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:53:30 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:53:51 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:54:01 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:54:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:54:45 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:55:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 20:55:36 tofuschnitzel kernel: [19106.844710] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
> May 8 20:55:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=3
> May 8 21:10:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
> May 8 21:10:58 tofuschnitzel kernel: [20029.040231] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
> May 8 21:10:58 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
> May 8 21:23:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
>
>
> My feeling is also that things like
> wpa_supplicant[5513]: wlan0: WPA: Key negotiation completed with 00:3a:9d:b4:54:5a [PTK=CCMP GTK=CCMP]
> have a strong effect on the actual connection.
>
>
> 4) conclusion
> =============
>
> in the current state, that is release 3.9.0, but the same happened
> in earlier kernels, this driver and/or NM is completely useless
> at times. At times it just works, at times it does nothing.
> In this case, now the 5th day in series ...
>
>
> Norbert
>
> ------------------------------------------------------------------------
> PREINING, Norbert http://www.preining.info
> JAIST, Japan TeX Live & Debian Developer
> DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
> ------------------------------------------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Oleksij
^ permalink raw reply
* RTL driver for RTL8191SEvB and/or wpa-supplicant really broken at times
From: Norbert Preining @ 2013-05-09 11:56 UTC (permalink / raw)
To: linux-wireless, linux-kernel, hostap
Dear all,
here is a short status report on my experiences with:
kernel 3.9.0
wpa_supplicant 1.0
hardware RTL191SEvB
Debian/sid
Short summary: broken to the degree that internet connection is impossible
Sorry for the long mail, I tried to reduce to the essentials only.
Contents:
=========
0) hardware and software description
1) during connection permanent break off
2) connection seems established according to kernel and NM, but nothing works
3) if connection is working, ping times are crazy and connection breaks down suddenly
4) conclusion
0) hardware and software description
====================================
Hardware:
Lenovo Thinkpad Edge
WLAN:
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device e020
Flags: bus master, fast devsel, latency 0, IRQ 17
I/O ports at 2000 [size=256]
Memory at f0500000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Legacy Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 88-55-22-fe-ff-4c-e0-00
Kernel driver in use: rtl8192se
Debian unstable up to date
kernel 3.9.0
# wpa_supplicant -v
wpa_supplicant v1.0
Copyright (c) 2003-2012, Jouni Malinen <j@w1.fi> and contributors
Debian version: 1.0-3+b2
Please note: during all the following experiments at times
two other computers (iPhone, WinXP) very connected without
any problems (of course on different IPs).
ad 1) during connection permanent break off
============================================
typical dmesg output:
many times:
May 8 20:54:59 tofuschnitzel NetworkManager[4878]: <info> (wlan0): supplicant interface state: disconnected -> scanning
May 8 20:54:59 tofuschnitzel wpa_supplicant[5513]: wlan0: SME: Trying to authenticate with 00:3a:9d:b4:54:5a (SSID='norbujp' fr
eq=2447 MHz)
kernel: [19070.021021] wlan0: authenticate with 00:3a:9d:b4:54:5a
NetworkManager[4878]: <info> (wlan0): supplicant interface state: scanning -> authenticating
kernel: [19070.040313] wlan0: send auth to 00:3a:9d:b4:54:5a (try 1/3)
kernel: [19070.144143] wlan0: send auth to 00:3a:9d:b4:54:5a (try 2/3)
kernel: [19070.248113] wlan0: send auth to 00:3a:9d:b4:54:5a (try 3/3)
wpa_supplicant[5513]: wlan0: Trying to associate with 00:3a:9d:b4:54:5a (SSID='norbujp' freq=2447 MHz)
kernel: [19070.286906] wlan0: authenticated
kernel: [19070.288224] wlan0: associate with 00:3a:9d:b4:54:5a (try 1/3)
NetworkManager[4878]: <info> (wlan0): supplicant interface state: authenticating -> associating
kernel: [19070.392185] wlan0: associate with 00:3a:9d:b4:54:5a (try 2/3)
kernel: [19070.496204] wlan0: associate with 00:3a:9d:b4:54:5a (try 3/3)
kernel: [19070.600253] wlan0: association with 00:3a:9d:b4:54:5a timed out
NetworkManager[4878]: <info> (wlan0): supplicant interface state: associating -> disconnected
after several of these I get one of the following:
kernel: [19073.340075] wlan0: associated
kernel: [19073.340155] cfg80211: Calling CRDA for country: JP
NetworkManager[4878]: <info> (wlan0): supplicant interface state: associating -> 4-way handshake
kernel: [19073.347635] cfg80211: Regulatory domain changed to country: JP
kernel: [19073.347643] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [19073.347648] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [19073.347652] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
kernel: [19073.347656] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm)
...
dbus[4074]: [system] Activating service name='org.freedesktop.PackageKit' (using servicehelper)
dbus[4074]: [system] Successfully activated service 'org.freedesktop.PackageKit'
kernel: [19077.405951] wlan0: deauthenticated from 00:3a:9d:b4:54:5a (Reason: 2)
wpa_supplicant[5513]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
kernel: [19077.416143] cfg80211: Calling CRDA to update world regulatory domain
NetworkManager[4878]: <info> (wlan0): supplicant interface state: 4-way handshake -> disconnected
NetworkManager[4878]: <info> Activation (wlan0/wireless): disconnected during association, asking for new key.
but it is the correct key! Anyway, then the above game restarts ...
sometimes, after many many many tries, the kernel/NM seems to believe
it got a connection:
2) connection seems established according to kernel and NM, but nothing works
=============================================================================
it starts as before, but then succeeds - in some way:
wpa_supplicant[5513]: wlan0: WPA: Key negotiation completed with 00:3a:9d:b4:54:5a [PTK=CCMP GTK=CCMP]
wpa_supplicant[5513]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:3a:9d:b4:54:5a completed (reauth) [id=0 id_str=]
NetworkManager[4878]: <info> (wlan0): supplicant interface state: 4-way handshake -> completed
NetworkManager[4878]: <info> Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'norbujp'.
NetworkManager[4878]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[4878]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[4878]: <info> (wlan0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[4878]: <info> Activation (wlan0) Beginning DHCPv4 transaction (timeout in 45 seconds)
NetworkManager[4878]: <info> dhclient started with pid 30807
NetworkManager[4878]: nm_utils_do_sysctl: assertion `path != NULL' failed
NetworkManager[4878]: <info> Activation (wlan0) Beginning IP6 addrconf.
NetworkManager[4878]: <warn> sysctl: failed to open '/proc/sys/net/ipv6/conf/wlan0/disable_ipv6': (2) No such file or directory
NetworkManager[4878]: <warn> sysctl: failed to open '/proc/sys/net/ipv6/conf/wlan0/disable_ipv6': (2) No such file or directory
NetworkManager[4878]: <info> Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete.
dhclient: Internet Systems Consortium DHCP Client 4.2.4
dhclient: Copyright 2004-2012 Internet Systems Consortium.
dhclient: All rights reserved.
dhclient: For info, please visit https://www.isc.org/software/dhcp/
dhclient:
NetworkManager[4878]: <info> (wlan0): DHCPv4 state changed nbi -> preinit
dhclient: Listening on LPF/wlan0/88:9f:fa:f9:07:28
dhclient: Sending on LPF/wlan0/88:9f:fa:f9:07:28
dhclient: Sending on Socket/fallback
dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
dhclient: DHCPACK from 192.168.0.1
dhclient: bound to 192.168.0.5 -- renewal in 37312 seconds.
NetworkManager[4878]: <info> (wlan0): DHCPv4 state changed preinit -> reboot
NetworkManager[4878]: <info> address 192.168.0.5
NetworkManager[4878]: <info> prefix 24 (255.255.255.0)
NetworkManager[4878]: <info> gateway 192.168.0.1
NetworkManager[4878]: <info> nameserver '192.168.0.1'
NetworkManager[4878]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[4878]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[4878]: <info> (wlan0): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
NetworkManager[4878]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[4878]: <info> (wlan0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[4878]: <info> Policy set 'Auto norbujp' (wlan0) as default for IPv4 routing and DNS.
NetworkManager[4878]: <info> Activation (wlan0) successful, device activated.
dbus[4074]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
dbus[4074]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
ntpd[4779]: Listen normally on 5 wlan0 192.168.0.5 UDP 123
ntpd[4779]: peers refreshed
nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' took too long; killing it.
May 8 20:45:22 tofuschnitzel NetworkManager[4878]: <warn> Dispatcher script timed out: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' timed out.
May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> (wlan0): IP6 addrconf timed out or failed.
May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) started...
May 8 20:45:37 tofuschnitzel NetworkManager[4878]: <info> Activation (wlan0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
But although both kernel as well as NM believe that all is fine:
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 88:9f:fa:f9:07:28
inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:205848 errors:0 dropped:0 overruns:0 frame:0
TX packets:4519 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44049656 (42.0 MiB) TX bytes:750906 (733.3 KiB)
$ iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:"norbujp"
Mode:Managed Frequency:2.447 GHz Access Point: 00:3A:9D:B4:54:5A
Bit Rate=150 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-35 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:6 Missed beacon:0
absolutely nothing works: Examples:
[~] ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>From 192.168.0.5 icmp_seq=1 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=2 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=5 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=7 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=39 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=40 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=41 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=42 Destination Host Unreachable
...
--- 192.168.0.1 ping statistics ---
88 packets transmitted, 0 received, +43 errors, 100% packet loss, time 87233ms pipe 4
absolutely nothing goes out - at least it seems so.
Sometimes, though, whoever decided to speak to me, and pings started
to get returned, but then ...
3) if connection is working, ping times are crazy and connection breaks down suddenly
=====================================================================================
pinging my own gateway results in things like:
64 bytes from 192.168.0.1: icmp_req=35 ttl=255 time=119395 ms
or
>From 192.168.0.5 icmp_seq=118 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=119 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=120 Destination Host Unreachable
64 bytes from 192.168.0.1: icmp_req=31 ttl=255 time=91863 ms
64 bytes from 192.168.0.1: icmp_req=32 ttl=255 time=91151 ms
>From 192.168.0.5 icmp_seq=121 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=122 Destination Host Unreachable
or
[~] ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=3 ttl=255 time=44447 ms
64 bytes from 192.168.0.1: icmp_req=7 ttl=255 time=41123 ms
64 bytes from 192.168.0.1: icmp_req=11 ttl=255 time=55627 ms
64 bytes from 192.168.0.1: icmp_req=14 ttl=255 time=69027 ms
64 bytes from 192.168.0.1: icmp_req=15 ttl=255 time=68046 ms
64 bytes from 192.168.0.1: icmp_req=19 ttl=255 time=75636 ms
64 bytes from 192.168.0.1: icmp_req=24 ttl=255 time=109967 ms
....
big up and down in ping times:
4 bytes from 192.168.0.1: icmp_req=442 ttl=255 time=1.51 ms
64 bytes from 192.168.0.1: icmp_req=443 ttl=255 time=1.61 ms
64 bytes from 192.168.0.1: icmp_req=444 ttl=255 time=2.77 ms
64 bytes from 192.168.0.1: icmp_req=445 ttl=255 time=37.0 ms
64 bytes from 192.168.0.1: icmp_req=446 ttl=255 time=1.53 ms
64 bytes from 192.168.0.1: icmp_req=447 ttl=255 time=469 ms
64 bytes from 192.168.0.1: icmp_req=448 ttl=255 time=116 ms
64 bytes from 192.168.0.1: icmp_req=449 ttl=255 time=1.73 ms
64 bytes from 192.168.0.1: icmp_req=450 ttl=255 time=1.58 ms
64 bytes from 192.168.0.1: icmp_req=451 ttl=255 time=6916 ms
64 bytes from 192.168.0.1: icmp_req=452 ttl=255 time=6632 ms
64 bytes from 192.168.0.1: icmp_req=453 ttl=255 time=5654 ms
64 bytes from 192.168.0.1: icmp_req=454 ttl=255 time=4716 ms
64 bytes from 192.168.0.1: icmp_req=455 ttl=255 time=3896 ms
64 bytes from 192.168.0.1: icmp_req=456 ttl=255 time=2897 ms
64 bytes from 192.168.0.1: icmp_req=457 ttl=255 time=1899 ms
64 bytes from 192.168.0.1: icmp_req=458 ttl=255 time=901 ms
64 bytes from 192.168.0.1: icmp_req=459 ttl=255 time=1.25 ms
64 bytes from 192.168.0.1: icmp_req=460 ttl=255 time=116 ms
64 bytes from 192.168.0.1: icmp_req=461 ttl=255 time=1.48 ms
...
64 bytes from 192.168.0.1: icmp_req=483 ttl=255 time=1.24 ms
64 bytes from 192.168.0.1: icmp_req=485 ttl=255 time=10910 ms
64 bytes from 192.168.0.1: icmp_req=486 ttl=255 time=9913 ms
64 bytes from 192.168.0.1: icmp_req=487 ttl=255 time=8913 ms
64 bytes from 192.168.0.1: icmp_req=488 ttl=255 time=7913 ms
64 bytes from 192.168.0.1: icmp_req=489 ttl=255 time=6913 ms
...
64 bytes from 192.168.0.1: icmp_req=494 ttl=255 time=1915 ms
64 bytes from 192.168.0.1: icmp_req=495 ttl=255 time=915 ms
>From 192.168.0.5 icmp_seq=530 Destination Host Unreachable
>From 192.168.0.5 icmp_seq=531 Destination Host Unreachable
...
>From 192.168.0.5 icmp_seq=581 Destination Host Unreachable
64 bytes from 192.168.0.1: icmp_req=497 ttl=255 time=87064 ms
>From 192.168.0.5 icmp_seq=582 Destination Host Unreachable
...
>From 192.168.0.5 icmp_seq=598 Destination Host Unreachable
64 bytes from 192.168.0.1: icmp_req=498 ttl=255 time=105208 ms
ping: sendmsg: No buffer space available
>From 192.168.0.5 icmp_seq=623 Destination Host Unreachable
...
Looking into the reasons why disconnects happen I see:
[~] grep reason= /var/log/syslog
May 8 20:43:57 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:44:04 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:45:02 tofuschnitzel kernel: [18472.914329] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
May 8 20:45:02 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
May 8 20:47:34 tofuschnitzel kernel: [18624.597387] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
May 8 20:47:34 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
May 8 20:48:27 tofuschnitzel kernel: [18677.928400] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
May 8 20:48:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
May 8 20:48:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:48:52 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:49:15 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:49:25 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:49:41 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:49:50 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:49:57 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:53:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:53:30 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:53:51 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:54:01 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:54:27 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:54:45 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:55:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 20:55:36 tofuschnitzel kernel: [19106.844710] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
May 8 20:55:36 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=3
May 8 21:10:07 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
May 8 21:10:58 tofuschnitzel kernel: [20029.040231] wlan0: deauthenticating from 00:3a:9d:b4:54:5a by local choice (reason=3)
May 8 21:10:58 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3
May 8 21:23:20 tofuschnitzel wpa_supplicant[5513]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:3a:9d:b4:54:5a reason=2
My feeling is also that things like
wpa_supplicant[5513]: wlan0: WPA: Key negotiation completed with 00:3a:9d:b4:54:5a [PTK=CCMP GTK=CCMP]
have a strong effect on the actual connection.
4) conclusion
=============
in the current state, that is release 3.9.0, but the same happened
in earlier kernels, this driver and/or NM is completely useless
at times. At times it just works, at times it does nothing.
In this case, now the 5th day in series ...
Norbert
------------------------------------------------------------------------
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
^ permalink raw reply
* Standardisation - adding 2 bit STBC and Ness to MCS (repost 3)
From: Oleksij Rempel @ 2013-05-09 9:55 UTC (permalink / raw)
To: radiotap, simon, ath9k-devel@lists.ath9k.org, linux-wireless,
johannes
Hallo all,
this is probably third repost of this standardisation request.
History:
- 11 May 2012. initial request made by Simon Barber.
http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
- 1 Okt 2012, Wireshark support this fields. Patches provided by
Wojciech Dubowik.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6720
- 1 Nov 2012. patches for intel adapters, ieee80211 and wireshark was
uploaded by Simon.
http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness?action=AttachFile
- 17 Nov 2012. Simon posted new thread as suggested Johannes Berg.
- 1 May 2013. I restarted this discussion.
link to initial discussion:
http://comments.gmane.org/gmane.network.wireless.radiotap/302
As you can see it is already long standing issue...
Now to proposal mad by Simon. Please add comments like: agreed or not
agreed and why.
======================== Proposal ===========================
This proposal is to extend the current MCS radiotap header to carry STBC
and Ness information. This information is carried in the 802.11 HT-SIG
field that carries all the other fields currently in this radiotap MCS
header. Both STBC and Ness fields are needed alongside the others to
calculate the length (duration in time) of a frame. This proposal adds 3
bits to the known field and the flags field. See below for proposed text.
= MCS =
Bit Number:: 19
Structure:: u8 known, u8 flags, u8 mcs
Required Alignment:: 1
The `mcs` field indicates the MCS rate index as in
[[http://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates|IEEE_802.11n-2009]]
The `known` field indicates which information is known:
||'''flag'''||'''definition'''||
|| `0x01` || bandwidth ||
|| `0x02` || MCS index known (in `mcs` part of the field) ||
|| `0x04` || guard interval ||
|| `0x08` || HT format ||
|| `0x10` || FEC type ||
|| `0x20` || STBC known ||
|| `0x40` || Ness known (Number of extension spatial streams) ||
|| `0x80` || Ness data - bit 1 (MSB) of Number of extension spatial
streams ||
The `flags` field is any combination of the following:
|| '''flag''' || '''definition''' ||
|| `0x03` || bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U ||
|| `0x04` || guard interval - 0: long GI, 1: short GI ||
|| `0x08` || HT format - 0: mixed, 1: greenfield ||
|| `0x10` || FEC type - 0: BCC, 1: LDPC ||
|| `0x60` || Number of STBC streams ||
|| `0x80` || Ness - bit 0 (LSB) of Number of extension spatial streams |
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH 08/21] iwlegacy: remove inline marking of EXPORT_SYMBOL functions
From: Denis Efremov @ 2013-05-09 9:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Denis Efremov, John W. Linville, linux-wireless, netdev,
linux-kernel, trivial, ldv-project
In-Reply-To: <1368086241-9357-1-git-send-email-yefremov.denis@gmail.com>
EXPORT_SYMBOL and inline directives are contradictory to each other.
The patch fixes this inconsistency.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
drivers/net/wireless/iwlegacy/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index 592d0aa..e9a3cbc 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -1423,7 +1423,7 @@ il_setup_rx_scan_handlers(struct il_priv *il)
}
EXPORT_SYMBOL(il_setup_rx_scan_handlers);
-inline u16
+u16
il_get_active_dwell_time(struct il_priv *il, enum ieee80211_band band,
u8 n_probes)
{
--
1.8.1.4
^ permalink raw reply related
* [PATCH 04/21] NFC: remove inline marking of EXPORT_SYMBOL functions
From: Denis Efremov @ 2013-05-09 7:58 UTC (permalink / raw)
To: Lauro Ramos Venancio
Cc: Denis Efremov, Aloisio Almeida Jr, Samuel Ortiz, linux-wireless,
linux-kernel, trivial, ldv-project
In-Reply-To: <1368086241-9357-1-git-send-email-yefremov.denis@gmail.com>
EXPORT_SYMBOL and inline directives are contradictory to each other.
The patch fixes this inconsistency.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
net/nfc/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfc/core.c b/net/nfc/core.c
index 40d2527..1c4b513 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -701,7 +701,7 @@ int nfc_target_lost(struct nfc_dev *dev, u32 target_idx)
}
EXPORT_SYMBOL(nfc_target_lost);
-inline void nfc_driver_failure(struct nfc_dev *dev, int err)
+void nfc_driver_failure(struct nfc_dev *dev, int err)
{
nfc_targets_found(dev, NULL, 0);
}
--
1.8.1.4
^ permalink raw reply related
* Re: atheros AR5B22, using ath9k, can't switch between inscure and WEP/WPA
From: Adrian Chadd @ 2013-05-09 5:57 UTC (permalink / raw)
To: Wally, ath9k-devel; +Cc: linux-wireless
In-Reply-To: <1368062883.17674.24.camel@bigdick-desktop>
Ah, right. An AR9462.
Odd. It should be fine. I wonder if the same behaviour exists for
other NICs in that general family (AR9380, AR9485.)
Some code has shown up recently in the reference driver that does
funny things with the keycache as a work-around for some bug. I don't
know what the bug is yet though.
I'll go check it out and get back to the list.
Adrian
On 8 May 2013 18:28, Wally <wally.yeh@a-trust.com.tw> wrote:
> Hi, Adrian:
> Here is it's wiki:http://wikidevi.com/wiki/Atheros_AR5B22
>
> As I modprobe ath9k. dmesg give these messages:
> ----------------------------------------------------------------------
> [49603.281250] compat-drivers backport release:
> compat-drivers-2013-03-28
> [49603.281250] Backport based on linux-next.git next-20130328
> [49603.281250] compat.git: linux-next.git
> [49603.367187] cfg80211: Calling CRDA to update world regulatory domain
> [49603.609375] ath: EEPROM regdomain: 0x60
> [49603.609375] ath: EEPROM indicates we should expect a direct regpair
> map
> [49603.609375] ath: Country alpha2 being used: 00
> [49603.609375] ath: Regpair used: 0x60
> [49603.609375] ieee80211 phy0: Selected rate control algorithm
> 'ath9k_rate_control'
> [49603.609375] Registered led device: ath9k-phy0
> [49603.609375] ieee80211 phy0: Atheros AR9462 Rev:2 mem=0xe1300000,
> irq=48
> -----------------------------------------------------------------------
> so it seems ath9k probe this chip as Atheros AR9462. do you have
> some idea?
>
> Wally
>
>
>
> 於 三，2013-05-08 於 15:46 -0700，Adrian Chadd 提到：
>> .. AR5B22? Which chip does that probe as?
>>
>>
>>
>> Adrian
>>
>>
>> On 8 May 2013 05:25, Wally <wally.yeh@a-trust.com.tw> wrote:
>> > Hi, guys:
>> > Recently I got a atheros mini-PCIE wifi module AR5B22, so I download
>> > the latest version of compat-driver(compat-drivers-2013-03-28.tar.gz),
>> > and build it for armel on my arm board, it works great but with one
>> > little problem:
>> >
>> > If I connect to an inscure AP then change to a WEP/WPA AP, I can't
>> > connect the inscure one again, I have to run "modprobe -r ath9k;
>> > modprobe ath9k" to connect the inscure AP.
>> >
>> > I think this may be a bug in the ath9k driver, I also search this
>> > bug on web but without an answer, so I send this letter for help.
>> >
>> > Any advice would be grateful, thanks.
>> >
>> > Wally
>> >
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH] ath9k: Disable spectral scan code to fix crash on rmmod.
From: Sujith Manoharan @ 2013-05-09 5:37 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1368050908-7554-1-git-send-email-greearb@candelatech.com>
greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> With CONFIG_ATH9K_DEBUGFS enabled, and slub memory poisoning
> enabled, I see this crash on rmmod of ath9k. I'm not sure how
> to fix this properly, but in the meantime, this patch to disable
> the spectral scan code works around the problem for me.
>
> With memory poisoning and the verify_mem_not_deleted code
> below added, the crash looks as follows... The dentry
> is not *always* freed at this point, probably because rcu
> callbacks haven't completed. You still get a crash soon
> after, however.
The relay file should probably be closed before calling ieee80211_unregister_hw().
The ath9k debugfs directory is created inside the phy#/ directory and that would
get cleaned up when the wiphy is unregistered.
Does this help ?
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 4101c4a..cecbe1f 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1684,6 +1684,14 @@ void ath9k_get_et_stats(struct ieee80211_hw *hw,
WARN_ON(i != ATH9K_SSTATS_LEN);
}
+void ath9k_deinit_debug(struct ath_softc *sc)
+{
+ if (config_enabled(CONFIG_ATH9K_DEBUGFS) && sc->rfs_chan_spec_scan) {
+ relay_close(sc->rfs_chan_spec_scan);
+ sc->rfs_chan_spec_scan = NULL;
+ }
+}
+
int ath9k_init_debug(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
index 62da19c..223418d 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -297,6 +297,7 @@ struct ath9k_debug {
};
int ath9k_init_debug(struct ath_hw *ah);
+void ath9k_deinit_debug(struct ath_softc *sc);
void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status);
void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
@@ -332,6 +333,10 @@ static inline int ath9k_init_debug(struct ath_hw *ah)
return 0;
}
+static inline void ath9k_deinit_debug(struct ath_softc *sc)
+{
+}
+
static inline void ath_debug_stat_interrupt(struct ath_softc *sc,
enum ath9k_int status)
{
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index c7b888f..c0aa4ff 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -903,7 +903,7 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc,
if (!ath_is_world_regd(reg)) {
error = regulatory_hint(hw->wiphy, reg->alpha2);
if (error)
- goto unregister;
+ goto debug_cleanup;
}
ath_init_leds(sc);
@@ -911,6 +911,8 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc,
return 0;
+debug_cleanup:
+ ath9k_deinit_debug(sc);
unregister:
ieee80211_unregister_hw(hw);
rx_cleanup:
@@ -939,11 +941,6 @@ static void ath9k_deinit_softc(struct ath_softc *sc)
sc->dfs_detector->exit(sc->dfs_detector);
ath9k_eeprom_release(sc);
-
- if (config_enabled(CONFIG_ATH9K_DEBUGFS) && sc->rfs_chan_spec_scan) {
- relay_close(sc->rfs_chan_spec_scan);
- sc->rfs_chan_spec_scan = NULL;
- }
}
void ath9k_deinit_device(struct ath_softc *sc)
@@ -957,6 +954,7 @@ void ath9k_deinit_device(struct ath_softc *sc)
ath9k_ps_restore(sc);
+ ath9k_deinit_debug(sc);
ieee80211_unregister_hw(hw);
ath_rx_cleanup(sc);
ath9k_deinit_softc(sc);
^ permalink raw reply related
* Re: Fun with QoS in AP mode.
From: Sujith Manoharan @ 2013-05-09 5:13 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <518A6C21.5070408@candelatech.com>
Ben Greear wrote:
> Yes, both AP and Station machine are ath9k, 3.9.0+, etc....
>
> Basically identicaly hardware and software loads..just one is acting as AP
> and one as station(s) in this scenario.
Works okay here.
STA1 <-> AP <-> STA2 (ath9k stations, ath9k AP running OpenWrt trunk).
Voice traffic from STA1 to STA2 and in the other direction are marked
as VO in the AP.
root@OpenWrt:/# cat /sys/kernel/debug/ieee80211/phy1/ath9k/xmit
BE BK VI VO
MPDUs Queued: 411 0 0 1780727
MPDUs Completed: 411 0 0 1780659
MPDUs XRetried: 0 0 0 2
Aggregates: 111093 0 0 0
AMPDUs Queued HW: 21843 0 0 0
AMPDUs Queued SW: 2297530 0 0 0
AMPDUs Completed: 2319373 0 0 0
AMPDUs Retried: 28995 0 0 0
AMPDUs XRetried: 0 0 0 0
TXERR Filtered: 0 0 0 217
FIFO Underrun: 0 0 0 0
TXOP Exceeded: 0 0 0 0
TXTIMER Expiry: 0 0 0 0
DESC CFG Error: 0 0 0 0
DATA Underrun: 0 0 0 0
DELIM Underrun: 0 0 0 0
TX-Pkts-All: 2319784 0 0 1780661
TX-Bytes-All: 455830482 0 02734843421
HW-put-tx-buf: 153471 0 0 263350
HW-tx-start: 0 0 0 0
HW-tx-proc-desc: 153681 0 0 1780661
TX-Failed: 0 0 0 0
Sujith
^ permalink raw reply
* Re: atheros AR5B22, using ath9k, can't switch between inscure and WEP/WPA
From: Sujith Manoharan @ 2013-05-09 4:24 UTC (permalink / raw)
To: Wally; +Cc: linux-wireless
In-Reply-To: <1368015905.17674.11.camel@bigdick-desktop>
Wally wrote:
> Recently I got a atheros mini-PCIE wifi module AR5B22, so I download
> the latest version of compat-driver(compat-drivers-2013-03-28.tar.gz),
> and build it for armel on my arm board, it works great but with one
> little problem:
>
> If I connect to an inscure AP then change to a WEP/WPA AP, I can't
> connect the inscure one again, I have to run "modprobe -r ath9k;
> modprobe ath9k" to connect the inscure AP.
>
> I think this may be a bug in the ath9k driver, I also search this
> bug on web but without an answer, so I send this letter for help.
What commands do you use to connect to the APs ? Also, can you post the
kernel log / wpa_supplicant log when the issue happens ?
Sujith
^ permalink raw reply
* Re: [PATCH 1/3] wil6210: TCP/UDP checksum offloading support
From: Julian Calaby @ 2013-05-09 1:37 UTC (permalink / raw)
To: wilocity.git
Cc: Vladimir Kondratiev, linux-wireless, wil6210, Erez Kirshenbaum
In-Reply-To: <1368001971-11551-1-git-send-email-wilocity.git@gmail.com>
Hi Erez,
Just a couple of notes on patch authorship and email addresses.
On Wed, May 8, 2013 at 6:32 PM, <wilocity.git@gmail.com> wrote:
> From: Erez Kirshenbaum <erezk@wilocity.com>
In the other two patches, your email address is "erezk@wilocitycom" -
note the missing "."
> Add TCP/UDP checksum hardware offloading, configure hw and set the corresponding offloading bits in the
> DMA descriptors.
>
> Signed-off-by: Erez Kirshenbaum <erezk@wilocity.com>
> Signed-off-by: Wilocity Git <wilocity.git@gmail.com>
I assume you've read Documentation/SubmittingPatches, particularly the
section about signing your changes:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n297
The names in Signed-off-bys are expected to be real people or
permanent email addresses for teams. Given the name of the gmail
account, this appears to be just a email address you're sending
patches through. Is it monitored? Can you not send patches directly
from your "real" account?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: atheros AR5B22, using ath9k, can't switch between inscure and WEP/WPA
From: Wally @ 2013-05-09 1:28 UTC (permalink / raw)
To: Adrian Chadd; +Cc: linux-wireless
In-Reply-To: <CAJ-Vmonq1YN2NoWFMXtqVYr16eTD=mZ0n74CCEhMHK=05M1xyQ@mail.gmail.com>
Hi, Adrian:
Here is it's wiki:http://wikidevi.com/wiki/Atheros_AR5B22
As I modprobe ath9k. dmesg give these messages:
----------------------------------------------------------------------
[49603.281250] compat-drivers backport release:
compat-drivers-2013-03-28
[49603.281250] Backport based on linux-next.git next-20130328
[49603.281250] compat.git: linux-next.git
[49603.367187] cfg80211: Calling CRDA to update world regulatory domain
[49603.609375] ath: EEPROM regdomain: 0x60
[49603.609375] ath: EEPROM indicates we should expect a direct regpair
map
[49603.609375] ath: Country alpha2 being used: 00
[49603.609375] ath: Regpair used: 0x60
[49603.609375] ieee80211 phy0: Selected rate control algorithm
'ath9k_rate_control'
[49603.609375] Registered led device: ath9k-phy0
[49603.609375] ieee80211 phy0: Atheros AR9462 Rev:2 mem=0xe1300000,
irq=48
-----------------------------------------------------------------------
so it seems ath9k probe this chip as Atheros AR9462. do you have
some idea?
Wally
於 三，2013-05-08 於 15:46 -0700，Adrian Chadd 提到：
> .. AR5B22? Which chip does that probe as?
>
>
>
> Adrian
>
>
> On 8 May 2013 05:25, Wally <wally.yeh@a-trust.com.tw> wrote:
> > Hi, guys:
> > Recently I got a atheros mini-PCIE wifi module AR5B22, so I download
> > the latest version of compat-driver(compat-drivers-2013-03-28.tar.gz),
> > and build it for armel on my arm board, it works great but with one
> > little problem:
> >
> > If I connect to an inscure AP then change to a WEP/WPA AP, I can't
> > connect the inscure one again, I have to run "modprobe -r ath9k;
> > modprobe ath9k" to connect the inscure AP.
> >
> > I think this may be a bug in the ath9k driver, I also search this
> > bug on web but without an answer, so I send this letter for help.
> >
> > Any advice would be grateful, thanks.
> >
> > Wally
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox