On Wed, 2009-06-10 at 17:22 +0200, Gábor Stefanik wrote: > On Wed, Jun 10, 2009 at 3:39 PM, Hin-Tak Leung<hintak.leung@xxxxxxxxx> wrote: > > I was talking about the client suspending/resuming (i.e. the client > > disappearing). Which isn't relevant for answering the question why there's no AP mode in zd1211rw, regardless of whether it has problems or not. > (Note that I'm also for allowing such "buggy" AP mode on devices > without a HW multicast buffer, perhaps with hostapd spitting out a > big, fat warning on startup; but Johannes has the final say in > mac80211-related questions.) > > (To Johannes: exactly why is it required for the multicast buffer to > be in hardware?) It isn't required, ath5k/9k don't have it there, they have the notorious "CAB" queue for sending frames directly after the beacon. So does b43, and probably other designs. The problem really is that powersave mode is very important for small clients like your mobile phone or digital camera, or even bluetooth3 device, and not doing multicast buffering correctly means that either those devices get into weird unreachable states, or you need to turn off powersaving features on them which makes the battery drain unbearable. Now, it may or may not be possible to work around this in software by sending out the multicast frames on a high-priority queue right after the beacon, or something like that, but frankly I'm not interested in working on zd1211rw myself, so that will have to be somebody who is (a) familiar with 802.11 powersaving and multicast buffering, (b) wants zd1211rw to work, and finally (c) has a lot of time to play with the device. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
