Quoting Christian Lamparter <chunkeey@xxxxxxxxxxxxxx>:
On Sunday 09 January 2011 16:46:56 Jussi Kivilinna wrote:
Quoting Christian Lamparter <chunkeey@xxxxxxxxxxxxxx>:
> On Wednesday 05 January 2011 00:49:10 Jussi Kivilinna wrote:
>> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
>> b/drivers/net/wireless/zd1211rw/zd_mac.c
>> index aace010..a3c7e8f 100644
>> --- a/drivers/net/wireless/zd1211rw/zd_mac.c
>> +++ b/drivers/net/wireless/zd1211rw/zd_mac.c
>> @@ -958,16 +958,46 @@ static int zd_op_config(struct ieee80211_hw
>> *hw, u32 changed)
>> return zd_chip_set_channel(&mac->chip, conf->channel->hw_value);
>> }
>>
>> +static void zd_beacon_done(struct zd_mac *mac)
>> +{
>
> 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).
> 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.
-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
