On Mon, Feb 18, 2013 at 3:16 AM, Chun-Yeow Yeoh <yeohchunyeow@xxxxxxxxx> 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 <cedric.voncken@xxxxxxxxx>
> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@xxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
