Thread (6 messages) 6 messages, 2 authors, 2012-05-25

Re: [RFC] mac80211: Use correct originator sequence number in a Path Reply

From: Yeoh Chun-Yeow <hidden>
Date: 2012-05-25 16:29:49
Also in: linux-wireless, lkml

No. I am referring to the originator sequence number in PREP because
when the PREP reaches the originator of the PREQ, the originator
sequence number in the PREP and the value of the metric is used to
determine which PREP will be accepted. If the originator sequence
numbers in the PREPs are different, then the PREP with the higher
sequence number will be accepted irrespective of the value of the
metric. Only if the originator sequence numbers in the PREP are equal
will the metric values in the PREPs be examined.
Based on the "Table 11C-17—Contents of a PREP element in Case A", the
originator HWMP sequence number is the HWMP sequence number of the
originator mesh STA. So this value (orig_sn in
hwmp_preq_frame_process) is unchanged in the generated PREP element
upon receiving the PREQ element.

The target HWMP sequence number is the HWMP sequence number of the
target mesh STA or target proxy mesh gate after it has been updated
according to 11C.9.8.3. So this value is changed based on target_sn in
hwmp_preq_frame_process.

I think that the confusion is in the hwmp_route_info_get,

case MPATH_PREP:
                /* Originator here refers to the MP that was the target in the
                 * Path Request. We divert from the nomenclature in the draft
                 * so that we can easily use a single function to gather path
                 * information from both PREQ and PREP frames.
                 */
                orig_sn = PREP_IE_TARGET_SN(hwmp_ie);

orig_sn here is actually the target HWMP sequence number of PREP
element generated by hwmp_preq_frame_process.
Please notice that in hwmp_preq_frame_process, target_sn ends up being
used as orig_sn for the PREP. This is probably what is causing the
confusion in your case.
I think that the PREQ element has originator sequence number at the
end but the PREQ element has the target sequence number at the end.
This is what mesh_path_sel_frame_tx is doing.
Your patch is definitely not what I was pointing out, in fact it
diverts from the standard functionality since it removes the check for
HWMPNetDiameterTraversalTime.
I thought that this is only for originator sequence number which is
done by mesh_path_start_discovery.

Regards,
Chun-Yeow
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help