Return-path: Received: from mout.gmx.net ([212.227.15.19]:61170 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754609Ab3LPP06 (ORCPT ); Mon, 16 Dec 2013 10:26:58 -0500 Received: from [192.168.1.138] ([79.218.126.58]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MOOpx-1Vvaji0JiX-005n1r for ; Mon, 16 Dec 2013 16:26:57 +0100 Message-ID: <52AF1BBE.5020602@rempel-privat.de> (sfid-20131216_162712_066882_F2C4B8D1) Date: Mon, 16 Dec 2013 16:26:54 +0100 From: Oleksij Rempel MIME-Version: 1.0 To: Johannes Berg , David Herrmann CC: 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> In-Reply-To: <1387206912.2057.25.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: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. > The issue here doesn't seem to be that call anyway, since that call was > for the data frames on the p2p-wlan1-0 interface, but rather seems to be > that ath9k_htc ignores the no-CCK parameter for the NL80211_CMD_FRAME > command (in mac80211, this would be IEEE80211_TX_CTL_NO_CCK_RATE) > > johannes > -- Regards, Oleksij