Re: [PATCH 1/2] mac80211: mesh_plink: handle confirm frames with new plid

[Bob Copeland <me@bobcopeland.com>]

[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