From owner-freebsd-wireless@freebsd.org Mon Sep 21 12:19:31 2015 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74FBBA06BE5 for ; Mon, 21 Sep 2015 12:19:31 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09E2C1E43; Mon, 21 Sep 2015 12:19:31 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by wicfx3 with SMTP id fx3so108381517wic.0; Mon, 21 Sep 2015 05:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=y5aLl8iJbI3E8UxoC0LimaoEjLDTakJ8pY1HAyfl7rI=; b=JoM+gTCZdTyPPiEALtTpRqt9SrwgLQ8/eW45d0vJJLvqZlM/LsDoEOJDoB5p4gkXoH 6nwZU4adfKx7JzgioSCm+tM3eJAe3708rQvQfjO1ww1ZGORbKmj5O+7ZcFhP8c8uqJGa kytgaX/aCCxtGH3ox5y2x6jafJcs5FU1Dh5t/oF3irpAaCn7tsmxJC7us7gJ5gJTYuR5 3CYugNmqAEx+yHuLLqtcR9HtUrRj0nzhT+BxxYY5btMsA9tanYLkMs34nBbSKyOy4kG5 VPeIJuG1lZi0GSianADa0ulezsSBoa/CZnIFL7oMXbHeTh1FT6NCMzZ3RkUWvPLBFrR2 oIVA== X-Received: by 10.194.176.6 with SMTP id ce6mr9440684wjc.101.1442837969336; Mon, 21 Sep 2015 05:19:29 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id kj5sm23836311wjb.19.2015.09.21.05.19.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Sep 2015 05:19:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Matthew Grooms" Subject: Re: urtwn and hostap References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> <55FAEA82.3060602@shrew.net> <55FFA1B9.8040005@shrew.net> Date: Mon, 21 Sep 2015 15:19:24 +0300 Cc: "Kevin Lo" , "Adrian Chadd" , freebsd-wireless@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <55FFA1B9.8040005@shrew.net> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 12:19:31 -0000 > Here is a new patch for the urtwn driver. I basically brought over the > changes committed to NetBSD that enabled hostap mode by merging in what > appeared to be the relevant differences. I also merged in two changes > that looked like they would make monitor mode more useful. > The only > change I added was to revert the beacon config register back to it's > original value when the adapter is switched back to station mode. There > are no comments around that particular call in the NetBSD driver so I'm > not sure if what I did was correct, it just seemed logical. I think too. > This patch doesn't manually generate a beacon frame using > ieee80211_beacon_alloc so I assume that setting the MSR register using > the appropriate value instructs the chip to handle that in hardware. I > tested this on both my ESXi VM using USB passthru and my raspberry pi 2. > Both appear to work as expected but the connection seemed less stable on > the latter. Can you check this with tcpdump(1) or dumpcap(1) on the sta side? (I have seen configurations, where STA's were associated with an AP without beaconing). About patch: > + if (vap->iv_opmode ==IEEE80211_M_HOSTAP) { > ... > + /* Allow Rx from any BSSID. */ > + urtwn_write_4(sc, R92C_RCR, > + urtwn_read_4(sc, R92C_RCR) & > + ~(R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN)); Is there any reason for that? (can be useful in ad-hoc mode, but I'm not sure about hostap). > + /* Set appropriate MSR bits */ > + msr |= R92C_MSR_INFRA; Probably, R92C_MSR_AP should be used here instead. > Thanks again, > > -Matthew