Mesh MPM

[Altshul, Maxim]

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 :)