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
