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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 May 2012 00:29:46 +0800
From:	Yeoh Chun-Yeow <yeohchunyeow@...il.com>
To:	devel@...ts.open80211s.org
Cc:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	linux-kernel@...r.kernel.org, ravip@...allas.edu
Subject: Re: [RFC] mac80211: Use correct originator sequence number in a Path Reply

> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html