On Mon, May 19, 2014 at 3:18 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > On Mon, May 19, 2014 at 11:00:53AM +0200, Henning Rogge wrote: >> Is there an easy way to stop HWMP in the 802.11s implementation? > > If I understand your use case, you want to basically remove the > resolving part of mesh_nexthop_resolve()? I don't believe the > current implementation has a way to turn that off. In principle, > you can specify a vendor-specific path selection protocol when > joining, but glancing at the existing code, we don't really do > anything with that field except use it for peering fitness checks. I have an IP router connected via ethernet to a radio with a single wifi card, using the wifi card as a bridged radio. Its a great way to build routers with lots of Wifi links because you can mount the wifi-cards itself on the antenna and keep the router in a central place. I don't want to use layer-2 forwarding in the mesh because this increases the broad-/multicast domain size and spams the available frequencies even more. > If all you want to do is force the paths, you can do so with the > NL80211_CMD_SET_MESH_PATH API; such paths would override any selected > by HWMP. But you'd still generate PREQ/PREPs and get multihop > communication in that case, it just wouldn't be subject to the > airtime link metric. > > Perhaps we should skip resolve in case ifmsh->mesh_pp_id != 1 > and assume paths are somehow set up out of band or something? I want to force 802.11s only to connect to other stations one layer-2 hop away. So no forwarding by intermediate stations. Does the "mesh_fwding" parameter maybe help? Or can I set a "TTL" for the PREQ messages to 1? Henning Rogge -- 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
