RE: Mesh MPM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux