[reordered top-posting] On Thu, Jul 03, 2014 at 08:36:28PM +0800, Chun-Yeow Yeoh wrote: > >> "If the peerLinkID in the mesh peering instance has not been > >> set, the Local Link ID field of the Mesh Peering Confirm > >> request shall be copied into the peerLinkID in the mesh > >> peering instance." > >> > Hi, Bob > > What is the consequence if we don't handle this case? Is the peer > going to do the re-auth again? > > Regards, > Chun-Yeow It shouldn't be a big problem -- looking at 802.11-2012 figure 13-2: Let's say station A is in OPN_SNT and station B is in OPN_RCVD, but station A failed to get the Open frame from B. When A gets a Confirm frame from B, it would ignore it (due to missing plid), then it would resend Open on dot11MeshRetryTimeout. Unfortunately, Confirm responses from B to that Open frame would be ignored too. However, B should also retry Open on dot11MeshRetryTimeout. If any are successful, A moves to OPN_RCVD, then both have plids and everything should be ok from then on. In the worst case, plink timer on either station fires dot11MeshMaxRetries times and peering instance closes. Then peering can start over after leaving holding state and either station gets a beacon. So in sum, it just adds a bit of resiliency and means we don't have to wait for a dot11MeshRetryTimeout in the case of one lost open frame. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
