On some practical cases, it is useful to drop new node in the distance.
Because mesh metric is calculated with hop count and without RSSI
information, a node far from local peer and near to destination node
could be used as best path.
For example, the nodes are located in linear. Distance of 0 - 1
Hi,
On Thu, 2017-03-16 at 10:57 +0900, Masashi Honma wrote:
> On some practical cases, it is useful to drop new node in the
> distance.
> Because mesh metric is calculated with hop count and without RSSI
> information, a node far from local peer and near to destination node
> could be used as best
On 2017/03/16 19:03, Johannes Berg wrote:
I'm not really sure this is the right solution?
It seems to me that it should be a function of the path selection to
take this into account, not prohibiting the longer path entirely?
Right. To calculate metric with RSSI level is better solution than
th
On Fri, 2017-03-17 at 14:56 +0900, Masashi Honma wrote:
> > It seems that this is really what the meshcfg.rssi_threshold was
> > intended for, and the plink code *does* take it into account. Can
> > you
> > explain where that's breaking down?
>
> Indeed meshcfg.rssi_threshold is already referred
On 2017/03/17 21:28, Johannes Berg wrote:
Hmm. If path selection isn't done by mac80211 in this case, wouldn't it
be more appropriate to put this logic into the (userspace) component
that does path selection?
Currently, userspace application(wpa_supplicant) does not have mesh
path selection fun
> But we still needs this patch for a special case on SAE. Some
> hardware can use hardware encryption for mesh SAE. Then the hardware
> has a limitation of key registration. For example, some hardware
> could only save keys for 8 stations. So we need to drop stations
> itself with weak signal ins
