Colleen,
And probably, the safest is to increment the local sequence number when the
previous original sequence number is unknown. i.e.
mpath = mesh_path_lookup(sdata, orig_addr);
old_orig_sn = (mpath != NULL) ? mpath->sn : orig_sn - 1;
if (SN_GT(orig_sn, old_orig_sn))
ifmsh->sn = SN_MAX(ifmsh->sn, target_sn) + 1;
Javier
On Sat, Apr 5, 2014 at 10:48 AM, Thomas Pedersen <[email protected]>wrote:
> On Fri, Apr 4, 2014 at 4:53 PM, Colleen T <[email protected]> wrote:
> > On Fri, Apr 4, 2014 at 11:39 AM, Thomas Pedersen <[email protected]>
> wrote:
> >> On Thu, Apr 3, 2014 at 9:57 PM, Colleen Twitty <[email protected]>
> wrote:
> >>> [PATCH] Update target SN when a new origin SN is RX'ed.
> >>>
> >>> Before possibly updating the mpath towards a station in
> >>> hwmp_route_info_get, get the SN from the mpath table.
> >>> Then pass this on to the function that processes PREQ's so
> >>> that we can use this information to update the target SN
> >>> if the origin SN has been updated.
> >>
> >> Why? What bug does this patch fix?
> >>
> >>> Signed-off-by: Colleen Twitty <[email protected]>
> >>> ---
> >>> This patch is meant to solve the some issue as Bob's, but with a
> different
> >>> approach. This removes considering net_traversal_jiffies in updating
> the
> >>> sequence number.
> >>
> >> Does that mean we can get rid of net_traversal_jiffies entirely then?
> >> PREQs are already gated by dot11MeshHWMPpreqMinInterval, so it seems
> >> kind of redundant now.
> >
> > No, they are used correctly in limiting the increment rate of a STA's
> > origin SN. I think we still need them there.
>
> Hmm. Ok then I'm missing something. Why is origin SN even incremented
> when receiving a PREQ for which ifmsh is the target?
>
> >>> net/mac80211/mesh_hwmp.c | 39 +++++++++++++++++++++++++++++++--------
> >>> 1 file changed, 31 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
> >>> index f951468..505e180 100644
> >>> --- a/net/mac80211/mesh_hwmp.c
> >>> +++ b/net/mac80211/mesh_hwmp.c
> >>> @@ -511,7 +511,8 @@ static u32 hwmp_route_info_get(struct
> ieee80211_sub_if_data *sdata,
> >>>
> >>> static void hwmp_preq_frame_process(struct ieee80211_sub_if_data
> *sdata,
> >>> struct ieee80211_mgmt *mgmt,
> >>> - const u8 *preq_elem, u32 metric)
> >>> + const u8 *preq_elem, u32 metric,
> >>> + bool chk_old_sn, u32 old_sn)
> >>> {
> >>> struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
> >>> struct mesh_path *mpath = NULL;
> >>> @@ -541,12 +542,9 @@ static void hwmp_preq_frame_process(struct
> ieee80211_sub_if_data *sdata,
> >>> forward = false;
> >>> reply = true;
> >>> metric = 0;
> >>> - if (time_after(jiffies, ifmsh->last_sn_update +
> >>> - net_traversal_jiffies(sdata))
> ||
> >>> - time_before(jiffies, ifmsh->last_sn_update)) {
> >>> - target_sn = ++ifmsh->sn;
> >>> - ifmsh->last_sn_update = jiffies;
> >>> - }
> >>> + if (chk_old_sn && SN_LT(old_sn, orig_sn))
> >>> + ifmsh->sn = max(ifmsh->sn, target_sn)+1;
> >>> + target_sn = ifmsh->sn;
> >>> } else if (is_broadcast_ether_addr(target_addr) &&
> >>> (target_flags & IEEE80211_PREQ_TO_FLAG)) {
> >>> rcu_read_lock();
> >>> @@ -855,7 +853,11 @@ void mesh_rx_path_sel_frame(struct
> ieee80211_sub_if_data *sdata,
> >>> struct ieee802_11_elems elems;
> >>> size_t baselen;
> >>> u32 last_hop_metric;
> >>> + const u8 *orig_addr;
> >>> struct sta_info *sta;
> >>> + bool chk_old_sn = false;
> >>> + u32 old_sn;
> >>> + struct mesh_path *mpath = NULL;
> >>>
> >>> /* need action_code */
> >>> if (len < IEEE80211_MIN_ACTION_SIZE + 1)
> >>> @@ -877,11 +879,32 @@ void mesh_rx_path_sel_frame(struct
> ieee80211_sub_if_data *sdata,
> >>> if (elems.preq_len != 37)
> >>> /* Right now we support just 1 destination and
> no AE */
> >>> return;
> >>> +
> >>> + orig_addr = PREQ_IE_ORIG_ADDR(elems.preq);
> >>> +
> >>> + /* Sec. 13.10.8.3 HWMP sequence numbering calls for
> the target
> >>> + * HWMP seq number to be incremented after each
> processed PREQ,
> >>> + * but that would result in all but the last PREP
> metric info
> >>> + * to be ignored. Instead, we only increment the
> target SN
> >>> + * when we detect that the originator SN has changed.
> This
> >>> + * results in all the PREPs generated in response to a
> single
> >>> + * PREQ to have the same seq num, and, therefore, for
> the
> >>> + * metrics for the different paths to be taken into
> account.
> >>> + */
> >>> + rcu_read_lock();
> >>> + mpath = mesh_path_lookup(sdata, orig_addr);
> >>> + if (mpath) {
> >>> + chk_old_sn = true;
> >>> + old_sn = mpath->sn;
> >>> + }
> >>> + rcu_read_unlock();
> >>
> >> hwmp_preq_frame_process() already does a mesh_path_lookup(), so why do
> >> it out here? If you get rid of this you could save the parameter bloat
> >> as well.
> >
> > Yes, hwmp_preq_fame_process does a mesh-path_lookup. However, it also
> > may update the information in the mpath table, and I am trying to
> > detect if the origin SN has changed. I am doing this lookup in order
> > to get the SN before it is (maybe) updated. I think the next step,
> > assuming this is the behavior we want for updating the target sequence
> > number, is to restructure some of the mpath code to avoid this. Can
> > you see a more straightfoward path here?
>
> Yes, get the old_sn in hwmp_preq_frame_process() before updating the mpath.
> _______________________________________________
> 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
