The rssi_threshold is defined as s32.
Signed-off-by: Masashi Honma <[email protected]>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b15903b..bd5959f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5714,7 +5714,7 @@ static int nl80211_get_mesh_config(struct sk_buff *skb,
cur_params.dot11MeshGateAnnouncementProtocol) ||
nla_put_u8(msg, NL80211_MESHCONF_FORWARDING,
cur_params.dot11MeshForwarding) ||
- nla_put_u32(msg, NL80211_MESHCONF_RSSI_THRESHOLD,
+ nla_put_s32(msg, NL80211_MESHCONF_RSSI_THRESHOLD,
cur_params.rssi_threshold) ||
nla_put_u32(msg, NL80211_MESHCONF_HT_OPMODE,
cur_params.ht_opmode) ||
--
2.7.4
On 2017/03/17 14:59, Masashi Honma wrote:
> Previously the meshcfg.rssi_threshold did not work with user_mpm=1.
>
> Signed-off-by: Masashi Honma <[email protected]>
Is there any comment ?
Masashi Honma.
> 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 instead of the pathes to its.
Fair enough. I've added that to the ocmmit message and applied the
patch.
johannes
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 by some codes. But
> when booting mesh node with user_mpm=1, the codes is not called.
> So we need to add another code.
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?
IOW, I'm not convinced that outright not adding the *peer* is a good
idea either way - it seems much better to me to not use the *path*.
johannes
On Mon, 2017-03-27 at 05:53 +0900, Masashi Honma wrote:
> On 2017/03/17 14:59, Masashi Honma wrote:
> > Previously the meshcfg.rssi_threshold did not work with user_mpm=1.
> >
> > Signed-off-by: Masashi Honma <[email protected]>
>
> Is there any comment ?
I just applied the other patch "drop new node"
johannes
Previously the meshcfg.rssi_threshold did not work with user_mpm=1.
Signed-off-by: Masashi Honma <[email protected]>
---
net/mac80211/mesh.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 6e7b6a0..281d834 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1100,8 +1100,14 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
if (!channel || channel->flags & IEEE80211_CHAN_DISABLED)
return;
- if (mesh_matches_local(sdata, &elems))
- mesh_neighbour_update(sdata, mgmt->sa, &elems);
+ if (mesh_matches_local(sdata, &elems)) {
+ mpl_dbg(sdata, "rssi_threshold=%d,rx_status->signal=%d\n",
+ sdata->u.mesh.mshcfg.rssi_threshold, rx_status->signal);
+ if (!sdata->u.mesh.user_mpm ||
+ sdata->u.mesh.mshcfg.rssi_threshold == 0 ||
+ sdata->u.mesh.mshcfg.rssi_threshold < rx_status->signal)
+ mesh_neighbour_update(sdata, mgmt->sa, &elems);
+ }
if (ifmsh->sync_ops)
ifmsh->sync_ops->rx_bcn_presp(sdata,
--
2.7.4
On Thu, 2017-03-16 at 10:57 +0900, Masashi Honma wrote:
> The rssi_threshold is defined as s32.
>
Doesn't really matter much, but does seem nicer - applied.
johannes
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 functionality.
> IOW, I'm not convinced that outright not adding the *peer* is a good
> idea either way - it seems much better to me to not use the *path*.
We have already had the code to calculate mesh path metric with RSSI.
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 instead of the pathes to its.
Masashi Honma.
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
this solution.
> 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 by some codes. But
when booting mesh node with user_mpm=1, the codes is not called.
So we need to add another code.
I will update commit log because this patch just enables
meshcfg.rssi_threshold with user_mpm=1.
Masashi Honma.
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 path.
>
> For example, the nodes are located in linear. Distance of 0 - 1 and
> 1 - 2 and 2 - 3 is 20meters. 0 to 3 signal is very weak.
>
> 0 --- 1 --- 2 --- 3
>
> Though most robust path from 0 to 3 is 0 -> 1 -> 2 -> 3,
> unfortunately, node 0 could recognize node 3 as neighbor. Then node 3
> could be next of node 0. This patch aims to avoid such a case.
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?
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?
The documentation for this als talks about it being a plink threshold,
so I'm not really sure we should use it to kick out stations entirely.
johannes
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 and
1 - 2 and 2 - 3 is 20meters. 0 to 3 signal is very weak.
0 --- 1 --- 2 --- 3
Though most robust path from 0 to 3 is 0 -> 1 -> 2 -> 3,
unfortunately, node 0 could recognize node 3 as neighbor. Then node 3
could be next of node 0. This patch aims to avoid such a case.
Signed-off-by: Masashi Honma <[email protected]>
---
net/mac80211/mesh.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 6e7b6a0..281d834 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1100,8 +1100,14 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
if (!channel || channel->flags & IEEE80211_CHAN_DISABLED)
return;
- if (mesh_matches_local(sdata, &elems))
- mesh_neighbour_update(sdata, mgmt->sa, &elems);
+ if (mesh_matches_local(sdata, &elems)) {
+ mpl_dbg(sdata, "rssi_threshold=%d,rx_status->signal=%d\n",
+ sdata->u.mesh.mshcfg.rssi_threshold, rx_status->signal);
+ if (!sdata->u.mesh.user_mpm ||
+ sdata->u.mesh.mshcfg.rssi_threshold == 0 ||
+ sdata->u.mesh.mshcfg.rssi_threshold < rx_status->signal)
+ mesh_neighbour_update(sdata, mgmt->sa, &elems);
+ }
if (ifmsh->sync_ops)
ifmsh->sync_ops->rx_bcn_presp(sdata,
--
2.7.4