Re: [PATCH] cfg80211: restrict AP beacon intervals

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2011-05-11 at 23:39 +0200, Björn Smedman wrote:
> 2011/5/11 Johannes Berg <johannes@sipsolutions.net>:
> > On Wed, 2011-05-11 at 17:58 +0200, Björn Smedman wrote:
> >
> >> > Yes, in theory that's possible, but apparently no driver actually did
> >> > this correctly. Also, it didn't seem like anyone really cares, and we
> >> > need to enforce some restrictions because otherwise drivers will end up
> >> > doing it wrong, and you'll end up having a beacon interval of 200 while
> >> > advertising 150 for example, which will totally throw off powersaving
> >> > clients.
> >>
> >> I'm very interested in having multiple AP vifs with different beacon
> >> intervals. If we're going to just fail anyway in this case can't we do
> >> that from the drivers instead? I would also prefer that from an
> >> aesthetic point of view, instead of having broken logic in the drivers
> >> "protected" by extra verification in cfg80211.
> >
> > We can't fail from the drivers, they don't have a failure path.
> 
> Wouldn't it be best to add a failure path? Based a quick look it seems
> a little complicated but not unmanageable... Or what do you think?

It's not overly complicated, but I don't like it anyway, that just opens
the door to the drivers failing all kinds of things and to userspace
that'll look random.

> Is there anything else where the driver may not support a certain
> combination of bss configurations? From the top of my head I can think
> of mac address. That should fail as well depending on HW capability,
> right? That seems to be another code path but the same problem (no
> failure path).

That has a failure path, and recently I posted a patch to advertise the
interface type combinations. I don't think MAC addresses impose any sort
of restriction.


Bottom line is this: We currently don't have a driver that handles this
correctly. Therefore, the patch is absolutely correct. If somebody
enhances drivers, they're free to also enhance the checking code, and
(hopefully) include some advertising of what is possible. Currently,
however, the best assumption is that it's not possible, and we should
encode that assumption somewhere in the userspace API.

johannes