[PATCH v2 2/2] AP: Set STA's assoc flag in the driver before sending assoc. resp.

[Peer, Ilan]

Hi Jouni,

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Saturday, February 06, 2016 19:41
> To: Peer, Ilan
> Cc: hostap at lists.infradead.org; Beker, Ayala; Otcheretianski, Andrei
> Subject: Re: [PATCH v2 2/2] AP: Set STA's assoc flag in the driver before
> sending assoc. resp.
> 
> On Mon, Jan 25, 2016 at 12:29:20PM +0200, Ilan Peer wrote:
> > Previously stations were added to the driver only after the
> > association response is acked. In the time period between the station
> > has acked the association response and between the time the station
> > was added to the kernel, the station can already start sending data
> > frames, which will be dropped by the HW. In addition to the data loss,
> > the driver may ignore NDPs with PM bit set from this STA.
> >
> > Fix this by setting/adding the STA with associated flag set to the
> > driver before the AP sends the association response with status success.
> > If the association response wasn't acked, remove the station from the
> > driver.
> 
> This is not compliant with the IEEE 802.11 standard. The station becomes
> associated when it acknowledges the (Re)Association Response frame. At
> minimum, the proposed behavior here could result in protocol compliance
> test cases failing since the AP would accept Class 3 frames before the non-AP
> STA has received or ACK'ed the (Re)Association Response frame.
> 

Indeed, we missed that point. However, as the port authorization is still handled
in the association response callback flow, class 3 frames would be still dropped.

> It would be better to add the associated flag in the driver (or
> mac80211) to allow this to be implemented in standards compliant manner.

We evaluated this option but preferred to handle this in hostap and not mac80211
as it requires monitoring assoc req/resp frames in mac80211 (while MLME is handled in
user space) which did not seem like a clean solution.

> At minimum, the commit log here would need to explain why the proposed
> behavior with the STA-removal-on-error (no ACK) is justifiable workaround
> and why it would not result in any worse issues than potential protocol
> compliance test case failures in practice.
> 

Does having the port authorization handled in the association callback a valid
reasoning? If so I can update the commit message.

> I did some cleanup to these two patches (including splitting the first one into
> two). The attached patches show the current state of the patches in my
> temporary branch. Please use them as the starting point for any possible
> resubmission of the changes. For now, I'm dropping these from my queue
> until this protocol compliance issue is resolved.
> 

Sure.

BTW, the issue addressed in the 2nd patch is valid even without the 1st one, as
we see cases that frames sent from the station immediately after acking the association
response are not handled on the AP side as the station is not yet added to the kernel.

Thanks,

Ilan.