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.
That doesn't seem right -- there is already a mesh_plink_block() which moves the plink state into BLOCKED. Instead, according to IEEE 802.11 13.4.5, we should move the plink into HOLDING and set the timer (which once expires will move it back into LISTEN). > 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. No? once you're in the rssi_threshold_check() branch the link won't be deactivated. > 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. Yes because you're open a plink if plink_state == BLOCKED :). This shouldn't be an issue if you fix the mesh_plink_deactivate() function as described above. Then you can just check for LISTEN as usual. > 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. yes :) Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
