Re: ath10k monitor mode issue

2017-03-20 Thread Alexis Green 
As far as I understand, only CT firmware provides per-packet
information about TX rate at the moment.
http://www.candelatech.com/ath10k-10.4.php

Best regards,

Alexis

On Mon, Mar 20, 2017 at 11:00 AM, Matteo Grandi  wrote:
> Hello all,
>
> I have an issue to collect tx/rx bitrates using ath10k.
> I want to collect Tx/RX statistics on a mesh network using
> compexWLE900VX Wi-Fi miniPCIe adapters chipset QCA9884 (QCA988X) with
> ath10k firmware firmware-5.bin_10.2.4.70.59-2.
>
> The OS is Ubuntu 14.04 kernel 3.14.48 backports 4.4.2.
>
> I'm able to build the mesh without any problem and I already have read
> that ath10k firmware doesn't provide correct TX/RX information.
> Using "iw  station dump" I can see the tx bitrate stuck on
> 6Mbps and the rx giving unreliable information about MCS, NSS, bitrate
> etc.
> I tried using iw version 3.4, 3.6 and 4.9.
>
> I really need to retrieve these info, and I tried also sniffing the
> airtraffic with another ath10k interface. According to
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/monitor I
> should see the right radiotap headers, since they are not in the
> knowing issue list.
> But I had the same bad results.
>
> I tried also using an ath9k wifi card.
> Each mesh link is set on 80MHz channel bandwidth, therefore I'm not
> able to capture the data traffic with the ath9k that doesn't support
> 80MHz.
>
> I'm able to sniff the traffic and see the radiotap header only using
> my laptop with an iwlwifi 11ac card.
>
> Do you know if there is a way to obtain reliable TX/RX information
> from the firmware, or if there is a way to sniff the radiotap header
> on an 80MHz channel using an ath9k interface?
>
> Thank you in advance for any hint!
>
> My best regards
>
> Matteo

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

2017-03-18 Thread Alexis Green 
Hi Johannes,

Thank you for the comments, I'll see if I can apply all of your
suggestions and resubmit.

Alexis

On Thu, Mar 16, 2017 at 3:18 AM, Johannes Berg
 wrote:
> Sorry - this is the other half of my reply that I accidentally deleted
> before sending...
>
>> +static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
>> +{
>> + struct ieee80211_if_mesh *ifmsh = >u.mesh;
>> + struct mesh_tx_queue *tx_node;
>> +
>> + spin_lock_bh(>mesh_tx_queue_lock);
>> +
>> + /* Note that this check is important because of the two-
>> stage
>> +  * way that ieee80211_if_mesh is initialized.
>> +  */
>
> I think you should fix that rather than work around it. If this is
> called with iftype != mesh then this is super problematic anyway, since
> ifmsh->tx_queue_len would alias some other variable (there's a union).
>
>> + if (ifmsh->tx_queue_len > 0) {
>> + mhwmp_dbg(sdata, "flushing %d skbs", ifmsh-
>> >tx_queue_len);
>> +
>> + while (!list_empty(>tx_queue.list)) {
>> + tx_node = list_last_entry(
>> >tx_queue.list,
>> +   struct
>> mesh_tx_queue, list);
>> + kfree_skb(tx_node->skb);
>> + list_del(_node->list);
>> + kfree(tx_node);
>> + }
>> + ifmsh->tx_queue_len = 0;
>> + }
>> +
>> + spin_unlock_bh(>mesh_tx_queue_lock);
>> +}
>
> All of this also gets *vastly* simpler if it's just skb_queue_purge()
> :)
>
>> + spin_lock_bh(>mesh_tx_queue_lock);
>> +
>> + list_for_each_entry(tx_node, >tx_queue.list, list) {
>> + ieee80211_tx_skb(sdata, tx_node->skb);
>> + }
>
> I don't think you should hold the lock across _tx_skb(), ISTR problems
> with that - particularly with the STA lock, so this might be OK, but it
> might also cause lock ordering issues. It's easy to avoid anyway, so
> better not to do it.
>
> johannes

Re: [NetDev-tech] [NetDev] ANNOUNCE: New sponsor Netronome

2017-03-18 Thread Alexis Green 
Why is this sent to linux-wireless?

On Sat, Mar 18, 2017 at 6:21 PM, Jamal Hadi Salim  wrote:
> On 17-03-18 08:07 PM, Amine Aouled Hamed wrote:
>>
>> Im subscribed to netfilter and netfilter-dev but does it matter? you
>> are spamming on multiple lists about something not related to the list
>> subject.
>> People subscribe to the list to exchange information and discuss
>> relevant subjects not to get ads...
>
>
> Netfilter is certainly part of the event.
>
>> If you are trying to bring people to your event than I guess you are
>> doing the exact opposite by spamming in all these lists.
>>
>
> Lets hear if more people want netfilter lists or any other lists
> removed.
>
> cheers,
> jamal

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

2017-03-10 Thread Alexis Green 
These images work intermittently for me. Here they are rehosted:

[1] http://i.imgur.com/zM0eLNk.png
[2] http://i.imgur.com/E7GL7U3.png

On Fri, Mar 10, 2017 at 12:40 AM, Kalle Valo  wrote:
> Matthias May  writes:
>
>> [1] http://may.nu/images/problem.png
>> [2] http://may.nu/images/jittered.png
>
> I get 404 "Not Found" for these.
>
> --
> Kalle Valo

[PATCH v2] mac80211: mesh - always do every discovery retry

2017-02-28 Thread Alexis Green 
Changes since v1: Make this behavior optional and configurable via
  netlink.

Instead of stopping path discovery when a path is found continue
attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
limit.

This is important because path messages are not reliable and it is
relatively common to have a short bad path to the destination along with a
longer but better path. With the original code rather often a path message
along the long path would be lost so we would stick with the bad path.
With this change we have a greater chance to get messages over the longer
path allowing us to select the long path if it's better.

The standard doesn't seem to address this issue. All it says (13.10.8.5)
is that discovery should be limited to dot11MeshHWMPmaxPREQretries.

Signed-off-by: Alexis Green <agr...@uniumwifi.com>
---
 include/net/cfg80211.h|  3 ++
 include/uapi/linux/nl80211.h  |  3 ++
 net/mac80211/cfg.c|  2 ++
 net/mac80211/debugfs_netdev.c |  3 ++
 net/mac80211/mesh_hwmp.c  | 65 +--
 net/wireless/mesh.c   |  1 +
 net/wireless/nl80211.c|  8 +-
 net/wireless/trace.h  |  5 +++-
 8 files changed, 67 insertions(+), 23 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 86c12f8..fb32abf 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1382,6 +1382,8 @@ struct bss_parameters {
  * @plink_timeout: If no tx activity is seen from a STA we've established
  * peering with for longer than this time (in seconds), then remove it
  * from the STA's list of peers.  Default is 30 minutes.
+ * @always_max_discoveries: whether to always perform number of discovery
+ * attemts equal to dot11MeshHWMPmaxPREQretries
  */
 struct mesh_config {
u16 dot11MeshRetryTimeout;
@@ -1412,6 +1414,7 @@ struct mesh_config {
enum nl80211_mesh_power_mode power_mode;
u16 dot11MeshAwakeWindowDuration;
u32 plink_timeout;
+   bool always_max_discoveries;
 };
 
 /**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 9a499b1..58f8f0c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3449,6 +3449,8 @@ enum nl80211_mesh_power_mode {
  * established peering with for longer than this time (in seconds), then
  * remove it from the STA's list of peers. You may set this to 0 to disable
  * the removal of the STA. Default is 30 minutes.
+ * @NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES: whether to always perform
+ * number of discovery attempts equal to MaxPREQretries (default is FALSE)
  *
  * @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
  */
@@ -3482,6 +3484,7 @@ enum nl80211_meshconf_params {
NL80211_MESHCONF_POWER_MODE,
NL80211_MESHCONF_AWAKE_WINDOW,
NL80211_MESHCONF_PLINK_TIMEOUT,
+   NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
 
/* keep last */
__NL80211_MESHCONF_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 9c7490c..9581873 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1956,6 +1956,8 @@ static int ieee80211_update_mesh_config(struct wiphy 
*wiphy,
nconf->dot11MeshAwakeWindowDuration;
if (_chg_mesh_attr(NL80211_MESHCONF_PLINK_TIMEOUT, mask))
conf->plink_timeout = nconf->plink_timeout;
+   if (_chg_mesh_attr(NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES, mask))
+   conf->always_max_discoveries = nconf->always_max_discoveries;
ieee80211_mbss_info_change_notify(sdata, BSS_CHANGED_BEACON);
return 0;
 }
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 8f5fff8..ceec6e8 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -642,6 +642,8 @@ IEEE80211_IF_FILE(dot11MeshHWMPconfirmationInterval,
 IEEE80211_IF_FILE(power_mode, u.mesh.mshcfg.power_mode, DEC);
 IEEE80211_IF_FILE(dot11MeshAwakeWindowDuration,
  u.mesh.mshcfg.dot11MeshAwakeWindowDuration, DEC);
+IEEE80211_IF_FILE(always_max_discoveries,
+ u.mesh.mshcfg.always_max_discoveries, DEC);
 #endif
 
 #define DEBUGFS_ADD_MODE(name, mode) \
@@ -763,6 +765,7 @@ static void add_mesh_config(struct ieee80211_sub_if_data 
*sdata)
MESHPARAMS_ADD(dot11MeshHWMPconfirmationInterval);
MESHPARAMS_ADD(power_mode);
MESHPARAMS_ADD(dot11MeshAwakeWindowDuration);
+   MESHPARAMS_ADD(always_max_discoveries);
 #undef MESHPARAMS_ADD
 }
 #endif
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index d07ee3c..7c019f9 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1198,34 +1198,57 @@ void mesh_path_timer(unsigned long data)
 {
struct mesh_path *mpath = (void *) data;
struct ieee80211_sub_if_data *sdata = mpath->sdata;
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   bool m

[PATCH] iw: Add support for NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES netlink attribute

2017-02-28 Thread Alexis Green 

This attributes allows configuring mesh to either do only minimum
number of discovery attempts (up to MaxPREretries) or always do
MaxPREretries number of tries even when getting responses.

Signed-off-by: Alexis Green <agr...@uniumwifi.com>
---
 mesh.c| 3 +++
 nl80211.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/mesh.c b/mesh.c
index 97f236b..b828408 100644
--- a/mesh.c
+++ b/mesh.c
@@ -264,6 +264,9 @@ const static struct mesh_param_descr _mesh_param_descrs[] =
_my_nla_put_u16, _parse_u16, _print_u16_in_TUs},
{"mesh_plink_timeout", NL80211_MESHCONF_PLINK_TIMEOUT,
_my_nla_put_u32, _parse_u32, _print_u32_in_seconds},
+   {"mesh_hwmp_always_max_discoveries",
+   NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
+   _my_nla_put_u8, _parse_u8_as_bool, _print_u8},
 };
 
 static void print_all_mesh_param_descr(void)
diff --git a/nl80211.h b/nl80211.h
index 56368e9..bb53e8b 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -3352,6 +3352,8 @@ enum nl80211_mesh_power_mode {
  * established peering with for longer than this time (in seconds), then
  * remove it from the STA's list of peers. You may set this to 0 to disable
  * the removal of the STA. Default is 30 minutes.
+ * @NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES: whether to always perform
+ * number of discovery attempts equal to MaxPREQretries (default is FALSE)
  *
  * @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
  */
@@ -3385,6 +3387,7 @@ enum nl80211_meshconf_params {
NL80211_MESHCONF_POWER_MODE,
NL80211_MESHCONF_AWAKE_WINDOW,
NL80211_MESHCONF_PLINK_TIMEOUT,
+   NL80211_MESHCONF_HWMP_ALWAYS_MAX_DISCOVERIES,
 
/* keep last */
__NL80211_MESHCONF_ATTR_AFTER_LAST,
-- 
2.5.0.rc3

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

2017-02-27 Thread Alexis Green 
Hi Johannes,

This is loosely based on RFC5148, specifically event-triggered message 
generation as described in section 5.2.
The frames are not duplicated, but, hopefully offset enough so they don't 
collide at the receiver (and, since, these are management frames, there is no 
retransmission and we may lose the information contained in them). If the two 
(or more) devices that reply are synchronized well enough, carrier sense will 
tell them that air is clear and messages will go out at the same time. It 
doesn't happen too often, but we found it noticeable enough in our testing.

Best regards,

Alexis Green

On 2/27/2017 5:30 AM, Johannes Berg wrote:
> On Fri, 2017-02-24 at 11:58 -0800, Alexis Green wrote:
>> From: Jesse Jones <jjo...@uniumwifi.com>
>>
>> When more than one station hears a broadcast request, it is possible
>> that multiple devices will reply at the same time, potentially
>> causing collision. This patch helps reduce this issue.
> 
> It's not clear to me what you mean by "collision"? Over the air the NAV
> should handle the avoidance thereof, so I don't really see what this
> does wrt. collisions?
> 
> Are these frames somehow duplicates? But I don't see any suppression if
> you've already put a frame on the "jittered" list then it will never be
> deleted from it again, so it doesn't suppress anything in that sense?
> 
> johannes
>

[PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

2017-02-24 Thread Alexis Green 
From: Jesse Jones <jjo...@uniumwifi.com>

Changes since v1: Only flush tx queue if interface is mesh mode.
  This prevents kernel panics due to uninitialized spin_lock.

When more than one station hears a broadcast request, it is possible that
multiple devices will reply at the same time, potentially causing
collision. This patch helps reduce this issue.

Signed-off-by: Alexis Green <agr...@uniumwifi.com>
Signed-off-by: Benjamin Morgan <bmor...@uniumwifi.com>
---
 net/mac80211/ieee80211_i.h |  11 
 net/mac80211/iface.c   |  61 ++
 net/mac80211/mesh.c|   2 +
 net/mac80211/mesh_hwmp.c   | 124 +++--
 4 files changed, 171 insertions(+), 27 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a7..f422897 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -330,6 +330,11 @@ struct mesh_preq_queue {
u8 flags;
 };
 
+struct mesh_tx_queue {
+   struct list_head list;
+   struct sk_buff *skb;
+};
+
 struct ieee80211_roc_work {
struct list_head list;
 
@@ -670,6 +675,11 @@ struct ieee80211_if_mesh {
spinlock_t mesh_preq_queue_lock;
struct mesh_preq_queue preq_queue;
int preq_queue_len;
+   /* Spinlock for trasmitted MPATH frames */
+   spinlock_t mesh_tx_queue_lock;
+   struct mesh_tx_queue tx_queue;
+   int tx_queue_len;
+
struct mesh_stats mshstats;
struct mesh_config mshcfg;
atomic_t estab_plinks;
@@ -919,6 +929,7 @@ struct ieee80211_sub_if_data {
 
struct work_struct work;
struct sk_buff_head skb_queue;
+   struct delayed_work tx_work;
 
u8 needed_rx_chains;
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd..d5b4bf4 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -778,6 +778,59 @@ static int ieee80211_open(struct net_device *dev)
return ieee80211_do_open(>wdev, true);
 }
 
+static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
+{
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   struct mesh_tx_queue *tx_node;
+
+   spin_lock_bh(>mesh_tx_queue_lock);
+
+   /* Note that this check is important because of the two-stage
+* way that ieee80211_if_mesh is initialized.
+*/
+   if (ifmsh->tx_queue_len > 0) {
+   mhwmp_dbg(sdata, "flushing %d skbs", ifmsh->tx_queue_len);
+
+   while (!list_empty(>tx_queue.list)) {
+   tx_node = list_last_entry(>tx_queue.list,
+ struct mesh_tx_queue, list);
+   kfree_skb(tx_node->skb);
+   list_del(_node->list);
+   kfree(tx_node);
+   }
+   ifmsh->tx_queue_len = 0;
+   }
+
+   spin_unlock_bh(>mesh_tx_queue_lock);
+}
+
+static void mesh_jittered_tx(struct work_struct *wk)
+{
+   struct ieee80211_sub_if_data *sdata =
+   container_of(
+wk, struct ieee80211_sub_if_data,
+tx_work.work);
+
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   struct mesh_tx_queue *tx_node;
+
+   spin_lock_bh(>mesh_tx_queue_lock);
+
+   list_for_each_entry(tx_node, >tx_queue.list, list) {
+   ieee80211_tx_skb(sdata, tx_node->skb);
+   }
+
+   while (!list_empty(>tx_queue.list)) {
+   tx_node = list_last_entry(>tx_queue.list,
+ struct mesh_tx_queue, list);
+   list_del(_node->list);
+   kfree(tx_node);
+   }
+   ifmsh->tx_queue_len = 0;
+
+   spin_unlock_bh(>mesh_tx_queue_lock);
+}
+
 static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
  bool going_down)
 {
@@ -881,6 +934,12 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data 
*sdata,
 
cancel_delayed_work_sync(>dfs_cac_timer_work);
 
+   /* Nothing to flush if the interface is not in mesh mode */
+   if (sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
+   flush_tx_skbs(sdata);
+
+   cancel_delayed_work_sync(>tx_work);
+
if (sdata->wdev.cac_started) {
chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
@@ -1846,6 +1905,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const 
char *name,
  ieee80211_dfs_cac_timer_work);
INIT_DELAYED_WORK(>dec_tailroom_needed_wk,
  ieee80211_delayed_tailroom_dec);
+   INIT_DELAYED_WORK(>tx_work,
+ mesh_jittered_tx);
 
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband;
diff --git

[PATCH] mac80211: Jitter HWMP MPATH reply frames to reduce collision, on dense networks.

2017-02-21 Thread Alexis Green 
From: Jesse Jones <jjo...@uniumwifi.com>

When more than one station hears a broadcast request, it is possible that
multiple devices will reply at the same time, potentially causing
collision. This patch helps reduce this issue.

Signed-off-by: Alexis Green <agr...@uniumwifi.com>
Signed-off-by: Benjamin Morgan <bmor...@uniumwifi.com>
---
 net/mac80211/ieee80211_i.h |  11 
 net/mac80211/iface.c   |  58 +
 net/mac80211/mesh.c|   2 +
 net/mac80211/mesh_hwmp.c   | 124 +++--
 4 files changed, 168 insertions(+), 27 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a7..f422897 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -330,6 +330,11 @@ struct mesh_preq_queue {
u8 flags;
 };
 
+struct mesh_tx_queue {
+   struct list_head list;
+   struct sk_buff *skb;
+};
+
 struct ieee80211_roc_work {
struct list_head list;
 
@@ -670,6 +675,11 @@ struct ieee80211_if_mesh {
spinlock_t mesh_preq_queue_lock;
struct mesh_preq_queue preq_queue;
int preq_queue_len;
+   /* Spinlock for MPATH frame tx queue */
+   spinlock_t mesh_tx_queue_lock;
+   struct mesh_tx_queue tx_queue;
+   int tx_queue_len;
+
struct mesh_stats mshstats;
struct mesh_config mshcfg;
atomic_t estab_plinks;
@@ -919,6 +929,7 @@ struct ieee80211_sub_if_data {
 
struct work_struct work;
struct sk_buff_head skb_queue;
+   struct delayed_work tx_work;
 
u8 needed_rx_chains;
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd..51d5cfa 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -778,6 +778,59 @@ static int ieee80211_open(struct net_device *dev)
return ieee80211_do_open(>wdev, true);
 }
 
+static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
+{
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   struct mesh_tx_queue *tx_node;
+
+   spin_lock_bh(>mesh_tx_queue_lock);
+
+   /* Note that this check is important because of the two-stage
+* way that ieee80211_if_mesh is initialized.
+*/
+   if (ifmsh->tx_queue_len > 0) {
+   mhwmp_dbg(sdata, "flushing %d skbs", ifmsh->tx_queue_len);
+
+   while (!list_empty(>tx_queue.list)) {
+   tx_node = list_last_entry(>tx_queue.list,
+ struct mesh_tx_queue, list);
+   kfree_skb(tx_node->skb);
+   list_del(_node->list);
+   kfree(tx_node);
+   }
+   ifmsh->tx_queue_len = 0;
+   }
+
+   spin_unlock_bh(>mesh_tx_queue_lock);
+}
+
+static void mesh_jittered_tx(struct work_struct *wk)
+{
+   struct ieee80211_sub_if_data *sdata =
+   container_of(
+wk, struct ieee80211_sub_if_data,
+tx_work.work);
+
+   struct ieee80211_if_mesh *ifmsh = >u.mesh;
+   struct mesh_tx_queue *tx_node;
+
+   spin_lock_bh(>mesh_tx_queue_lock);
+
+   list_for_each_entry(tx_node, >tx_queue.list, list) {
+   ieee80211_tx_skb(sdata, tx_node->skb);
+   }
+
+   while (!list_empty(>tx_queue.list)) {
+   tx_node = list_last_entry(>tx_queue.list,
+ struct mesh_tx_queue, list);
+   list_del(_node->list);
+   kfree(tx_node);
+   }
+   ifmsh->tx_queue_len = 0;
+
+   spin_unlock_bh(>mesh_tx_queue_lock);
+}
+
 static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
  bool going_down)
 {
@@ -881,6 +934,9 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data 
*sdata,
 
cancel_delayed_work_sync(>dfs_cac_timer_work);
 
+   flush_tx_skbs(sdata);
+   cancel_delayed_work_sync(>tx_work);
+
if (sdata->wdev.cac_started) {
chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
@@ -1846,6 +1902,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const 
char *name,
  ieee80211_dfs_cac_timer_work);
INIT_DELAYED_WORK(>dec_tailroom_needed_wk,
  ieee80211_delayed_tailroom_dec);
+   INIT_DELAYED_WORK(>tx_work,
+ mesh_jittered_tx);
 
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index c28b0af..f0d3cd9 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1381,6 +1381,8 @@ void ieee80211_mesh_init_sdata(struct 
ieee80211_sub_if_data *sdata)
ieee80211_mesh_path_root_

Re: ath10k firmware crashes in mesh mode on QCA9880

2016-12-13 Thread Alexis Green 
Hi Adrian,

I have not done much testing of ath10k and ath9k devices in a single
encrypted mesh recently, but I have a memory of only having this issue
when communicating between ath10k devices.

Alexis

On Tue, Dec 13, 2016 at 9:53 PM, Adrian Chadd  wrote:
> Hi!
>
> Hm! So is there a firmware bug if there are 11n only capable nodes in
> an 11s mesh?
>
>
>
> -adrian

Re: ath10k firmware crashes in mesh mode on QCA9880

2016-12-13 Thread Alexis Green 
Thank you for your help Rajkumar,

We've traced the problem down to a peering issue. Looks like there was
a missing compile flag that caused some kind of incongruence. My best
guest is that beacons are generated by firmware and advertise support
for AC mode, whereas wpa_supplicant, when not compiled with
CONFIG_IEEE80211AC=y, sends mesh peering messages and creates peers
without AC support, causing firmware to get confused. After
recompiling supplicant with the correct flag, no more crashes were
observed in casual testing. I submitted a pull request to LEDE to,
hopefully, fix it in upstream.

Best regards,

Alexis

On Tue, Dec 13, 2016 at 3:51 PM, Manoharan, Rajkumar
 wrote:
>> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT
>> encryption and it still crashes. I suspect this means wpa_supplicant is 
>> setting up
>> the interface incorrectly and/or transmitting a malformed packet that is 
>> causing
>> the driver to crash.
>>
> Ben,
>
> IIRC mesh support was validated in qca988x in VHT mode while ago.  Either it 
> could
> be regression in driver/fw or lede mac80211 package.
>
> 1) Could you please try plain backports in lede w/o applying ath10k patches.
>  I do see 160MHz support in LEDE.
> 2) There are some peer stats dump from your earlier log. Disable peer stats
>  by "peer_stats" debugfs.
> 3) Please confirm the behavior with older firmware revisions.
> 4) use iw to bring up open mesh to rule out wpa_s config
>
> -Rajkumar
>

Re: Ralink RT5592 5Ghz capability not working

2015-11-03 Thread Alexis Green 
This is so strange. Asus RT-N56U you mentioned earlier as one of the
examples actually has two separate chips for each band (and one of
them is RT3091) - https://wikidevi.com/wiki/ASUS_RT-N56U
Are you able to take a picture of the chip?

On Tue, Nov 3, 2015 at 10:10 AM, Alberto Mattea  wrote:
> Hey, thanks for your answer. The device definitely isn't a RT3091, so do you
> think it's some sort of an OEM hybrid? Do you think it would be better to
> report this to the openwrt bugzilla?
>
> Thanks
>
> In data mar 3 novembre 2015 14:41:35, Xose Vazquez Perez ha scritto:
>> Alberto Mattea wrote:
>> > this is about the mini-pcie version used in some embedded products
>> > (for example the Buffalo WHR-600D and the Asus RP-N53).
>> > It has an RT5592 chip and the hardware supports both 2.4 and 5Ghz
>> > (5Ghz works with the proprietary driver supplied with the devices),
>> > but rt2800pci seems to see only the 2.4 Ghz capability.
>>
>> As far as I know, RT5592 PCIe devices are unsupported by rt2800pci.
>>
>> > dmesg:
>> >
>> > [   14.07] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev
>> > 0222 detected [   14.08] ieee80211 phy0: rt2x00_set_rf: Info - RF
>> > chipset 0001 detected [   14.10] ieee80211 phy0: Selected rate
>> > control algorithm 'minstrel_ht' [  134.42] ieee80211 phy0:
>> > rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin' [
>> > 134.46] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware
>> > detected - version: 0.34
>> Here is the output of a real RT5592 PCIe device with rt2800pci driver(Feb
>> 2013):
>>
>> phy1 -> rt2x00_set_chip: Info - Chipset detected - rt: 5592, rf: 000f, rev:
>> 0222. phy1 -> rt2800_init_eeprom: Error - Invalid RT chipset 0x5592
>> detected. phy1 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
>>
>> > The weird thing is that in lspci it is reported as an RT3091, due to the
>> > 0x3091 pci device id:
>> >
>> > 01:00.0 Network controller [0280]: Ralink corp. RT3091 Wireless 802.11n
>> > 1T/2R PCIe [1814:3091]>
>> > Subsystem: Ralink corp. RT3091 Wireless 802.11n 1T/2R PCIe
>> > [1814:3091]
>> >
>> > [...]
>>
>> 06:00.0 Network controller [0280]: Ralink corp. Device [1814:5592]
>> Subsystem: ASUSTeK Computer Inc. Device [1043:851a]
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
>> DEVSEL=fast >TAbort- SERR- > Cache Line Size: 64 bytes
>> Interrupt: pin A routed to IRQ 11
>> Region 0: Memory at fe50 (32-bit, non-prefetchable) [size=64K]
>> Capabilities: [40] Power Management version 3
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0
>> DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
>> Address:   Data: 
>> Capabilities: [70] Express (v2) Endpoint, MSI 00
>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
>> <512ns, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd-
>> ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128
>> bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns,
>> L1 <64us ClockPM+ Surprise- LLActRep- BwNot-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
>> CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed
>> 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> DevCap2: Completion Timeout: Not Supported, TimeoutDis+ DevCtl2: Completion
>> Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 2.5GT/s,
>> EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin:
>> Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance
>> De-emphasis: -6dB
>> LnkSta2: Current De-emphasis Level: -6dB,
>> EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-,
>> EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1]
>> Advanced Error Reporting
>> UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
>> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:  DLP- SDES- TLP- FCP-
>> CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+
>> ECRC- UnsupReq- ACSViol- CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+ CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout-
>> NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+
>> ChkEn- Capabilities: [140 v1] Device Serial Number c1-a5-f3-ff-fe-a9-85-30
>> > So maybe due to this (i'm not sure), rt2800pci only enables the 2.4 Ghz
> band support:

[PATCH] mac80211: mesh - always do every discovery retry

2015-06-24 Thread Alexis Green 
From: Jesse Jones jjo...@cococorp.com

Instead of stopping path discovery when a path is found continue
attempting to find paths until we hit the dot11MeshHWMPmaxPREQretries
limit.

This is important because path messages are not reliable and it is
relatively common to have a short bad path to the destination along with a
longer but better path. With the original code rather often a path message
along the long path would be lost so we would stick with the bad path.
With this change we have a greater chance to get messages over the longer
path allowing us to select the long path if it's better.

The standard doesn't seem to address this issue. All it says (13.10.8.5)
is that discovery should be limited to dot11MeshHWMPmaxPREQretries.

Signed-off-by: Alexis Green agr...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index d80e0a4..3eec501 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1179,16 +1179,20 @@ void mesh_path_timer(unsigned long data)
return;
 
spin_lock_bh(mpath-state_lock);
-   if (mpath-flags  MESH_PATH_RESOLVED ||
-   (!(mpath-flags  MESH_PATH_RESOLVING))) {
-   mpath-flags = ~(MESH_PATH_RESOLVING | MESH_PATH_RESOLVED);
-   spin_unlock_bh(mpath-state_lock);
-   } else if (mpath-discovery_retries  max_preq_retries(sdata)) {
+
+   if (mpath-discovery_retries  max_preq_retries(sdata)) {
++mpath-discovery_retries;
mpath-discovery_timeout *= 2;
mpath-flags = ~MESH_PATH_REQ_QUEUED;
spin_unlock_bh(mpath-state_lock);
mesh_queue_preq(mpath, 0);
+
+   } else if (
+   mpath-flags  MESH_PATH_RESOLVED ||
+   (!(mpath-flags  MESH_PATH_RESOLVING))) {
+   mpath-flags = ~(MESH_PATH_RESOLVING | MESH_PATH_RESOLVED);
+   spin_unlock_bh(mpath-state_lock);
+
} else {
mpath-flags = ~(MESH_PATH_RESOLVING |
  MESH_PATH_RESOLVED |
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: don't invalidate SN on discovery failure

2015-06-12 Thread Alexis Green 
From: Jesse Jones jjo...@cococorp.com

The 2012 spec mentions that path SNs can be invalid when created (see
section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating
SNs. Which makes sense: if we have figured out the path to a target at a
certain SN then we want to remember that fact. Failing to do so can lead
to routing loops because if we don't have a valid SN then we have no way
of knowing whether an incoming path message leads to or away from the
target.

However currently when discovery fails we zero out mpath-flags which
clears MESH_PATH_SN_VALID. This patch fixes that so that only the
discovery relevant flags are cleared.

Signed-off-by: Alexis Green agr...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 085edc1..1d849be
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1176,7 +1176,8 @@ void mesh_path_timer(unsigned long data)
spin_unlock_bh(mpath-state_lock);
mesh_queue_preq(mpath, 0);
} else {
-   mpath-flags = 0;
+   mpath-flags = ~(MESH_PATH_RESOLVING |
+   MESH_PATH_RESOLVED | MESH_PATH_REQ_QUEUED);
mpath-exp_time = jiffies;
spin_unlock_bh(mpath-state_lock);
if (!mpath-is_gate  mesh_gate_num(sdata)  0) {
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: Check SN for deactivated mpaths

2015-06-12 Thread Alexis Green 
From: Jesse Jones jjo...@cococorp.com

When processing a PREQ or PREP it's critical to use the incoming SN. If
that is improperly done routing loops and other types of badness can
happen. But the code was always processing path messages for deactivated
paths. This path fixes that so that if we have a valid SN then we use it
to verify that it is a message we can accept. For reference the relevant
section of the standard is 13.10.8.4 which doesn't address the deactivated
path case at all.

I also included a special case for when our peer reboots or restarts
networking. This is an important case because without it there can be a
very long delay before we accept path messages from that peer. It's also a
simple case and intimately associated with processing messages for
deactivated paths so I used one patch instead of two.

Signed-off-by: Alexis Green agr...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 45485f3..3c5f76a 100755
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -79,6 +79,12 @@ static inline u16 u16_field_get(const u8 *preq_elem, int 
offset, bool ae)
 #define MSEC_TO_TU(x) (x*1000/1024)
 #define SN_GT(x, y) ((s32)(y - x)  0)
 #define SN_LT(x, y) ((s32)(x - y)  0)
+#define MAX_SANE_SN_DELTA 32
+
+static inline u32 SN_DELTA(u32 x, u32 y)
+{
+   return x = y ? x - y : y - x;
+}
 
 #define net_traversal_jiffies(s) \
msecs_to_jiffies(s-u.mesh.mshcfg.dot11MeshHWMPnetDiameterTraversalTime)
@@ -441,6 +447,26 @@ static u32 hwmp_route_info_get(struct 
ieee80211_sub_if_data *sdata,
process = false;
fresh_info = false;
}
+   } else if (!(mpath-flags  MESH_PATH_ACTIVE)) {
+   bool have_sn, newer_sn, bounced;
+
+   have_sn = mpath-flags  MESH_PATH_SN_VALID;
+   newer_sn = have_sn  SN_GT(orig_sn, mpath-sn);
+   bounced = have_sn 
+   (SN_DELTA(orig_sn, mpath-sn) 
+   MAX_SANE_SN_DELTA);
+
+   if (!have_sn || newer_sn) {
+   /* if SN is newer than what we had
+* then we can take it */;
+   } else if (bounced) {
+   /* if SN is way different than what
+* we had then assume the other side
+* rebooted or restarted */;
+   } else {
+   process = false;
+   fresh_info = false;
+   }
}
} else {
mpath = mesh_path_add(sdata, orig_addr);
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: Add missing case to PERR processing

2015-06-10 Thread Alexis Green 
When the nexthop is unable to resolve its own nexthop it will send back a
PERR with a zero target_sn. According to section 13.10.11.4.3 step b in the
2012 standard that perr should be forwarded and the associated mpath-sn
should be incremented. Neither one of those was happening whichis rather
bad because the originator was not told that packets are black holing.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 3c7cf3c..28c18cb 100755
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -736,9 +736,12 @@ static void hwmp_perr_frame_process(struct 
ieee80211_sub_if_data *sdata,
if (mpath-flags  MESH_PATH_ACTIVE 
ether_addr_equal(ta, sta-sta.addr) 
(!(mpath-flags  MESH_PATH_SN_VALID) ||
-   SN_GT(target_sn, mpath-sn))) {
+   SN_GT(target_sn, mpath-sn)  || target_sn == 0)) {
mpath-flags = ~MESH_PATH_ACTIVE;
-   mpath-sn = target_sn;
+   if (target_sn != 0)
+   mpath-sn = target_sn;
+   else
+   mpath-sn += 1;
spin_unlock_bh(mpath-state_lock);
if (!ifmsh-mshcfg.dot11MeshForwarding)
goto endperr;
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Always check rates and capabilities in mesh mode

2015-06-09 Thread Alexis Green 
Will resend using a better mail client. Just found out that web-gmail is no-go.

On Tue, Jun 9, 2015 at 12:44 PM, Johannes Berg
johan...@sipsolutions.net wrote:
 On Fri, 2015-05-29 at 15:24 -0700, Alexis Green wrote:
 In mesh mode there is a race between establishing links and processing rates
 and capabilities in beacons. This is very noticeable with slow beacons (e.g.
 beacon intervals of 1s) and manifested for us as stations using minstrel when
 minstrel_ht should be used. Fixed by changing mesh_sta_info_init so that it
 always checks rates and such if it has not already done so.

 Signed-off-by: Alexis Green agr...@cococorp.com
 CC: Jesse Jones jjo...@cococorp.com

 This patch doesn't apply, it's line-broken and whitespace damaged.

 johannes

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2]: mac80211: Always check rates and capabilities in mesh mode

2015-06-09 Thread Alexis Green 
In mesh mode there is a race between establishing links and processing
rates and capabilities in beacons. This is very noticeable with slow
beacons (e.g. beacon intervals of 1s) and manifested for us as stations
using minstrel when minstrel_ht should be used. Fixed by changing
mesh_sta_info_init so that it always checks rates and such if it has not
already done so.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index ac843fc..54656af 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -394,8 +394,9 @@ static void mesh_sta_info_init(struct ieee80211_sub_if_data 
*sdata,
sta-last_rx = jiffies;
 
/* rates and capabilities don't change during peering */
-   if (sta-plink_state == NL80211_PLINK_ESTAB)
+   if (sta-plink_state == NL80211_PLINK_ESTAB  sta-processed_beacon)
goto out;
+   sta-processed_beacon = true;
 
if (sta-sta.supp_rates[band] != rates)
changed |= IEEE80211_RC_SUPP_RATES_CHANGED;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 9bd1e97..226f8ca4 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -369,6 +369,8 @@ struct ieee80211_fast_tx {
  * @rx_msdu: MSDUs received from this station, using IEEE80211_NUM_TID
  * entry for non-QoS frames
  * @fast_tx: TX fastpath information
+ * @processed_beacon: set to true after peer rates and capabilities are
+ * processed
  */
 struct sta_info {
/* General information, mostly static */
@@ -473,6 +475,7 @@ struct sta_info {
enum nl80211_mesh_power_mode local_pm;
enum nl80211_mesh_power_mode peer_pm;
enum nl80211_mesh_power_mode nonpeer_pm;
+   bool processed_beacon;
 #endif
 
 #ifdef CONFIG_MAC80211_DEBUGFS
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: Fix a case of incorrect metric used when forwarding a PREQ

2015-06-09 Thread Alexis Green 
Resubmitting as v2 due to mangled white spaces.

On Mon, Jun 8, 2015 at 10:28 AM, Jesse Jones jjo...@cococorp.com wrote:
 I took a look at the spec too and also didn't see mention of the MP_F_RF
 flag. Section 13.10.9.3 for example talks about PREQ handling and in case E2
 talks about sending replies back. It says to do that if target only is not
 set which makes sense: MP_F_RF and MP_F_DO are exclusive options so it's
 silly to use two different flags for them.

 But for the purposes of this patch that is a moot issue: the semantics of
 the function don't change and the original code was both confusing and using
 the wrong value for metric for the not target only, intermediate station
 case.

   -- Jesse

 -Original Message-
 From: linux-wireless-ow...@vger.kernel.org
 [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Yeoh Chun-Yeow
 Sent: Monday, June 08, 2015 1:55 AM
 To: linux-wireless@vger.kernel.org
 Subject: Re: [PATCH] mac80211: Fix a case of incorrect metric used when
 forwarding a PREQ

 As mentioned in Section 13.10.9.3 Case E2, the PREQ forwarding should use
 metric as received + own metric toward transmitter of received PREQ. So
 you are right.

 Just MP_F_RF bit is no longer use. After replying with PREP, forwarding the
 PREQ by setting the IEEE80211_PREQ_TO_FLAG in the per target flags.

 ---
 Chun-Yeow

 On Mon, Jun 8, 2015 at 4:07 PM, Yeoh Chun-Yeow yeohchuny...@gmail.com
 wrote:
 Hi, Alexis Green

 I just take a look back on the code before implementing the Proactive
 PREQ for PREP. For the case of reply and forward (target_flags 
 MP_F_RF), the previous metric used is the one which resolved from
 mpath-metric.

 Refer here:
 https://github.com/o11s/open80211s/blob/o11s-0.4.2/net/mac80211/mesh_h
 wmp.c

 But to say that, I cannpt confirm whether this is correct. The
 standard 802.11-2012 has no longer specified bit-1 MP_F_RF (Refer
 section 8.4.2.115 per target flag). So maybe it is not relevant
 anymore. We may need to remove as well.

 
 Chun-Yeow
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org More majordomo info at
 http://vger.kernel.org/majordomo-info.html
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mac80211: Fix a case of incorrect metric used when forwarding a PREQ

2015-06-09 Thread Alexis Green 
This patch fixes a bug in hwmp_preq_frame_process where the wrong metric
can be used when forwarding a PREQ. This happens because the code uses
the same metric variable to record the value of the metric to the source
of the PREQ and the value of the metric to the target of the PREQ.

This comes into play when both reply and forward are set which happens
when IEEE80211_PREQ_PROACTIVE_PREP_FLAG is set and when MP_F_DO | MP_F_RF
is set. The original code had a special case to handle the first case
but not the second.

The patch uses distinct variables for the two metrics which makes the
code flow much clearer and removes the need to restore the original
value of metric when forwarding.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 214e63b..84d1044 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -510,14 +510,14 @@ static u32 hwmp_route_info_get(struct 
ieee80211_sub_if_data *sdata,
 
 static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt,
-   const u8 *preq_elem, u32 metric)
+   const u8 *preq_elem, u32 orig_metric)
 {
struct ieee80211_if_mesh *ifmsh = sdata-u.mesh;
struct mesh_path *mpath = NULL;
const u8 *target_addr, *orig_addr;
const u8 *da;
u8 target_flags, ttl, flags;
-   u32 orig_sn, target_sn, lifetime, orig_metric;
+   u32 orig_sn, target_sn, lifetime, target_metric;
bool reply = false;
bool forward = true;
bool root_is_gate;
@@ -528,7 +528,6 @@ static void hwmp_preq_frame_process(struct 
ieee80211_sub_if_data *sdata,
target_sn = PREQ_IE_TARGET_SN(preq_elem);
orig_sn = PREQ_IE_ORIG_SN(preq_elem);
target_flags = PREQ_IE_TARGET_F(preq_elem);
-   orig_metric = metric;
/* Proactive PREQ gate announcements */
flags = PREQ_IE_FLAGS(preq_elem);
root_is_gate = !!(flags  RANN_FLAG_IS_GATE);
@@ -539,7 +538,7 @@ static void hwmp_preq_frame_process(struct 
ieee80211_sub_if_data *sdata,
mhwmp_dbg(sdata, PREQ is for us\n);
forward = false;
reply = true;
-   metric = 0;
+   target_metric = 0;
if (time_after(jiffies, ifmsh-last_sn_update +
net_traversal_jiffies(sdata)) ||
time_before(jiffies, ifmsh-last_sn_update)) {
@@ -556,7 +555,7 @@ static void hwmp_preq_frame_process(struct 
ieee80211_sub_if_data *sdata,
reply = true;
target_addr = sdata-vif.addr;
target_sn = ++ifmsh-sn;
-   metric = 0;
+   target_metric = 0;
ifmsh-last_sn_update = jiffies;
}
if (root_is_gate)
@@ -574,7 +573,7 @@ static void hwmp_preq_frame_process(struct 
ieee80211_sub_if_data *sdata,
} else if ((!(target_flags  MP_F_DO)) 
(mpath-flags  MESH_PATH_ACTIVE)) {
reply = true;
-   metric = mpath-metric;
+   target_metric = mpath-metric;
target_sn = mpath-sn;
if (target_flags  MP_F_RF)
target_flags |= MP_F_DO;
@@ -593,7 +592,8 @@ static void hwmp_preq_frame_process(struct 
ieee80211_sub_if_data *sdata,
mesh_path_sel_frame_tx(MPATH_PREP, 0, orig_addr,
   orig_sn, 0, target_addr,
   target_sn, mgmt-sa, 0, ttl,
-  lifetime, metric, 0, sdata);
+  lifetime, target_metric, 0,
+  sdata);
} else {
ifmsh-mshstats.dropped_frames_ttl++;
}
@@ -619,13 +619,12 @@ static void hwmp_preq_frame_process(struct 
ieee80211_sub_if_data *sdata,
if (flags  IEEE80211_PREQ_PROACTIVE_PREP_FLAG) {
target_addr = PREQ_IE_TARGET_ADDR(preq_elem);
target_sn = PREQ_IE_TARGET_SN(preq_elem);
-   metric = orig_metric;
}
 
mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
   orig_sn, target_flags, target_addr,
   target_sn, da, hopcount, ttl, lifetime,
-  metric, preq_id, sdata);
+  orig_metric, preq_id

Re: mac80211 modification

2015-06-08 Thread Alexis Green 
You should build mac80211 as module instead of built-in driver and
make modules instead of full make. This way you'll be just
rebuilding mac80211.ko instead of the whole thing.

On Mon, Jun 8, 2015 at 2:39 AM, Duy Tai Nguyen duytai@gmail.com wrote:
 Hi,

 I want to inject particular data into beacon frame in Android device.
 I found two approaches:
 1. Write loadable kernel module.
 2. Modify MAC80211 subsystem
 In the first approach, I found that I could not include directly
 source code from MAC80211 sub system in folder /net/mac80211/. Thus, I
 used the second approach, but, every time I change any line of source
 code, it takes 30 minutes to build zImage  then install new kernel in
 my Android device. Finally, I was stuck.
 Therefore, my questions are:
 1. Is it right approach to modify MAC80211 subsystem?
 2. Are there any faster approach to modify MAC80211 and test source code?
 3. I am curious about the way you write code and test MAC80211. Could
 you explain in details?
 Best Regards,
 Duy Tai.
 
 Nguyen Duy Tai
 Ym: kimjiwoo741
 Phone: +841676919422
 Faculty of Computer Science and Engineering.
 University of Technology HCMC.
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: Fix a case of incorrect metric used when forwarding a PREQ

2015-06-05 Thread Alexis Green 
This patch fixes a bug in hwmp_preq_frame_process where the wrong metric
can be used when forwarding a PREQ. This happens because the code uses
the same metric variable to record the value of the metric to the source
of the PREQ and the value of the metric to the target of the PREQ.

This comes into play when both reply and forward are set which happens
when IEEE80211_PREQ_PROACTIVE_PREP_FLAG is set and when MP_F_DO | MP_F_RF
is set. The original code had a special case to handle the first case
but not the second.

The patch uses distinct variables for the two metrics which makes the
code flow much clearer and removes the need to restore the original
value of metric when forwarding.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 214e63b..bb93170 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -510,14 +510,14 @@ static u32 hwmp_route_info_get(struct
ieee80211_sub_if_data *sdata,

 static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt,
-   const u8 *preq_elem, u32 metric)
+   const u8 *preq_elem, u32 orig_metric)
 {
struct ieee80211_if_mesh *ifmsh = sdata-u.mesh;
struct mesh_path *mpath = NULL;
const u8 *target_addr, *orig_addr;
const u8 *da;
u8 target_flags, ttl, flags;
-   u32 orig_sn, target_sn, lifetime, orig_metric;
+   u32 orig_sn, target_sn, lifetime, target_metric;
bool reply = false;
bool forward = true;
bool root_is_gate;
@@ -528,7 +528,6 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
target_sn = PREQ_IE_TARGET_SN(preq_elem);
orig_sn = PREQ_IE_ORIG_SN(preq_elem);
target_flags = PREQ_IE_TARGET_F(preq_elem);
-   orig_metric = metric;
/* Proactive PREQ gate announcements */
flags = PREQ_IE_FLAGS(preq_elem);
root_is_gate = !!(flags  RANN_FLAG_IS_GATE);
@@ -539,7 +538,7 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
mhwmp_dbg(sdata, PREQ is for us\n);
forward = false;
reply = true;
-   metric = 0;
+   target_metric = 0;
if (time_after(jiffies, ifmsh-last_sn_update +
net_traversal_jiffies(sdata)) ||
time_before(jiffies, ifmsh-last_sn_update)) {
@@ -556,7 +555,7 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
reply = true;
target_addr = sdata-vif.addr;
target_sn = ++ifmsh-sn;
-   metric = 0;
+   target_metric = 0;
ifmsh-last_sn_update = jiffies;
}
if (root_is_gate)
@@ -574,7 +573,7 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
} else if ((!(target_flags  MP_F_DO)) 
(mpath-flags  MESH_PATH_ACTIVE)) {
reply = true;
-   metric = mpath-metric;
+   target_metric = mpath-metric;
target_sn = mpath-sn;
if (target_flags  MP_F_RF)
target_flags |= MP_F_DO;
@@ -593,7 +592,8 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
mesh_path_sel_frame_tx(MPATH_PREP, 0, orig_addr,
   orig_sn, 0, target_addr,
   target_sn, mgmt-sa, 0, ttl,
-  lifetime, metric, 0, sdata);
+  lifetime, target_metric,
+  0, sdata);
} else {
ifmsh-mshstats.dropped_frames_ttl++;
}
@@ -619,13 +619,12 @@ static void hwmp_preq_frame_process(struct
ieee80211_sub_if_data *sdata,
if (flags  IEEE80211_PREQ_PROACTIVE_PREP_FLAG) {
target_addr = PREQ_IE_TARGET_ADDR(preq_elem);
target_sn = PREQ_IE_TARGET_SN(preq_elem);
-   metric = orig_metric;
}

mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
   orig_sn, target_flags, target_addr,
   target_sn, da, hopcount, ttl, lifetime,
-  metric, preq_id, sdata);
+  orig_metric, preq_id, sdata);
if (!is_multicast_ether_addr(da))
ifmsh-mshstats.fwded_unicast++;
else
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: Fix incorrectly named last_hop_metric variable in mesh_rx_path_sel_frame

2015-06-05 Thread Alexis Green 
The last hop metric should refer to link cost (this is how
hwmp_route_info_get uses it for example). But in mesh_rx_path_sel_frame
we are not dealing with link cost but with the total cost to the origin
of a PREQ or PREP.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 214e63b..be33e41 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -854,7 +854,7 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data 
*sdata,
 {
struct ieee802_11_elems elems;
size_t baselen;
-   u32 last_hop_metric;
+   u32 path_metric;
struct sta_info *sta;
 
/* need action_code */
@@ -877,21 +877,21 @@ void mesh_rx_path_sel_frame(struct ieee80211_sub_if_data 
*sdata,
if (elems.preq_len != 37)
/* Right now we support just 1 destination and no AE */
return;
-   last_hop_metric = hwmp_route_info_get(sdata, mgmt, elems.preq,
- MPATH_PREQ);
-   if (last_hop_metric)
+   path_metric = hwmp_route_info_get(sdata, mgmt, elems.preq,
+ MPATH_PREQ);
+   if (path_metric)
hwmp_preq_frame_process(sdata, mgmt, elems.preq,
-   last_hop_metric);
+   path_metric);
}
if (elems.prep) {
if (elems.prep_len != 31)
/* Right now we support no AE */
return;
-   last_hop_metric = hwmp_route_info_get(sdata, mgmt, elems.prep,
- MPATH_PREP);
-   if (last_hop_metric)
+   path_metric = hwmp_route_info_get(sdata, mgmt, elems.prep,
+ MPATH_PREP);
+   if (path_metric)
hwmp_prep_frame_process(sdata, mgmt, elems.prep,
-   last_hop_metric);
+   path_metric);
}
if (elems.perr) {
if (elems.perr_len != 15)
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mwlwifi: Initial submission of wireless driver to mainline

2015-06-05 Thread Alexis Green 
Are there plans to add support for 802.11s mesh point mode?

On Fri, Jun 5, 2015 at 8:09 AM, David Lin d...@marvell.com wrote:
 On 06/05/2015 12:29 PM, Ben Greear wrote:
 On 06/04/2015 07:41 PM, David Lin wrote:
  On 06/03/2015 09:55 PM, David Lin wrote:
  Hi all,
 
Herewith, I am submitting the Linux driver for WRT1900AC. The
 work
  was initially developed as part of openwrt effort and maintained on
  https://github.com/kaloz/mwlwifi, thanks to the host where it is
  nurtured.
 
Recently, I have also patched it to pass checkpatch.pl so that it
  can be qualified for mainline.
 
This is still work in progress, with 8864 chipset more mature and
  tested, while 8897 for the similar use case is added recently. We
  will continue to maintain and enhance it.
 
  We hope the community will welcome this initial submission!
 
  Do you have any notes on what features this driver/NIC provides?
 
  Does it require firmware, and if so, is source available?
 
  Support both 11b/g/a/n/ac AP mode, and STA mode (though the primary use
  case is AP). Driver matches most features in mac80211 and
  hostapd/supplicant. All basic securities mode have been validated.
 
  Yes, it will require firmware microcode. Matching binary is reprovided 
  as a
  separate .bin file(s) for each chip. Source codes of chip-dependent 
  microcode
  will not be provided.

 Can it do multiple virtual stations (and other virtual device combinations)?

 With ath10k, for instance, there is a complex firmware between the host and
 the NIC hardware, so any bugs and limitations in the firmware make it almost
 impossible to add interesting features or fix bugs w/out being able to modify
 the firmware source.

 Any comments on how 'thick' the marvell firmware is?

 Yes, the partitioning technically allows multiple logical interfaces. 
 However, this open source driver is not yet developed for many combinations, 
 yet.

 It is hard to comment about thickness of the firmware :) All (most?) 802.11 
 mgmt packets are handled in host driver. Think of microcode as part of 
 hardware or controlling/abstracting the hardware.

 Thanks,
 David

 --
 Ben Greear gree...@candelatech.com
 Candela Technologies Inc  http://www.candelatech.com
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: Always check rates and capabilities in mesh mode

2015-05-29 Thread Alexis Green 
In mesh mode there is a race between establishing links and processing rates
and capabilities in beacons. This is very noticeable with slow beacons (e.g.
beacon intervals of 1s) and manifested for us as stations using minstrel when
minstrel_ht should be used. Fixed by changing mesh_sta_info_init so that it
always checks rates and such if it has not already done so.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index ac843fc..4f9f23c 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -394,8 +394,9 @@ static void mesh_sta_info_init(struct
ieee80211_sub_if_data *sdata,
sta-last_rx = jiffies;

/* rates and capabilities don't change during peering */
-   if (sta-plink_state == NL80211_PLINK_ESTAB)
+   if (sta-plink_state == NL80211_PLINK_ESTAB  sta-processedBeacon)
goto out;
+   sta-processedBeacon = true;

if (sta-sta.supp_rates[band] != rates)
changed |= IEEE80211_RC_SUPP_RATES_CHANGED;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 9bd1e97..e3ae2b0 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -369,6 +369,8 @@ struct ieee80211_fast_tx {
  * @rx_msdu: MSDUs received from this station, using IEEE80211_NUM_TID
  * entry for non-QoS frames
  * @fast_tx: TX fastpath information
+ * @processedBeacon: set to true after peer rates and capabilities are
+ * processed
  */
 struct sta_info {
/* General information, mostly static */
@@ -473,6 +475,7 @@ struct sta_info {
enum nl80211_mesh_power_mode local_pm;
enum nl80211_mesh_power_mode peer_pm;
enum nl80211_mesh_power_mode nonpeer_pm;
+   bool processedBeacon;
 #endif

 #ifdef CONFIG_MAC80211_DEBUGFS
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: fix a NULL dereference in ath9k (and likely other drivers) when fixed mesh paths are used

2015-05-21 Thread Alexis Green 
This patch fixes a NULL dereference in ath9k (and likely other drivers) when
fixed mesh paths are used. The problem is that when a station comes up
sta_info_alloc allocates ath_node implicitly via hw-sta_data_size. When it
does that the ath_node is zeroed out. The ath_node isn’t actually initialized
until the station becomes associated and ath9k_sta_state is called.

Normally this is OK because paths won't be formed to a station that isn't
authorized. But when the path is fixed the MAC thinks it knows how to
 route the packet, sends it down to ath9k, and winds up inducing reboots
in places like ath_tx_start when tid-ac is dereferenced.

Signed-off-by: Alexis Green agr...@cococorp.com
CC: Jesse Jones jjo...@cococorp.com

---

diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 214e63b..14e146e 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1081,6 +1081,11 @@ int mesh_nexthop_resolve(struct
ieee80211_sub_if_data *sdata,
if (!err)
goto endlookup;

+   if (err == -EPERM) {
+   mesh_path_discard_frame(sdata, skb);
+   goto endlookup;
+   }
+
/* no nexthop found, start resolving */
mpath = mesh_path_lookup(sdata, target_addr);
if (!mpath) {
@@ -1145,6 +1150,12 @@ int mesh_nexthop_lookup(struct
ieee80211_sub_if_data *sdata,

next_hop = rcu_dereference(mpath-next_hop);
if (next_hop) {
+   if (mpath-flags  MESH_PATH_FIXED) {
+   if (next_hop-sta_state != IEEE80211_STA_AUTHORIZED) {
+   err = -EPERM;
+   goto endlookup;
+   }
+   }
memcpy(hdr-addr1, next_hop-sta.addr, ETH_ALEN);
memcpy(hdr-addr2, sdata-vif.addr, ETH_ALEN);
ieee80211_mps_set_frame_flags(sdata, next_hop, hdr);
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Issues with mesh networking path detection

2015-05-21 Thread Alexis Green 
Keep in mind that mpath table is going to empty unless you try to
reach another node. Assuming your routing is correct, pinging from one
node to another should initiate ARP request, which will cause path
requests to go out and, ultimately, add entries to mpath table. I
didn't see any mention of attempting to send data packets across the
mesh, so that might be the only problem.

On Thu, May 21, 2015 at 10:24 AM, Oleksij Rempel li...@rempel-privat.de wrote:
 Am 21.05.2015 um 19:11 schrieb Jason Scatena:
 Hello all,

 I am attempting to set up a mesh network between 4 computers with
 Atheros 9271 based usb wifi dongles using the ath9k driver.

 I followed the guide at: https://github.com/o11s/open80211s/wiki/HOWTO

 to set up the network.

 When I get all of the computers up and configured they all see each other.
 The command iw dev mesh station dump shows all the nodes in the
 area. However the path selection doesn't seem to work at all. For
 instance the command iw dev mesh mpath dump returns nothing. However
 if I manually add arp entries using the arp command they show up in
 the mpath dump.

 I am willing to do whatever to troubleshoot however there is very
 little documentation that I have been able to find on trouble shooting
 these issues. I would also be able to provide a pcap file of the nodes
 coming online.

 I'm new to the wireless world but have C coding experience and would
 be willing to put in the time to learn.


 Hi,

 i don't think there are people who will know the answer without research
 and reading the code.

 Since you are willing to learn any way, fallow the codepath and find out
 what is happening. We would be happy to have more wifi experts :)

 Find out what executed in kernel if you start this command: iw dev mesh
 mpath dump. I assume it is starting somewhere in linux/net/wireless/mesh.c

 Use printk() placed in code or use gdb+openocd+jtag if you use some arm
 or mips system.


 Best,
 Jason Scatena
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



 --
 Regards,
 Oleksij

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html