* [PATCH v2 2/6] mac80211: add HT IEs to mesh frames
From: Thomas Pedersen @ 2011-10-20 18:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319135679-6740-1-git-send-email-thomas@cozybit.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
---
net/mac80211/mesh.c | 43 +++++++++++++++++++++++++++++++++++++++++++
net/mac80211/mesh.h | 4 ++++
net/mac80211/mesh_plink.c | 9 +++++++++
net/mac80211/tx.c | 4 ++++
4 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index a7078fd..2dc76a9 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -341,6 +341,49 @@ int mesh_add_ds_params_ie(struct sk_buff *skb,
return 0;
}
+int mesh_add_ht_cap_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_supported_band *sband;
+ u8 *pos;
+
+ sband = local->hw.wiphy->bands[local->oper_channel->band];
+ if (!sband->ht_cap.ht_supported ||
+ local->_oper_channel_type == NL80211_CHAN_NO_HT)
+ return 0;
+
+ if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_cap))
+ return -ENOMEM;
+
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_cap));
+ ieee80211_ie_build_ht_cap(pos, sband, sband->ht_cap.cap);
+
+ return 0;
+}
+
+int mesh_add_ht_info_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_channel *channel = local->oper_channel;
+ enum nl80211_channel_type channel_type = local->_oper_channel_type;
+ struct ieee80211_supported_band *sband =
+ local->hw.wiphy->bands[channel->band];
+ struct ieee80211_sta_ht_cap *ht_cap = &sband->ht_cap;
+ u8 *pos;
+
+ if (!ht_cap->ht_supported || channel_type == NL80211_CHAN_NO_HT)
+ return 0;
+
+ if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_ht_info))
+ return -ENOMEM;
+
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_ht_info));
+ ieee80211_ie_build_ht_info(pos, ht_cap, channel, channel_type);
+
+ return 0;
+}
static void ieee80211_mesh_path_timer(unsigned long data)
{
struct ieee80211_sub_if_data *sdata =
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 8c00e2d..0f2c4e6 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -212,6 +212,10 @@ int mesh_add_vendor_ies(struct sk_buff *skb,
struct ieee80211_sub_if_data *sdata);
int mesh_add_ds_params_ie(struct sk_buff *skb,
struct ieee80211_sub_if_data *sdata);
+int mesh_add_ht_cap_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata);
+int mesh_add_ht_info_ie(struct sk_buff *skb,
+ struct ieee80211_sub_if_data *sdata);
void mesh_rmc_free(struct ieee80211_sub_if_data *sdata);
int mesh_rmc_init(struct ieee80211_sub_if_data *sdata);
void ieee80211s_init(void);
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 42a0544..bbfbd45 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -168,6 +168,8 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
2 + (IEEE80211_MAX_SUPP_RATES - 8) +
2 + sdata->u.mesh.mesh_id_len +
2 + sizeof(struct ieee80211_meshconf_ie) +
+ 2 + sizeof(struct ieee80211_ht_cap) +
+ 2 + sizeof(struct ieee80211_ht_info) +
2 + 8 + /* peering IE */
sdata->u.mesh.ie_len);
if (!skb)
@@ -244,6 +246,13 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
memcpy(pos, &reason, 2);
pos += 2;
}
+
+ if (action != WLAN_SP_MESH_PEERING_CLOSE) {
+ if (mesh_add_ht_cap_ie(skb, sdata) ||
+ mesh_add_ht_info_ie(skb, sdata))
+ return -1;
+ }
+
if (mesh_add_vendor_ies(skb, sdata))
return -1;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f28a920..faca189 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2290,6 +2290,8 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
2 + 8 + /* supported rates */
2 + 3 + /* DS params */
2 + (IEEE80211_MAX_SUPP_RATES - 8) +
+ 2 + sizeof(struct ieee80211_ht_cap) +
+ 2 + sizeof(struct ieee80211_ht_info) +
2 + sdata->u.mesh.mesh_id_len +
2 + sizeof(struct ieee80211_meshconf_ie) +
sdata->u.mesh.ie_len);
@@ -2318,6 +2320,8 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
mesh_add_ds_params_ie(skb, sdata) ||
ieee80211_add_ext_srates_ie(&sdata->vif, skb) ||
mesh_add_rsn_ie(skb, sdata) ||
+ mesh_add_ht_cap_ie(skb, sdata) ||
+ mesh_add_ht_info_ie(skb, sdata) ||
mesh_add_meshid_ie(skb, sdata) ||
mesh_add_meshconf_ie(skb, sdata) ||
mesh_add_vendor_ies(skb, sdata)) {
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 3/6] mac80211: set HT capabilities for mesh peer
From: Thomas Pedersen @ 2011-10-20 18:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319135679-6740-1-git-send-email-thomas@cozybit.com>
Set peer's HT capabilities, and disallow peering if we're on a different
channel type.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
---
net/mac80211/mesh.c | 25 +++++++++++++++++--------
net/mac80211/mesh_plink.c | 13 ++++++++++---
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 2dc76a9..b3a125f 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -76,6 +76,7 @@ static void ieee80211_mesh_housekeeping_timer(unsigned long data)
bool mesh_matches_local(struct ieee802_11_elems *ie, struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee80211_local *local = sdata->local;
/*
* As support for each feature is added, check for matching
@@ -87,15 +88,23 @@ bool mesh_matches_local(struct ieee802_11_elems *ie, struct ieee80211_sub_if_dat
* - MDA enabled
* - Power management control on fc
*/
- if (ifmsh->mesh_id_len == ie->mesh_id_len &&
- memcmp(ifmsh->mesh_id, ie->mesh_id, ie->mesh_id_len) == 0 &&
- (ifmsh->mesh_pp_id == ie->mesh_config->meshconf_psel) &&
- (ifmsh->mesh_pm_id == ie->mesh_config->meshconf_pmetric) &&
- (ifmsh->mesh_cc_id == ie->mesh_config->meshconf_congest) &&
- (ifmsh->mesh_sp_id == ie->mesh_config->meshconf_synch) &&
- (ifmsh->mesh_auth_id == ie->mesh_config->meshconf_auth))
- return true;
-
+ if (!(ifmsh->mesh_id_len == ie->mesh_id_len &&
+ memcmp(ifmsh->mesh_id, ie->mesh_id, ie->mesh_id_len) == 0 &&
+ (ifmsh->mesh_pp_id == ie->mesh_config->meshconf_psel) &&
+ (ifmsh->mesh_pm_id == ie->mesh_config->meshconf_pmetric) &&
+ (ifmsh->mesh_cc_id == ie->mesh_config->meshconf_congest) &&
+ (ifmsh->mesh_sp_id == ie->mesh_config->meshconf_synch) &&
+ (ifmsh->mesh_auth_id == ie->mesh_config->meshconf_auth)))
+ goto mismatch;
+
+ /* disallow peering with mismatched channel types for now */
+ if (ie->ht_info_elem &&
+ (local->_oper_channel_type !=
+ ieee80211_ht_info_to_channel_type(ie->ht_info_elem)))
+ goto mismatch;
+
+ return true;
+mismatch:
return false;
}
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index bbfbd45..f0705e6 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -80,11 +80,15 @@ static inline void mesh_plink_fsm_restart(struct sta_info *sta)
* on it in the lifecycle management section!
*/
static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
- u8 *hw_addr, u32 rates)
+ u8 *hw_addr, u32 rates,
+ struct ieee802_11_elems *elems)
{
struct ieee80211_local *local = sdata->local;
+ struct ieee80211_supported_band *sband;
struct sta_info *sta;
+ sband = local->hw.wiphy->bands[local->oper_channel->band];
+
if (local->num_sta >= MESH_MAX_PLINKS)
return NULL;
@@ -96,6 +100,9 @@ static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
set_sta_flag(sta, WLAN_STA_AUTHORIZED);
set_sta_flag(sta, WLAN_STA_WME);
sta->sta.supp_rates[local->hw.conf.channel->band] = rates;
+ if (elems->ht_cap_elem)
+ ieee80211_ht_cap_ie_to_sta_ht_cap(sband, elems->ht_cap_elem,
+ &sta->sta.ht_cap);
rate_control_rate_init(sta);
return sta;
@@ -279,7 +286,7 @@ void mesh_neighbour_update(u8 *hw_addr, u32 rates,
elems->ie_start, elems->total_len,
GFP_KERNEL);
else
- sta = mesh_plink_alloc(sdata, hw_addr, rates);
+ sta = mesh_plink_alloc(sdata, hw_addr, rates, elems);
if (!sta)
return;
if (sta_info_insert_rcu(sta)) {
@@ -570,7 +577,7 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
}
rates = ieee80211_sta_get_rates(local, &elems, rx_status->band);
- sta = mesh_plink_alloc(sdata, mgmt->sa, rates);
+ sta = mesh_plink_alloc(sdata, mgmt->sa, rates, &elems);
if (!sta) {
mpl_dbg("Mesh plink error: plink table full\n");
return;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 4/6] mac80211: allow frame aggregation for mesh
From: Thomas Pedersen @ 2011-10-20 18:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319135679-6740-1-git-send-email-thomas@cozybit.com>
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
---
v2:
Remove outdated comments (Christian)
net/mac80211/agg-rx.c | 3 ++-
net/mac80211/agg-tx.c | 10 +++-------
net/mac80211/ht.c | 3 ++-
net/mac80211/rx.c | 7 +------
4 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 0cde8df..e8af4b0 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -176,7 +176,8 @@ static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *d
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 2ac0339..fefc7e5 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -77,7 +77,8 @@ static void ieee80211_send_addba_request(struct ieee80211_sub_if_data *sdata,
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
@@ -371,13 +372,8 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
pubsta->addr, tid);
#endif /* CONFIG_MAC80211_HT_DEBUG */
- /*
- * The aggregation code is not prepared to handle
- * anything but STA/AP due to the BSSID handling.
- * IBSS could work in the code but isn't supported
- * by drivers or the standard.
- */
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
+ sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_AP)
return -EINVAL;
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index f80a35c..988c7ec 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -195,7 +195,8 @@ void ieee80211_send_delba(struct ieee80211_sub_if_data *sdata,
memcpy(mgmt->da, da, ETH_ALEN);
memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
if (sdata->vif.type == NL80211_IFTYPE_AP ||
- sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8c03d6e..39b69e2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2208,13 +2208,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
switch (mgmt->u.action.category) {
case WLAN_CATEGORY_BACK:
- /*
- * The aggregation code is not prepared to handle
- * anything but STA/AP due to the BSSID handling;
- * IBSS could work in the code but isn't supported
- * by drivers or the standard.
- */
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
+ sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_AP)
break;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 5/6] mac80211: add WMM IE to mesh frames
From: Thomas Pedersen @ 2011-10-20 18:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319135679-6740-1-git-send-email-thomas@cozybit.com>
Include the WMM IE in mesh peering and beacon frames. This is needed
tell any potential peers what our WMM / EDCA parameters are.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
include/linux/ieee80211.h | 26 +++++++++++++
include/net/mac80211.h | 4 ++
net/mac80211/mesh_plink.c | 4 +-
net/mac80211/tx.c | 2 +
net/mac80211/util.c | 92 +++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 127 insertions(+), 1 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 48363c3..ec6f396 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -152,6 +152,11 @@
#define IEEE80211_WMM_IE_STA_QOSINFO_SP_MASK 0x03
#define IEEE80211_WMM_IE_STA_QOSINFO_SP_SHIFT 5
+#define IEEE80211_WMM_IE_ECWMIN_MASK 0x0f
+#define IEEE80211_WMM_IE_ECWMIN_SHIFT 0
+#define IEEE80211_WMM_IE_ECWMAX_MASK 0xf0
+#define IEEE80211_WMM_IE_ECWMAX_SHIFT 4
+
#define IEEE80211_HT_CTL_LEN 4
struct ieee80211_hdr {
@@ -605,6 +610,27 @@ struct ieee80211_tim_ie {
u8 virtual_map[1];
} __attribute__ ((packed));
+struct ieee80211_wmm_ac_param {
+ u8 ac_aci_acm_aifsn;
+ u8 ac_ecwmin_ecwmax;
+ __le16 ac_txop_limit;
+} __attribute__ ((packed));
+
+/**
+ * struct ieee80211_wmm_param
+ *
+ * This structure refers to "WMM parameter information element"
+ */
+struct ieee80211_wmm_param_ie {
+ u8 oui[3];
+ u8 oui_type;
+ u8 oui_subtype;
+ u8 version;
+ u8 qos_info;
+ u8 reserved;
+ struct ieee80211_wmm_ac_param ac[4];
+} __attribute__ ((packed));
+
/**
* struct ieee80211_meshconf_ie
*
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index dc1123a..fd28b2b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3649,4 +3649,8 @@ int ieee80211_add_srates_ie(struct ieee80211_vif *vif, struct sk_buff *skb);
int ieee80211_add_ext_srates_ie(struct ieee80211_vif *vif,
struct sk_buff *skb);
+int ieee80211_build_wmm_ie(struct ieee80211_vif *vif,
+ u8 *ie_data);
+int ieee80211_add_wmm_ie(struct ieee80211_vif *vif,
+ struct sk_buff *skb);
#endif /* MAC80211_H */
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index f0705e6..069e5dc 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -177,6 +177,7 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
2 + sizeof(struct ieee80211_meshconf_ie) +
2 + sizeof(struct ieee80211_ht_cap) +
2 + sizeof(struct ieee80211_ht_info) +
+ 2 + sizeof(struct ieee80211_wmm_param_ie) +
2 + 8 + /* peering IE */
sdata->u.mesh.ie_len);
if (!skb)
@@ -256,7 +257,8 @@ static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
if (action != WLAN_SP_MESH_PEERING_CLOSE) {
if (mesh_add_ht_cap_ie(skb, sdata) ||
- mesh_add_ht_info_ie(skb, sdata))
+ mesh_add_ht_info_ie(skb, sdata) ||
+ ieee80211_add_wmm_ie(&sdata->vif, skb))
return -1;
}
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index faca189..dfb6bb9 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2294,6 +2294,7 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
2 + sizeof(struct ieee80211_ht_info) +
2 + sdata->u.mesh.mesh_id_len +
2 + sizeof(struct ieee80211_meshconf_ie) +
+ 2 + sizeof(struct ieee80211_wmm_param_ie) +
sdata->u.mesh.ie_len);
if (!skb)
goto out;
@@ -2324,6 +2325,7 @@ struct sk_buff *ieee80211_beacon_get_tim(struct ieee80211_hw *hw,
mesh_add_ht_info_ie(skb, sdata) ||
mesh_add_meshid_ie(skb, sdata) ||
mesh_add_meshconf_ie(skb, sdata) ||
+ ieee80211_add_wmm_ie(&sdata->vif, skb) ||
mesh_add_vendor_ies(skb, sdata)) {
pr_err("o11s: couldn't add ies!\n");
goto out;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 72b3a2e..071b425 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1419,6 +1419,98 @@ u8 *ieee80211_ie_build_ht_info(u8 *pos,
return pos + sizeof(struct ieee80211_ht_info);
}
+static inline u8 ieee80211_wmm_ecw(struct ieee80211_tx_queue_params *txq)
+{
+ u8 cw_min, cw_max, n = 0;
+
+ /* cw_min and cw_max are transmitted as n in 2^n - 1 */
+ while ((txq->cw_min >> n) & 0x01)
+ n++;
+ cw_min = n;
+
+ n = 0;
+ while ((txq->cw_max >> n) & 0x01)
+ n++;
+ cw_max = n;
+
+ return ((cw_min << IEEE80211_WMM_IE_ECWMIN_SHIFT) &
+ IEEE80211_WMM_IE_ECWMIN_MASK) |
+ ((cw_max << IEEE80211_WMM_IE_ECWMAX_SHIFT) &
+ IEEE80211_WMM_IE_ECWMAX_MASK);
+}
+
+static inline u8 ieee80211_aci_to_q(u8 aci)
+{
+ u8 q;
+
+ switch (aci) {
+ case 1: /* BK */
+ q = 3;
+ break;
+ default:
+ case 0: /* BE */
+ q = 2;
+ break;
+ case 2: /* VI */
+ q = 1;
+ break;
+ case 3: /* VO */
+ q = 0;
+ break;
+ }
+
+ return q;
+}
+
+int ieee80211_build_wmm_ie(struct ieee80211_vif *vif, u8 *data)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct ieee80211_wmm_param_ie *wmm;
+ struct ieee80211_wmm_ac_param *ac;
+ struct ieee80211_tx_queue_params *txconf;
+ u8 aci;
+
+ wmm = (struct ieee80211_wmm_param_ie *) data;
+ wmm->oui[0] = 0x00;
+ wmm->oui[1] = 0x50;
+ wmm->oui[2] = 0xf2;
+ wmm->oui_type = 2; /* WMM */
+ wmm->oui_subtype = 1; /* WMM param */
+ wmm->version = 1;
+ wmm->qos_info = 0;
+ wmm->reserved = 0;
+
+ for (aci = 0; aci < 4; aci++) {
+ ac = &wmm->ac[aci];
+ txconf = &sdata->tx_conf[ieee80211_aci_to_q(aci)];
+
+ ac->ac_aci_acm_aifsn = (aci << 5) | txconf->aifs;
+ ac->ac_ecwmin_ecwmax = ieee80211_wmm_ecw(txconf);
+ ac->ac_txop_limit = cpu_to_le16(txconf->txop);
+ }
+
+ return 0;
+}
+
+int ieee80211_add_wmm_ie(struct ieee80211_vif *vif,
+ struct sk_buff *skb)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ u8 *pos;
+
+ if (sdata->local->hw.queues < 4)
+ return 0;
+
+ if (skb_tailroom(skb) < 2 + sizeof(struct ieee80211_wmm_param_ie))
+ return -ENOMEM;
+
+ pos = skb_put(skb, 2 + sizeof(struct ieee80211_wmm_param_ie));
+ *pos++ = WLAN_EID_VENDOR_SPECIFIC;
+ *pos++ = sizeof(struct ieee80211_wmm_param_ie);
+
+ return ieee80211_build_wmm_ie(vif, pos);
+}
+
enum nl80211_channel_type
ieee80211_ht_info_to_channel_type(struct ieee80211_ht_info *ht_info)
{
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 6/6] mac80211: check mesh peer's WMM parameters
From: Thomas Pedersen @ 2011-10-20 18:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319135679-6740-1-git-send-email-thomas@cozybit.com>
For now, disallow peering if our WMM parameters don't match our peer's.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
net/mac80211/mesh.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index b3a125f..dd83c8f7 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -103,6 +103,13 @@ bool mesh_matches_local(struct ieee802_11_elems *ie, struct ieee80211_sub_if_dat
ieee80211_ht_info_to_channel_type(ie->ht_info_elem)))
goto mismatch;
+ if (ie->wmm_param) {
+ u8 wmm_local[sizeof(struct ieee80211_wmm_param_ie)];
+ ieee80211_build_wmm_ie(&sdata->vif, wmm_local);
+ if (memcmp(ie->wmm_param, wmm_local, sizeof(wmm_local)))
+ goto mismatch;
+ }
+
return true;
mismatch:
return false;
--
1.7.5.4
^ permalink raw reply related
* Re: iwlagn: WARN_ON() in iwl_get_idle_rx_chain_count()
From: Michał Mirosław @ 2011-10-20 18:57 UTC (permalink / raw)
To: wwguy
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20111014192105.GA23640@rere.qmqm.pl>
On Fri, Oct 14, 2011 at 09:21:05PM +0200, Michał Mirosław wrote:
> On Fri, Oct 14, 2011 at 08:29:18AM -0700, wwguy wrote:
> > Could you try the attach patch and see if it fix your problem.
> [attached patch removed]
> Backported and applied. I'll test it for couple of days.
I haven't tripped on the warnings in those last days with your
patch applied. I think the backported version should be included
in 3.1.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: iwlagn: WARN_ON() in iwl_get_idle_rx_chain_count()
From: wwguy @ 2011-10-20 18:54 UTC (permalink / raw)
To: Michał Mirosław
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20111020185756.GA24185@rere.qmqm.pl>
On Thu, 2011-10-20 at 11:57 -0700, Michał Mirosław wrote:
> On Fri, Oct 14, 2011 at 09:21:05PM +0200, Michał Mirosław wrote:
> > On Fri, Oct 14, 2011 at 08:29:18AM -0700, wwguy wrote:
> > > Could you try the attach patch and see if it fix your problem.
> > [attached patch removed]
> > Backported and applied. I'll test it for couple of days.
>
> I haven't tripped on the warnings in those last days with your
> patch applied. I think the backported version should be included
> in 3.1.
>
Thank you for testing it, I will push it upstream into 3.1
Best Regards
Wey
^ permalink raw reply
* Compat-wireless release for 2011-10-20 is baked
From: Compat-wireless cronjob account @ 2011-10-20 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814119 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3535 - % of code consists of backport work
^ permalink raw reply
* Re: [PATCH v2 0/6] HT support for mesh
From: Xianghua Xiao @ 2011-10-20 19:17 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless
In-Reply-To: <1319135679-6740-1-git-send-email-thomas@cozybit.com>
how does this relate to Alex HT patches? Alex's patch addresses IBSS
but there seems to be some overlaps between Mesh/IBSS HT patches.
thanks,
On Thu, Oct 20, 2011 at 1:34 PM, Thomas Pedersen <thomas@cozybit.com> wrote:
> This patchset adds basic HT support for mesh nodes. We avoid the question of
> how to negotiate channel types, by simply disallowing peering with mismatched
> HT modes. Needs the mesh fixes posted earlier today for patch context.
>
> Many thanks to Luis Rodriguez for his assistance, and Ashok Nagarajan for
> co-authoring this patchset.
>
> v2:
> Remove outdated BA comments (Christian)
>
> Alexander Simon (1):
> mac80211: Add HT helper functions
>
> Thomas Pedersen (5):
> mac80211: add HT IEs to mesh frames
> mac80211: set HT capabilities for mesh peer
> mac80211: allow frame aggregation for mesh
> mac80211: add WMM IE to mesh frames
> mac80211: check mesh peer's WMM parameters
>
> include/linux/ieee80211.h | 26 ++++++
> include/net/mac80211.h | 4 +
> net/mac80211/agg-rx.c | 3 +-
> net/mac80211/agg-tx.c | 10 +--
> net/mac80211/ht.c | 3 +-
> net/mac80211/ieee80211_i.h | 8 ++
> net/mac80211/mesh.c | 75 ++++++++++++++--
> net/mac80211/mesh.h | 4 +
> net/mac80211/mesh_plink.c | 24 +++++-
> net/mac80211/rx.c | 7 +--
> net/mac80211/tx.c | 6 ++
> net/mac80211/util.c | 208 ++++++++++++++++++++++++++++++++++++++++----
> net/mac80211/work.c | 29 +------
> 13 files changed, 336 insertions(+), 71 deletions(-)
>
> --
> 1.7.5.4
>
> --
> 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 v2 0/6] HT support for mesh
From: Johannes Berg @ 2011-10-20 19:18 UTC (permalink / raw)
To: Xianghua Xiao; +Cc: Thomas Pedersen, linux-wireless
In-Reply-To: <CAP7cwtsB0jckz_WVFJuibKiewuOQZ_BMHTHBDfCTMNt_ge9buw@mail.gmail.com>
On Thu, 2011-10-20 at 14:17 -0500, Xianghua Xiao wrote:
> how does this relate to Alex HT patches? Alex's patch addresses IBSS
> but there seems to be some overlaps between Mesh/IBSS HT patches.
He just uses one of Alex's refactoring patches here :)
johannes
^ permalink raw reply
* Question on channel 44 and HT40+
From: Ben Greear @ 2011-10-20 21:53 UTC (permalink / raw)
To: hostap, linux-wireless@vger.kernel.org
I configured hostapd for channel 44, and gave it option for HT40+
That seems to work fine:
[root@ct520-6157 ]# cat /debug/ieee80211/wiphy0/ath9k/wiphy
wiphy0 (chan=44 center-freq: 5220 MHz channel-type: 3 (ht40+))
addr: 00:0e:8e:32:12:cf
addrmask: ff:79:e8:45:74:31
rfilt: 0x4497 UCAST MCAST BCAST BEACON PROBEREQ COMP_BAR PSPOLL
[root@ct520-6157 ]#
However, the clients will not use HT40 because this check from the kernel's
mlme.c fails:
case IEEE80211_HT_PARAM_CHA_SEC_ABOVE:
if (!(local->hw.conf.channel->flags &
IEEE80211_CHAN_NO_HT40PLUS))
channel_type = NL80211_CHAN_HT40PLUS;
Both systems are ath9k on 3.0.6+ (+ my standard set of hacks).
Both systems are using US country code.
Client-side:
03:00.0 Network controller: Atheros Communications Inc. AR9160 802.11abgn Wireless PCI Adapter (rev 01)
AP:
03:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
So, the question is: Is this *supposed* to work? The hostapd conf file seems
to indicate that HT40+ is valid on channel 44...
The hostapd config file is here:
interface=vap0
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
dump_file=/home/lanforge/wifi/hostapd_vap0.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=test123
bssid=00:88:99:88:99:01
country_code=US
ieee80211d=0
hw_mode=a
ieee80211n=1
channel=44
beacon_int=240
dtim_period=2
max_num_sta=2007
rts_threshold=2347
fragm_threshold=2346
preamble=0
macaddr_acl=0
auth_algs=3
ignore_broadcast_ssid=0
# Enable HT modes if you want 300Mbps+ throughput.
#ht_capab=[HT20][HT40-][HT40+][GF][SHORT-GI-20][SHORT-GI-40]
# [TX-STBC][RX-STBC123][MAX-AMSDU-7935][DSSS_CCK-40][PSMP][LSIG-TXOP-PROT]
ht_capab=[HT20][HT40+][HT40-][SHORT-GI-40]
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
ieee8021x=0
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=1
wpa_pairwise=TKIP CCMP
wpa_passphrase=test1234
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH v2] ath6kl: Implement support for listen interval from userspace
From: Rishi Panjwani @ 2011-10-20 22:35 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Rishi Panjwani
The patch allows modification of listen interval thereby allowing change
in sleep/awake cycle causing change in power consumption numbers.
Rishi Panjwani (1):
ath6kl: Implement support for listen interval from userspace
drivers/net/wireless/ath/ath6kl/debug.c | 60 +++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH v2] ath6kl: Implement support for listen interval from userspace
From: Rishi Panjwani @ 2011-10-20 22:35 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Rishi Panjwani
In-Reply-To: <1319150111-5647-1-git-send-email-rpanjwan@qca.qualcomm.com>
In order to allow user space based control of listen interval, we use
available debugfs infrastructure. Listen interval implies how frequently
we want the WLAN chip to wake up and synchronize the beacons in case it
is in sleep mode. The feature has been added for testing purposes. The
command requires two parameters in the following order:
1) listen_interval_time
2) listen_interval_beacons
The user has to write the listen interval_time (in msecs) and
listen_interval_beacons (in no. of beacons) to the listen_interval file in
ath6kl debug directory.
Example:
echo "30 1" > listen_interval
Signed-off-by: Rishi Panjwani <rpanjwan@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/debug.c | 60 +++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index 3eaa291..b589ab6 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -1489,6 +1489,66 @@ static const struct file_operations fops_bgscan_int = {
.llseek = default_llseek,
};
+static ssize_t ath6kl_listen_int_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ u16 listen_int_t, listen_int_b;
+ char buf[32];
+ char *sptr, *token;
+ ssize_t len;
+
+ len = min(count, sizeof(buf) - 1);
+ if (copy_from_user(buf, user_buf, len))
+ return -EFAULT;
+
+ buf[len] = '\0';
+ sptr = buf;
+
+ token = strsep(&sptr, " ");
+ if (!token)
+ return -EINVAL;
+ if (kstrtou16(token, 0, &listen_int_t) ||
+ kstrtou16(sptr, 0, &listen_int_b))
+ return -EINVAL;
+
+
+ if ((listen_int_t >= 15) && (listen_int_t <= 5000) &&
+ (listen_int_b >= 1) && (listen_int_b <= 50)) {
+ ar->listen_intvl_t = listen_int_t;
+ ar->listen_intvl_b = listen_int_b;
+ ath6kl_wmi_listeninterval_cmd(ar->wmi, ar->listen_intvl_t,
+ ar->listen_intvl_b);
+ } else {
+ return -EINVAL;
+ }
+
+ return count;
+}
+
+static ssize_t ath6kl_listen_int_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ char buf[16];
+ int len;
+
+ len = snprintf(buf, sizeof(buf), "%u %u\n", ar->listen_intvl_t,
+ ar->listen_intvl_b);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_listen_int = {
+ .read = ath6kl_listen_int_read,
+ .write = ath6kl_listen_int_write,
+ .open = ath6kl_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
int ath6kl_debug_init(struct ath6kl *ar)
{
ar->debug.fwlog_buf.buf = vmalloc(ATH6KL_FWLOG_SIZE);
--
1.7.0.4
^ permalink raw reply related
* rtl8192cu - fails to maintain connection to some Access Points
From: Alan Pater @ 2011-10-20 23:02 UTC (permalink / raw)
To: linux-wireless
Hi folks
Several people over on Ubuntu Launchpad are reporting that this USB WiFi
adaptor has issues connecting to certain access points. In my case, I cannot
connect to a Meraki mesh network, but have no trouble when using my Android
phone as a WiFi Access Point.
The launchpad bugs are:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/852190
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869530
https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/+bug/862684
~$ uname -a
Linux crow 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011
i686 i686 i386 GNU/Linux
~$ lsusb
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp.
Note that I have tried newer kernels, including 3.1.0 without it making a
difference.
Is there some other steps we could be taking to figure out what is going on
here?
gracias,
Alan
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-21 1:23 UTC (permalink / raw)
To: Johannes Berg
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <1319096418.3959.1.camel@jlt3.sipsolutions.net>
On Do, 20 Okt 2011, Johannes Berg wrote:
> > [17409.616748] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
..
> > [17419.285141] iwlagn 0000:06:00.0: Encounter TX_STATUS_FAIL_PASSIVE_NO_RX, am I on 5.2G band? (0)
> > [17419.286583] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> > [17419.300296] cfg80211: Calling CRDA for country: JP
> > [17419.309278] wlan0: authenticate with 00:24:c4:ab:bd:ef (try 1)
> > [17419.310105] wlan0: authenticated
> > [17419.317900] wlan0: associate with 00:24:c4:ab:bd:ef (try 1)
>
> It seems a bit like the 5 GHz AP (:e0) just fails, and wpa_supplicant
> selects a 2.4 GHz AP (:ef) now? Pure conjecture, I guess the AP could
> also be on the same channel -- did you have scan information for these
> APs?
BSS 00:24:c4:ab:bd:e0 (on wlan0)
TSF: 8728607601135 usec (101d, 00:36:47)
freq: 2412
beacon interval: 102
capability: ESS ShortPreamble ShortSlotTime (0x0421)
signal: -62.00 dBm
last seen: 6012 ms ago
SSID: XXXXXX
Supported rates: 1.0* 2.0* 5.5* 6.0 9.0 11.0* 12.0 18.0
DS Parameter set: channel 1
TIM: DTIM Count 0 DTIM Period 1 Bitmap Control 0x0 Bitmap[0] 0x0
Country: JP Environment: Indoor/Outdoor
Channels [1 - 13] @ 20 dBm
ERP: Use_Protection
HT capabilities:
Capabilities: 0x182c
HT20
SM Power Save disabled
RX HT20 SGI
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-15
HT TX MCS rate indexes are undefined
Extended supported rates: 24.0 36.0 48.0 54.0
HT operation:
* primary channel: 1
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 0
* HT protection: non-HT mixed
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
And the one I am on:
BSS 00:24:c4:ab:bd:ef (on wlan0) -- associated
TSF: 8728558719143 usec (101d, 00:35:58)
freq: 5200
beacon interval: 102
capability: ESS (0x0001)
signal: -69.00 dBm
last seen: 96 ms ago
Information elements from Probe Response frame:
SSID: XXXXXX
Supported rates: 6.0* 9.0 12.0* 18.0 24.0* 36.0 48.0 54.0
Country: JP Environment: Indoor/Outdoor
Channels [36 - 64] @ 22 dBm
HT capabilities:
Capabilities: 0x186e
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-15
HT TX MCS rate indexes are undefined
HT operation:
* primary channel: 40
* secondary channel offset: below
* STA channel width: any
* RIFS: 1
* HT protection: no
* non-GF present: 1
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
No idea if that helps you.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
SCREGGAN (n. banking)
The crossed-out bit caused by people putting the wrong year on their
cheques all through January.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-21 1:24 UTC (permalink / raw)
To: wwguy
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <1319119852.2111.2.camel@wwguy-ubuntu>
On Do, 20 Okt 2011, wwguy wrote:
> Great, this is just a test patch, we will figure out what is the correct
> way to handle this and fix the issue for good :-)
Thanks. If you need more testing just let me know.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
HODDLESDEN (n.)
An 'injured' footballer's limb back into the game which draws applause
but doesn't fool anybody.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Module rtl8192cu (Upstream kernel bug)
From: Larry Finger @ 2011-10-21 3:52 UTC (permalink / raw)
To: Thor Malmjursson; +Cc: ziv_huang, georgia, linux-wireless, linux-kernel
In-Reply-To: <SNT114-W5A13731399C34DE1C30D6A4EB0@phx.gbl>
On 10/20/2011 03:19 PM, Thor Malmjursson wrote:
> Hi. My name is Thor Malmjursson, I'm on the Kubuntu 11.10 OS, and I've
> discovered a bug with a kernel driver module which may need some attention. The
> main details of the bug are here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/878504
>
> The issue is with the rtl8192cu kernel module, released in the 3.0 series of
> kernels, which we only got for the first time with our distro upgrade about 6
> days ago. I have a USB WiFi adapter which should work with that module, and it
> actually associates with it when I plug it into the PC - the problem is, the
> device is immediately locking open and refusing to scan, either automatically or
> manually.
>
> It's a wireless adapter made by Texet, with the USBID 0BDA:8176
>
> The only way I've been able to get the device to function is through
> ndiswrapper, but native support would be much better.
>
> As all the information you would need (i assume) is present on the bug report I
> listed above, I will leave this with you.
>
> I trust you will be able to help me with this.
I tried to post on the Ubuntu bugzilla, but the response was really slow and I
gave up there.
The dmesg output you posted there involved using ndiswrapper, thus I did not see
if the device was able to load the firmware. The specific file for that device
is /lib/firmware/rtlwifi/rtl8192cufw.bin. It is part of a kernel firmware
package. I do not know what Ubuntu calls it.
Larry
^ permalink raw reply
* Re: rtl8192cu - fails to maintain connection to some Access Points
From: Larry Finger @ 2011-10-21 3:59 UTC (permalink / raw)
To: Alan Pater; +Cc: linux-wireless, 'George0505', 'georgia'
In-Reply-To: <CAN4ACka-egrr=GnBomT0Yc_r_mzS-+v8OE=D0vBoH+jFQJwX8w@mail.gmail.com>
On 10/20/2011 06:02 PM, Alan Pater wrote:
> Hi folks
>
> Several people over on Ubuntu Launchpad are reporting that this USB WiFi
> adaptor has issues connecting to certain access points. In my case, I cannot
> connect to a Meraki mesh network, but have no trouble when using my Android
> phone as a WiFi Access Point.
>
> The launchpad bugs are:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/852190
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869530
> https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/+bug/862684
>
> ~$ uname -a
> Linux crow 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011
> i686 i686 i386 GNU/Linux
> ~$ lsusb
> Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp.
>
> Note that I have tried newer kernels, including 3.1.0 without it making a
> difference.
>
> Is there some other steps we could be taking to figure out what is going on
> here?
You need to run wireshark on a different computer and capture the attempt to
connect. The device works with my 3 APs, but none are Meraki.
Larry
^ permalink raw reply
* Re: Question on channel 44 and HT40+
From: Ben Greear @ 2011-10-21 4:11 UTC (permalink / raw)
To: hostap, linux-wireless@vger.kernel.org
In-Reply-To: <4EA09874.3010006@candelatech.com>
On 10/20/2011 02:53 PM, Ben Greear wrote:
>
> I configured hostapd for channel 44, and gave it option for HT40+
> That seems to work fine:
>
> [root@ct520-6157 ]# cat /debug/ieee80211/wiphy0/ath9k/wiphy
> wiphy0 (chan=44 center-freq: 5220 MHz channel-type: 3 (ht40+))
> addr: 00:0e:8e:32:12:cf
> addrmask: ff:79:e8:45:74:31
> rfilt: 0x4497 UCAST MCAST BCAST BEACON PROBEREQ COMP_BAR PSPOLL
> [root@ct520-6157 ]#
Gah, user-error. The client NIC had country-code of AM (Armenia..really??)
and I had forgotten to enable the over-ride.
Once I force the NIC's country-code to 0 then it will do HT-40+- just
fine.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: select queue for fwded mesh frames
From: Thomas Pedersen @ 2011-10-21 4:24 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1319135408-6370-2-git-send-email-thomas@cozybit.com>
On Thu, Oct 20, 2011 at 11:30 AM, Thomas Pedersen <thomas@cozybit.com> wrote:
> Set proper queue mapping and timestamp for forwarded mesh frames.
>
> Thanks to Luis Rodriguez for investigating and fixing this.
>
> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
>
> ---
> v2:
> We were already doing this for mcast frames, so don't duplicate
> the code.
>
> net/mac80211/rx.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index b867bd5..1408472 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -1952,13 +1952,15 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
> info = IEEE80211_SKB_CB(fwd_skb);
> memset(info, 0, sizeof(*info));
> info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
> + info->control.jiffies = jiffies;
> info->control.vif = &rx->sdata->vif;
> + skb_set_queue_mapping(fwd_skb,
> + ieee80211_select_queue(sdata, fwd_skb));
> + ieee80211_set_qos_hdr(sdata, fwd_skb);
> +
> if (is_multicast_ether_addr(fwd_hdr->addr1)) {
> IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
> fwded_mcast);
> - skb_set_queue_mapping(fwd_skb,
> - ieee80211_select_queue(sdata, fwd_skb));
> - ieee80211_set_qos_hdr(sdata, fwd_skb);
> } else {
> int err;
> /*
> --
> 1.7.5.4
>
>
John,
It seems this patch reverts part of
4777be41638cfab56c78b2a764a5f83beb6cfdd2 "mac80211: Start implementing
QoS support for mesh interfaces", and is probably the cause for some
breakage we're seeing here. Please hold off on this patch until I can
figure out what the right thing to do is.
Thanks,
Thomas
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Johannes Berg @ 2011-10-21 7:26 UTC (permalink / raw)
To: Norbert Preining
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111021012354.GA26758@gamma.logic.tuwien.ac.at>
On Fri, 2011-10-21 at 10:23 +0900, Norbert Preining wrote:
> > > [17419.285141] iwlagn 0000:06:00.0: Encounter TX_STATUS_FAIL_PASSIVE_NO_RX, am I on 5.2G band? (0)
> > > [17419.286583] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> > > [17419.300296] cfg80211: Calling CRDA for country: JP
> > > [17419.309278] wlan0: authenticate with 00:24:c4:ab:bd:ef (try 1)
> > > [17419.310105] wlan0: authenticated
> > > [17419.317900] wlan0: associate with 00:24:c4:ab:bd:ef (try 1)
> >
> > It seems a bit like the 5 GHz AP (:e0) just fails, and wpa_supplicant
> > selects a 2.4 GHz AP (:ef) now? Pure conjecture, I guess the AP could
> > also be on the same channel -- did you have scan information for these
> > APs?
>
> BSS 00:24:c4:ab:bd:e0 (on wlan0)
> freq: 2412
> And the one I am on:
> BSS 00:24:c4:ab:bd:ef (on wlan0) -- associated
> freq: 5200
> No idea if that helps you.
Yes, thanks. So it's actually the other way around I guess.
I'm wondering if this too is related to the channel mess in mac80211.
johannes
^ permalink raw reply
* Re: rtl8192cu - fails to maintain connection to some Access Points
From: Sedat Dilek @ 2011-10-21 7:28 UTC (permalink / raw)
To: Larry Finger; +Cc: Alan Pater, linux-wireless, George0505, georgia
In-Reply-To: <4EA0EE26.8010107@lwfinger.net>
On Fri, Oct 21, 2011 at 5:59 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 10/20/2011 06:02 PM, Alan Pater wrote:
>>
>> Hi folks
>>
>> Several people over on Ubuntu Launchpad are reporting that this USB WiFi
>> adaptor has issues connecting to certain access points. In my case, I
>> cannot
>> connect to a Meraki mesh network, but have no trouble when using my
>> Android
>> phone as a WiFi Access Point.
>>
>> The launchpad bugs are:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/852190
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869530
>>
>> https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/+bug/862684
>>
>> ~$ uname -a
>> Linux crow 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:18:14 UTC 2011
>> i686 i686 i386 GNU/Linux
>> ~$ lsusb
>> Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp.
>>
>> Note that I have tried newer kernels, including 3.1.0 without it making a
>> difference.
>>
>> Is there some other steps we could be taking to figure out what is going
>> on
>> here?
>
> You need to run wireshark on a different computer and capture the attempt to
> connect. The device works with my 3 APs, but none are Meraki.
>
Asking as a non-native speaker/writer: What do you mean by "Meraki"?
- Sedat -
[1] http://meraki.com/products/wireless/wifi-stumbler
> Larry
>
> --
> 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
* iwlagn and iwconfig
From: jarek @ 2011-10-21 7:25 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi all!
How can I select radio channels on iwlagn (Intel Wireless-N 1030
adapter) in monitor mode ?
I've tried to use
iwconfig wlan0 channel NN
but it doesn't work properly. Any channel number is accepted, but is not
changed. The card is working properly, network-manager is able to find
all hotspots on all channels, so it must use some other way to make
channel hooping.
Best regards
Jarek
^ permalink raw reply
* [PATCH] mac80211: exit cooked monitor RX early if there are none
From: Johannes Berg @ 2011-10-21 8:17 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
If there are no cooked monitor interfaces, there's
no point in building the radiotap RX header for the
frame and iterating the interface list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/rx.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/mac80211/rx.c 2011-10-20 22:03:03.000000000 +0200
+++ b/net/mac80211/rx.c 2011-10-21 10:15:27.000000000 +0200
@@ -2496,6 +2496,10 @@ static void ieee80211_rx_cooked_monitor(
goto out_free_skb;
rx->flags |= IEEE80211_RX_CMNTR;
+ /* If there are no cooked monitor interfaces, just free the SKB */
+ if (!local->>cooked_mntrs)
+ goto out_free_skb;
+
if (skb_headroom(skb) < sizeof(*rthdr) &&
pskb_expand_head(skb, sizeof(*rthdr), 0, GFP_ATOMIC))
goto out_free_skb;
^ permalink raw reply
* [PATCH v2] mac80211: exit cooked monitor RX early if there are none
From: Johannes Berg @ 2011-10-21 8:22 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1319185071.3964.5.camel@jlt3.sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
If there are no cooked monitor interfaces, there's
no point in building the radiotap RX header for the
frame and iterating the interface list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v2: wow, embarrassing ... try quilt refresh ...
net/mac80211/rx.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/mac80211/rx.c 2011-10-21 10:19:33.000000000 +0200
+++ b/net/mac80211/rx.c 2011-10-21 10:20:59.000000000 +0200
@@ -2489,6 +2489,10 @@ static void ieee80211_rx_cooked_monitor(
goto out_free_skb;
rx->flags |= IEEE80211_RX_CMNTR;
+ /* If there are no cooked monitor interfaces, just free the SKB */
+ if (!local->cooked_mntrs)
+ goto out_free_skb;
+
if (skb_headroom(skb) < sizeof(*rthdr) &&
pskb_expand_head(skb, sizeof(*rthdr), 0, GFP_ATOMIC))
goto out_free_skb;
^ 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