On Thu, Sep 22, 2016 at 10:07:46AM +0000, Altshul, Maxim wrote: > Hi All, > I am trying to control the mesh connection process manually, and I have a > couple of questions regarding the process: You probably know this but just in case, besides "connection" (peering) you can also control the (multihop) path. If your use case is only about managing the route data traffic is going to take, then you can fix mpaths instead. > 1. When using the cli command mesh_peer_add after using mesh_peer_remove ,the command returns "No such mesh peer". > I understand that this is because mesh_peer_add only calls mesh_mpm_connect_peer, which will look up the station and then return "No such mesh peer" since it was removed from the station hash table by mesh_peer_remove. > Is this by design? Wouldn't we want to add the station (using mesh_mpm_add_peer) and then connect it? This command name is maybe misleading, it means to initiate peering with an existing station, it doesn't mean "add the station as a potential peer candidate." Generally the kernel will automatically add the station entries for peer candidates when the beacon or probe response is received from the neighbor station. > 2. When a mesh point is empty (no peers), using no_auto_peer = 1 does not > stop the MP from looking up a candidate and connecting to it (I'm guessing > that the scan process causes this). Is this also by design? no_auto_peer=1 means the mesh point will not initiate a peering (by sending a peering open frame) but if it receives a peering open frame, it can still complete the peering process. If it is peering based on a scan result, then yes, that sounds like a bug. -- Bob Copeland %% http://bobcopeland.com/ _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
