wpa_supplicant: IBSS/RSN and node reboot

[Antonio Quartulli]

On Tue, Dec 20, 2011 at 09:03:50 +0100, Antonio Quartulli wrote:
> > On Mon, Dec 19, 2011 at 09:59:49PM +0100, Antonio Quartulli wrote:
> > > I'm trying to make IBSS/RSN work in various scenarios. 
> > > 
> > > In particular I'm now
> > > focussing on the simple case of two nodes (say A and B) which get in sync and
> > > where one of them (say B) suddenly reboots. After this event B tries to
> > > renegotiate the key but, A (which didn't delete A's state since it haven't
> > > received any IBSS_PEER_REMOVE) will drop its EAPOL packets due to wrong
> > > replay_counter..is there any way to workaround this issue? Actually, since A is
> > > never going to receive the IBSS_PEER_REMOVE (because A and B are again the same
> > > IBSS), A is not going to delete/reinitiate B's state machine.
> > 
> > The IEEE 802.11 standard provides a mechanism that could potentially be
> > used to recover from this (well, at least if PMF is not used). Station B
> > could send an Authentication frame here and that should make station A
> > drop the current PTKSA. While the rules on Key Replay Counter do not
> > strictly speaking discuss this IBSS use, I'd say it would be fine to
> > allow this to be used to initialize key replay counter to 0 (this is
> > describe beibg on on "(re)association" which does not really happen in
> > IBSS).
> >
> 
> You mean using the authentication frame to reset the replay counter? this should
> straightforward (from the coder point of view :-))

But, am I wrong or wpa_s get an IBSS_RSN_START event only on node joining? I'm
asking because, on the lower layer, the node is still in the IBSS when pops up
again and so no IBSS_RSN_START is going to be triggered.

Regards,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara