Mesh MPM

Altshul, Maxim maxim.altshul at
Tue Sep 27 06:10:54 PDT 2016

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

More information about the Hostap mailing list