On Mon, Feb 18, 2013 at 3:16 AM, Chun-Yeow Yeoh <[email protected]> wrote: > Unicast frame with unknown forwarding information always trigger > the path discovery assuming destination is always located inside the > MBSS. This patch allows the forwarding to look for mesh gate if path > discovery inside the MBSS has failed. > > Reported-by: Cedric Voncken <[email protected]> > Signed-off-by: Chun-Yeow Yeoh <[email protected]> > --- > net/mac80211/tx.c | 15 ++++++++++++--- > 1 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c > index 5b9602b..dce3af3 100644 > --- a/net/mac80211/tx.c > +++ b/net/mac80211/tx.c > @@ -1844,9 +1844,18 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff > *skb, > } > > if (!is_multicast_ether_addr(skb->data)) { > - mpath = mesh_path_lookup(sdata, skb->data); > - if (!mpath) > - mppath = mpp_path_lookup(sdata, skb->data); > + struct sta_info *next_hop; > + > + mpath = mesh_path_lookup(skb->data, sdata);
The API is now mesh_path_lookup(sdata, skb->data) :) > + if (mpath) > + next_hop = rcu_dereference(mpath->next_hop); > + > + if (!mpath || (mpath && (!next_hop || > + !(mpath->flags & MESH_PATH_ACTIVE)))) The mpath could still be resolving? > + mppath = mpp_path_lookup(skb->data, sdata); > + > + if (mppath && mpath) > + mesh_path_del(mpath->dst, mpath->sdata); In general the mpath / mppath path selection code is very similar to the point of duplication. I think these are ripe for a refactoring, where a single mpath could represent an intra-MBSS or mesh gate proxied destination. This is obviously out of scope for your patch, but hopefully some day we can make all this mpath code readable :) -- Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
