John W. Linville wrote: > On Mon, Nov 09, 2009 at 10:37:36AM +0200, Kalle Valo wrote: >> Holger Schurig <holgerschurig@xxxxxxxxxxxxxx> writes: > >>> So, I personally prefer to have "Do an AP right" or "Don't do it at >>> all". But please no general enablement. >>> >>> But, for example, having some CONFIG_AR9K_AP_MODE depending on >>> CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully >>> this would scara away distros, so that they don't turn this on for >>> there standard kernel :-) >> I think EXPERIMENTAL is not enough, I would prefer that the user needs >> to patch the driver to enable it. Or if that's not good enough, then >> maybe depend on BROKEN. > > Here we go again... :-) > > So I definitely agree that it should be off by default. I also agree > that it should be difficult to turn it on accidentally. We don't > need any extra wierd bug reports. > > OTOH, I think we can all acknowledge that many people have reasonable > use cases with their fleet of equipment. I wonder if a sysctl would > be enough of a deterrent? They are fairly simple to turn-on, but > you do have to know about them to do so... /me would be happy about such thing as a short-term workaround if a true fix is more complicated. So far I'm lacking a feeling for the complexity - low-level 802.11 is unexplored terrain for me. Could someone briefly explain how the firmware is supposed to handle this case? By scanning outgoing frames for multicast addresses? Should the DTIM condition be detected and reported (via beacon) only by the firmware, or would the driver be involved to some degree? If we handle this transparently in the firmware, I guess that it would have to buffer not only a single multicast frame, right? Do we have enough memory for this on the chip? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
