Right after associating, the AP sends us the EAPOL frame. We miss that
frame, due to a race condition (we add the STA info for the AP a little
too late and drop the frame because we don't know who it is from).
The AP of course retries the frame, a little later, but p54 misses the
TIM bit -- see the ps.pkt file.
We should probably make that race window smaller somehow (stop the
tasklet that is processing RX while processing assoc frames maybe?) but
this is clearly foremost a p54 problem.
johannes
> Well, I guess I figured out what's wrong: the hw spec.
> So this patch might work on PCI & USB, but could break SPI devices.
Heh.
> Johannes, can you please test the attached patch?
>
> BTW: there might be two problems:
> 1. if the timeout is too low the device might be fast enough to go into ps:
> - either before sending a probe request
> (firmware reports tx_status TX_PSM, so the frame wasn't sent at all)
> - or the AP got the request and responded...
> But the frame was lost, because probe responds are not buffered...
?
> 2. there was something wrong in ieee80211_rx_mgmt_beacon
> Sometimes the TIM was parsed, but thanks to
> local->hw.conf.dynamic_ps_timeout == 0
> mac80211 didn't issue a wakeup => so no data => disconnect
>
> But this bug maybe comes from the old RFCs from yesterday,
> as I didn't tried the final version yet...
I didn't change that -- Kalle did that, see the comment there. I guess
we need to change that then.
> Oh and one question:
> Some time ago, I found some useful function that converted beacon_int TUs <-> msec,
> do we still have them somewhere around and I'm just (temp) blind ?
I just added TU -> msec in one of my patches to include/linux/ieee8021.h
johannes
On Wednesday 15 April 2009 21:24:55 Johannes Berg wrote:
> Right after associating, the AP sends us the EAPOL frame. We miss that
> frame, due to a race condition (we add the STA info for the AP a little
> too late and drop the frame because we don't know who it is from).
>
> The AP of course retries the frame, a little later, but p54 misses the
> TIM bit -- see the ps.pkt file.
>
> We should probably make that race window smaller somehow (stop the
> tasklet that is processing RX while processing assoc frames maybe?) but
> this is clearly foremost a p54 problem.
Well, I guess I figured out what's wrong: the hw spec.
So this patch might work on PCI & USB, but could break SPI devices.
Johannes, can you please test the attached patch?
BTW: there might be two problems:
1. if the timeout is too low the device might be fast enough to go into ps:
- either before sending a probe request
(firmware reports tx_status TX_PSM, so the frame wasn't sent at all)
- or the AP got the request and responded...
But the frame was lost, because probe responds are not buffered...
2. there was something wrong in ieee80211_rx_mgmt_beacon
Sometimes the TIM was parsed, but thanks to
local->hw.conf.dynamic_ps_timeout == 0
mac80211 didn't issue a wakeup => so no data => disconnect
But this bug maybe comes from the old RFCs from yesterday,
as I didn't tried the final version yet...
Oh and one question:
Some time ago, I found some useful function that converted beacon_int TUs <-> msec,
do we still have them somewhere around and I'm just (temp) blind ?
Regards,
Chr
On Thursday 16 April 2009 22:18:24 Johannes Berg wrote:
>
> > Well, I guess I figured out what's wrong: the hw spec.
> > So this patch might work on PCI & USB, but could break SPI devices.
>
> Heh.
>
> > Johannes, can you please test the attached patch?
> >
updated version.
On Fri, 2009-04-17 at 13:56 +0200, Christian Lamparter wrote:
> On Thursday 16 April 2009 22:18:24 Johannes Berg wrote:
> >
> > > Well, I guess I figured out what's wrong: the hw spec.
> > > So this patch might work on PCI & USB, but could break SPI devices.
> >
> > Heh.
> >
> > > Johannes, can you please test the attached patch?
> > >
>
> updated version.
Loads of "Fake beacon loss" but works. :)
johannes
On Fri, 2009-04-17 at 13:56 +0200, Christian Lamparter wrote:
> + priv->beacon_timeout_guard = jiffies;
I wonder if you shouldn't do this when CONF_PS is (first?) enabled
instead? Or add_interface?
johannes