On Mon, Sep 26, 2016 at 18:34:16, Bob Copeland wrote: > Subject: Re: Mesh MPM > > 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. > Yes we know this, but we want to control the connection process itself. The paths can be chosen by the HWMP. > > 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. > Well...it doesn't :) After the mesh_remove_peer command is issued, it doesn't connect to the STA that was removed anymore. I will try to investigate further.. > > 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. > All of my MP's were on no_auto_peer=1. I will look into it also. Thanks for the response :) _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
