On Wed, 2011-05-11 at 23:39 +0200, BjÃrn Smedman wrote: > 2011/5/11 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
