[ath9k-devel] [BUG] P2P setup timeout

[Oleksij Rempel <linux@rempel-privat.de>]

Am 16.12.2013 16:29, schrieb Johannes Berg:
> On Mon, 2013-12-16 at 16:26 +0100, Oleksij Rempel wrote:
>> Am 16.12.2013 16:15, schrieb Johannes Berg:
>>> On Mon, 2013-12-16 at 16:09 +0100, David Herrmann wrote:
>>>
>>>> Thanks, I tracked down the ENETDOWN. I'm not entirely sure but I think it's:
>>>
>>> Obviously :)
>>>
>>>> @Oleksij, I actually have three ath9k-htc devices so I'd like to get
>>>> this working, and the devices are really nice apart from this bug. I
>>>> will keep you up to date, but if you have any hints where to continue
>>>> digging, lemme know. Until it's fixed, I'll just work on
>>>> wired-displays via ethernet instead of wifi-displays..
>>>
>>> Based on what Oleksij said, these issues are likely not even related -
>>> maybe ath9k_htc can't even set the rates to exclude CCK, so even if that
>>> call were to succeed it wouldn't work?
>>
>> Hmm.. WMI_BITRATE_MASK should do it.
>> ieee80211_ops->set_bitrate_mask is set, so theoretically we should be
>> able to exclude CCK. Today i won't be able to check it.
> 
> There are two things:
>  * the issue at hand, which is only for some certain management frames
> that I
>    believe are sent over the normal wlan0 netdev/vif, but still must not
> use CCK
>    even though wlan0 allows CCK
>  * the issue about the set tx-rate on the p2p netdev/vif, which is how I
> noticed
>    this, but which is actually not related to the current bug
> 
> It sounds to me like only the latter can be solved with WMI_BITRATE_MASK
> since you can't generally disable CCK on wlan0 when doing P2P (you might
> be connected to an 11b AP at the same time)
> 
> For the latter issue, you really need a per-frame "disable CCK" flag in
> the firmware, or you need to use a P2P_DEVICE vif.

Ah.. there is comment which clarify the situation with
ieee80211_ops->set_bitrate_mask in ath9k_htc:
/*
 * Currently, this is used only for selecting the minimum rate
 * for management frames, rate selection for data frames remain
 * unaffected.
 */

-- 
Regards,
Oleksij