Linux wireless drivers development
 help / color / mirror / Atom feed
* [PATCH-WN 2/3] wireless: Check for dangling wdev->current_bss pointer.
From: greearb @ 2013-06-19 21:06 UTC (permalink / raw)
  To: linux-wireless; +Cc: Ben Greear
In-Reply-To: <1371675987-28732-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb@candelatech.com>

If it *is* still set when the netdev is being deleted,
then we are about to leak a pointer.  Warn and clean up
in that case.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---

This is against wireless-next.  I've never seen this hit,
though possibly it would catch some future bugs.  If you
think it's not useful, I won't argue :)

 net/wireless/core.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 9143288..042d6a3 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -934,6 +934,12 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
 		 * freed.
 		 */
 		cfg80211_process_wdev_events(wdev);
+
+		if (WARN_ON(wdev->current_bss)) {
+			cfg80211_unhold_bss(wdev->current_bss);
+			cfg80211_put_bss(wdev->wiphy, &wdev->current_bss->pub);
+			wdev->current_bss = NULL;
+		}
 		break;
 	case NETDEV_PRE_UP:
 		if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH-WN 3/3] wireless: Add comments about bss refcounting.
From: greearb @ 2013-06-19 21:06 UTC (permalink / raw)
  To: linux-wireless; +Cc: Ben Greear
In-Reply-To: <1371675987-28732-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb@candelatech.com>

Should help the next person that tries to understand
the bss refcounting logic.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---

This is against wireless-next.

 net/wireless/scan.c |    4 ++++
 net/wireless/sme.c  |    3 +++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index abb0399..d2f4db0 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -623,6 +623,7 @@ static int cmp_bss(struct cfg80211_bss *a,
 	}
 }
 
+/* Returned bss is reference counted and must be cleaned up appropriately. */
 struct cfg80211_bss *cfg80211_get_bss(struct wiphy *wiphy,
 				      struct ieee80211_channel *channel,
 				      const u8 *bssid,
@@ -778,6 +779,7 @@ static bool cfg80211_combine_bsses(struct cfg80211_registered_device *dev,
 	return true;
 }
 
+/* Returned bss is reference counted and must be cleaned up appropriately. */
 static struct cfg80211_internal_bss *
 cfg80211_bss_update(struct cfg80211_registered_device *dev,
 		    struct cfg80211_internal_bss *tmp)
@@ -963,6 +965,7 @@ cfg80211_get_bss_channel(struct wiphy *wiphy, const u8 *ie, size_t ielen,
 	return channel;
 }
 
+/* Returned bss is reference counted and must be cleaned up appropriately. */
 struct cfg80211_bss*
 cfg80211_inform_bss(struct wiphy *wiphy,
 		    struct ieee80211_channel *channel,
@@ -1020,6 +1023,7 @@ cfg80211_inform_bss(struct wiphy *wiphy,
 }
 EXPORT_SYMBOL(cfg80211_inform_bss);
 
+/* Returned bss is reference counted and must be cleaned up appropriately. */
 struct cfg80211_bss *
 cfg80211_inform_bss_frame(struct wiphy *wiphy,
 			  struct ieee80211_channel *channel,
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 32dac8c..1d3cfb1 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -239,6 +239,7 @@ void cfg80211_conn_work(struct work_struct *work)
 	rtnl_unlock();
 }
 
+/* Returned bss is reference counted and must be cleaned up appropriately. */
 static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev)
 {
 	struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
@@ -699,6 +700,7 @@ void cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
 }
 EXPORT_SYMBOL(cfg80211_connect_result);
 
+/* Consumes bss object one way or another */
 void __cfg80211_roamed(struct wireless_dev *wdev,
 		       struct cfg80211_bss *bss,
 		       const u8 *req_ie, size_t req_ie_len,
@@ -775,6 +777,7 @@ void cfg80211_roamed(struct net_device *dev,
 }
 EXPORT_SYMBOL(cfg80211_roamed);
 
+/* Consumes bss object one way or another */
 void cfg80211_roamed_bss(struct net_device *dev,
 			 struct cfg80211_bss *bss, const u8 *req_ie,
 			 size_t req_ie_len, const u8 *resp_ie,
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH-WN 1/3] wireless: Make sure __cfg80211_connect_result always puts bss.
From: greearb @ 2013-06-19 21:06 UTC (permalink / raw)
  To: linux-wireless; +Cc: Ben Greear

From: Ben Greear <greearb@candelatech.com>

Otherwise, we can leak a bss reference.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---

This is against wireless-next.

 net/wireless/sme.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index c0bf781..32dac8c 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -557,6 +557,7 @@ static DECLARE_WORK(cfg80211_disconnect_work, disconnect_work);
  * SME event handling
  */
 
+/* This method must consume bss one way or another */
 void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
 			       const u8 *req_ie, size_t req_ie_len,
 			       const u8 *resp_ie, size_t resp_ie_len,
@@ -572,8 +573,10 @@ void __cfg80211_connect_result(struct net_device *dev, const u8 *bssid,
 	ASSERT_WDEV_LOCK(wdev);
 
 	if (WARN_ON(wdev->iftype != NL80211_IFTYPE_STATION &&
-		    wdev->iftype != NL80211_IFTYPE_P2P_CLIENT))
+		    wdev->iftype != NL80211_IFTYPE_P2P_CLIENT)) {
+		cfg80211_put_bss(wdev->wiphy, bss);
 		return;
+	}
 
 	nl80211_send_connect_result(wiphy_to_dev(wdev->wiphy), dev,
 				    bssid, req_ie, req_ie_len,
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH-WN] wireless: Add memory usage debugging.
From: greearb @ 2013-06-19 21:03 UTC (permalink / raw)
  To: linux-wireless; +Cc: Ben Greear

From: Ben Greear <greearb@candelatech.com>

The bss objects are reference counted, and the ies
are also tricky to keep track of.  Add option to
track allocation and freeing of the ies and bss objects,
and add debugfs files to show the current objects.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---

This patch is against wireless-next.

 net/wireless/Kconfig   |   13 +++++
 net/wireless/core.c    |    5 +-
 net/wireless/core.h    |   17 ++++++
 net/wireless/debugfs.c |  117 ++++++++++++++++++++++++++++++++++++++++++++
 net/wireless/debugfs.h |    2 +
 net/wireless/scan.c    |  127 ++++++++++++++++++++++++++++++++++++++++++------
 6 files changed, 264 insertions(+), 17 deletions(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 16d08b3..43ec2cd 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -115,6 +115,19 @@ config CFG80211_DEBUGFS
 
 	  If unsure, say N.
 
+config CFG80211_MEM_DEBUGGING
+	bool "cfg80211 memory debugging logic"
+	default n
+	depends on CFG80211_DEBUGFS
+	---help---
+	  Enable this if you want to debug memory handling for bss and ies
+	  objects.  New debugfs files: ieee80211/all_ies and all_bss will
+	  be created to display these objects.  This has a moderate CPU cost
+	  and uses a bit more memory than normal, but otherwise is not very
+	  expensive.
+
+	  If unsure, say N.
+
 config CFG80211_INTERNAL_REGDB
 	bool "use statically compiled regulatory rules database" if EXPERT
 	default n
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4224e75..9143288 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -990,6 +990,7 @@ static int __init cfg80211_init(void)
 		goto out_fail_nl80211;
 
 	ieee80211_debugfs_dir = debugfs_create_dir("ieee80211", NULL);
+	ieee80211_debugfs_add_glbl(ieee80211_debugfs_dir);
 
 	err = regulatory_init();
 	if (err)
@@ -1006,7 +1007,7 @@ static int __init cfg80211_init(void)
 out_fail_wq:
 	regulatory_exit();
 out_fail_reg:
-	debugfs_remove(ieee80211_debugfs_dir);
+	debugfs_remove_recursive(ieee80211_debugfs_dir);
 out_fail_nl80211:
 	unregister_netdevice_notifier(&cfg80211_netdev_notifier);
 out_fail_notifier:
@@ -1020,7 +1021,7 @@ subsys_initcall(cfg80211_init);
 
 static void __exit cfg80211_exit(void)
 {
-	debugfs_remove(ieee80211_debugfs_dir);
+	debugfs_remove_recursive(ieee80211_debugfs_dir);
 	nl80211_exit();
 	unregister_netdevice_notifier(&cfg80211_netdev_notifier);
 	wiphy_sysfs_exit();
diff --git a/net/wireless/core.h b/net/wireless/core.h
index a6b45bf..f665957 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -114,6 +114,23 @@ extern struct workqueue_struct *cfg80211_wq;
 extern struct list_head cfg80211_rdev_list;
 extern int cfg80211_rdev_list_generation;
 
+#ifdef CONFIG_CFG80211_MEM_DEBUGGING
+
+struct wifi_mem_tracker {
+	struct list_head mylist;
+	char buf[40];
+	void *ptr;
+};
+extern struct list_head ies_list;
+extern spinlock_t ies_lock;
+extern atomic_t ies_count;
+
+extern struct list_head bss_list;
+extern spinlock_t bss_lock;
+extern atomic_t bss_count;
+
+#endif
+
 struct cfg80211_internal_bss {
 	struct list_head list;
 	struct list_head hidden_list;
diff --git a/net/wireless/debugfs.c b/net/wireless/debugfs.c
index 90d0500..a7dec4e 100644
--- a/net/wireless/debugfs.c
+++ b/net/wireless/debugfs.c
@@ -31,6 +31,110 @@ static const struct file_operations name## _ops = {			\
 	.llseek = generic_file_llseek,					\
 };
 
+#define DEBUGFS_READONLY_FILE_OPS(name) \
+static const struct file_operations name## _ops = {			\
+	.read = name## _read,						\
+	.open = simple_open,						\
+	.llseek = generic_file_llseek,					\
+};
+
+#ifdef CONFIG_CFG80211_MEM_DEBUGGING
+static ssize_t all_ies_read(struct file *file, char __user *user_buf,
+				size_t count, loff_t *ppos)
+{
+	int mxln = 31500;
+	char *buf = kzalloc(mxln, GFP_KERNEL);
+	int q, res = 0;
+	struct wifi_mem_tracker *iesm;
+
+	if (!buf)
+		return 0;
+
+	spin_lock_bh(&ies_lock);
+	res += sprintf(buf + res, "Total: %i\n", atomic_read(&ies_count));
+	list_for_each_entry(iesm, &ies_list, mylist) {
+		res += sprintf(buf + res, "%p: %s\n",
+			       iesm->ptr, iesm->buf);
+		if (res >= mxln) {
+			res = mxln;
+			break;
+		}
+	}
+	spin_unlock_bh(&ies_lock);
+
+	q = simple_read_from_buffer(user_buf, count, ppos, buf, res);
+	kfree(buf);
+	return q;
+}
+
+static ssize_t all_bss_read(struct file *file, char __user *user_buf,
+			    size_t count, loff_t *ppos)
+{
+	int mxln = 31500;
+	char *buf = kzalloc(mxln, GFP_KERNEL);
+	int q, res = 0;
+	struct wifi_mem_tracker *bssm;
+
+	if (!buf)
+		return 0;
+
+	spin_lock_bh(&bss_lock);
+	res += sprintf(buf + res, "Total: %i\n", atomic_read(&bss_count));
+	list_for_each_entry(bssm, &bss_list, mylist) {
+		struct cfg80211_internal_bss *bss;
+		bss = (struct cfg80211_internal_bss *)(bssm->ptr);
+		res += sprintf(buf + res, "%p: #%lu %s\n",
+			       bssm->ptr, bss->refcount, bssm->buf);
+		if (res >= mxln) {
+			res = mxln;
+			break;
+		}
+	}
+	spin_unlock_bh(&bss_lock);
+
+	q = simple_read_from_buffer(user_buf, count, ppos, buf, res);
+	kfree(buf);
+	return q;
+}
+
+DEBUGFS_READONLY_FILE_OPS(all_ies);
+DEBUGFS_READONLY_FILE_OPS(all_bss);
+
+#endif
+
+static ssize_t bss_read(struct file *file, char __user *user_buf,
+			size_t count, loff_t *ppos)
+{
+	struct wiphy *wiphy = file->private_data;
+	struct cfg80211_registered_device *dev = wiphy_to_dev(wiphy);
+	int mxln = 31500;
+	char *buf = kzalloc(mxln, GFP_KERNEL);
+	int q, res = 0;
+	struct cfg80211_internal_bss *bss;
+
+	if (!buf)
+		return 0;
+
+	spin_lock_bh(&dev->bss_lock);
+	list_for_each_entry(bss, &dev->bss_list, list) {
+		res += sprintf(buf + res,
+			       "%p: #%lu  bcn: %p  pr: %p  hidden: %p\n",
+			       bss, bss->refcount,
+			       rcu_access_pointer(bss->pub.beacon_ies),
+			       rcu_access_pointer(bss->pub.proberesp_ies),
+			       bss->pub.hidden_beacon_bss);
+		if (res >= mxln) {
+			res = mxln;
+			break;
+		}
+	}
+	spin_unlock_bh(&dev->bss_lock);
+
+	q = simple_read_from_buffer(user_buf, count, ppos, buf, res);
+	kfree(buf);
+	return q;
+}
+
 DEBUGFS_READONLY_FILE(rts_threshold, 20, "%d",
 		      wiphy->rts_threshold)
 DEBUGFS_READONLY_FILE(fragmentation_threshold, 20, "%d",
@@ -39,6 +143,7 @@ DEBUGFS_READONLY_FILE(short_retry_limit, 20, "%d",
 		      wiphy->retry_short)
 DEBUGFS_READONLY_FILE(long_retry_limit, 20, "%d",
 		      wiphy->retry_long);
+DEBUGFS_READONLY_FILE_OPS(bss);
 
 static int ht_print_chan(struct ieee80211_channel *chan,
 			 char *buf, int buf_size, int offset)
@@ -112,4 +217,16 @@ void cfg80211_debugfs_rdev_add(struct cfg80211_registered_device *rdev)
 	DEBUGFS_ADD(short_retry_limit);
 	DEBUGFS_ADD(long_retry_limit);
 	DEBUGFS_ADD(ht40allow_map);
+	DEBUGFS_ADD(bss);
+}
+
+#define DEBUGFS_ADD_GLBL(name)						\
+	debugfs_create_file(#name, S_IRUGO, dir, NULL, &name## _ops);
+
+void ieee80211_debugfs_add_glbl(struct dentry *dir)
+{
+#ifdef CONFIG_CFG80211_MEM_DEBUGGING
+	DEBUGFS_ADD_GLBL(all_ies);
+	DEBUGFS_ADD_GLBL(all_bss);
+#endif
 }
diff --git a/net/wireless/debugfs.h b/net/wireless/debugfs.h
index 74fdd38..f644869 100644
--- a/net/wireless/debugfs.h
+++ b/net/wireless/debugfs.h
@@ -3,9 +3,11 @@
 
 #ifdef CONFIG_CFG80211_DEBUGFS
 void cfg80211_debugfs_rdev_add(struct cfg80211_registered_device *rdev);
+void ieee80211_debugfs_add_glbl(struct dentry *dir);
 #else
 static inline
 void cfg80211_debugfs_rdev_add(struct cfg80211_registered_device *rdev) {}
+static inline void ieee80211_debugfs_add_glbl(struct dentry *dir) { }
 #endif
 
 #endif /* __CFG80211_DEBUGFS_H */
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index dd01b58..abb0399 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -57,6 +57,106 @@
 
 #define IEEE80211_SCAN_RESULT_EXPIRE	(30 * HZ)
 
+#ifdef CONFIG_CFG80211_MEM_DEBUGGING
+
+LIST_HEAD(ies_list);
+DEFINE_SPINLOCK(ies_lock);
+atomic_t ies_count = ATOMIC_INIT(0);
+
+LIST_HEAD(bss_list);
+DEFINE_SPINLOCK(bss_lock);
+atomic_t bss_count = ATOMIC_INIT(0);
+
+
+static void my_kfree_rcu_ies(struct cfg80211_bss_ies *ies)
+{
+	struct wifi_mem_tracker *iesm;
+	spin_lock_bh(&ies_lock);
+	list_for_each_entry(iesm, &ies_list, mylist) {
+		if (iesm->ptr == ies) {
+			list_del(&iesm->mylist);
+			kfree(iesm);
+			break;
+		}
+	}
+	spin_unlock_bh(&ies_lock);
+	atomic_sub(1, &ies_count);
+	kfree_rcu(ies, rcu_head);
+}
+
+#define my_kmalloc_ies(s, g)				\
+	_my_kmalloc_ies(s, g, __LINE__);
+
+static void* _my_kmalloc_ies(size_t s, gfp_t gfp, int l)
+{
+	void *rv = kmalloc(s, gfp);
+	if (rv) {
+		struct wifi_mem_tracker *iesm = kmalloc(sizeof(*iesm), gfp);
+		atomic_add(1, &ies_count);
+		if (iesm) {
+			snprintf(iesm->buf, sizeof(iesm->buf), "%i", l);
+			iesm->buf[sizeof(iesm->buf)-1] = 0;
+			iesm->ptr = rv;
+			INIT_LIST_HEAD(&iesm->mylist);
+			spin_lock_bh(&ies_lock);
+			list_add(&iesm->mylist, &ies_list);
+			spin_unlock_bh(&ies_lock);
+		} else {
+			pr_err("ERROR:  Could not allocate iesm.\n");
+		}
+	}
+	return rv;
+}
+
+static void my_kfree_bss(struct cfg80211_internal_bss *bss)
+{
+	struct wifi_mem_tracker *bssm;
+	spin_lock_bh(&bss_lock);
+	list_for_each_entry(bssm, &bss_list, mylist) {
+		if (bssm->ptr == bss) {
+			list_del(&bssm->mylist);
+			kfree(bssm);
+			break;
+		}
+	}
+	atomic_sub(1, &bss_count);
+	spin_unlock_bh(&bss_lock);
+	kfree(bss);
+}
+
+#define my_kzalloc_bss(s, g)				\
+	_my_kzalloc_bss(s, g, __LINE__);
+
+static void* _my_kzalloc_bss(size_t s, gfp_t gfp, int l)
+{
+	void *rv = kmalloc(s, gfp);
+	if (rv) {
+		struct wifi_mem_tracker *bssm = kmalloc(sizeof(*bssm), gfp);
+		atomic_add(1, &bss_count);
+		if (bssm) {
+			snprintf(bssm->buf, sizeof(bssm->buf), "%i", l);
+			bssm->buf[sizeof(bssm->buf)-1] = 0;
+			bssm->ptr = rv;
+			INIT_LIST_HEAD(&bssm->mylist);
+			spin_lock_bh(&bss_lock);
+			list_add(&bssm->mylist, &bss_list);
+			spin_unlock_bh(&bss_lock);
+		} else {
+			pr_err("ERROR:  Could not allocate bssm for bss.\n");
+		}
+	}
+	return rv;
+}
+
+#else
+
+#define my_kfree_rcu_ies(ies) kfree_rcu(ies, rcu_head)
+#define my_kmalloc_ies(s, g) kmalloc(s, g)
+#define my_kfree_bss(a) kfree(a)
+#define my_kzalloc_bss(s, g) kzalloc(s, g)
+
+#endif
+
 static void bss_free(struct cfg80211_internal_bss *bss)
 {
 	struct cfg80211_bss_ies *ies;
@@ -66,10 +166,10 @@ static void bss_free(struct cfg80211_internal_bss *bss)
 
 	ies = (void *)rcu_access_pointer(bss->pub.beacon_ies);
 	if (ies && !bss->pub.hidden_beacon_bss)
-		kfree_rcu(ies, rcu_head);
+		my_kfree_rcu_ies(ies);
 	ies = (void *)rcu_access_pointer(bss->pub.proberesp_ies);
 	if (ies)
-		kfree_rcu(ies, rcu_head);
+		my_kfree_rcu_ies(ies);
 
 	/*
 	 * This happens when the module is removed, it doesn't
@@ -78,7 +178,7 @@ static void bss_free(struct cfg80211_internal_bss *bss)
 	if (!list_empty(&bss->hidden_list))
 		list_del(&bss->hidden_list);
 
-	kfree(bss);
+	my_kfree_bss(bss);
 }
 
 static inline void bss_ref_get(struct cfg80211_registered_device *dev,
@@ -711,8 +811,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
 			rcu_assign_pointer(found->pub.ies,
 					   tmp->pub.proberesp_ies);
 			if (old)
-				kfree_rcu((struct cfg80211_bss_ies *)old,
-					  rcu_head);
+				my_kfree_rcu_ies((struct cfg80211_bss_ies *)old);
 		} else if (rcu_access_pointer(tmp->pub.beacon_ies)) {
 			const struct cfg80211_bss_ies *old;
 			struct cfg80211_internal_bss *bss;
@@ -732,8 +831,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
 				 */
 
 				f = rcu_access_pointer(tmp->pub.beacon_ies);
-				kfree_rcu((struct cfg80211_bss_ies *)f,
-					  rcu_head);
+				my_kfree_rcu_ies((struct cfg80211_bss_ies *)f);
 				goto drop;
 			}
 
@@ -760,8 +858,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
 			}
 
 			if (old)
-				kfree_rcu((struct cfg80211_bss_ies *)old,
-					  rcu_head);
+				my_kfree_rcu_ies((struct cfg80211_bss_ies *)old);
 		}
 
 		found->pub.beacon_interval = tmp->pub.beacon_interval;
@@ -778,15 +875,15 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
 		 * is allocated on the stack since it's not needed in the
 		 * more common case of an update
 		 */
-		new = kzalloc(sizeof(*new) + dev->wiphy.bss_priv_size,
-			      GFP_ATOMIC);
+		new = my_kzalloc_bss(sizeof(*new) + dev->wiphy.bss_priv_size,
+				     GFP_ATOMIC);
 		if (!new) {
 			ies = (void *)rcu_dereference(tmp->pub.beacon_ies);
 			if (ies)
-				kfree_rcu(ies, rcu_head);
+				my_kfree_rcu_ies(ies);
 			ies = (void *)rcu_dereference(tmp->pub.proberesp_ies);
 			if (ies)
-				kfree_rcu(ies, rcu_head);
+				my_kfree_rcu_ies(ies);
 			goto drop;
 		}
 		memcpy(new, tmp, sizeof(*new));
@@ -900,7 +997,7 @@ cfg80211_inform_bss(struct wiphy *wiphy,
 	 * override the IEs pointer should we have received an earlier
 	 * indication of Probe Response data.
 	 */
-	ies = kmalloc(sizeof(*ies) + ielen, gfp);
+	ies = my_kmalloc_ies(sizeof(*ies) + ielen, gfp);
 	if (!ies)
 		return NULL;
 	ies->len = ielen;
@@ -957,7 +1054,7 @@ cfg80211_inform_bss_frame(struct wiphy *wiphy,
 	if (!channel)
 		return NULL;
 
-	ies = kmalloc(sizeof(*ies) + ielen, gfp);
+	ies = my_kmalloc_ies(sizeof(*ies) + ielen, gfp);
 	if (!ies)
 		return NULL;
 	ies->len = ielen;
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH-WN 2/2] ath9k_htc: Add ethtool stats support.
From: greearb @ 2013-06-19 21:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: ath9k-devel, Ben Greear
In-Reply-To: <1371675735-28591-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb@candelatech.com>

This provides some of the same info found in
the ath9k_htc debugfs through the standard ethtool stats API.

This logic is only supported when ath9k_htc debugfs kernel
feature is enabled, since that is the only time stats
are actually gathered.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---

This patch is against wireless-next, and has been tested
against my 3.9 tree for quite a while.

 drivers/net/wireless/ath/ath9k/hif_usb.c       |    8 ++-
 drivers/net/wireless/ath/ath9k/htc.h           |   14 ++++
 drivers/net/wireless/ath/ath9k/htc_drv_debug.c |   81 ++++++++++++++++++++++++
 drivers/net/wireless/ath/ath9k/htc_drv_main.c  |    6 ++
 4 files changed, 108 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..9e582e1 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -234,10 +234,15 @@ static inline void ath9k_skb_queue_complete(struct hif_device_usb *hif_dev,
 	struct sk_buff *skb;
 
 	while ((skb = __skb_dequeue(queue)) != NULL) {
+#ifdef CONFIG_ATH9K_HTC_DEBUGFS
+		int ln = skb->len;
+#endif
 		ath9k_htc_txcompletion_cb(hif_dev->htc_handle,
 					  skb, txok);
-		if (txok)
+		if (txok) {
 			TX_STAT_INC(skb_success);
+			TX_STAT_ADD(skb_success_bytes, ln);
+		}
 		else
 			TX_STAT_INC(skb_failed);
 	}
@@ -620,6 +625,7 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
 
 err:
 	for (i = 0; i < pool_index; i++) {
+		RX_STAT_ADD(skb_completed_bytes, skb_pool[i]->len);
 		ath9k_htc_rx_msg(hif_dev->htc_handle, skb_pool[i],
 				 skb_pool[i]->len, USB_WLAN_RX_PIPE);
 		RX_STAT_INC(skb_completed);
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 6bd556d..055d7c2 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -324,7 +324,9 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct sk_buff *skb)
 #ifdef CONFIG_ATH9K_HTC_DEBUGFS
 
 #define TX_STAT_INC(c) (hif_dev->htc_handle->drv_priv->debug.tx_stats.c++)
+#define TX_STAT_ADD(c, a) (hif_dev->htc_handle->drv_priv->debug.tx_stats.c += a)
 #define RX_STAT_INC(c) (hif_dev->htc_handle->drv_priv->debug.rx_stats.c++)
+#define RX_STAT_ADD(c, a) (hif_dev->htc_handle->drv_priv->debug.rx_stats.c += a)
 #define CAB_STAT_INC   priv->debug.tx_stats.cab_queued++
 
 #define TX_QSTAT_INC(q) (priv->debug.tx_stats.queue_stats[q]++)
@@ -337,6 +339,7 @@ struct ath_tx_stats {
 	u32 buf_completed;
 	u32 skb_queued;
 	u32 skb_success;
+	u32 skb_success_bytes;
 	u32 skb_failed;
 	u32 cab_queued;
 	u32 queue_stats[IEEE80211_NUM_ACS];
@@ -345,6 +348,7 @@ struct ath_tx_stats {
 struct ath_rx_stats {
 	u32 skb_allocated;
 	u32 skb_completed;
+	u32 skb_completed_bytes;
 	u32 skb_dropped;
 	u32 err_crc;
 	u32 err_decrypt_crc;
@@ -362,10 +366,20 @@ struct ath9k_debug {
 	struct ath_rx_stats rx_stats;
 };
 
+void ath9k_htc_get_et_strings(struct ieee80211_hw *hw,
+			      struct ieee80211_vif *vif,
+			      u32 sset, u8 *data);
+int ath9k_htc_get_et_sset_count(struct ieee80211_hw *hw,
+				struct ieee80211_vif *vif, int sset);
+void ath9k_htc_get_et_stats(struct ieee80211_hw *hw,
+			    struct ieee80211_vif *vif,
+			    struct ethtool_stats *stats, u64 *data);
 #else
 
 #define TX_STAT_INC(c) do { } while (0)
+#define TX_STAT_ADD(c, a) do { } while (0)
 #define RX_STAT_INC(c) do { } while (0)
+#define RX_STAT_ADD(c, a) do { } while (0)
 #define CAB_STAT_INC   do { } while (0)
 
 #define TX_QSTAT_INC(c) do { } while (0)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
index 632d13d..7416d58 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
@@ -902,6 +902,87 @@ static const struct file_operations fops_modal_eeprom = {
 	.llseek = default_llseek,
 };
 
+
+/* Ethtool support for get-stats */
+#define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
+static const char ath9k_htc_gstrings_stats[][ETH_GSTRING_LEN] = {
+	"tx_pkts_nic",
+	"tx_bytes_nic",
+	"rx_pkts_nic",
+	"rx_bytes_nic",
+
+	AMKSTR(d_tx_pkts),
+
+	"d_rx_crc_err",
+	"d_rx_decrypt_crc_err",
+	"d_rx_phy_err",
+	"d_rx_mic_err",
+	"d_rx_pre_delim_crc_err",
+	"d_rx_post_delim_crc_err",
+	"d_rx_decrypt_busy_err",
+
+	"d_rx_phyerr_radar",
+	"d_rx_phyerr_ofdm_timing",
+	"d_rx_phyerr_cck_timing",
+
+};
+#define ATH9K_HTC_SSTATS_LEN ARRAY_SIZE(ath9k_htc_gstrings_stats)
+
+void ath9k_htc_get_et_strings(struct ieee80211_hw *hw,
+			      struct ieee80211_vif *vif,
+			      u32 sset, u8 *data)
+{
+	if (sset == ETH_SS_STATS)
+		memcpy(data, *ath9k_htc_gstrings_stats,
+		       sizeof(ath9k_htc_gstrings_stats));
+}
+
+int ath9k_htc_get_et_sset_count(struct ieee80211_hw *hw,
+				struct ieee80211_vif *vif, int sset)
+{
+	if (sset == ETH_SS_STATS)
+		return ATH9K_HTC_SSTATS_LEN;
+	return 0;
+}
+
+#define STXBASE priv->debug.tx_stats
+#define SRXBASE priv->debug.rx_stats
+#define ASTXQ(a)					\
+	data[i++] = STXBASE.a[IEEE80211_AC_BE];		\
+	data[i++] = STXBASE.a[IEEE80211_AC_BK];		\
+	data[i++] = STXBASE.a[IEEE80211_AC_VI];		\
+	data[i++] = STXBASE.a[IEEE80211_AC_VO]
+
+void ath9k_htc_get_et_stats(struct ieee80211_hw *hw,
+			    struct ieee80211_vif *vif,
+			    struct ethtool_stats *stats, u64 *data)
+{
+	struct ath9k_htc_priv *priv = hw->priv;
+	int i = 0;
+
+	data[i++] = STXBASE.skb_success;
+	data[i++] = STXBASE.skb_success_bytes;
+	data[i++] = SRXBASE.skb_completed;
+	data[i++] = SRXBASE.skb_completed_bytes;
+
+	ASTXQ(queue_stats);
+
+	data[i++] = SRXBASE.err_crc;
+	data[i++] = SRXBASE.err_decrypt_crc;
+	data[i++] = SRXBASE.err_phy;
+	data[i++] = SRXBASE.err_mic;
+	data[i++] = SRXBASE.err_pre_delim;
+	data[i++] = SRXBASE.err_post_delim;
+	data[i++] = SRXBASE.err_decrypt_busy;
+
+	data[i++] = SRXBASE.err_phy_stats[ATH9K_PHYERR_RADAR];
+	data[i++] = SRXBASE.err_phy_stats[ATH9K_PHYERR_OFDM_TIMING];
+	data[i++] = SRXBASE.err_phy_stats[ATH9K_PHYERR_CCK_TIMING];
+
+	WARN_ON(i != ATH9K_HTC_SSTATS_LEN);
+}
+
+
 int ath9k_htc_init_debug(struct ath_hw *ah)
 {
 	struct ath_common *common = ath9k_hw_common(ah);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index ef68857..be6baf7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1837,4 +1837,10 @@ struct ieee80211_ops ath9k_htc_ops = {
 	.set_bitrate_mask   = ath9k_htc_set_bitrate_mask,
 	.get_stats	    = ath9k_htc_get_stats,
 	.get_antenna	    = ath9k_htc_get_antenna,
+
+#ifdef CONFIG_ATH9K_HTC_DEBUGFS
+	.get_et_sset_count  = ath9k_htc_get_et_sset_count,
+	.get_et_stats       = ath9k_htc_get_et_stats,
+	.get_et_strings     = ath9k_htc_get_et_strings,
+#endif
 };
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH-WN 1/2] ath9k_htc: Support reporting tx and rx chain mask.
From: greearb @ 2013-06-19 21:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: ath9k-devel, Ben Greear

From: Ben Greear <greearb@candelatech.com>

Signed-off-by: Ben Greear <greearb@candelatech.com>
---

This is against wireless-next, and has been in my 3.9 tree for
some time.

 drivers/net/wireless/ath/ath9k/htc.h           |    2 +
 drivers/net/wireless/ath/ath9k/htc_drv_debug.c |   16 +---------
 drivers/net/wireless/ath/ath9k/htc_drv_init.c  |    7 ++++
 drivers/net/wireless/ath/ath9k/htc_drv_main.c  |   38 ++++++++++++++++++++++++
 4 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 6958103..6bd556d 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -583,6 +583,8 @@ bool ath9k_htc_setpower(struct ath9k_htc_priv *priv,
 void ath9k_start_rfkill_poll(struct ath9k_htc_priv *priv);
 void ath9k_htc_rfkill_poll_state(struct ieee80211_hw *hw);
 
+struct base_eep_header *ath9k_htc_get_eeprom_base(struct ath9k_htc_priv *priv);
+
 #ifdef CONFIG_MAC80211_LEDS
 void ath9k_init_leds(struct ath9k_htc_priv *priv);
 void ath9k_deinit_leds(struct ath9k_htc_priv *priv);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
index 87110de5..632d13d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
@@ -496,21 +496,7 @@ static ssize_t read_file_base_eeprom(struct file *file, char __user *user_buf,
 	ssize_t retval = 0;
 	char *buf;
 
-	/*
-	 * This can be done since all the 3 EEPROM families have the
-	 * same base header upto a certain point, and we are interested in
-	 * the data only upto that point.
-	 */
-
-	if (AR_SREV_9271(priv->ah))
-		pBase = (struct base_eep_header *)
-			&priv->ah->eeprom.map4k.baseEepHeader;
-	else if (priv->ah->hw_version.usbdev == AR9280_USB)
-		pBase = (struct base_eep_header *)
-			&priv->ah->eeprom.def.baseEepHeader;
-	else if (priv->ah->hw_version.usbdev == AR9287_USB)
-		pBase = (struct base_eep_header *)
-			&priv->ah->eeprom.map9287.baseEepHeader;
+	pBase = ath9k_htc_get_eeprom_base(priv);
 
 	if (pBase == NULL) {
 		ath_err(common, "Unknown EEPROM type\n");
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index bb0ba9e..925c5b0 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -716,6 +716,7 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
 			       struct ieee80211_hw *hw)
 {
 	struct ath_common *common = ath9k_hw_common(priv->ah);
+	struct base_eep_header *pBase;
 
 	hw->flags = IEEE80211_HW_SIGNAL_DBM |
 		IEEE80211_HW_AMPDU_AGGREGATION |
@@ -771,6 +772,12 @@ static void ath9k_set_hw_capab(struct ath9k_htc_priv *priv,
 				     &priv->sbands[IEEE80211_BAND_5GHZ].ht_cap);
 	}
 
+	pBase = ath9k_htc_get_eeprom_base(priv);
+	if (pBase) {
+		hw->wiphy->available_antennas_rx = pBase->rxMask;
+		hw->wiphy->available_antennas_tx = pBase->txMask;
+	}
+
 	SET_IEEE80211_PERM_ADDR(hw, common->macaddr);
 }
 
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index eaa94fe..ef68857 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1774,6 +1774,43 @@ static int ath9k_htc_get_stats(struct ieee80211_hw *hw,
 	return 0;
 }
 
+struct base_eep_header *ath9k_htc_get_eeprom_base(struct ath9k_htc_priv *priv)
+{
+	struct base_eep_header *pBase = NULL;
+	/*
+	 * This can be done since all the 3 EEPROM families have the
+	 * same base header upto a certain point, and we are interested in
+	 * the data only upto that point.
+	 */
+
+	if (AR_SREV_9271(priv->ah))
+		pBase = (struct base_eep_header *)
+			&priv->ah->eeprom.map4k.baseEepHeader;
+	else if (priv->ah->hw_version.usbdev == AR9280_USB)
+		pBase = (struct base_eep_header *)
+			&priv->ah->eeprom.def.baseEepHeader;
+	else if (priv->ah->hw_version.usbdev == AR9287_USB)
+		pBase = (struct base_eep_header *)
+			&priv->ah->eeprom.map9287.baseEepHeader;
+	return pBase;
+}
+
+
+static int ath9k_htc_get_antenna(struct ieee80211_hw *hw, u32 *tx_ant,
+				 u32 *rx_ant)
+{
+	struct ath9k_htc_priv *priv = hw->priv;
+	struct base_eep_header *pBase = ath9k_htc_get_eeprom_base(priv);
+	if (pBase) {
+		*tx_ant = pBase->txMask;
+		*rx_ant = pBase->rxMask;
+	} else {
+		*tx_ant = 0;
+		*rx_ant = 0;
+	}
+	return 0;
+}
+
 struct ieee80211_ops ath9k_htc_ops = {
 	.tx                 = ath9k_htc_tx,
 	.start              = ath9k_htc_start,
@@ -1799,4 +1836,5 @@ struct ieee80211_ops ath9k_htc_ops = {
 	.set_coverage_class = ath9k_htc_set_coverage_class,
 	.set_bitrate_mask   = ath9k_htc_set_bitrate_mask,
 	.get_stats	    = ath9k_htc_get_stats,
+	.get_antenna	    = ath9k_htc_get_antenna,
 };
-- 
1.7.3.4


^ permalink raw reply related

* Re: BCM4331 deauthenticates every five minutes
From: Arend van Spriel @ 2013-06-19 20:58 UTC (permalink / raw)
  To: Chris Adams
  Cc: Rafał Miłecki, Larry Finger, b43-dev, linux-wireless
In-Reply-To: <20130619175850.GD4784@cmadams.net>

On 06/19/2013 07:58 PM, Chris Adams wrote:
> Once upon a time, Rafał Miłecki <zajec5@gmail.com> said:
>> I don't know how/if driver can be responsible for such reconnects.
>> Over all it just TX and RX packets, right? Loosing a signal is
>> something different, that can be related to the driver's bug. But as
>> this happens every 5 minutes... I don't know.
>>
>> Did you try connecting to this AP with any other card and using
>> similar kernel? I wonder if this can be some supplicant / mac80211
>> stack issue...
>
> I just fired up my Thinkpad T510 with an Intel "Centrino Ultimate-N
> 6300" using iwlwifi, and it stays connected (does not appear to drop any
> packets).  This is also Fedora 18 x86_64 (slightly older kernel, but
> I've had the problem on the MacBook since I installed it).  There are
> other people in the office with the same MacBook hardware (but running
> OS X) that don't appear to be having any trouble either.
>
> The AP appears to be an Adtran (don't know the model).
>

Can you make a capture using a wireless sniffer (using your thinkpad maybe)?

Gr. AvS


^ permalink raw reply

* regulatory splat in wireless-next (3.10.0-rc1+)
From: Ben Greear @ 2013-06-19 20:50 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org

I have just a few small patches in this tree, so probably not my fault :)

 From this code in reg.c:

/*
  * Restoring regulatory settings involves ingoring any
  * possibly stale country IE information and user regulatory
  * settings if so desired, this includes any beacon hints
  * learned as we could have traveled outside to another country
  * after disconnection. To restore regulatory settings we do
  * exactly what we did at bootup:
  *
  *   - send a core regulatory hint
  *   - send a user regulatory hint if applicable
  *
  * Device drivers that send a regulatory hint for a specific country
  * keep their own regulatory domain on wiphy->regd so that does does
  * not need to be remembered.
  */
static void restore_regulatory_settings(bool reset_user)
{
	char alpha2[2];
	char world_alpha2[2];
	struct reg_beacon *reg_beacon, *btmp;
	struct regulatory_request *reg_request, *tmp;
	LIST_HEAD(tmp_reg_req_list);
	struct cfg80211_registered_device *rdev;

	ASSERT_RTNL();

	reset_regdomains(true, &world_regdom);
	restore_alpha2(alpha2, reset_user);


cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
cfg80211: Disabling freq 2484 MHz
cfg80211: Ignoring regulatory request Set by driver since the driver requires its own regulatory domain to be set first
cfg80211: Ignoring regulatory request Set by driver since the driver requires its own regulatory domain to be set first
cfg80211: Current regulatory domain intersected:
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm)
cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
cfg80211: Timeout while waiting for CRDA to reply, restoring regulatory settings
RTNL: assertion failed at /home/greearb/git/linux.wireless-next/net/wireless/reg.c (1831)
CPU: 2 PID: 164 Comm: kworker/2:1 Not tainted 3.10.0-rc1+ #3
Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.3 09/05/2011
Workqueue: events reg_timeout_work [cfg80211]
  ffff88022bd13880 ffff8802178a5db8 ffffffff815d0e01 ffff8802178a5e08
  ffffffffa026d777 ffff8802178a5dc8 ffff8802178a5dc8 0000000000014000
  0000000000000080 0000000000000000 ffff880222240380 ffff88022bd13880
Call Trace:
  [<ffffffff815d0e01>] dump_stack+0x19/0x20
  [<ffffffffa026d777>] restore_regulatory_settings+0x47/0x3f7 [cfg80211]
  [<ffffffffa026db48>] reg_timeout_work+0x21/0x23 [cfg80211]
  [<ffffffff810b7dac>] process_one_work+0x23d/0x37f
  [<ffffffff810b805c>] worker_thread+0x16e/0x283
  [<ffffffff810b7eee>] ? process_one_work+0x37f/0x37f
  [<ffffffff810bde31>] kthread+0xb5/0xbd
  [<ffffffff810bdd7c>] ? kthread_freezable_should_stop+0x60/0x60
  [<ffffffff815d9c2c>] ret_from_fork+0x7c/0xb0
  [<ffffffff810bdd7c>] ? kthread_freezable_should_stop+0x60/0x60
RTNL: assertion failed at /home/greearb/git/linux.wireless-next/net/wireless/reg.c (207)
CPU: 2 PID: 164 Comm: kworker/2:1 Not tainted 3.10.0-rc1+ #3
Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.3 09/05/2011
Workqueue: events reg_timeout_work [cfg80211]
  ffffffffa029c140 ffff8802178a5d98 ffffffff815d0e01 ffff8802178a5db8
  ffffffffa026d55c ffff880222240301 ffff88022bd13880 ffff8802178a5e08
  ffffffffa026d788 ffff8802178a5dc8 ffff8802178a5dc8 0000000000014000
Call Trace:
  [<ffffffff815d0e01>] dump_stack+0x19/0x20
  [<ffffffffa026d55c>] reset_regdomains+0x38/0xce [cfg80211]
  [<ffffffffa026d788>] restore_regulatory_settings+0x58/0x3f7 [cfg80211]
  [<ffffffffa026db48>] reg_timeout_work+0x21/0x23 [cfg80211]
  [<ffffffff810b7dac>] process_one_work+0x23d/0x37f
  [<ffffffff810b805c>] worker_thread+0x16e/0x283
  [<ffffffff810b7eee>] ? process_one_work+0x37f/0x37f
  [<ffffffff810bde31>] kthread+0xb5/0xbd
  [<ffffffff810bdd7c>] ? kthread_freezable_should_stop+0x60/0x60
  [<ffffffff815d9c2c>] ret_from_fork+0x7c/0xb0
  [<ffffffff810bdd7c>] ? kthread_freezable_should_stop+0x60/0x60
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
cfg80211: Restoring regulatory settings including user preference
cfg80211: Kicking the queue
cfg80211: Calling CRDA to update world regulatory domain

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* Re: [PATCH 2/2] cfg80211: hold BSS over association process
From: Johannes Berg @ 2013-06-19 20:36 UTC (permalink / raw)
  To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <51C21476.2070401@candelatech.com>

On Wed, 2013-06-19 at 13:28 -0700, Ben Greear wrote:
> On 06/19/2013 06:53 AM, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > This fixes the potential issue that the BSS struct that we use
> > and later assign to wdev->current_bss is removed from the scan
> > list while associating.
> >
> > Also warn when we don't have a BSS struct in connect_result
> > unless it's from a driver that only has the connect() API.
> 
> I ran these two patches, plus my memory debugging patch
> on top of wireless-testing (in relatively light testing).
> 
> It appears to fix the leaks I was seeing.
> 
> Just to make sure I am not missing something:
> 
> mac80211 should never take an additional reference
> on the bss related to auth_data now?

On *auth_data* it takes and (unconditionally) puts one. On *assoc_data*
the reference is only temporarily owned by mac80211 until given back to
cfg80211, and unless mac80211 wanted to have a separate one afterwards
it doesn't need one (it would probably make sense to take one for
"ifmgd->associated" though, but currently it relies on that being the
same as "wdev->current_bss")

johannes


^ permalink raw reply

* Re: [PATCH 2/2] cfg80211: hold BSS over association process
From: Ben Greear @ 2013-06-19 20:28 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1371650017-14293-2-git-send-email-johannes@sipsolutions.net>

On 06/19/2013 06:53 AM, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This fixes the potential issue that the BSS struct that we use
> and later assign to wdev->current_bss is removed from the scan
> list while associating.
>
> Also warn when we don't have a BSS struct in connect_result
> unless it's from a driver that only has the connect() API.

I ran these two patches, plus my memory debugging patch
on top of wireless-testing (in relatively light testing).

It appears to fix the leaks I was seeing.

Just to make sure I am not missing something:

mac80211 should never take an additional reference
on the bss related to auth_data now?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* Re: [PATCH mac80211-next] brcm80211: fix null pointer access
From: Antonio Quartulli @ 2013-06-19 19:48 UTC (permalink / raw)
  To: John W. Linville
  Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <20130619192714.GF12079@tuxdriver.com>

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

Hi John,

On Wed, Jun 19, 2013 at 12:27:14PM -0700, John W. Linville wrote:
> FWIW, driver fixes like this come to me rather than Johannes...
> 

I sent this to Johannes because this is fixing a patch I sent a couple of days
ago, and therefore I did not know if this patch was already in your tree or not.

Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* pull request: wireless 2013-06-19
From: John W. Linville @ 2013-06-19 19:41 UTC (permalink / raw)
  To: davem; +Cc: linux-wireless, netdev, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

Dave,

One more late-breaking fix in the nl80211 code, the fix for the
nl80211_fam.attrbuf race Linus ran into and analysed.  Hopefully it
looks familiar... :-)

Let me know if there are problems!

John

---

The following changes since commit eb064c3b49931dc73bba59887019c7f5cb97d322:

  vxlan: fix check for migration of static entry (2013-06-19 00:50:58 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem

for you to fetch changes up to 4067c666f2dccf56f5db5c182713e68c40d46013:

  Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-06-19 15:24:36 -0400)

----------------------------------------------------------------

Johannes Berg (1):
      nl80211: fix attrbuf access race by allocating a separate one

John W. Linville (2):
      Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
      Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem

 net/wireless/nl80211.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d5aed3b..b14b7e3 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1564,12 +1564,17 @@ static int nl80211_dump_wiphy(struct sk_buff *skb, struct netlink_callback *cb)
 	struct cfg80211_registered_device *dev;
 	s64 filter_wiphy = -1;
 	bool split = false;
-	struct nlattr **tb = nl80211_fam.attrbuf;
+	struct nlattr **tb;
 	int res;
 
+	/* will be zeroed in nlmsg_parse() */
+	tb = kmalloc(sizeof(*tb) * (NL80211_ATTR_MAX + 1), GFP_KERNEL);
+	if (!tb)
+		return -ENOMEM;
+
 	mutex_lock(&cfg80211_mutex);
 	res = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
-			  tb, nl80211_fam.maxattr, nl80211_policy);
+			  tb, NL80211_ATTR_MAX, nl80211_policy);
 	if (res == 0) {
 		split = tb[NL80211_ATTR_SPLIT_WIPHY_DUMP];
 		if (tb[NL80211_ATTR_WIPHY])
@@ -1583,6 +1588,7 @@ static int nl80211_dump_wiphy(struct sk_buff *skb, struct netlink_callback *cb)
 			netdev = dev_get_by_index(sock_net(skb->sk), ifidx);
 			if (!netdev) {
 				mutex_unlock(&cfg80211_mutex);
+				kfree(tb);
 				return -ENODEV;
 			}
 			if (netdev->ieee80211_ptr) {
@@ -1593,6 +1599,7 @@ static int nl80211_dump_wiphy(struct sk_buff *skb, struct netlink_callback *cb)
 			dev_put(netdev);
 		}
 	}
+	kfree(tb);
 
 	list_for_each_entry(dev, &cfg80211_rdev_list, list) {
 		if (!net_eq(wiphy_net(&dev->wiphy), sock_net(skb->sk)))
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 19:36 UTC (permalink / raw)
  To: Ben Greear
  Cc: Oleksij Rempel, Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FAFB.9090209@candelatech.com>

On Wed, Jun 19, 2013 at 11:39:55AM -0700, thus spake Ben Greear:
> Does the ath9k_htc do it's own rate control, perhaps modelled on
> ath9k_rate_control algorithm?

Do you mean ATH9K_LEGACY_RATE_CONTROL ?

> If so, that could be the problem...it has issues with associating when
> network conditions are poor...

Frankly, I doubt this is the case.  With so many different setups, and the AP
is like one meter away from the station right now.

-- 
The groove will take you through times without money
much better than money will take you through times without groove.

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 19:33 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FA76.3090109@rempel-privat.de>

On Wed, Jun 19, 2013 at 08:37:42PM +0200, thus spake Oleksij Rempel:
> Can you please tell more about your access point:
> - hardware
> - firmware
> - configuration
> - "iw dev wlan0 scan dump"

I tested the thing with at least three different APs:

  - Netgear DG834Gv4 with latest firmware.
  - Netgear DG834Gv5 (don't know which firmware and can't check at this time).
  - hostapd (can't say which version at this time either) with the same
    ath9k_htc.

All APs are configured for WPA2-PSK.

The scan dump for the first AP:

BSS 00:1e:2a:ed:35:70 (on wlan7)
        TSF: 163623606 usec (0d, 00:02:43)
        freq: 2412
        beacon interval: 100
        capability: ESS Privacy ShortSlotTime (0x0411)
        signal: -43.00 dBm
        last seen: 24 ms ago
        Information elements from Probe Response frame:
        SSID: Wolfnet
        Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
        DS Parameter set: channel 1
        ERP: Barker_Preamble_Mode
        RSN:     * Version: 1
                 * Group cipher: CCMP
                 * Pairwise ciphers: CCMP
                 * Authentication suites: PSK
                 * Capabilities: 16-PTKSA-RC (0x000c)
        Extended supported rates: 6.0 9.0 12.0 48.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: CW 3-7, AIFSN 2, TXOP 1504 usec

-- 
Save the whales. Feed the hungry. Free the mallocs. 

^ permalink raw reply

* Re: BCM4331 deauthenticates every five minutes
From: Rafał Miłecki @ 2013-06-19 19:30 UTC (permalink / raw)
  To: Rafał Miłecki, Larry Finger, b43-dev, linux-wireless
In-Reply-To: <20130619175850.GD4784@cmadams.net>

2013/6/19 Chris Adams <cma@cmadams.net>:
> Once upon a time, Rafał Miłecki <zajec5@gmail.com> said:
>> I don't know how/if driver can be responsible for such reconnects.
>> Over all it just TX and RX packets, right? Loosing a signal is
>> something different, that can be related to the driver's bug. But as
>> this happens every 5 minutes... I don't know.
>>
>> Did you try connecting to this AP with any other card and using
>> similar kernel? I wonder if this can be some supplicant / mac80211
>> stack issue...
>
> I just fired up my Thinkpad T510 with an Intel "Centrino Ultimate-N
> 6300" using iwlwifi, and it stays connected (does not appear to drop any
> packets).  This is also Fedora 18 x86_64 (slightly older kernel, but
> I've had the problem on the MacBook since I installed it).  There are
> other people in the office with the same MacBook hardware (but running
> OS X) that don't appear to be having any trouble either.
>
> The AP appears to be an Adtran (don't know the model).

Thanks for info/testing. I still wonder how driver's code can cause
any disconnections happening exactly every 5 minutes... Any idea
anyone?

One bug that was recently discovered and that sits in b43's code is
passive scanning. For some reason it seems b43 doesn't do passive
scanning, I didn't have time to debug that yet. I wonder if this can
affect connection stability anyhow.

Perhaps you could try performing manual scanning every ~minute? It's
really just a crazy guess, I don't have any idea why it could help.
But it's so trivial you may want to give it a try.

-- 
Rafał

^ permalink raw reply

* Re: [PATCH mac80211-next] brcm80211: fix null pointer access
From: John W. Linville @ 2013-06-19 19:27 UTC (permalink / raw)
  To: Antonio Quartulli; +Cc: Johannes Berg, linux-wireless, Antonio Quartulli
In-Reply-To: <1371641731-1297-1-git-send-email-ordex@autistici.org>

FWIW, driver fixes like this come to me rather than Johannes...

On Wed, Jun 19, 2013 at 01:35:31PM +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
> 
> Do not unconditionally access the chan variable in
> brcmf_cfg80211_mgmt_tx() as it may be NULL.
> Use freq instead.
> 
> Introduced by c2ff8cad64233b539c71a27e2a6e324001143ef0
> ("brcm80211: make mgmt_tx in brcmfmac accept a NULL channel")
> 
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> ---
>  drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> index 8bd256b..d316d62 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> @@ -3985,8 +3985,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
>  		       le16_to_cpu(action_frame->len));
>  
>  		brcmf_dbg(TRACE, "Action frame, cookie=%lld, len=%d, freq=%d\n",
> -			  *cookie, le16_to_cpu(action_frame->len),
> -			  chan->center_freq);
> +			  *cookie, le16_to_cpu(action_frame->len), freq);
>  
>  		ack = brcmf_p2p_send_action_frame(cfg, cfg_to_ndev(cfg),
>  						  af_params);
> -- 
> 1.8.1.5
> 
> --
> 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
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: pull-request: mac80211 2013-06-19
From: John W. Linville @ 2013-06-19 19:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1371659691.8349.24.camel@jlt4.sipsolutions.net>

On Wed, Jun 19, 2013 at 06:34:51PM +0200, Johannes Berg wrote:
> Hi John,
> 
> One more ...
> 
> This is just the fix for the nl80211_fam.attrbuf race Linus ran into and
> analysed.
> 
> johannes
> 
> The following changes since commit 795d855d56c6d172f50a974f603ba923ac93ee76:
> 
>   mac80211: Fix rate control mask matching call (2013-06-12 09:12:43 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
> 
> for you to fetch changes up to 3a5a423bb958ad22eeccca66c533e85bf69ba10e:
> 
>   nl80211: fix attrbuf access race by allocating a separate one (2013-06-19 18:31:20 +0200)
> 
> ----------------------------------------------------------------
> Johannes Berg (1):
>       nl80211: fix attrbuf access race by allocating a separate one
> 
>  net/wireless/nl80211.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)

Pulling now...

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 18:55 UTC (permalink / raw)
  To: Ben Greear
  Cc: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FAFB.9090209@candelatech.com>

Am 19.06.2013 20:39, schrieb Ben Greear:
> On 06/19/2013 11:37 AM, Oleksij Rempel wrote:
>>
>>
>> Am 19.06.2013 20:03, schrieb Ignacy Gawedzki:
>>> On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
>>>> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
>>>>> Ignacy, Is it RPi +  TL-WN722NC?
>>>>
>>>> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu
>>>> 13.04).
>>>
>>> BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
>>
>> Can you please tell more about your access point:
>> - hardware
>> - firmware
>> - configuration
>> - "iw dev wlan0 scan dump"
>
> Does the ath9k_htc do it's own rate control, perhaps modelled on
> ath9k_rate_control
> algorithm?
>
> If so, that could be the problem...it has issues with associating when
> network conditions are poor...

uff... yeah... we can't do comparison test :( except just come closer to AP.

-- 
Regards,
Oleksij

^ permalink raw reply

* Re: Howto remove rfkill from kernel
From: John W. Linville @ 2013-06-19 18:38 UTC (permalink / raw)
  To: rlwkayaker; +Cc: linux-wireless
In-Reply-To: <20130619133638.3d183a00@compuzoo>

On Wed, Jun 19, 2013 at 01:36:38PM -0400, rlwkayaker wrote:
> The rfkill "feature" has rendered the internal wireless of my
> Averatec 3260 laptop unusable.  It works fine with earlier
> kernels without this "feature".  How do I remove the rfkill
> "feature" from a custom built kernel?

The rfkill "feature" has been in the kernel for years.  Exactly what
kernels are you using?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Corey Richardson @ 2013-06-19 18:44 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Johannes Berg, Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org
In-Reply-To: <51C1FA33.2050308@rempel-privat.de>

On Wed, Jun 19, 2013 at 2:36 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Every thing about your old WAP and symptoms of problems you had.
> - hardware. also you ath9k_htc adapter too

The adapter is a netgear WNA1100. The WAP actually died,
unfortunately, it will no longer boot up, and I no longer have it, but
it was an HP ProCurve something-or-another.

Sorry I can't be more useful :(

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ben Greear @ 2013-06-19 18:39 UTC (permalink / raw)
  To: Oleksij Rempel
  Cc: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <51C1FA76.3090109@rempel-privat.de>

On 06/19/2013 11:37 AM, Oleksij Rempel wrote:
>
>
> Am 19.06.2013 20:03, schrieb Ignacy Gawedzki:
>> On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
>>> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
>>>> Ignacy, Is it RPi +  TL-WN722NC?
>>>
>>> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
>>
>> BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.
>
> Can you please tell more about your access point:
> - hardware
> - firmware
> - configuration
> - "iw dev wlan0 scan dump"

Does the ath9k_htc do it's own rate control, perhaps modelled on ath9k_rate_control
algorithm?

If so, that could be the problem...it has issues with associating when
network conditions are poor...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 18:37 UTC (permalink / raw)
  To: Ignacy Gawedzki, Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <20130619180354.GB19405@zenon.in.qult.net>



Am 19.06.2013 20:03, schrieb Ignacy Gawedzki:
> On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
>> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
>>> Ignacy, Is it RPi +  TL-WN722NC?
>>
>> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).
>
> BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.

Can you please tell more about your access point:
- hardware
- firmware
- configuration
- "iw dev wlan0 scan dump"

-- 
Regards,
Oleksij

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Oleksij Rempel @ 2013-06-19 18:36 UTC (permalink / raw)
  To: Corey Richardson
  Cc: Johannes Berg, Ignacy Gawedzki, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org
In-Reply-To: <CA++BO6Rsys5Q_Wxuhcm+00uMvJq3HF2GcU7LmuVsYWq_BW-svw@mail.gmail.com>

Am 19.06.2013 17:11, schrieb Corey Richardson:
> On Wed, Jun 19, 2013 at 11:08 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 19.06.2013 16:11, schrieb Johannes Berg:
>>>
>>> Btw, I'm a bit confused -- are you using ath9k_htc as per the subject,
>>> or ath9k?
>>>
>>> if it's ath9k_htc then I don't really understand why the patch that
>>> *fixed* it for Corey *broke* it for you?
>>>
>>> johannes
>>
>>
>> It will be interesting to get some more info from Corey, about his wireless
>> setup.
>>
>
> It seems many of my issues were related to a faulty WAP, once I
> replaced it with a different one 90% of my problems went away. What
> information do you want?

Every thing about your old WAP and symptoms of problems you had.
- hardware. also you ath9k_htc adapter too
- firmware
- configuration
- "iw dev wlan0 scan dump"

Currently we have diffetrent mystical bugs, which are impossible to 
reproduce some where else. So we will just collect every information we 
can find.

-- 
Regards,
Oleksij

^ permalink raw reply

* Re: BCM4331 deauthenticates every five minutes
From: Chris Adams @ 2013-06-19 17:58 UTC (permalink / raw)
  To: Rafał Miłecki; +Cc: Larry Finger, b43-dev, linux-wireless
In-Reply-To: <CACna6rzbTHnyqs5SzTuYL7r_SW3iCNh0qqbnvfsF7Wspyhp1WA@mail.gmail.com>

Once upon a time, Rafał Miłecki <zajec5@gmail.com> said:
> I don't know how/if driver can be responsible for such reconnects.
> Over all it just TX and RX packets, right? Loosing a signal is
> something different, that can be related to the driver's bug. But as
> this happens every 5 minutes... I don't know.
> 
> Did you try connecting to this AP with any other card and using
> similar kernel? I wonder if this can be some supplicant / mac80211
> stack issue...

I just fired up my Thinkpad T510 with an Intel "Centrino Ultimate-N
6300" using iwlwifi, and it stays connected (does not appear to drop any
packets).  This is also Fedora 18 x86_64 (slightly older kernel, but
I've had the problem on the MacBook since I installed it).  There are
other people in the office with the same MacBook hardware (but running
OS X) that don't appear to be having any trouble either.

The AP appears to be an Adtran (don't know the model).

-- 
Chris Adams <cma@cmadams.net>

^ permalink raw reply

* Re: [ath9k-devel] ath9k_htc: station unable to authenticate
From: Ignacy Gawedzki @ 2013-06-19 18:03 UTC (permalink / raw)
  To: Oleksij Rempel, Johannes Berg, ath9k-devel@lists.ath9k.org,
	linux-wireless@vger.kernel.org, Corey Richardson
In-Reply-To: <20130619175939.GA19405@zenon.in.qult.net>

On Wed, Jun 19, 2013 at 07:59:39PM +0200, thus spake Ignacy Gawedzki:
> On Wed, Jun 19, 2013 at 05:08:12PM +0200, thus spake Oleksij Rempel:
> > Ignacy, Is it RPi +  TL-WN722NC?
> 
> Yes, absolutely, but it happens on a Dell XPS 13" as well (Ubuntu 13.04).

BTW, removing CFG80211_DEFAULT_PS doesn't make any difference.

-- 
Everything is more fun naked except cooking with grease.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox