Paths to mesh portals were being timed out immediately after each use in
intermediate forwarding nodes. mppath->exp_time is set to the expiration time
so assigning it to jiffies was marking the path as expired.
Signed-off-by: Javier Cardona <[email protected]>
Signed-off-by: Andrey Yurovsky <[email protected]>
---
net/mac80211/rx.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8b3faa8..3d88541 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1712,7 +1712,6 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
mpp_path_add(proxied_addr, mpp_addr, sdata);
} else {
spin_lock_bh(&mppath->state_lock);
- mppath->exp_time = jiffies;
if (compare_ether_addr(mppath->mpp, mpp_addr) != 0)
memcpy(mppath->mpp, mpp_addr, ETH_ALEN);
spin_unlock_bh(&mppath->state_lock);
--
1.6.3.3
The patch (be48ad42a1a6b82108df722034aebd12680bca44) was actually a bug.
Reverted it and improved the explanation of how mesh path refresh works.
Signed-off-by: Javier Cardona <[email protected]>
Signed-off-by: Andrey Yurovsky <[email protected]>
---
net/mac80211/mesh.h | 5 +++--
net/mac80211/mesh_hwmp.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 31e1025..85562c5 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -188,8 +188,9 @@ struct mesh_rmc {
*/
#define MESH_PREQ_MIN_INT 10
#define MESH_DIAM_TRAVERSAL_TIME 50
-/* Paths will be refreshed if they are closer than PATH_REFRESH_TIME to their
- * expiration
+/* A path will be refreshed if it is used PATH_REFRESH_TIME milliseconds before
+ * timing out. This way it will remain ACTIVE and no data frames will be
+ * unnecesarily held in the pending queue.
*/
#define MESH_PATH_REFRESH_TIME 1000
#define MESH_MIN_DISCOVERY_TIMEOUT (2 * MESH_DIAM_TRAVERSAL_TIME)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 9aecf02..c43fa91 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -936,7 +936,7 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
}
if (mpath->flags & MESH_PATH_ACTIVE) {
- if (time_after(jiffies, mpath->exp_time +
+ if (time_after(jiffies, mpath->exp_time -
msecs_to_jiffies(sdata->u.mesh.mshcfg.path_refresh_time))
&& !memcmp(sdata->dev->dev_addr, hdr->addr4,
ETH_ALEN)
--
1.6.3.3
On Wed, Dec 9, 2009 at 6:43 PM, Javier Cardona <[email protected]> wrote:
> Paths to mesh portals were being timed out immediately after each use in
> intermediate forwarding nodes. mppath->exp_time is set to the expiration time
> so assigning it to jiffies was marking the path as expired.
>
> Signed-off-by: Javier Cardona <[email protected]>
> Signed-off-by: Andrey Yurovsky <[email protected]>
Is Cc: [email protected] required or does actually CC'ing
[email protected] in the patch suffice? If the patch has the CC
embedded on the commit log I thought stable team would be notified
upon a merge of the patch. Please correct me if I'm wrong.
Would like to verify as I'm going to be a stable whore now.
Luis
On Wed, Dec 09, 2009 at 10:20:03PM -0800, Luis R. Rodriguez wrote:
> On Wed, Dec 9, 2009 at 6:43 PM, Javier Cardona <[email protected]> wrote:
> > Paths to mesh portals were being timed out immediately after each use in
> > intermediate forwarding nodes. ?mppath->exp_time is set to the expiration time
> > so assigning it to jiffies was marking the path as expired.
> >
> > Signed-off-by: Javier Cardona <[email protected]>
> > Signed-off-by: Andrey Yurovsky <[email protected]>
>
> Is Cc: [email protected] required or does actually CC'ing
> [email protected] in the patch suffice? If the patch has the CC
> embedded on the commit log I thought stable team would be notified
> upon a merge of the patch. Please correct me if I'm wrong.
>
> Would like to verify as I'm going to be a stable whore now.
AIUI either is acceptable. But adding the Cc line in the commit log
aids the stable team in automating their process.
In any case, sending stuff to [email protected] is highly recommended
(within their guidelines, of course).
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.