rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

[Igor Perminov]

Dear colleagues,

I've discovered that a rt73 usb wi-fi stick in the AP mode doesn't
receive PS Poll frames from a station. The station sends a PS Poll
frame, but the mac80211 stack doesn't see it.
More details can be found here:
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10,
issue #1.

I've found that the FIF_CONTROL flag isn't passed to the rt2x00's
configure_filter function (namely rt2x00mac_configure_filter) by the
mac80211 stack even if the device is configured as an access point.
So, the hardware is configured by the driver to filter out control
frames according to the flags given.

And here is my question: what would be the correct behaviour?
A) The mac80211 stack should pass the FIF_CONTROL flag to the driver
when the device is configured in the AP mode.
B) The driver should configure the hardware to receive PS Poll frames by
itself when the device is configured in the AP mode, even if the
FIF_CONTROL flag isn't passed by the mac80211 stack.

Best regards,
Igor Perminov

Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Tue, 2009-07-28 at 16:36 +0400, Igor Perminov wrote:

> And here is my question: what would be the correct behaviour?
> A) The mac80211 stack should pass the FIF_CONTROL flag to the driver
> when the device is configured in the AP mode.
> B) The driver should configure the hardware to receive PS Poll frames by
> itself when the device is configured in the AP mode, even if the
> FIF_CONTROL flag isn't passed by the mac80211 stack.

Hmm. Passing up *all* control frames wouldn't really be good -- think of
all the ACK frames. Do you have filters per frame type?

Maybe we should introduce a FIF_PSPOLL flag?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

[Igor Perminov]

> Hmm. Passing up *all* control frames wouldn't really be good -- think of
> all the ACK frames. Do you have filters per frame type?
> 
> Maybe we should introduce a FIF_PSPOLL flag?
> 
> johannes

As I see from the rt2x00 source code, older Ralink devices have common
filter for all control frames. Newer devices (including rt73usb one) can
filter ACK/CTS and other control frames separately. And the rt2800
device has a separate filter for PS Poll frames.

I agree, we should filter out the ACK frames where it is possible.

And in case we introduce the FIF_PSPOLL flag, what the exact semantics
will it have? When the FIF_CONTROL flag is passed to a driver, but the
FIF_PSPOLL one isn't, should the driver filter out PS Poll frames (a) or
not (b)?

May be it would be better to take into account the FIF_PSPOLL flag when
the FIF_CONTROL one isn't passed only (choice b) to be compatible with
the current implementation? I.e. the device should receive PS Poll
frames if either FIF_CONTROL or FIF_PSPOLL is passed (or both of them,
of course).

Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Tue, 2009-07-28 at 18:17 +0400, Igor Perminov wrote:

> And in case we introduce the FIF_PSPOLL flag, what the exact semantics
> will it have? When the FIF_CONTROL flag is passed to a driver, but the
> FIF_PSPOLL one isn't, should the driver filter out PS Poll frames (a) or
> not (b)?

Like all filter flags, FIF_PSPOLL would mean "give us PSPOLL frames
please", so (b).

> May be it would be better to take into account the FIF_PSPOLL flag when
> the FIF_CONTROL one isn't passed only (choice b) to be compatible with
> the current implementation? I.e. the device should receive PS Poll
> frames if either FIF_CONTROL or FIF_PSPOLL is passed (or both of them,
> of course).

I think it might make more sense to just set FIF_PSPOLL in mac80211 if
FIF_CONTROL is being set for some reason.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

[Igor Perminov]

On Tue, 28/07/2009 at 17:25 +0200, Johannes Berg wrote:
> On Tue, 2009-07-28 at 18:17 +0400, Igor Perminov wrote:
> 
> > And in case we introduce the FIF_PSPOLL flag, what the exact semantics
> > will it have? When the FIF_CONTROL flag is passed to a driver, but the
> > FIF_PSPOLL one isn't, should the driver filter out PS Poll frames (a) or
> > not (b)?
> 
> Like all filter flags, FIF_PSPOLL would mean "give us PSPOLL frames
> please", so (b).

And one more question.

How will a driver behave in case a device has no a separate hardware
filter for PS Poll frames? I.e. what value should the driver return from
configure_filter in total_flags?

In case there is one common filter for all control frames, it's an easy
thing. If FIF_CONTROL or FIF_PSPOLL are passed to driver's
configure_filter in total_flags, both of them should be set there and
the filter should be configured to pass through all control frames.

And suppose a device has two filters: one for ACK frames and one for all
other control frames.
Suppose FIF_CONTROL is passed in total_flags only. In that case the
driver sets FIF_PSPOLL there and configures both filters to pass through
frames. Right?
And what if FIF_PSPOLL is passed in total_flags only? In that case the
ACK filter should be configured to filter out ACK frames (otherwise it
would have performance overhead at least). And the second filter is
configured to pass through frames only (i.e. all control frames except
for ACK). So, the driver will receive not only PS Poll control frames,
but some others.
The question here is: should the driver set FIF_CONTROL in total_flags
or not in that case?

Igor

Re: rt2x00: rt73usb doesn't receive PS Poll frames in the AP mode

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Fri, 2009-07-31 at 00:09 +0400, Igor Perminov wrote:

> How will a driver behave in case a device has no a separate hardware
> filter for PS Poll frames? I.e. what value should the driver return from
> configure_filter in total_flags?
> 
> In case there is one common filter for all control frames, it's an easy
> thing. If FIF_CONTROL or FIF_PSPOLL are passed to driver's
> configure_filter in total_flags, both of them should be set there and
> the filter should be configured to pass through all control frames.
> 
> And suppose a device has two filters: one for ACK frames and one for all
> other control frames.
> Suppose FIF_CONTROL is passed in total_flags only. In that case the
> driver sets FIF_PSPOLL there and configures both filters to pass through
> frames. Right?
> And what if FIF_PSPOLL is passed in total_flags only? In that case the
> ACK filter should be configured to filter out ACK frames (otherwise it
> would have performance overhead at least). And the second filter is
> configured to pass through frames only (i.e. all control frames except
> for ACK). So, the driver will receive not only PS Poll control frames,
> but some others.
> The question here is: should the driver set FIF_CONTROL in total_flags
> or not in that case?

Huh this is getting complicated.

I think that driver behave as follows:

 * PSPOLL:             configure control, no-ack, set PSPOLL
 * CONTROL:            configure control, ack, set CONTROL
 * PSPOLL | CONTROL:   configure control, ack, set PSPOLL | CONTROL

Although I guess it could also set PSPOLL to indicate that is being
passed. OTOH, I don't think CONTROL by itself makes any sense to pass
in, so the second case won't really happen anyway.

johannes


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]