2009/6/10 Johannes Berg <johannes@xxxxxxxxxxxxxxxx>: > 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. For the sake of being pedantic, can I have some reference (if only for those sleepless nights for lack of boring reading materials...)? Maybe I won't understand it anyway, but maybe somebody else who is listening in to this exchange can chip in. I have a 1300-page pdf supposedly the 802.11 2007 standard I downloaded some months ago through one of the wikipedia links, I think (somewhere under http://standards.ieee.org/) ... chapter 11 is MLME and section 11.2 is power management, which in turn is split into two sub-sections about power management in infrastructure nework and IBSS mode. I found a particular sentence in section 11.2.1. which sounds a bit like what you are saying (except with some cryptic acronyms!): ------ If any STA in its BSS is in PSmode, the AP shall buffer all broadcast and multicast MSDUs and deliver them to all STAs immediately following the next Beacon frame containing a DTIM transmission. ------ Have I found the right place to read up on such things, or there are other documents, etc (more detailed, or more "layman")? On the broken-AP mode in the zd1211 vendor driver - presumably Zydas did not wrote that specially for linux, but just modified/adapted from their windows driver? So I guess windows users of zd1211 (or other USB sticks) are used to being able to do such things and assume whatever it does is normal? It just crossed my mind that if some off-spec behavior is sufficiently popular on windows (e.g. if connection-sharing requires AP mode to work and won't take IBSS), sometimes the spec gets modified to ratify a formerly barbaric off-spec behavior. Hin-Tak -- 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
