Return-path: Received: from mout.gmx.net ([212.227.17.21]:58271 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754474Ab3LPPiC (ORCPT ); Mon, 16 Dec 2013 10:38:02 -0500 Received: from [192.168.1.138] ([79.218.126.58]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MFMEG-1Vn64B2uQO-00EPlH for ; Mon, 16 Dec 2013 16:38:00 +0100 Message-ID: <52AF1E57.2040300@rempel-privat.de> (sfid-20131216_163806_152796_5349883F) Date: Mon, 16 Dec 2013 16:37:59 +0100 From: Oleksij Rempel MIME-Version: 1.0 To: Johannes Berg CC: David Herrmann , linux-wireless , "ath9k-devel@lists.ath9k.org" Subject: Re: [BUG] P2P setup timeout References: <1387197416.4665.15.camel@jlt4.sipsolutions.net> <1387201528.2057.1.camel@jlt4.sipsolutions.net> <52AF14EC.9010803@rempel-privat.de> (sfid-20131216_160940_365143_3C2C01EE) <1387206912.2057.25.camel@jlt4.sipsolutions.net> <52AF1BBE.5020602@rempel-privat.de> (sfid-20131216_162658_384029_A0D0E0F0) <1387207795.2057.29.camel@jlt4.sipsolutions.net> In-Reply-To: <1387207795.2057.29.camel@jlt4.sipsolutions.net> Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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