Hi Cédric, Without going into the details of the patch, let me explain why we implemented the rssi_threshhold_check functionality and why we only check it before link establishment.
On certain situations, a mesh node will be deployed at the fringes of a mesh network. When that happens, if there is no rssi check, a marginal mesh peer link could be created. By marginal I mean that the frame data rates will be very low and the frame loss probability will be high, but *some* traffic might actually go through. By introducing a minimal RSSI threshold we are avoiding the establishment of those marginal links. But why not using RSSI for teardown? Once a node is part of the mesh network, HWMP will gracefully respond to link quality degradation. HWMP has better information to make that decision than just using RSSI. Furthermore, the scenario where a node joins a mesh, then temporarily moves out of range, and then is brought back within range should be supported without having to re-establish the peer link. This is why I don't really see the value for that feature. Of course you might have a different usage in mind. If you still think it makes sense to have this feature, I would then request that you do it in a way that can be configured independently for establishment and for teardown. Thanks! Javier On Thu, Apr 3, 2014 at 3:32 AM, Cédric Debarge - ACKSYS < [email protected]> wrote: > On Wed, Apr 2, 2014 at 7:46 PM, Thomas Pedersen <[email protected]> > wrote: > > From: Thomas Pedersen <[email protected]> > > > > On Wed, Apr 2, 2014 at 2:11 AM, Cedric Debarge <[email protected] > > > > wrote: > > > From: Cédric DEBARGE <[email protected]> > > > > > > Hi all, > > > > > > Here is an RFC to extend rssi_threshold behaviour. > > > The actual code provides a way to prevent plinks from being opened if > > > the rssi with the node is lower than the configured threshold. > > > Nevertheless, it does not disable the plink if the node rssi drops > > > below the threshold after having successfully opened it in the past. > > > > > > The following patch intends to implement it. > > > It has been successfully tested in my system. > > > > > > Thanks > > > > > > Cédic DEBARGE, > > > ACKSYS R&D Dept. > > > > > > --- > > > net/mac80211/mesh_plink.c | 17 +++++++++++------ > > > 1 file changed, 11 insertions(+), 6 deletions(-) > > > > > > diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c > > > index e8f60aa..2faaf7d 100644 > > > --- a/net/mac80211/mesh_plink.c > > > +++ b/net/mac80211/mesh_plink.c > > > @@ -519,12 +519,17 @@ void mesh_neighbour_update(struct > > ieee80211_sub_if_data > > > if (!sta) > > > goto out; > > > > > > - if (mesh_peer_accepts_plinks(elems) && > > > - sta->plink_state == NL80211_PLINK_LISTEN && > > > - sdata->u.mesh.accepting_plinks && > > > - sdata->u.mesh.mshcfg.auto_open_plinks && > > > - rssi_threshold_check(sdata, sta)) > > > - changed = mesh_plink_open(sta); > > > + if (rssi_threshold_check(sta, sdata)) { > > > + if (mesh_peer_accepts_plinks(elems) && > > > + (sta->plink_state == NL80211_PLINK_LISTEN || > > > + sta->plink_state == NL80211_PLINK_BLOCKED|| > > > + sta->plink_state == NL80211_PLINK_ESTAB) && > > > + sdata->u.mesh.accepting_plinks && > > > + sdata->u.mesh.mshcfg.auto_open_plinks) { > > > + changed = mesh_plink_open(sta); > > > + } > > > + } else > > > + changed = mesh_plink_deactivate(sta); > > > > Makes sense, but why did you add those extra state checks? We _shouldn't_ > > open a plink if peering state is BLOCKED or ESTAB, right? > > > > Thomas > > mesh_plink_deactivate makes sta->plink_state = NL80211_PLINK_BLOCKED. > So the corresponding test is dedicated to handle this case. > The NL80211_PLINK_ESTAB test is here to prevent this code from > deactivating an > already established plink. This case might arrive just after you open a > plink > which was previously in NL80211_PLINK_BLOCKED state. > > Furthermore, your answer made me realize that this implementation actually > breaks the iw mechanism for blocking plinks which use the > NL80211_PLINK_BLOCKED > state through NL80211_PLINK_ACTION_BLOCK. > > How about introducing a new plink_state value dedicated to the state where > the > plink is deactivated because of the rssi threshold? This would avoid > messing > with NL80211_PLINK_ACTION_BLOCK and NL80211_PLINK_ACTION_OPEN coming from > iw. > > Another way of doing it could be to flush mesh paths with this peer as next > hop (like mesh_plink_deactivate does) when the rssi drops below the > threshold > and then reset plink_state to NL80211_PLINK_LISTEN using > mesh_plink_fsm_restart. > > Do you have any preference for one of the two ways? > > Thanks in advance, > > Cédric DEBARGE > ACKSYS R&D Dept. > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > -- Javier Cardona cozybit Inc. http://www.cozybit.com
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
