Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933435Ab2EYQ3t (ORCPT ); Fri, 25 May 2012 12:29:49 -0400 Received: from mail-gg0-f174.google.com ([209.85.161.174]:52632 "EHLO mail-gg0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755139Ab2EYQ3r convert rfc822-to-8bit (ORCPT ); Fri, 25 May 2012 12:29:47 -0400 MIME-Version: 1.0 In-Reply-To: References: <1337934071-29342-1-git-send-email-qasimj@gmail.com> Date: Sat, 26 May 2012 00:29:46 +0800 Message-ID: Subject: Re: [RFC] mac80211: Use correct originator sequence number in a Path Reply From: Yeoh Chun-Yeow To: devel@lists.open80211s.org Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, ravip@utdallas.edu Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2507 Lines: 55 > 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/