Quoting Christian Lamparter <chunkeey@xxxxxxxxxxxxxx>:
On Wednesday 19 January 2011 19:49:03 Jussi Kivilinna wrote:
Quoting Christian Lamparter <chunkeey@xxxxxxxxxxxxxx>:
On Sunday 09 January 2011 16:46:56 Jussi Kivilinna wrote:
Quoting Christian Lamparter <chunkeey@xxxxxxxxxxxxxx>:
this is an interesting one...
Since zd_beacon_done also uploads the next beacon so long in advance,
there could be an equally long race between the outdated state of the
next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
which -in your case- was uploaded almost a beacon interval ago and
the xmit of ieee80211_get_buffered_bc *now*.
The dtim bc/mc bit might be not set, when a mc/bc arrived after the
beacon was uploaded, but before the "beacon done event" from the
hardware. So, dozing stations don't expect the broadcast traffic
and of course, they might miss it completely.
It's probably better to fix this in mac80211 (see the attached hack).
Ok, should I add this to my patchset?
well, difficult to say. As far as I can say, it should be correct for "your
case". But, on the other hand: what about solutions that can't buffer
mc/bc frames (and needs to call ieee80211_get_buffered_bc), however the
firmware is clever enough to maintain a beacon internally (so they
won't call ieee80211_beacon_get and only relies on set_tim)?
Sure, it's just a unlikely corner case... In fact, I didn't check if
that's even possible, but it does sound reasonable to some extend.
From what I checked none of currect driver/device is such.
Maybe if such device appears then !bss->dtim_bc_mc check in
ieee80211_beacon_add_tim() could be masked with driver flag (something
like
IEEE80211_HW_CAN_AND_HANDLE_BEACON_BUT_STILL_NEEDS_HOST_BROADCAST_PS_BUFFERING).
True, but a recent discussion into this matter have made parts of the
API you are planning to use sort-of "deprecated"? [I think?]
http://marc.info/?l=linux-wireless&m=129463297300480
I don't know the exact details, but I'm sure Kvalo does have his reasons.
[afaik it has to do with wl12xx, he even explained it once, but I can't
find that mail anymore].
What I understood from that thread is that rt2x00/usb doesn't have HW
buffering and doesn't enable IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING
(rt2x00/pci does), and yet enables AP-mode. Driver has this comment:
/*
* Initialize all hw fields.
*
* Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING unless we are
* capable of sending the buffered frames out after the DTIM
* transmission using rt2x00lib_beacondone. This will send out
* multicast and broadcast traffic immediately instead of buffering it
* infinitly and thus dropping it after some time.
*/
In fact, you could just as well drop "[09/17] zd1211rw: implement
seq_num for IEEE80211_TX_CTL_ASSIGN_SEQ"... unless of course, I'm
an idiot and there is a really clever way around these issues.
Oh well, I should have checked this more closely before doing that
patch. HW is assigning seq-numbers already and that patch is not needed.
heh, p54's fw can assign sequence numbers as well, but there's a
txdesc flag
to control the counter, so the firmware does not mess with the
sequence control
of QoS-Data frames. I hope zd1211* has one too.
There is tx-control flag that doesn't have effect, but since zd1211
doesn't appear to support QoS it's not a problem.
Ok, that sound reasonable.
One more thing, is there a tx-control flag to instruct the HW/FW to write
the TSF into probe response frames, just like it does for beacons frames?
Sure, this feature is far more important for IBSS, but the 802.11-2007
specs @11.1.4 says that a STA might use beacons or probe responses to
synchronize its timers. [However 11.1.1.1 and 11.1.3.4 say that STAs
should "only" pick this information from beacons, if I'm not mistaken?!]
(Also a uniform "0..0" timestamp in every probe-response looks so sad.)
No such flag I'm afraid. Vendor driver appears to be reading
tsf-register from driver and writing value to probe response frames,
maybe something I should add to zd1211rw too.
-Jussi
--
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
