From owner-freebsd-wireless@freebsd.org Sun Sep 13 03:35:36 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 9D81C9CD562 for ; Sun, 13 Sep 2015 03:35:36 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (nm30-vm1.bullet.mail.ne1.yahoo.com [98.138.90.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E3D2128C for ; Sun, 13 Sep 2015 03:35:35 +0000 (UTC) (envelope-from sreenathbh@rocketmail.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s2048; t=1442115329; bh=D0GP6dX3zL9QjzQ7/Hb8FToj33mWlbiF3bAH1LO61Wo=; h=Date:From:Subject:To:Cc:In-Reply-To:From:Subject; b=oJ6p789QdlsVWdWCnxXgrnUkI0BLE7s+neYrwO7ija/JU01tIr7sRSM4vPzAXdaZK/bdveFQiz/XRBcMKBkHpaE2m3nv9+LT5TIRZIsOcfwefJrh/Hw1HNGFQjNw2HT+2ITkZxrulIi8LSJZHrDERja71R8roMGE7Xg+we8+KsHaLL69ORq8vdQxqn9bh66IP6MYbH987yEO3ULJ4rwF7G7kwdb+6loCdWIZxEHG7Z8OyC/1TJmXpSQH4w2slo6r6koUCa5PZtn6zfkNTPbTH62MzQTRCUVkhwBdBviynnChHYqAQDMj05wKRdJnD9z0JP8uQDAC3TlQOdT9NKxwig== Received: from [98.138.226.178] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2015 03:35:29 -0000 Received: from [98.138.226.166] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2015 03:35:29 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 13 Sep 2015 03:35:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 207171.3700.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 86410 invoked by uid 60001); 13 Sep 2015 03:35:29 -0000 X-YMail-OSG: dOvQJJcVM1kkP_x7w_AZqO2g5vQzQFHNSgSR7qo2HnRT08e mY5IuFk.FdqOmY2ck7z.pb.TZF1U.4SwjGSyYR10mP2Mc7mM76PJ4tvKEo9I e9XYuf2ZxBfubnp3zI_orgRLW09sgl8kcJBFZO1LnQz_aJt_kxdf0A60NpOi 5sIn2Gz4Dgj85FGK9rU3OkVWOCeQJNypWh.coG4QZDKlXgOYhDwTGUFkTZj6 SzknZOntIIdMH90LdAbZMKSUrBFHe.EiNmGZzOLaxvOEeZtr9coHwH.7EDI_ 3Ru_VVulRJjikwGchYsDu_l1PrLUtFnyLZE7WHbc4mh8df73D.4SCdHFbVbU LxlFK34UdxRHpt0gDv1kV9N9OdhzhE1ws1Vw.l53SL3m3c29GGDhGbvSuQz2 ZD6XFYIea4_Mg4LKqmj6wlxlruRjvwktqhnMsrF2zsqet6KD85I8g1fMD1ha VyGuwxGW_D5_KBPTo1T5imkSfdMXFjUUuf5EnRzLNVLj_uCNUakw7ULsQUqk 7pGD8y2ilomRCAM9guKIl_z7N2ZWaik8xj.M78w3lnNHcIAEddAef66bEl9J 3KNKVhNip Received: from [61.1.251.251] by web122103.mail.ne1.yahoo.com via HTTP; Sat, 12 Sep 2015 20:35:28 PDT X-Rocket-MIMEInfo: 002.001, VGhvdWdoIHRoZSBkb2N1bWVudGF0aW9uIHRoYXQgY2FtZSB3aXRoIHRoZSBsYXB0b3AgZG9lcyBub3Qgc2F5IGFueXRoaW5nLA0KdGhlIGRhdGEgc2hlZXQgb2YgdGhlIG1vZGVsIG9uIEFtYXpvbiBkb2VzIHNheSBpdCBpcyA4MDIuMTFhYy4NCg0KLVNyZWVuYXRoDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbiBTYXQsIDkvMTIvMTUsIEFkcmlhbiBDaGFkZCA8YWRyaWFuLmNoYWRkQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiBTdWJqZWN0OiBSZTogQXRoZXJvcyB3aXIBMAEBAQE- X-Mailer: YahooMailBasic/683 YahooMailWebService/0.8.203.813 Message-ID: <1442115328.67303.YahooMailBasic@web122103.mail.ne1.yahoo.com> Date: Sat, 12 Sep 2015 20:35:28 -0700 From: Sreenath Battalahalli Subject: Re: Atheros wireless interface not working To: Adrian Chadd Cc: "freebsd-wireless@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sun, 13 Sep 2015 03:35:36 -0000 Though the documentation that came with the laptop does not say anything, the data sheet of the model on Amazon does say it is 802.11ac. -Sreenath -------------------------------------------- On Sat, 9/12/15, Adrian Chadd wrote: Subject: Re: Atheros wireless interface not working To: "Sreenath Battalahalli" Cc: "freebsd-wireless@freebsd.org" Date: Saturday, September 12, 2015, 3:24 PM =20 Is it the 11ac part? =20 =20 -a =20 =20 On 11 September 2015 at 23:16, Sreenath Battalahalli wrote: > Hi > > I got a new laptop (Acer E5-573) that has an atheros wireless adapter. > However, the driver available with Freebsd 10.2 does not recognise the adapter, and I don't see the wlan0 interface. > > Here are relevant lines from > $ pciconf -lv > > none2@pci0:3:0:0:=A0 =A0 =A0=A0=A0class=3D0x028000 card=3D0x080611ad chip=3D0x0042168c rev=3D0x30 > hdr=3D0x00 >=A0 =A0=A0=A0vendor=A0 =A0=A0=A0=3D 'Atheros Communications Inc.' >=A0 =A0=A0=A0class=A0 =A0 =A0 =3D network > > dmesg shows one following lines for the same device. > pci3: at device 0.0 (no driver attached) > > any help in getting this working appreciated. > > thanks, > Sreenath > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.o= rg" From owner-freebsd-wireless@freebsd.org Sun Sep 13 19:07:18 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 B25D9A0350F for ; Sun, 13 Sep 2015 19:07:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 88C1A1A2D for ; Sun, 13 Sep 2015 19:07:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofb144 with SMTP id b144so145882165iof.1 for ; Sun, 13 Sep 2015 12:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H4J96xpFgUu3QA/VcGhSa2uhvwpb/A/mhLkZhEp87LA=; b=mnCtn8ZiEyS2p3ehP3t4vJF7R8h3Ad8JVvOsWsJ5t6P3eof49x7AJ6ttf5QtGdq6ex 3CQoyElumnCbX+lnoTYgNh84JLhrbFSSiduZlOuU0c5n6jfu6FYsjKNvnupJNnaux0bC qha2ZSHjBRPP//GnKiDH4AIVuAKcsXVGF0/k/igQ35CYbMKselgJnujN7jqEy7E03GG/ M8l0CLlcKAg5jSANxYflN1HAKwaMyOUmkREHmTV4a9ZeE0hBGRlv6bFXIm4ge0CeNBl6 CGXZ24kgDEX9rHxpD236b8XXzQMumOwp6NJZk4wioLkxyK5n8kj6dq2bZiBgzKOzXFlu z76g== MIME-Version: 1.0 X-Received: by 10.107.35.78 with SMTP id j75mr18003668ioj.123.1442171237808; Sun, 13 Sep 2015 12:07:17 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Sun, 13 Sep 2015 12:07:17 -0700 (PDT) In-Reply-To: <1442115328.67303.YahooMailBasic@web122103.mail.ne1.yahoo.com> References: <1442115328.67303.YahooMailBasic@web122103.mail.ne1.yahoo.com> Date: Sun, 13 Sep 2015 12:07:17 -0700 Message-ID: Subject: Re: Atheros wireless interface not working From: Adrian Chadd To: Sreenath Battalahalli Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Sun, 13 Sep 2015 19:07:18 -0000 hiya, ok. There aren't any plans yet to do that driver. I have all the hardwrae and documentation (i was part of the team that did bringup and driver development for this particular chip, so I know it pretty well) but I have too much else going on at the moment. I'll send an email out to the list if/when I have done an initial ath10k port from linux. Thanks! -a On 12 September 2015 at 20:35, Sreenath Battalahalli wrote: > Though the documentation that came with the laptop does not say anything, > the data sheet of the model on Amazon does say it is 802.11ac. > > -Sreenath > > -------------------------------------------- > On Sat, 9/12/15, Adrian Chadd wrote: > > Subject: Re: Atheros wireless interface not working > To: "Sreenath Battalahalli" > Cc: "freebsd-wireless@freebsd.org" > Date: Saturday, September 12, 2015, 3:24 PM > > Is it the 11ac part? > > > -a > > > On 11 September 2015 at > 23:16, Sreenath Battalahalli > > wrote: > > Hi > > > > I got a new laptop (Acer E5-573) that has > an atheros wireless adapter. > > However, > the driver available with Freebsd 10.2 does not recognise > the adapter, and I don't see the wlan0 interface. > > > > Here are relevant > lines from > > $ pciconf -lv > > > > none2@pci0:3:0:0: > class=0x028000 card=0x080611ad chip=0x0042168c > rev=0x30 > > hdr=0x00 > > vendor = > 'Atheros Communications Inc.' > > > class = network > > > > dmesg shows one > following lines for the same device. > > > pci3: at device 0.0 (no driver attached) > > > > any help in getting > this working appreciated. > > > > thanks, > > > Sreenath > > > > > _______________________________________________ > > freebsd-wireless@freebsd.org > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > From owner-freebsd-wireless@freebsd.org Sun Sep 13 19:45:29 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 74BA5A038FF for ; Sun, 13 Sep 2015 19:45:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 41E631B15 for ; Sun, 13 Sep 2015 19:45:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh134 with SMTP id h134so145937436iof.0 for ; Sun, 13 Sep 2015 12:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=NlfdHsyRQZZfE21/Bmurh6m+Q9ao+TJSJMWmf9TQ5U4=; b=iLbnTn7AUgsYNoPT/1F1/v7PMu0EwJ/YeBRrq1Vvr/3mm+OZkYTX161cwh0f73jjrY HWREcaUdDa+nLO5DpL/KOk+H73YC/zksG2E4wBitfQGSr3G4AbHOzZhs6fjzstQTNG8P e717K9xeD0PWYNQK+sz2EkiNy9uNw2eH0upvl3xywA/yVkkNLqISllnCqtf2YE76DGn8 H0jLqdVNAfYqpGCxjTCWbUteFbOcvNc030slzL3t9LyQOULzMr1rU39hS+cMzTuemsMv C2yVbAjm8r/Lwg4aDbIhYzDwAHuUcyMe/MeBYd7b0mbQnDBITK7LwphcETbU0+M9YaeR euAw== MIME-Version: 1.0 X-Received: by 10.107.13.75 with SMTP id 72mr18305248ion.75.1442173528472; Sun, 13 Sep 2015 12:45:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Sun, 13 Sep 2015 12:45:28 -0700 (PDT) Date: Sun, 13 Sep 2015 12:45:28 -0700 X-Google-Sender-Auth: 43so-PjPDvjgSkFZaQ2g4RbzEa0 Message-ID: Subject: looking for if_rsu testers From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Sun, 13 Sep 2015 19:45:29 -0000 hi all, I've done some digging into if_rsu (thanks to idwer on #freebsd-wifi on efnet!) and found a few places that needed addressing. I haven't yet enabled 11n on the thing yet, but it now seems a bunch more stable and associating-y than it did before. Here's what I've found thus far: http://urbinek.eu/_soft/RTL819xSU_usb_linux_v2.6.6.0.20120405/rtl8712_8188_8191_8192SU_usb_linux_v2.6.6.0.20120405/document/RTL8712_D0_1_Programming_Guide_20090601.pdf http://www.urbinek.eu/_soft/RTL819xSU_usb_linux_v2.6.6.0.20120405/rtl8712_8188_8191_8192SU_usb_linux_v2.6.6.0.20120405/ReleaseNotes.pdf I also looked at the rtlwifi driver in linux and the fork specifically for this particular chipset for ideas: https://github.com/chunkeey/rtl8192su/tree/master/rtlwifi This is a mostly-smart device. ie, the firmware handles scanning, 802.11 association, transmit rate control, and I /think/ at least something to do with 11n aggregation - but I don't know the full details there yet. * openbsd adds a ENOTSUPP stub method for ic_send_mgmt() - ie, it blocks all software-generated management frames out. The general idea here is that the device handles scan, probe, assoc req, etc itself. I bet freebsd transmitting its own assoc request / probe requests at the same time the device is was confusing things. * it's smart like iwm/iwn/etc - however scan returns a survey message set, not beacons - so we should directly populate the scan cache rather than the current hack of faking a beacon to the stack * handle the STA disassociate message - yes, it's actually legit. * the debug sysctl is now a bitmap, so you can see interesting things without getting spammed. The most interesting one is the /text/ firmware debug messages - sysctl hw.usb.rsu.debug=0x200 - which is actually pretty enlightening. * we don't yet print out the join message response code - it does tell you about failures if they occur. * there's some very large scan-to-scan differences in reported RSSI, which is highly suspicious. That's worth looking into, in case our calibration code is suspect. So, if you're using if_rsu then please update to the latest -head and try it out. I'm very interested in the results. firmware messages via debugging is also good - compile a kernel with USB_DEBUG, and sysctl hw.usb.rsu.debug=0x200 . It'll actually give you text strings as debugging info, which is highly awesome. Thanks! -adrian From owner-freebsd-wireless@freebsd.org Sun Sep 13 19:50:20 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 A26E1A03B4E for ; Sun, 13 Sep 2015 19:50:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 6FA8E1C90 for ; Sun, 13 Sep 2015 19:50:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbkq10 with SMTP id kq10so76870917igb.0 for ; Sun, 13 Sep 2015 12:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=9pxLLtkVLEkyQZKqgqkmTx5DrwSxCbXCklgpSfGH5DA=; b=Y2R8ZkMUw51e+T2xNOeBN3i9KMv9nsAYpWy1XmOu6vQ2pPvofHI8paxYun4tsjZt4f GfJDysUFRAMW8Vz0Mzr3GnjRjf8n4mnp6alcxeJvuaov8ldCHGStfjJzBwVY5giwkD3D 4lvjKUxfGZlcWD2oUFRB3JmAteiepqTv5YEghjoQfeDt9gbAevFyORtJiyMoNXGXaK6A zfgYvP4VhFMz7z8N1VvKCq487BuSywG65/pKxZlleSJWZsA5G7Hqqtjkx0toMeuiKzRP byWg2PvJ2ZOquzhrZXumpWPGVk5yGhBZZps0Us4Fv9ubds3mCUvlPvB0V2Sspb5xyeu5 tp2w== MIME-Version: 1.0 X-Received: by 10.50.45.33 with SMTP id j1mr12083559igm.61.1442173819843; Sun, 13 Sep 2015 12:50:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Sun, 13 Sep 2015 12:50:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Sep 2015 12:50:19 -0700 X-Google-Sender-Auth: FkLZXjcOGf5f7UiR42uycMVa0m0 Message-ID: Subject: Re: looking for if_rsu testers From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Sun, 13 Sep 2015 19:50:20 -0000 oh, and I should add: * - PS_ACTIVE actually means "fully on" - it's not actually doing any intelligent power saving. We should port over the basic power management code from rtlwifi so we put the NIC into off mode if it's not active, and into power-save mode if it's not associated - much like what I did with ath(4) for network-sleep. * I think the transmit path is always using TID 0, rather than an appropriate TID for things. We have to fix that before we do 11n or lulz will ensue. * the nic supports softap, ibss and monitor modes - it'd be nice to at least get monitor mode working as a way of testing out 11n.. -adrian On 13 September 2015 at 12:45, Adrian Chadd wrote: > hi all, > > I've done some digging into if_rsu (thanks to idwer on #freebsd-wifi > on efnet!) and found a few places that needed addressing. I haven't > yet enabled 11n on the thing yet, but it now seems a bunch more stable > and associating-y than it did before. > > Here's what I've found thus far: > > http://urbinek.eu/_soft/RTL819xSU_usb_linux_v2.6.6.0.20120405/rtl8712_8188_8191_8192SU_usb_linux_v2.6.6.0.20120405/document/RTL8712_D0_1_Programming_Guide_20090601.pdf > > http://www.urbinek.eu/_soft/RTL819xSU_usb_linux_v2.6.6.0.20120405/rtl8712_8188_8191_8192SU_usb_linux_v2.6.6.0.20120405/ReleaseNotes.pdf > > I also looked at the rtlwifi driver in linux and the fork specifically > for this particular chipset for ideas: > > https://github.com/chunkeey/rtl8192su/tree/master/rtlwifi > > This is a mostly-smart device. ie, the firmware handles scanning, > 802.11 association, transmit rate control, and I /think/ at least > something to do with 11n aggregation - but I don't know the full > details there yet. > > * openbsd adds a ENOTSUPP stub method for ic_send_mgmt() - ie, it > blocks all software-generated management frames out. The general idea > here is that the device handles scan, probe, assoc req, etc itself. I > bet freebsd transmitting its own assoc request / probe requests at the > same time the device is was confusing things. > * it's smart like iwm/iwn/etc - however scan returns a survey message > set, not beacons - so we should directly populate the scan cache > rather than the current hack of faking a beacon to the stack > * handle the STA disassociate message - yes, it's actually legit. > * the debug sysctl is now a bitmap, so you can see interesting things > without getting spammed. The most interesting one is the /text/ > firmware debug messages - sysctl hw.usb.rsu.debug=0x200 - which is > actually pretty enlightening. > * we don't yet print out the join message response code - it does tell > you about failures if they occur. > * there's some very large scan-to-scan differences in reported RSSI, > which is highly suspicious. That's worth looking into, in case our > calibration code is suspect. > > So, if you're using if_rsu then please update to the latest -head and > try it out. I'm very interested in the results. firmware messages via > debugging is also good - compile a kernel with USB_DEBUG, and sysctl > hw.usb.rsu.debug=0x200 . It'll actually give you text strings as > debugging info, which is highly awesome. > > Thanks! > > > -adrian From owner-freebsd-wireless@freebsd.org Sun Sep 13 21:00:28 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 92DB4A03230 for ; Sun, 13 Sep 2015 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8602F1362 for ; Sun, 13 Sep 2015 21:00:28 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DL0S4Q014180 for ; Sun, 13 Sep 2015 21:00:28 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201509132100.t8DL0S4Q014180@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-wireless@FreeBSD.org Subject: Problem reports for freebsd-wireless@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 13 Sep 2015 21:00:28 +0000 Content-Type: text/plain; charset="UTF-8" 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: Sun, 13 Sep 2015 21:00:28 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 154598 | [ath] Atheros 5424/2424 can't connect to WPA netw Open | 163312 | [panic] [ath] kernel panic: page fault with ath0 Open | 166190 | [ath] TX hangs and frames stuck in TX queue Open | 166357 | [ath] 802.11n TX stall when the first frame in th Open | 169362 | [ath] AR5416: radar pulse PHY errors sometimes in 5 problems total for which you should take action. From owner-freebsd-wireless@freebsd.org Sun Sep 13 21:36:39 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 8A684A045D5 for ; Sun, 13 Sep 2015 21:36:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7653C198D for ; Sun, 13 Sep 2015 21:36:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DLadkG016655 for ; Sun, 13 Sep 2015 21:36:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203086] [patch] security/wpa_supplicant or from base: fix WPA-None in IBSS mode Date: Sun, 13 Sep 2015 21:36:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: s3erios@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 13 Sep 2015 21:36:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203086 Bug ID: 203086 Summary: [patch] security/wpa_supplicant or from base: fix WPA-None in IBSS mode Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: s3erios@gmail.com Keywords: patch Created attachment 161021 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161021&action=edit Fix.diff -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Sun Sep 13 21:58:09 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 1D77CA031A1 for ; Sun, 13 Sep 2015 21:58:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0784015BD for ; Sun, 13 Sep 2015 21:58:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DLw82N052619 for ; Sun, 13 Sep 2015 21:58:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203088] [patch] net/if_media.h: remove obsolete mode (IFM_IEEE80211_IBSS) Date: Sun, 13 Sep 2015 21:58:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: s3erios@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 13 Sep 2015 21:58:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203088 Bug ID: 203088 Summary: [patch] net/if_media.h: remove obsolete mode (IFM_IEEE80211_IBSS) Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: s3erios@gmail.com Keywords: patch Created attachment 161025 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161025&action=edit Remove IFM_IEEE80211_IBSS from net/if_media.h The IFM_IEEE80211_IBSS mode is not used in the kernel and should be removed (or aliased to IFM_IEEE80211_ADHOC) to prevent any misuses of it. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Sun Sep 13 21:58:42 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 E3995A031DF for ; Sun, 13 Sep 2015 21:58:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF89315DB for ; Sun, 13 Sep 2015 21:58:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DLwgJP053183 for ; Sun, 13 Sep 2015 21:58:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203086] [patch] security/wpa_supplicant or from base: fix WPA-None in IBSS mode Date: Sun, 13 Sep 2015 21:58:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: s3erios@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: blocked Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 13 Sep 2015 21:58:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203086 Andriy Voskoboinyk changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |203088 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Sun Sep 13 21:58:42 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 B34B9A031DD for ; Sun, 13 Sep 2015 21:58:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F53915DA for ; Sun, 13 Sep 2015 21:58:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8DLwgvp053178 for ; Sun, 13 Sep 2015 21:58:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203088] [patch] net/if_media.h: remove obsolete mode (IFM_IEEE80211_IBSS) Date: Sun, 13 Sep 2015 21:58:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: s3erios@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: dependson Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 13 Sep 2015 21:58:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203088 Andriy Voskoboinyk changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |203086 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 08:09:35 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 F06C7A038CA for ; Mon, 14 Sep 2015 08:09:35 +0000 (UTC) (envelope-from mueller6723@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.227]) by mx1.freebsd.org (Postfix) with ESMTP id C37D81C00 for ; Mon, 14 Sep 2015 08:09:35 +0000 (UTC) (envelope-from mueller6723@twc.com) Received: from [96.28.178.143] ([96.28.178.143:50602] helo=localhost) by dnvrco-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 42/EE-28247-80F76F55; Mon, 14 Sep 2015 08:02:16 +0000 Date: Mon, 14 Sep 2015 08:01:20 +0000 Message-ID: <42.EE.28247.80F76F55@dnvrco-oedge02> From: "Thomas Mueller" To: freebsd-wireless@freebsd.org References: Subject: Re: looking for if_rsu testers X-RR-Connecting-IP: 107.14.64.130:25 X-Authority-Analysis: v=2.1 cv=DKQB4k9b c=1 sm=1 tr=0 a=RKm8ZHSrUWUxlfG+7GhaOw==:117 a=RKm8ZHSrUWUxlfG+7GhaOw==:17 a=ayC55rCoAAAA:8 a=pedpZTtsAAAA:8 a=4OlG4wkvnqIZdA6-0VcA:9 a=HmOp8F5oYWYA:10 X-Cloudmark-Score: 0 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, 14 Sep 2015 08:09:36 -0000 I have the Hiro H50191 with Realtek RSU8191SU chip, can test it with new improvements on FreeBSD-HEAD amd64 and possibly i386, but not this minute, will try as soon as possible. OpenBSD supported this chip, also Atheros AR9271, but failed to load the firmware, so that is an issue to be considered. FreeBSD didn't have this particular problem. Tom From owner-freebsd-wireless@freebsd.org Mon Sep 14 08:18:02 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 5A009A03D28 for ; Mon, 14 Sep 2015 08:18:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 268A81F1D for ; Mon, 14 Sep 2015 08:18:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcrk20 with SMTP id rk20so81790414igc.1 for ; Mon, 14 Sep 2015 01:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nCi/2onFyyBqu1m8d02ZEtF17um417agT+qq2g/c+RU=; b=wGWOzHS4tTXCruQBugLaRmwKK+1UOqWs5gP4UfjAKYQKdWBtM+cSXXVOiEpzkEte4i 0dgPZ7MzvKFJRFSyPImiEkWTFAd0Z1EsYQ3XqXapBzk/XX1IfAQvz5jRMPPLSX0hKMH4 GMbt6xPGhW4ufvMsZlIJVA6LYUaKKOttchyqLCaid4czAjTFGj+smixgHqWmBBjcYj4w KE4gTO9dGM8aRUaCk9TsjuZEtJblHysAI2v2qtAyLJJyge1aw3CCfqvGg5oX8YTHQkME pXVVAc/SVQpEh+O8vq/jM286MbuHXh/owHTsi4XoGzhr5Q3AwdDZAylpYNceuvgMpBXs cQtw== MIME-Version: 1.0 X-Received: by 10.50.45.33 with SMTP id j1mr15035178igm.61.1442218681523; Mon, 14 Sep 2015 01:18:01 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Mon, 14 Sep 2015 01:18:01 -0700 (PDT) In-Reply-To: <42.EE.28247.80F76F55@dnvrco-oedge02> References: <42.EE.28247.80F76F55@dnvrco-oedge02> Date: Mon, 14 Sep 2015 01:18:01 -0700 Message-ID: Subject: Re: looking for if_rsu testers From: Adrian Chadd To: Thomas Mueller Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 14 Sep 2015 08:18:02 -0000 We don't have the AR9271/AR7010 USB glue in our driver. Someone has to port the glue to our atheros driver. I'll help get the HAL AR9271 bits in place if this is done! I don't know why the openbsd rsu driver works fine but ours doesn't - there's not much difference. Maybe we're doing something different in usb/net80211 land? Or maybe something locking/concurrency related? I'm not sure yet. I still do get the "firmware doesn't successfully join" problem at home, even after today's fixes. I at least have a way to reproduce the problem but I'm not sure what is going on. It'd be really helpful if someone with openbsd can get some debugging information and join #freebsd-wifi on efnet. Thanks! -adrian On 14 September 2015 at 01:01, Thomas Mueller wrote: > I have the Hiro H50191 with Realtek RSU8191SU chip, can test it with new improvements on FreeBSD-HEAD amd64 and possibly i386, but not this minute, will try as soon as possible. > > OpenBSD supported this chip, also Atheros AR9271, but failed to load the firmware, so that is an issue to be considered. FreeBSD didn't have this particular problem. > > > Tom > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Mon Sep 14 19:09:55 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 81D64A04F14 for ; Mon, 14 Sep 2015 19:09:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 554061268 for ; Mon, 14 Sep 2015 19:09:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EJ9tPR089117 for ; Mon, 14 Sep 2015 19:09:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203104] rtl8188ce not supported Date: Mon, 14 Sep 2015 19:09:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 19:09:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203104 Bug ID: 203104 Summary: rtl8188ce not supported Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: tony@git-pull.com Thinkpad X230 carry these. https://forums.freebsd.org/threads/get-realtek-rtl8188ce-802-11-g-n-wifi-adapter-to-work.45914/ http://wiki.pcbsd.org/index.php/Wireless_Testing mentions it. none2@pci0:3:0:0: class=0x028000 card=0x819510ec chip=0x817610ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8188CE 802.11b/g/n WiFi Adapter' class = network bar [10] = type I/O Port, range 32, base 0x4000, size 256, enabled bar [18] = type Memory, range 64, base 0xf1c00000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[140] = VC 1 max VC0 ecap 0003[160] = Serial 1 019181feff4ce000 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 19:24:59 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 AF916A03928 for ; Mon, 14 Sep 2015 19:24:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6B8107F for ; Mon, 14 Sep 2015 19:24:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EJOx7Q014752 for ; Mon, 14 Sep 2015 19:24:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203104] rtl8188ce not supported Date: Mon, 14 Sep 2015 19:24:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 19:24:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203104 --- Comment #1 from Tony Narlock --- Hi, I am finding conflicting information. Another issue mentions rtl8188ce (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168860). Is anyone here running rtl8188ce correctly? The issue above didn't give us an svn version, so far my research hasn't found anyone successfully running this. I do see "rtl8188ce-vau" mentioned in the top of https://github.com/freebsd/freebsd/blob/master/sys/dev/usb/wlan/if_urtwn.c. Are there potentially multiple versions of rtl8188ce? Anymore information I could provide? $ freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD x230 11.0-CURRENT FreeBSD 11.0-CURRENT #4: Fri Sep 11 11:42:41 CDT 2015 root@x230:/usr/obj/usr/src/sys/MYKERNEL amd64 amd64 1100079 1100079 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 19:28:38 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 D01D3A03A44 for ; Mon, 14 Sep 2015 19:28:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCEC710F6 for ; Mon, 14 Sep 2015 19:28:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EJSckS018060 for ; Mon, 14 Sep 2015 19:28:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Mon, 14 Sep 2015 19:28:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 19:28:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 Bug ID: 203105 Summary: [new driver] Port openbsd rtwn, new rtl8188ce driver Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: tony@git-pull.com New in OpenBSD 5.8: - http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/rtwn.4 - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_rtwn.c - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_rtwnreg.h It seems there may be (seeking clarification in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203104) missing support for rtl8188ce. OpenBSD made a driver for it, I've been using it and its been stable so far. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 19:31: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 3E50AA03B6E for ; Mon, 14 Sep 2015 19:31:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B51012F4 for ; Mon, 14 Sep 2015 19:31:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EJVVoE025753 for ; Mon, 14 Sep 2015 19:31:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203104] rtl8188ce not supported Date: Mon, 14 Sep 2015 19:31:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 19:31:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203104 --- Comment #2 from Tony Narlock --- It's been my understanding for a while rtl8188ce support doesn't exist, or is missing. I have another issue at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 to port the OpenBSD rtwn driver (new in 5.8) which I had good results with. Looking for a word back on this and we'll handle things accordingly. If by chance I'm totally out of the loop - no problem, we'll at least been on the record / more clear on the state of it. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 19:38:20 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 1624DA04014 for ; Mon, 14 Sep 2015 19:38:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02B341A9F for ; Mon, 14 Sep 2015 19:38:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EJcJNf033265 for ; Mon, 14 Sep 2015 19:38:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Mon, 14 Sep 2015 19:38:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 19:38:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 --- Comment #1 from Tony Narlock --- I would like to give this a stab myself on the weekend to learn the internals more and get in a contribution. It would be superb to see if this could make it in 11-CURRENT. If you already are on this and want to give it shot / could do it easily, no problem, just mention here. Is the fact that this module is separate from urtwn pose a problem? (OpenBSD made a whole different module for rtl8188ce called rtwn instead of having it in urtwn, I suppose they have a good reason) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 20:04:48 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 C670AA04D06 for ; Mon, 14 Sep 2015 20:04:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B31E8180A for ; Mon, 14 Sep 2015 20:04:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8EK4mvl010756 for ; Mon, 14 Sep 2015 20:04:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Mon, 14 Sep 2015 20:04:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 20:04:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #2 from Adrian Chadd --- What exactly is the difference? Is this the PCIe version? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 21:29:33 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 7BA7FA03562 for ; Mon, 14 Sep 2015 21:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 683801CAD for ; Mon, 14 Sep 2015 21:29:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8ELTXU9084006 for ; Mon, 14 Sep 2015 21:29:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Mon, 14 Sep 2015 21:29:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jkim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 21:29:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 Jung-uk Kim changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jkim@FreeBSD.org --- Comment #3 from Jung-uk Kim --- (In reply to Adrian Chadd from comment #2) Yes, it seems so: http://www.realtek.com/products/productsView.aspx?Langid=1&PFid=48&Level=5&Conn=4&ProdID=272 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Mon Sep 14 21:36:08 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 CA0F7A039F3 for ; Mon, 14 Sep 2015 21:36:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6A34103C for ; Mon, 14 Sep 2015 21:36:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8ELa8Ae095720 for ; Mon, 14 Sep 2015 21:36:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Mon, 14 Sep 2015 21:36:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 14 Sep 2015 21:36:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 --- Comment #4 from Adrian Chadd --- They're almost the same chips though. How similar are the drivers? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Tue Sep 15 03:04:21 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 5D06FA03E59 for ; Tue, 15 Sep 2015 03:04:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49BCD1C36 for ; Tue, 15 Sep 2015 03:04:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8F34LJc003849 for ; Tue, 15 Sep 2015 03:04:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203104] rtl8188ce not supported Date: Tue, 15 Sep 2015 03:04:21 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Tue, 15 Sep 2015 03:04:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203104 --- Comment #3 from Tony Narlock --- As an update: > That's it. Unfortunately, the only OpenBSD driver that has support for this is the RTL8188CE-VAU, a USB variant chipset, via the urtwn(4) driver. which is USB-only. There is no driver for the for the PCI-bus RTL8188CE. source: http://daemonforums.org/showpost.php?p=50084&postcount=9 So we are in fact missing support for RTL8188CE (the PCI one) you would find in a laptop like the Thinkpad X230. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Tue Sep 15 03:09:13 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 87DC8A020CB for ; Tue, 15 Sep 2015 03:09:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7476B1D94 for ; Tue, 15 Sep 2015 03:09:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8F39DhL056759 for ; Tue, 15 Sep 2015 03:09:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203104] rtl8188ce PCI adapter not supported Date: Tue, 15 Sep 2015 03:09:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tony@git-pull.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Tue, 15 Sep 2015 03:09:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203104 Tony Narlock changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|rtl8188ce not supported |rtl8188ce PCI adapter not | |supported -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Tue Sep 15 08:30:19 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 DFAE7A03299 for ; Tue, 15 Sep 2015 08:30:19 +0000 (UTC) (envelope-from mueller6723@twc.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.225]) by mx1.freebsd.org (Postfix) with ESMTP id B245218EE for ; Tue, 15 Sep 2015 08:30:18 +0000 (UTC) (envelope-from mueller6723@twc.com) Received: from [96.28.178.143] ([96.28.178.143:64630] helo=localhost) by dnvrco-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 97/F1-01924-956D7F55; Tue, 15 Sep 2015 08:27:06 +0000 Date: Tue, 15 Sep 2015 08:26:05 +0000 Message-ID: <97.F1.01924.956D7F55@dnvrco-oedge01> From: "Thomas Mueller" To: freebsd-wireless@freebsd.org References: <42.EE.28247.80F76F55@dnvrco-oedge02> Subject: Re: looking for if_rsu testers X-RR-Connecting-IP: 107.14.64.118:25 X-Authority-Analysis: v=2.1 cv=fZ8jyigF c=1 sm=1 tr=0 a=RKm8ZHSrUWUxlfG+7GhaOw==:117 a=RKm8ZHSrUWUxlfG+7GhaOw==:17 a=ayC55rCoAAAA:8 a=pedpZTtsAAAA:8 a=FP58Ms26AAAA:8 a=3tcz3bTJAAAA:8 a=PLUjekkXDLzMlGrr2QoA:9 a=83IDqXaSLGwA:10 X-Cloudmark-Score: 0 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: Tue, 15 Sep 2015 08:30:20 -0000 > We don't have the AR9271/AR7010 USB glue in our driver. Someone has to > port the glue to our atheros driver. I'll help get the HAL AR9271 bits > in place if this is done! > I don't know why the openbsd rsu driver works fine but ours doesn't - > there's not much difference. Maybe we're doing something different in > usb/net80211 land? Or maybe something locking/concurrency related? I'm > not sure yet. > I still do get the "firmware doesn't successfully join" problem at > home, even after today's fixes. I at least have a way to reproduce the > problem but I'm not sure what is going on. It'd be really helpful if > someone with openbsd can get some debugging information and join > #freebsd-wifi on efnet. > Thanks! > -adrian With Hiro H50191 (rsu) on FreeBSD, I don't get the firmware-not-loading problem but did in OpenBSD. All I have for OpenBSD is the latest (5.4) USB-stick image from liveusb-openbsd.sourceforge.net , and updated bsd.rd for OpenBSD 5.5, 5,6 and 5.7. Neither AR9271 (athn) nor rsu ever loaded the firmware. On NetBSD-current, sometimes athn works at least for some time before silently quitting, but most of the time I get athn0: could not load firmware (35) Fortunately Realtek 8111E Ethernet works with re, now FreeBSD as well as NetBSD, but not OpenBSD (maybe the upcoming OpenBSD 5.8 due for Oct 18, 2015?). A problem with OpenBSD is not supporting gpt. I noticed gpt commented out in GENERIC config (cvsweb interface), but now I see, on www.openbsd.org/plus58.html Disable GPT support. It appears to create broken spoofed labels for empty disks. (end of quote) That makes it very difficult to do anything with OpenBSD, unless I do everything on USB sticks (limited writes?). Try to cross-compile Bitrig (forked from OpenBSD) from NetBSD-current amd64? I actually git-cloned and updated (git pull) the source, xenocara and ports trees to at least have a look. Tom From owner-freebsd-wireless@freebsd.org Wed Sep 16 05:46:42 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 DCEA19CDD51 for ; Wed, 16 Sep 2015 05:46:42 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 580891ECB for ; Wed, 16 Sep 2015 05:46:41 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8G5fgFD035421 for ; Wed, 16 Sep 2015 00:41:42 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-179-24-154.austin.res.rr.com [72.179.24.154]) by mail.shrew.net (Postfix) with ESMTPSA id 2C21718B9F3 for ; Wed, 16 Sep 2015 00:41:31 -0500 (CDT) To: freebsd-wireless@freebsd.org From: Matthew Grooms Subject: urtwn and hostap Message-ID: <55F90187.10809@shrew.net> Date: Wed, 16 Sep 2015 00:43:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020602080509020909060107" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 16 Sep 2015 00:41:42 -0500 (CDT) X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Wed, 16 Sep 2015 05:46:43 -0000 This is a multi-part message in MIME format. --------------020602080509020909060107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hey wireless folks, I wanted to setup a Raspberry Pi as a FreeBSD AP and purchased a picked up a few Edimax 802.11 adapters to play with. Unfortunately these aren't supported in hostap mode. As it turns out these Edimax adapters use the RTL8188CUS chipset so I poked around the net and noticed that Linux does support the host AP feature with it's RTL8188CUS driver. I was also able to find a patch for OpenBSD that added support for the RTL8188EU chipset to the urtwn driver ... http://marc.info/?l=openbsd-tech&m=143577648117514&w=2 So I ordered one of these which arrived from China a few weeks later ... http://www.amazon.com/gp/product/B00L28AN88?psc=1&redirect=true&ref_=oh_aui_detailpage_o05_s00 Next I took a stab at porting the patch to FreeBSD. With the attached patch applied, I was able to setup a wlan0 device with the hostap feature. After bridging it with the LAN I could associate with my android phone, obtain an IP address via DHCP, browse a few web pages and watch all the packets pass through the bridge. Sadly, when I attempted to destroy the wlan0 device I got a kernel panic. The screenshot for that is also attached and I'm not sure if I'm going to be able to figure this one out without some help. I'm pretty out of my element here. I assume it's happening in ieee80211_free_node() when IEEE80211_NODE_LOCK() is called. To be clear, the crash only occurs when the adapter is configured in hostap mode with the patch applied. Anyone have any suggestions as to what I should be looking at to prevent this crash? If I can get this working for the RTL8188EU, I'll also take a stab at getting the RTL8188CUS chipset working in hostap mode. That is, assuming I can glean enough info from drivers that support this feature on other open source platforms. It appears to be extremely popular with the Raspberry PI crowd ... http://www.amazon.com/Edimax-EW-7811Un-150Mbps-Raspberry-Supports/dp/B003MTTJOY Thanks in advance, -Matthew --------------020602080509020909060107 Content-Type: text/plain; charset=UTF-8; name="urtwn.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="urtwn.diff" SW5kZXg6IGRldi91c2Ivd2xhbi9pZl91cnR3bi5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGRldi91 c2Ivd2xhbi9pZl91cnR3bi5jCShyZXZpc2lvbiAyODczNDIpCisrKyBkZXYvdXNiL3dsYW4v aWZfdXJ0d24uYwkod29ya2luZyBjb3B5KQpAQCAtMTgxLDYgKzE4MSw4IEBACiBzdGF0aWMg c3RydWN0IG1idWYgKgl1cnR3bl9yeGVvZihzdHJ1Y3QgdXNiX3hmZXIgKiwgc3RydWN0IHVy dHduX2RhdGEgKiwKIAkJCSAgICBpbnQgKiwgaW50OF90ICopOwogc3RhdGljIHZvaWQJCXVy dHduX3R4ZW9mKHN0cnVjdCB1c2JfeGZlciAqLCBzdHJ1Y3QgdXJ0d25fZGF0YSAqKTsKK2lu dAkJCXVydHduX3R4YmNuKHN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCwKKwkJCSAgICBzdHJ1 Y3QgaWVlZTgwMjExX25vZGUgKik7CiBzdGF0aWMgaW50CQl1cnR3bl9hbGxvY19saXN0KHN0 cnVjdCB1cnR3bl9zb2Z0YyAqLAogCQkJICAgIHN0cnVjdCB1cnR3bl9kYXRhW10sIGludCwg aW50KTsKIHN0YXRpYyBpbnQJCXVydHduX2FsbG9jX3J4X2xpc3Qoc3RydWN0IHVydHduX3Nv ZnRjICopOwpAQCAtNDM2LDYgKzQzOCwxMCBAQAogCQl8IElFRUU4MDIxMV9DX1dQQQkJLyog ODAyLjExaSAqLwogCQk7CiAKKwlpZiAoc2MtPmNoaXAgJiBVUlRXTl9DSElQXzg4RSkKKwkJ aWMtPmljX2NhcHMgfD0KKwkJICAgIElFRUU4MDIxMV9DX0hPU1RBUDsJCS8qIEhvc3RBcCBt b2RlIHN1cHBvcnRlZCAqLworCiAJYmFuZHMgPSAwOwogCXNldGJpdCgmYmFuZHMsIElFRUU4 MDIxMV9NT0RFXzExQik7CiAJc2V0Yml0KCZiYW5kcywgSUVFRTgwMjExX01PREVfMTFHKTsK QEAgLTg1Nyw2ICs4NjMsMzYgQEAKIAlzYy0+c2NfdHh0aW1lciA9IDA7CiB9CiAKKy8qCisg KiBQdXNoIGEgYmVhY29uIGZyYW1lIGludG8gdGhlIGNoaXAgYW5kIGNoZWNrIGlmIGl0IHdh cyBhY2NlcHRlZC4gIEJlYWNvbiB3aWxsCisgKiBiZSByZXBlYXRlZCBieSB0aGUgY2hpcCBl dmVyeSBSOTJDX0JDTl9JTlRFUlZBTC4KKyAqLworaW50Cit1cnR3bl90eGJjbihzdHJ1Y3Qg aWVlZTgwMjExdmFwICp2YXAsIHN0cnVjdCBpZWVlODAyMTFfbm9kZSAqbmkpCit7CisJc3Ry dWN0IGllZWU4MDIxMWNvbSAqaWMgPSBuaS0+bmlfaWM7CisJc3RydWN0IHVydHduX3NvZnRj ICpzYyA9IGljLT5pY19zb2Z0YzsKKwlzdHJ1Y3QgdXJ0d25fZGF0YSAqYmY7CisJc3RydWN0 IG1idWYgKm07CisKKwltID0gaWVlZTgwMjExX2JlYWNvbl9hbGxvYyhuaSwgJlVSVFdOX1ZB UCh2YXApLT5ibyk7CisKKwliZiA9IHVydHduX2dldGJ1ZihzYyk7CisJaWYgKGJmID09IE5V TEwpIHsKKwkJbV9mcmVlbShtKTsKKwkJcmV0dXJuIChFTk9CVUZTKTsKKwl9CisKKwlpZiAo dXJ0d25fdHhfc3RhcnQoc2MsIG5pLCBtLCBiZikgIT0gMCkgeworCQlTVEFJTFFfSU5TRVJU X0hFQUQoJnNjLT5zY190eF9pbmFjdGl2ZSwgYmYsIG5leHQpOworCQlyZXR1cm4gKEVJTyk7 CisJfQorCisJc2MtPnNjX3R4dGltZXIgPSA1OworCisJcmV0dXJuICgwKTsKK30KKwogc3Rh dGljIHZvaWQKIHVydHduX2J1bGtfdHhfY2FsbGJhY2soc3RydWN0IHVzYl94ZmVyICp4ZmVy LCB1c2JfZXJyb3JfdCBlcnJvcikKIHsKQEAgLTE0NjYsNiArMTUwMiw3IEBACiAJc3RydWN0 IGllZWU4MDIxMV9ub2RlICpuaTsKIAllbnVtIGllZWU4MDIxMV9zdGF0ZSBvc3RhdGU7CiAJ dWludDMyX3QgcmVnOworCWludCBlcnJvcjsKIAogCW9zdGF0ZSA9IHZhcC0+aXZfc3RhdGU7 CiAJRFBSSU5URigiJXMgLT4gJXNcbiIsIGllZWU4MDIxMV9zdGF0ZV9uYW1lW29zdGF0ZV0s CkBAIC0xNTUzLDIzICsxNTkwLDY4IEBACiAJCX0KIAogCQluaSA9IGllZWU4MDIxMV9yZWZf bm9kZSh2YXAtPml2X2Jzcyk7Ci0JCS8qIFNldCBtZWRpYSBzdGF0dXMgdG8gJ0Fzc29jaWF0 ZWQnLiAqLwotCQlyZWcgPSB1cnR3bl9yZWFkXzQoc2MsIFI5MkNfQ1IpOwotCQlyZWcgPSBS VyhyZWcsIFI5MkNfQ1JfTkVUVFlQRSwgUjkyQ19DUl9ORVRUWVBFX0lORlJBKTsKLQkJdXJ0 d25fd3JpdGVfNChzYywgUjkyQ19DUiwgcmVnKTsKIAotCQkvKiBTZXQgQlNTSUQuICovCi0J CXVydHduX3dyaXRlXzQoc2MsIFI5MkNfQlNTSUQgKyAwLCBMRV9SRUFEXzQoJm5pLT5uaV9i c3NpZFswXSkpOwotCQl1cnR3bl93cml0ZV80KHNjLCBSOTJDX0JTU0lEICsgNCwgTEVfUkVB RF8yKCZuaS0+bmlfYnNzaWRbNF0pKTsKKwkJaWYgKGljLT5pY19vcG1vZGUgPT0gSUVFRTgw MjExX01fU1RBKSB7CisJCQkvKiBTZXQgQlNTSUQuICovCisJCQl1cnR3bl93cml0ZV80KHNj LCBSOTJDX0JTU0lEICsgMCwKKwkJCQlMRV9SRUFEXzQoJm5pLT5uaV9ic3NpZFswXSkpOwor CQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19CU1NJRCArIDQsCisJCQkJTEVfUkVBRF8yKCZu aS0+bmlfYnNzaWRbNF0pKTsKIAotCQlpZiAoaWMtPmljX2N1cm1vZGUgPT0gSUVFRTgwMjEx X01PREVfMTFCKQotCQkJdXJ0d25fd3JpdGVfMShzYywgUjkyQ19JTklSVFNfUkFURV9TRUws IDApOwotCQllbHNlCS8qIDgwMi4xMWIvZyAqLwotCQkJdXJ0d25fd3JpdGVfMShzYywgUjky Q19JTklSVFNfUkFURV9TRUwsIDMpOworCQkJaWYgKGljLT5pY19jdXJtb2RlID09IElFRUU4 MDIxMV9NT0RFXzExQikKKwkJCQl1cnR3bl93cml0ZV8xKHNjLCBSOTJDX0lOSVJUU19SQVRF X1NFTCwgMCk7CisJCQllbHNlCS8qIDgwMi4xMWIvZyAqLworCQkJCXVydHduX3dyaXRlXzEo c2MsIFI5MkNfSU5JUlRTX1JBVEVfU0VMLCAzKTsKIAotCQkvKiBFbmFibGUgUnggb2YgZGF0 YSBmcmFtZXMuICovCi0JCXVydHduX3dyaXRlXzIoc2MsIFI5MkNfUlhGTFRNQVAyLCAweGZm ZmYpOworCQkJLyogRW5hYmxlIFJ4IG9mIGRhdGEgZnJhbWVzLiAqLworCQkJdXJ0d25fd3Jp dGVfMihzYywgUjkyQ19SWEZMVE1BUDIsIDB4ZmZmZik7CiAKKwkJCS8qIEFsbG93IFJ4IGZy b20gb3VyIEJTU0lEIG9ubHkuICovCisJCQl1cnR3bl93cml0ZV80KHNjLCBSOTJDX1JDUiwg dXJ0d25fcmVhZF80KHNjLCBSOTJDX1JDUikgfAorCQkJICAgIFI5MkNfUkNSX0NCU1NJRF9E QVRBIHwgUjkyQ19SQ1JfQ0JTU0lEX0JDTik7CisKKwkJCS8qIFNldCBtZWRpYSBzdGF0dXMg dG8gJ0Fzc29jaWF0ZWQnLiAqLworCQkJcmVnID0gdXJ0d25fcmVhZF80KHNjLCBSOTJDX0NS KTsKKwkJCXJlZyA9IFJXKHJlZywgUjkyQ19DUl9ORVRUWVBFLCBSOTJDX0NSX05FVFRZUEVf SU5GUkEpOworCQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19DUiwgcmVnKTsKKwkJfQorCisJ CWlmIChpYy0+aWNfb3Btb2RlID09IElFRUU4MDIxMV9NX0hPU1RBUCkgeworCQkJLyogU2V0 IG1lZGlhIHN0YXR1cyB0byAnQVAnLiAqLworCQkJcmVnID0gdXJ0d25fcmVhZF80KHNjLCBS OTJDX0NSKTsKKwkJCXJlZyA9IFJXKHJlZywgUjkyQ19DUl9ORVRUWVBFLCBSOTJDX0NSX05F VFRZUEVfQVApOworCQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19DUiwgcmVnKTsKKworCQkJ LyogU2V0IEJTU0lELiAqLworCQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19CU1NJRCArIDAs CisJCQkgICAgTEVfUkVBRF80KCZuaS0+bmlfYnNzaWRbMF0pKTsKKwkJCXVydHduX3dyaXRl XzQoc2MsIFI5MkNfQlNTSUQgKyA0LAorCQkJICAgIExFX1JFQURfMigmbmktPm5pX2Jzc2lk WzRdKSk7CisKKwkJCS8qCisJCQkgKiBJZiAzcmQgb3IgNHRoIGJpdHMgYXJlIHNldCB0byB6 ZXJvIGNoaXAgd2lsbCBzdG9wCisJCQkgKiByZXBlYXRpbmcgYmVhY29uIGFmdGVyIGZpcnN0 IHRyYW5zbWlzc2lvbiBmb3IgcG9ydDAKKwkJCSAqIGFuZCBwb3J0MSByZXNwZWN0aXZlbHku IFRoaXMgd2lsbCBjYXVzZSBTVEFzIHRvCisJCQkgKiBkaXNjb25uZWN0IGFmdGVyIHNob3J0 IHBlcmlvZCBvZiB0aW1lLgorCQkJICovCisJCQlyZWcgPSB1cnR3bl9yZWFkXzEoc2MsIFI5 MkNfTUJJRF9OVU0pOworCQkJcmVnIHw9IDB4ODsKKwkJCXJlZyB8PSAweDEwOworCQkJdXJ0 d25fd3JpdGVfMShzYywgUjkyQ19NQklEX05VTSwgcmVnKTsKKworCQkJLyogSW52YWxpZGF0 ZSBjYW0gZW50cmllcyAqLworCQkJdXJ0d25fY2FtX2luaXQoc2MpOworCisJCQkvKiBTZXQg Y2hhbi9idyAqLworCQkJdXJ0d25fc2V0X2NoYW4oc2MsIGljLT5pY19jdXJjaGFuLCBOVUxM KTsKKworCQkJLyogUHVzaCBiZWFjb24gZnJhbWUgaW50byB0aGUgY2hpcCAqLworCQkJZXJy b3IgPSB1cnR3bl90eGJjbih2YXAsIG5pKTsKKwkJCWlmIChlcnJvciAhPSAwKQorCQkJCXBy aW50ZigiJXM6IHVuYWJsZSB0byBwdXNoIGJlYWNvbiBpbnRvIHRoZSIKKwkJCQkgICAgIiBj aGlwXG4iLCBkZXZpY2VfZ2V0X25hbWV1bml0KHNjLT5zY19kZXYpKTsKKwkJfQorCiAJCS8q IEZsdXNoIGFsbCBBQyBxdWV1ZXMuICovCiAJCXVydHduX3dyaXRlXzEoc2MsIFI5MkNfVFhQ QVVTRSwgMCk7CiAKQEAgLTE1NzYsMTEgKzE2NTgsNiBAQAogCQkvKiBTZXQgYmVhY29uIGlu dGVydmFsLiAqLwogCQl1cnR3bl93cml0ZV8yKHNjLCBSOTJDX0JDTl9JTlRFUlZBTCwgbmkt Pm5pX2ludHZhbCk7CiAKLQkJLyogQWxsb3cgUnggZnJvbSBvdXIgQlNTSUQgb25seS4gKi8K LQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19SQ1IsCi0JCSAgICB1cnR3bl9yZWFkXzQoc2Ms IFI5MkNfUkNSKSB8Ci0JCSAgICBSOTJDX1JDUl9DQlNTSURfREFUQSB8IFI5MkNfUkNSX0NC U1NJRF9CQ04pOwotCiAJCS8qIEVuYWJsZSBUU0Ygc3luY2hyb25pemF0aW9uLiAqLwogCQl1 cnR3bl90c2Zfc3luY19lbmFibGUoc2MpOwogCkBAIC0xNzU0LDcgKzE4MzEsNyBAQAogCXN0 cnVjdCBpZWVlODAyMTF2YXAgKnZhcCA9IG5pLT5uaV92YXA7CiAJc3RydWN0IHVzYl94ZmVy ICp4ZmVyOwogCXN0cnVjdCByOTJjX3R4X2Rlc2MgKnR4ZDsKLQl1aW50OF90IHJhaWQsIHR5 cGU7CisJdWludDhfdCByYWlkLCB0eXBlLCBzdWJ0eXBlOwogCXVpbnQxNl90IHN1bTsKIAlp bnQgaSwgaGFzcW9zLCB4ZmVybGVuOwogCXN0cnVjdCB1c2JfeGZlciAqdXJ0d25fcGlwZXNb NF0gPSB7CkBAIC0xNzcxLDYgKzE4NDgsNyBAQAogCSAqLwogCXdoID0gbXRvZChtMCwgc3Ry dWN0IGllZWU4MDIxMV9mcmFtZSAqKTsKIAl0eXBlID0gd2gtPmlfZmNbMF0gJiBJRUVFODAy MTFfRkMwX1RZUEVfTUFTSzsKKwlzdWJ0eXBlID0gd2gtPmlfZmNbMF0gJiBJRUVFODAyMTFf RkMwX1NVQlRZUEVfTUFTSzsKIAogCWlmICh3aC0+aV9mY1sxXSAmIElFRUU4MDIxMV9GQzFf UFJPVEVDVEVEKSB7CiAJCWsgPSBpZWVlODAyMTFfY3J5cHRvX2VuY2FwKG5pLCBtMCk7CkBA IC0xODE5LDcgKzE4OTcsNyBAQAogCQlpZiAoc2MtPmNoaXAgJiBVUlRXTl9DSElQXzg4RSkg ewogCQkJdHhkLT50eGR3MSB8PSBodG9sZTMyKAogCQkJICAgIFNNKFI4OEVfVFhEVzFfTUFD SUQsIFVSVFdOX01BQ0lEX0JTUykgfAotCQkJICAgIFNNKFI5MkNfVFhEVzFfUVNFTCwgUjky Q19UWERXMV9RU0VMX0JFKSB8CisJCQkgICAgU00oUjkyQ19UWERXMV9RU0VMLCBSODhFX1RY RFcxX1FTRUxfQkUpIHwKIAkJCSAgICBTTShSOTJDX1RYRFcxX1JBSUQsIHJhaWQpKTsKIAkJ CXR4ZC0+dHhkdzIgfD0gaHRvbGUzMihSODhFX1RYRFcyX0FHR0JLKTsKIAkJfSBlbHNlIHsK QEAgLTE4NDMsOSArMTkyMSwyMCBAQAogCQkvKiBTZW5kIGRhdGEgYXQgT0ZETTU0LiAqLwog CQl0eGQtPnR4ZHc1IHw9IGh0b2xlMzIoU00oUjkyQ19UWERXNV9EQVRBUkFURSwgMTEpKTsK IAl9IGVsc2UgeworCQkvKgorCQkgKiBJZiBiZWFjb24gZnJhbWUgaXMgcHVzaGVkIGludG8g d3JvbmcgcXVldWUsIHRoZSBjaGlwIHdvbid0CisJCSAqIHN0YXJ0IHJlcGVhdGluZyBpdC4K KwkJICovCisJCWlmIChzdWJ0eXBlID09IElFRUU4MDIxMV9GQzBfU1VCVFlQRV9CRUFDT04g JiYKKwkJICAgIHNjLT5jaGlwICYgVVJUV05fQ0hJUF84OEUpCisJCQl0eGQtPnR4ZHcxIHw9 IGh0b2xlMzIoU00oUjkyQ19UWERXMV9RU0VMLAorCQkJICAgIFI4OEVfVFhEVzFfUVNFTF9N R05UKSk7CisJCWVsc2UKKwkJCXR4ZC0+dHhkdzEgfD0gaHRvbGUzMihTTShSOTJDX1RYRFcx X1FTRUwsCisJCQkgICAgUjkyQ19UWERXMV9RU0VMX01HTlQpKTsKKwogCQl0eGQtPnR4ZHcx IHw9IGh0b2xlMzIoCiAJCSAgICBTTShSOTJDX1RYRFcxX01BQ0lELCAwKSB8Ci0JCSAgICBT TShSOTJDX1RYRFcxX1FTRUwsIFI5MkNfVFhEVzFfUVNFTF9NR05UKSB8CiAJCSAgICBTTShS OTJDX1RYRFcxX1JBSUQsIFI5MkNfUkFJRF8xMUIpKTsKIAogCQkvKiBGb3JjZSBDQ0sxLiAq LwpJbmRleDogZGV2L3VzYi93bGFuL2lmX3VydHducmVnLmgKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g ZGV2L3VzYi93bGFuL2lmX3VydHducmVnLmgJKHJldmlzaW9uIDI4NzM0MikKKysrIGRldi91 c2Ivd2xhbi9pZl91cnR3bnJlZy5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMDE5LDcgKzEwMTks OSBAQAogI2RlZmluZSBSOTJDX1RYRFcxX1FTRUxfTQkweDAwMDAxZjAwCiAjZGVmaW5lIFI5 MkNfVFhEVzFfUVNFTF9TCTgKICNkZWZpbmUgUjkyQ19UWERXMV9RU0VMX0JFCTB4MDAKKyNk ZWZpbmUgUjg4RV9UWERXMV9RU0VMX0JFCTB4MDMKICNkZWZpbmUgUjkyQ19UWERXMV9RU0VM X01HTlQJMHgxMgorI2RlZmluZSBSODhFX1RYRFcxX1FTRUxfTUdOVAkweDEwCiAjZGVmaW5l IFI5MkNfVFhEVzFfUkFJRF9NCTB4MDAwZjAwMDAKICNkZWZpbmUgUjkyQ19UWERXMV9SQUlE X1MJMTYKICNkZWZpbmUgUjkyQ19UWERXMV9DSVBIRVJfTQkweDAwYzAwMDAwCg== --------------020602080509020909060107-- From owner-freebsd-wireless@freebsd.org Wed Sep 16 06:06:04 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 3EE839CE65D for ; Wed, 16 Sep 2015 06:06:04 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1923214BF for ; Wed, 16 Sep 2015 06:06:03 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8G642dV035773 for ; Wed, 16 Sep 2015 01:04:02 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-179-24-154.austin.res.rr.com [72.179.24.154]) by mail.shrew.net (Postfix) with ESMTPSA id 14802187E50 for ; Wed, 16 Sep 2015 01:03:51 -0500 (CDT) Subject: Re: urtwn and hostap To: freebsd-wireless@freebsd.org References: <55F90187.10809@shrew.net> From: Matthew Grooms Message-ID: <55F906CB.9030007@shrew.net> Date: Wed, 16 Sep 2015 01:06:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F90187.10809@shrew.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 16 Sep 2015 01:04:02 -0500 (CDT) 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: Wed, 16 Sep 2015 06:06:04 -0000 On 9/16/2015 12:43 AM, Matthew Grooms wrote: > Hey wireless folks, > > I wanted to setup a Raspberry Pi as a FreeBSD AP and purchased a > picked up a few Edimax 802.11 adapters to play with. Unfortunately > these aren't supported in hostap mode. As it turns out these Edimax > adapters use the RTL8188CUS chipset so I poked around the net and > noticed that Linux does support the host AP feature with it's > RTL8188CUS driver. I was also able to find a patch for OpenBSD that > added support for the RTL8188EU chipset to the urtwn driver ... > > http://marc.info/?l=openbsd-tech&m=143577648117514&w=2 > > So I ordered one of these which arrived from China a few weeks later ... > > http://www.amazon.com/gp/product/B00L28AN88?psc=1&redirect=true&ref_=oh_aui_detailpage_o05_s00 > > > Next I took a stab at porting the patch to FreeBSD. With the attached > patch applied, I was able to setup a wlan0 device with the hostap > feature. After bridging it with the LAN I could associate with my > android phone, obtain an IP address via DHCP, browse a few web pages > and watch all the packets pass through the bridge. Sadly, when I > attempted to destroy the wlan0 device I got a kernel panic. The > screenshot for that is also attached and I'm not sure if I'm going to > be able to figure this one out without some help. I'm pretty out of my > element here. I assume it's happening in ieee80211_free_node() when > IEEE80211_NODE_LOCK() is called. To be clear, the crash only occurs > when the adapter is configured in hostap mode with the patch applied. > Anyone have any suggestions as to what I should be looking at to > prevent this crash? > > If I can get this working for the RTL8188EU, I'll also take a stab at > getting the RTL8188CUS chipset working in hostap mode. That is, > assuming I can glean enough info from drivers that support this > feature on other open source platforms. It appears to be extremely > popular with the Raspberry PI crowd ... > > http://www.amazon.com/Edimax-EW-7811Un-150Mbps-Raspberry-Supports/dp/B003MTTJOY > > It looks like my screenshot got scrubbed. Here is my hopefully faithful transcription ... Fatal trap 9: general protection fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer = 0x20:0xffffffff80a01105 stack pointer = 0x28:0xfffffe0092fe86f0 frame pointer = 0x28:0xfffffe0092fe8740 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 716 (ifconfig) [thread pid 716 tid 100082 ] Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax db> bt Tracing pid 716 tid 100082 td 0xffffff800512814d0 __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfffffe0092fe8780 ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame 0xfffffe0092fe87a0 ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame 0xfffffe0092fe87d0 urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfffffe0092fe8840 if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- db> -Matthew From owner-freebsd-wireless@freebsd.org Wed Sep 16 06:54:13 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 A2CBA9CD3DA for ; Wed, 16 Sep 2015 06:54:13 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 3AEE21F14 for ; Wed, 16 Sep 2015 06:54:13 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by wicgb1 with SMTP id gb1so59064560wic.1 for ; Tue, 15 Sep 2015 23:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=G7azdT+nm9kPqi0RQSOlgwnh4VQs3O1VGZMgXp8bDKY=; b=EkXgM7kqcP/5CryyoZo4EOawDKRTbK0ywgUIkjtT1RH1jcAs0dNrsKutEevwvjxPv4 Q5k2bZLVhYLHMO1D8r6T3kErzORUrncfA7VIWgsSKLug6mRX/SUqrw04Q8PbGS6/QVE0 CJdTFGLJYpGNkRB5YYgackvwNXzJ2kkbiG0O9TeEn0ThBpTtlCDQjz3rsCxGg0Qos7h0 9yThiB3ri0tWF1B4OOUlbrRA5VS+Lk5MAJ8tt0zOgQtsXVpluZwD/ocwRAlkGejasR+6 oP1wFXYMAb8/kHElcEIzBAGYNtt9wdln632jFFv7nyJ5vDtUV8vv22Pg4j6Uk99Eh3nZ c3WQ== X-Received: by 10.194.91.193 with SMTP id cg1mr52829758wjb.88.1442386451769; Tue, 15 Sep 2015 23:54:11 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id ej5sm24838214wjd.22.2015.09.15.23.54.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Sep 2015 23:54:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-wireless@freebsd.org Subject: Re: urtwn and hostap References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> Date: Wed, 16 Sep 2015 09:54:06 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <55F906CB.9030007@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: Wed, 16 Sep 2015 06:54:13 -0000 > ieee80211_free_node() at ieee80211_free_node()_0x38/frame > 0xfffffe0092fe8780 > ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame > 0xfffffe0092fe87a0 > ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame > 0xfffffe0092fe87d0 > urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 > if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame > 0xfffffe0092fe8840 > if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 > kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 > sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 > amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 > Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 > -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = > 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- > db> > > -Matthew I'm suspecting that ieee80211_tx_complete() eats one extra reference to the vap->iv_bss - try to add ieee80211_node_incref(vap->iv_bss); before urtwn_tx_start() (this is not a proper solution, but should work for now). From owner-freebsd-wireless@freebsd.org Wed Sep 16 11:27:41 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 9EE8C9CE7D3 for ; Wed, 16 Sep 2015 11:27:41 +0000 (UTC) (envelope-from vidwer@gmail.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 5F3D71235 for ; Wed, 16 Sep 2015 11:27:41 +0000 (UTC) (envelope-from vidwer@gmail.com) Received: by qgez77 with SMTP id z77so168600843qge.1 for ; Wed, 16 Sep 2015 04:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4p8I31S6W6olGbimcWfN4d6qwHnhuiUqOVgKKHyL0mY=; b=rV6hyY9zON0Jt3q8m4K6N2e+i4IqxmIiMq/itJvRGd69M/JNFhk7bCahnAoRiFQlWi WEV2UFp8ClMxNLfDHMY2z2ammjjFioU5R7qKwR/m4reMLl/RmrLiqXRLqzs47QTBkirv /fPu00Pi85obOtmzMOTWk7a5HnlSrTT6zNCGRmDaqBbpLaI8cW1yQ47383sXmDgbwE7B o7ggYK2mPPdCRR/jbJczEOWkgr+eeQs4wFOROmS7sHk++qynU+ppYR0zvDU+CLt7zfad MeAd8HsXn09ay5jvMkgOR51U2XjX6ay0ONfLZXwuYn1IR2K3l/YzMgiBdZw1bE606iK/ xHzg== MIME-Version: 1.0 X-Received: by 10.141.23.19 with SMTP id z19mr38981461qhd.39.1442402860582; Wed, 16 Sep 2015 04:27:40 -0700 (PDT) Received: by 10.55.214.2 with HTTP; Wed, 16 Sep 2015 04:27:40 -0700 (PDT) In-Reply-To: <55F906CB.9030007@shrew.net> References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> Date: Wed, 16 Sep 2015 13:27:40 +0200 Message-ID: Subject: Re: urtwn and hostap From: Idwer Vollering To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Wed, 16 Sep 2015 11:27:41 -0000 2015-09-16 8:06 GMT+02:00 Matthew Grooms : > > It looks like my screenshot got scrubbed. Here is my hopefully faithful > transcription ... > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 3; apic id = 03 > instruction pointer = 0x20:0xffffffff80a01105 > stack pointer = 0x28:0xfffffe0092fe86f0 > frame pointer = 0x28:0xfffffe0092fe8740 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 716 (ifconfig) > [thread pid 716 tid 100082 ] > Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax > db> bt > Tracing pid 716 tid 100082 td 0xffffff800512814d0 > __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 > ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfffffe0092fe8780 > ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame > 0xfffffe0092fe87a0 > ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame > 0xfffffe0092fe87d0 > urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 > if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfffffe0092fe8840 > if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 > kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 > sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 > amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 > Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 > -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = > 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- > db> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have entered 'dump' at the db> blinker :) The trap details are found in /var/crash/, run kgdb: "kgdb /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at its prompt. > > -Matthew > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Wed Sep 16 15:58:49 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 90BE49CD78B for ; Wed, 16 Sep 2015 15:58:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 649D81A0B for ; Wed, 16 Sep 2015 15:58:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofb144 with SMTP id b144so235555622iof.1 for ; Wed, 16 Sep 2015 08:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kHP9XTFiQXm+OKUJLIN0fcX2P5g/n/fl1kagEBuqxao=; b=vgW/jrLQR+MSIKybk1QC9+FDboV9i1uZQn7N4IlH4SY7zwhTMORC/8mjcneTd8eGHc x87uTeHL2YcdbmG4y/rSYHUv2mpaX4JGS6rSkIRHTx4Wlfgn3IkImn6nTkmbtRasJSnH tHoW+zpKedVzW0d5Zf2rW3ZIMxSK6qHAU31MY2esZo0cthR9/b5mG4F8yaVqs+w+Vagl k+Dq5IbYW1puLEVnoB8c7AHIrOLBoWBTZWxp7BC7Uz4L88wnVt8q1gE/mM3iGi9/Hbv9 i5HUX8LB+/h0HNFty8oqliZxknQgQ266qk1TQv2928jfAo9Dl6SOd3HOTw9I/e/rqhQn 9RBw== MIME-Version: 1.0 X-Received: by 10.107.13.75 with SMTP id 72mr43204374ion.75.1442419128744; Wed, 16 Sep 2015 08:58:48 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Wed, 16 Sep 2015 08:58:48 -0700 (PDT) In-Reply-To: References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> Date: Wed, 16 Sep 2015 08:58:48 -0700 Message-ID: Subject: Re: urtwn and hostap From: Adrian Chadd To: Idwer Vollering Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Wed, 16 Sep 2015 15:58:49 -0000 I think the net80211 beacon create routine doesn't allocate a node ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after calling becaon_create(), and deref it if the tx fails. The TX success will free the node ref for you. -adrian On 16 September 2015 at 04:27, Idwer Vollering wrote: > 2015-09-16 8:06 GMT+02:00 Matthew Grooms : > >> >> It looks like my screenshot got scrubbed. Here is my hopefully faithful >> transcription ... >> >> Fatal trap 9: general protection fault while in kernel mode >> cpuid = 3; apic id = 03 >> instruction pointer = 0x20:0xffffffff80a01105 >> stack pointer = 0x28:0xfffffe0092fe86f0 >> frame pointer = 0x28:0xfffffe0092fe8740 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 716 (ifconfig) >> [thread pid 716 tid 100082 ] >> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >> db> bt >> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >> ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfffffe0092fe8780 >> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >> 0xfffffe0092fe87a0 >> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >> 0xfffffe0092fe87d0 >> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfffffe0092fe8840 >> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >> db> > > Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have > entered 'dump' at the db> blinker :) > > The trap details are found in /var/crash/, run kgdb: "kgdb > /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at > its prompt. > >> >> -Matthew >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Wed Sep 16 16:13:17 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 0B2A79CDFA3 for ; Wed, 16 Sep 2015 16:13:17 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA536136F for ; Wed, 16 Sep 2015 16:13:16 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id t8GGB9RI078698 for ; Wed, 16 Sep 2015 11:11:09 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id D539F18BDC7 for ; Wed, 16 Sep 2015 11:11:03 -0500 (CDT) Subject: Re: urtwn and hostap To: freebsd-wireless@freebsd.org References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> From: Matthew Grooms Message-ID: <55F99514.7070509@shrew.net> Date: Wed, 16 Sep 2015 11:13:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Wed, 16 Sep 2015 11:11:09 -0500 (CDT) 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: Wed, 16 Sep 2015 16:13:17 -0000 On 9/16/2015 1:54 AM, Andriy Voskoboinyk wrote: >> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >> 0xfffffe0092fe8780 >> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >> 0xfffffe0092fe87a0 >> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >> 0xfffffe0092fe87d0 >> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >> 0xfffffe0092fe8840 >> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >> db> >> >> -Matthew > > I'm suspecting that ieee80211_tx_complete() eats one extra reference > to the > vap->iv_bss - try to add ieee80211_node_incref(vap->iv_bss); > before urtwn_tx_start() (this is not a proper solution, but should work > for now). Ahh, that makes sense. I'll look at that tonight. Thanks for the suggestion! -Matthew From owner-freebsd-wireless@freebsd.org Wed Sep 16 16:18:22 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 9D35B9C2208 for ; Wed, 16 Sep 2015 16:18:22 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D152159A for ; Wed, 16 Sep 2015 16:18:21 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8GGGJxn040509 for ; Wed, 16 Sep 2015 11:16:19 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 562FB18BDDB for ; Wed, 16 Sep 2015 11:16:09 -0500 (CDT) Subject: Re: urtwn and hostap To: freebsd-wireless@freebsd.org References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> From: Matthew Grooms Message-ID: <55F99646.6040200@shrew.net> Date: Wed, 16 Sep 2015 11:18:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 16 Sep 2015 11:16:19 -0500 (CDT) 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: Wed, 16 Sep 2015 16:18:22 -0000 On 9/16/2015 6:27 AM, Idwer Vollering wrote: > 2015-09-16 8:06 GMT+02:00 Matthew Grooms : > >> It looks like my screenshot got scrubbed. Here is my hopefully faithful >> transcription ... >> >> Fatal trap 9: general protection fault while in kernel mode >> cpuid = 3; apic id = 03 >> instruction pointer = 0x20:0xffffffff80a01105 >> stack pointer = 0x28:0xfffffe0092fe86f0 >> frame pointer = 0x28:0xfffffe0092fe8740 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 716 (ifconfig) >> [thread pid 716 tid 100082 ] >> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >> db> bt >> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >> ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfffffe0092fe8780 >> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >> 0xfffffe0092fe87a0 >> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >> 0xfffffe0092fe87d0 >> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfffffe0092fe8840 >> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >> db> > Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have > entered 'dump' at the db> blinker :) > > The trap details are found in /var/crash/, run kgdb: "kgdb > /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at > its prompt. That sounds super useful. I felt like I was fumbling around in the dark at the db prompt :) Thanks again, -Matthew From owner-freebsd-wireless@freebsd.org Wed Sep 16 16:21:25 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 B72ED9C245D for ; Wed, 16 Sep 2015 16:21:25 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90C9918F9 for ; Wed, 16 Sep 2015 16:21:25 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id t8GGJIWB078857 for ; Wed, 16 Sep 2015 11:19:18 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id F3E1F18BDC7 for ; Wed, 16 Sep 2015 11:19:12 -0500 (CDT) Subject: Re: urtwn and hostap To: freebsd-wireless@freebsd.org References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> From: Matthew Grooms Message-ID: <55F996FD.5060804@shrew.net> Date: Wed, 16 Sep 2015 11:21:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Wed, 16 Sep 2015 11:19:18 -0500 (CDT) 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: Wed, 16 Sep 2015 16:21:25 -0000 On 9/16/2015 10:58 AM, Adrian Chadd wrote: > I think the net80211 beacon create routine doesn't allocate a node > ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after > calling becaon_create(), and deref it if the tx fails. The TX success > will free the node ref for you. > Got it. I'll take another look at one of the drivers that support hostap to make sure I'm following the same pattern. Thanks again for the feedback! -Matthew > > -adrian > > > On 16 September 2015 at 04:27, Idwer Vollering wrote: >> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : >> >>> It looks like my screenshot got scrubbed. Here is my hopefully faithful >>> transcription ... >>> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff80a01105 >>> stack pointer = 0x28:0xfffffe0092fe86f0 >>> frame pointer = 0x28:0xfffffe0092fe8740 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 716 (ifconfig) >>> [thread pid 716 tid 100082 ] >>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >>> db> bt >>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame 0xfffffe0092fe8780 >>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >>> 0xfffffe0092fe87a0 >>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >>> 0xfffffe0092fe87d0 >>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame 0xfffffe0092fe8840 >>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >>> db> >> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have >> entered 'dump' at the db> blinker :) >> >> The trap details are found in /var/crash/, run kgdb: "kgdb >> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at >> its prompt. >> >>> -Matthew >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Wed Sep 16 16:24:21 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 183FC9C25C1 for ; Wed, 16 Sep 2015 16:24:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 E481019DA for ; Wed, 16 Sep 2015 16:24:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igxx6 with SMTP id x6so35231318igx.1 for ; Wed, 16 Sep 2015 09:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dYQHkNThO8ncxAidiG7Hp7fszCbo5Z8yrB4YXar4iRk=; b=IWsO2m6DRul/7nNvuUye7MZSW1O+eSCTHLYOYALcp1WJ79B8k0L0/YNNcwRgpVFvpT 8xpf+KM4EWdwHgflnnNTJZJqchfLz4Sz6MASqGKtSyBOvLCAOxBiQDLDtHQaTYqX8N1W EfRgJ3rsgTZlXYqmRj7FSUdQjA1+MKSna3HUxch4dQfEPveY48T5VpeMlLMWOoFUkCIu vmYljMjD8T1/abjh270QBLvAPWKsm2SJdM/jlSZIvQ1keM4i3UXo0nwduqrMYGXwIm02 uxrftnWSo7zDPCGlOb9AOY8+6LYjk83POwazP4CqS3B287e75RtPZZ/MsTVhfcFELzcF zIuQ== MIME-Version: 1.0 X-Received: by 10.50.43.227 with SMTP id z3mr16946186igl.22.1442420660219; Wed, 16 Sep 2015 09:24:20 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Wed, 16 Sep 2015 09:24:20 -0700 (PDT) In-Reply-To: <55F996FD.5060804@shrew.net> References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> Date: Wed, 16 Sep 2015 09:24:20 -0700 Message-ID: Subject: Re: urtwn and hostap From: Adrian Chadd To: Matthew Grooms Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Wed, 16 Sep 2015 16:24:21 -0000 The only one to look at is ath(4). I've not fixed/hacked on any other hostap chips. :) if_ath_beacon.c has the logic - it gets a reference when creating a beacon frame. -adrian On 16 September 2015 at 09:21, Matthew Grooms wrote: > On 9/16/2015 10:58 AM, Adrian Chadd wrote: >> >> I think the net80211 beacon create routine doesn't allocate a node >> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after >> calling becaon_create(), and deref it if the tx fails. The TX success >> will free the node ref for you. >> > > Got it. I'll take another look at one of the drivers that support hostap to > make sure I'm following the same pattern. Thanks again for the feedback! > > -Matthew > > >> >> -adrian >> >> >> On 16 September 2015 at 04:27, Idwer Vollering wrote: >>> >>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : >>> >>>> It looks like my screenshot got scrubbed. Here is my hopefully faithful >>>> transcription ... >>>> >>>> Fatal trap 9: general protection fault while in kernel mode >>>> cpuid = 3; apic id = 03 >>>> instruction pointer = 0x20:0xffffffff80a01105 >>>> stack pointer = 0x28:0xfffffe0092fe86f0 >>>> frame pointer = 0x28:0xfffffe0092fe8740 >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, long 1, def32 0, gran >>>> 1 >>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>> current process = 716 (ifconfig) >>>> [thread pid 716 tid 100082 ] >>>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >>>> db> bt >>>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >>>> 0xfffffe0092fe8780 >>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >>>> 0xfffffe0092fe87a0 >>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >>>> 0xfffffe0092fe87d0 >>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >>>> 0xfffffe0092fe8840 >>>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >>>> db> >>> >>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have >>> entered 'dump' at the db> blinker :) >>> >>> The trap details are found in /var/crash/, run kgdb: "kgdb >>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at >>> its prompt. >>> >>>> -Matthew >>>> _______________________________________________ >>>> freebsd-wireless@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>> To unsubscribe, send any mail to >>>> "freebsd-wireless-unsubscribe@freebsd.org" >>> >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to >>> "freebsd-wireless-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to >> "freebsd-wireless-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Thu Sep 17 06:39:38 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 CC8899CE13D for ; Thu, 17 Sep 2015 06:39:38 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 718EC108B for ; Thu, 17 Sep 2015 06:39:37 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id t8H6bOiw082426; Thu, 17 Sep 2015 01:37:24 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-179-24-154.austin.res.rr.com [72.179.24.154]) by mail.shrew.net (Postfix) with ESMTPSA id 73EFA18B903; Thu, 17 Sep 2015 01:37:18 -0500 (CDT) Subject: Re: urtwn and hostap To: Adrian Chadd References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> Cc: "freebsd-wireless@freebsd.org" From: Matthew Grooms Message-ID: <55FA6022.8090609@shrew.net> Date: Thu, 17 Sep 2015 01:39:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------080104090206010805030600" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Thu, 17 Sep 2015 01:37:24 -0500 (CDT) 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: Thu, 17 Sep 2015 06:39:38 -0000 This is a multi-part message in MIME format. --------------080104090206010805030600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Seems to behave better now and hostap appears to be working ... #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap #ifconfig wlan0 list caps drivercaps=2181c401 #ifconfig wlan0 up ssid freebsdap mode 11g channel 1 #ifconfig bridge0 create up addm em0 addm wlan0 #ifconfig wlan0 wlan0: flags=8943 metric 0 mtu 1500 ether 00:c3:e1:16:11:32 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32 country US authmode OPEN privacy OFF txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs groups: wlan #ifconfig bridge0 bridge0: flags=8843 metric 0 mtu 1500 ether 02:df:20:d2:42:00 nd6 options=1 groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: wlan0 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 370370 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20000 The speed leaves a lot to be desired. Throughput for the associated host is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative of a problem. Occasionally I also see the this message on the console when I'm bringing the adapter up ... wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost If I down and up the adapter again, it seems to correct itself. Not sure what that's all about. I am passing the USB adapter through to a VM inside of ESXi to test the patch, so maybe that has something to do with these quirks. I'll try to run some tests with the adapter associated to a physical AP tomorrow to get a baseline. Thanks, -Matthew On 9/16/2015 11:24 AM, Adrian Chadd wrote: > The only one to look at is ath(4). I've not fixed/hacked on any other > hostap chips. :) > > if_ath_beacon.c has the logic - it gets a reference when creating a > beacon frame. > > > > -adrian > > > On 16 September 2015 at 09:21, Matthew Grooms wrote: >> On 9/16/2015 10:58 AM, Adrian Chadd wrote: >>> I think the net80211 beacon create routine doesn't allocate a node >>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after >>> calling becaon_create(), and deref it if the tx fails. The TX success >>> will free the node ref for you. >>> >> Got it. I'll take another look at one of the drivers that support hostap to >> make sure I'm following the same pattern. Thanks again for the feedback! >> >> -Matthew >> >> >>> -adrian >>> >>> >>> On 16 September 2015 at 04:27, Idwer Vollering wrote: >>>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : >>>> >>>>> It looks like my screenshot got scrubbed. Here is my hopefully faithful >>>>> transcription ... >>>>> >>>>> Fatal trap 9: general protection fault while in kernel mode >>>>> cpuid = 3; apic id = 03 >>>>> instruction pointer = 0x20:0xffffffff80a01105 >>>>> stack pointer = 0x28:0xfffffe0092fe86f0 >>>>> frame pointer = 0x28:0xfffffe0092fe8740 >>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>> = DPL 0, pres 1, long 1, def32 0, gran >>>>> 1 >>>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>>> current process = 716 (ifconfig) >>>>> [thread pid 716 tid 100082 ] >>>>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >>>>> db> bt >>>>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >>>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >>>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >>>>> 0xfffffe0092fe8780 >>>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >>>>> 0xfffffe0092fe87a0 >>>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >>>>> 0xfffffe0092fe87d0 >>>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >>>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >>>>> 0xfffffe0092fe8840 >>>>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >>>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >>>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >>>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >>>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >>>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >>>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >>>>> db> >>>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have >>>> entered 'dump' at the db> blinker :) >>>> >>>> The trap details are found in /var/crash/, run kgdb: "kgdb >>>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at >>>> its prompt. >>>> >>>>> -Matthew >>>>> _______________________________________________ >>>>> freebsd-wireless@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>> To unsubscribe, send any mail to >>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>> _______________________________________________ >>>> freebsd-wireless@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>> To unsubscribe, send any mail to >>>> "freebsd-wireless-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to >>> "freebsd-wireless-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" --------------080104090206010805030600 Content-Type: text/plain; charset=UTF-8; name="urtwn.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="urtwn.diff" SW5kZXg6IHN5cy9kZXYvdXNiL3dsYW4vaWZfdXJ0d24uYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvZGV2L3VzYi93bGFuL2lmX3VydHduLmMJKHJldmlzaW9uIDI4NzM0MikKKysrIHN5cy9k ZXYvdXNiL3dsYW4vaWZfdXJ0d24uYwkod29ya2luZyBjb3B5KQpAQCAtMTgxLDYgKzE4MSw4 IEBACiBzdGF0aWMgc3RydWN0IG1idWYgKgl1cnR3bl9yeGVvZihzdHJ1Y3QgdXNiX3hmZXIg Kiwgc3RydWN0IHVydHduX2RhdGEgKiwKIAkJCSAgICBpbnQgKiwgaW50OF90ICopOwogc3Rh dGljIHZvaWQJCXVydHduX3R4ZW9mKHN0cnVjdCB1c2JfeGZlciAqLCBzdHJ1Y3QgdXJ0d25f ZGF0YSAqKTsKK2ludAkJCXVydHduX3R4YmNuKHN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCwK KwkJCSAgICBzdHJ1Y3QgaWVlZTgwMjExX25vZGUgKik7CiBzdGF0aWMgaW50CQl1cnR3bl9h bGxvY19saXN0KHN0cnVjdCB1cnR3bl9zb2Z0YyAqLAogCQkJICAgIHN0cnVjdCB1cnR3bl9k YXRhW10sIGludCwgaW50KTsKIHN0YXRpYyBpbnQJCXVydHduX2FsbG9jX3J4X2xpc3Qoc3Ry dWN0IHVydHduX3NvZnRjICopOwpAQCAtNDM2LDYgKzQzOCwxMCBAQAogCQl8IElFRUU4MDIx MV9DX1dQQQkJLyogODAyLjExaSAqLwogCQk7CiAKKwlpZiAoc2MtPmNoaXAgJiBVUlRXTl9D SElQXzg4RSkKKwkJaWMtPmljX2NhcHMgfD0KKwkJICAgIElFRUU4MDIxMV9DX0hPU1RBUDsJ CS8qIEhvc3RBcCBtb2RlIHN1cHBvcnRlZCAqLworCiAJYmFuZHMgPSAwOwogCXNldGJpdCgm YmFuZHMsIElFRUU4MDIxMV9NT0RFXzExQik7CiAJc2V0Yml0KCZiYW5kcywgSUVFRTgwMjEx X01PREVfMTFHKTsKQEAgLTg1Nyw2ICs4NjMsMzkgQEAKIAlzYy0+c2NfdHh0aW1lciA9IDA7 CiB9CiAKKy8qCisgKiBQdXNoIGEgYmVhY29uIGZyYW1lIGludG8gdGhlIGNoaXAgYW5kIGNo ZWNrIGlmIGl0IHdhcyBhY2NlcHRlZC4gIEJlYWNvbiB3aWxsCisgKiBiZSByZXBlYXRlZCBi eSB0aGUgY2hpcCBldmVyeSBSOTJDX0JDTl9JTlRFUlZBTC4KKyAqLworaW50Cit1cnR3bl90 eGJjbihzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAsIHN0cnVjdCBpZWVlODAyMTFfbm9kZSAq bmkpCit7CisJc3RydWN0IGllZWU4MDIxMWNvbSAqaWMgPSBuaS0+bmlfaWM7CisJc3RydWN0 IHVydHduX3NvZnRjICpzYyA9IGljLT5pY19zb2Z0YzsKKwlzdHJ1Y3QgdXJ0d25fZGF0YSAq YmY7CisJc3RydWN0IG1idWYgKm07CisKKwlpZWVlODAyMTFfcmVmX25vZGUobmkpOworCW0g PSBpZWVlODAyMTFfYmVhY29uX2FsbG9jKG5pLCAmVVJUV05fVkFQKHZhcCktPmJvKTsKKwor CWJmID0gdXJ0d25fZ2V0YnVmKHNjKTsKKwlpZiAoYmYgPT0gTlVMTCkgeworCQlpZWVlODAy MTFfZnJlZV9ub2RlKG5pKTsKKwkJbV9mcmVlbShtKTsKKwkJcmV0dXJuIChFTk9CVUZTKTsK Kwl9CisKKwlpZiAodXJ0d25fdHhfc3RhcnQoc2MsIG5pLCBtLCBiZikgIT0gMCkgeworCQlp ZWVlODAyMTFfZnJlZV9ub2RlKG5pKTsKKwkJU1RBSUxRX0lOU0VSVF9IRUFEKCZzYy0+c2Nf dHhfaW5hY3RpdmUsIGJmLCBuZXh0KTsKKwkJcmV0dXJuIChFSU8pOworCX0KKworCXNjLT5z Y190eHRpbWVyID0gNTsKKworCXJldHVybiAoMCk7Cit9CisKIHN0YXRpYyB2b2lkCiB1cnR3 bl9idWxrX3R4X2NhbGxiYWNrKHN0cnVjdCB1c2JfeGZlciAqeGZlciwgdXNiX2Vycm9yX3Qg ZXJyb3IpCiB7CkBAIC0xNDY2LDYgKzE1MDUsNyBAQAogCXN0cnVjdCBpZWVlODAyMTFfbm9k ZSAqbmk7CiAJZW51bSBpZWVlODAyMTFfc3RhdGUgb3N0YXRlOwogCXVpbnQzMl90IHJlZzsK KwlpbnQgZXJyb3I7CiAKIAlvc3RhdGUgPSB2YXAtPml2X3N0YXRlOwogCURQUklOVEYoIiVz IC0+ICVzXG4iLCBpZWVlODAyMTFfc3RhdGVfbmFtZVtvc3RhdGVdLApAQCAtMTU1MywyMyAr MTU5Myw2OCBAQAogCQl9CiAKIAkJbmkgPSBpZWVlODAyMTFfcmVmX25vZGUodmFwLT5pdl9i c3MpOwotCQkvKiBTZXQgbWVkaWEgc3RhdHVzIHRvICdBc3NvY2lhdGVkJy4gKi8KLQkJcmVn ID0gdXJ0d25fcmVhZF80KHNjLCBSOTJDX0NSKTsKLQkJcmVnID0gUlcocmVnLCBSOTJDX0NS X05FVFRZUEUsIFI5MkNfQ1JfTkVUVFlQRV9JTkZSQSk7Ci0JCXVydHduX3dyaXRlXzQoc2Ms IFI5MkNfQ1IsIHJlZyk7CiAKLQkJLyogU2V0IEJTU0lELiAqLwotCQl1cnR3bl93cml0ZV80 KHNjLCBSOTJDX0JTU0lEICsgMCwgTEVfUkVBRF80KCZuaS0+bmlfYnNzaWRbMF0pKTsKLQkJ dXJ0d25fd3JpdGVfNChzYywgUjkyQ19CU1NJRCArIDQsIExFX1JFQURfMigmbmktPm5pX2Jz c2lkWzRdKSk7CisJCWlmIChpYy0+aWNfb3Btb2RlID09IElFRUU4MDIxMV9NX1NUQSkgewor CQkJLyogU2V0IEJTU0lELiAqLworCQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19CU1NJRCAr IDAsCisJCQkJTEVfUkVBRF80KCZuaS0+bmlfYnNzaWRbMF0pKTsKKwkJCXVydHduX3dyaXRl XzQoc2MsIFI5MkNfQlNTSUQgKyA0LAorCQkJCUxFX1JFQURfMigmbmktPm5pX2Jzc2lkWzRd KSk7CiAKLQkJaWYgKGljLT5pY19jdXJtb2RlID09IElFRUU4MDIxMV9NT0RFXzExQikKLQkJ CXVydHduX3dyaXRlXzEoc2MsIFI5MkNfSU5JUlRTX1JBVEVfU0VMLCAwKTsKLQkJZWxzZQkv KiA4MDIuMTFiL2cgKi8KLQkJCXVydHduX3dyaXRlXzEoc2MsIFI5MkNfSU5JUlRTX1JBVEVf U0VMLCAzKTsKKwkJCWlmIChpYy0+aWNfY3VybW9kZSA9PSBJRUVFODAyMTFfTU9ERV8xMUIp CisJCQkJdXJ0d25fd3JpdGVfMShzYywgUjkyQ19JTklSVFNfUkFURV9TRUwsIDApOworCQkJ ZWxzZQkvKiA4MDIuMTFiL2cgKi8KKwkJCQl1cnR3bl93cml0ZV8xKHNjLCBSOTJDX0lOSVJU U19SQVRFX1NFTCwgMyk7CiAKLQkJLyogRW5hYmxlIFJ4IG9mIGRhdGEgZnJhbWVzLiAqLwot CQl1cnR3bl93cml0ZV8yKHNjLCBSOTJDX1JYRkxUTUFQMiwgMHhmZmZmKTsKKwkJCS8qIEVu YWJsZSBSeCBvZiBkYXRhIGZyYW1lcy4gKi8KKwkJCXVydHduX3dyaXRlXzIoc2MsIFI5MkNf UlhGTFRNQVAyLCAweGZmZmYpOwogCisJCQkvKiBBbGxvdyBSeCBmcm9tIG91ciBCU1NJRCBv bmx5LiAqLworCQkJdXJ0d25fd3JpdGVfNChzYywgUjkyQ19SQ1IsIHVydHduX3JlYWRfNChz YywgUjkyQ19SQ1IpIHwKKwkJCSAgICBSOTJDX1JDUl9DQlNTSURfREFUQSB8IFI5MkNfUkNS X0NCU1NJRF9CQ04pOworCisJCQkvKiBTZXQgbWVkaWEgc3RhdHVzIHRvICdBc3NvY2lhdGVk Jy4gKi8KKwkJCXJlZyA9IHVydHduX3JlYWRfNChzYywgUjkyQ19DUik7CisJCQlyZWcgPSBS VyhyZWcsIFI5MkNfQ1JfTkVUVFlQRSwgUjkyQ19DUl9ORVRUWVBFX0lORlJBKTsKKwkJCXVy dHduX3dyaXRlXzQoc2MsIFI5MkNfQ1IsIHJlZyk7CisJCX0KKworCQlpZiAoaWMtPmljX29w bW9kZSA9PSBJRUVFODAyMTFfTV9IT1NUQVApIHsKKwkJCS8qIFNldCBtZWRpYSBzdGF0dXMg dG8gJ0FQJy4gKi8KKwkJCXJlZyA9IHVydHduX3JlYWRfNChzYywgUjkyQ19DUik7CisJCQly ZWcgPSBSVyhyZWcsIFI5MkNfQ1JfTkVUVFlQRSwgUjkyQ19DUl9ORVRUWVBFX0FQKTsKKwkJ CXVydHduX3dyaXRlXzQoc2MsIFI5MkNfQ1IsIHJlZyk7CisKKwkJCS8qIFNldCBCU1NJRC4g Ki8KKwkJCXVydHduX3dyaXRlXzQoc2MsIFI5MkNfQlNTSUQgKyAwLAorCQkJICAgIExFX1JF QURfNCgmbmktPm5pX2Jzc2lkWzBdKSk7CisJCQl1cnR3bl93cml0ZV80KHNjLCBSOTJDX0JT U0lEICsgNCwKKwkJCSAgICBMRV9SRUFEXzIoJm5pLT5uaV9ic3NpZFs0XSkpOworCisJCQkv KgorCQkJICogSWYgM3JkIG9yIDR0aCBiaXRzIGFyZSBzZXQgdG8gemVybyBjaGlwIHdpbGwg c3RvcAorCQkJICogcmVwZWF0aW5nIGJlYWNvbiBhZnRlciBmaXJzdCB0cmFuc21pc3Npb24g Zm9yIHBvcnQwCisJCQkgKiBhbmQgcG9ydDEgcmVzcGVjdGl2ZWx5LiBUaGlzIHdpbGwgY2F1 c2UgU1RBcyB0bworCQkJICogZGlzY29ubmVjdCBhZnRlciBzaG9ydCBwZXJpb2Qgb2YgdGlt ZS4KKwkJCSAqLworCQkJcmVnID0gdXJ0d25fcmVhZF8xKHNjLCBSOTJDX01CSURfTlVNKTsK KwkJCXJlZyB8PSAweDg7CisJCQlyZWcgfD0gMHgxMDsKKwkJCXVydHduX3dyaXRlXzEoc2Ms IFI5MkNfTUJJRF9OVU0sIHJlZyk7CisKKwkJCS8qIEludmFsaWRhdGUgY2FtIGVudHJpZXMg Ki8KKwkJCXVydHduX2NhbV9pbml0KHNjKTsKKworCQkJLyogU2V0IGNoYW4vYncgKi8KKwkJ CXVydHduX3NldF9jaGFuKHNjLCBpYy0+aWNfY3VyY2hhbiwgTlVMTCk7CisKKwkJCS8qIFB1 c2ggYmVhY29uIGZyYW1lIGludG8gdGhlIGNoaXAgKi8KKwkJCWVycm9yID0gdXJ0d25fdHhi Y24odmFwLCBuaSk7CisJCQlpZiAoZXJyb3IgIT0gMCkKKwkJCQlwcmludGYoIiVzOiB1bmFi bGUgdG8gcHVzaCBiZWFjb24gaW50byB0aGUiCisJCQkJICAgICIgY2hpcFxuIiwgZGV2aWNl X2dldF9uYW1ldW5pdChzYy0+c2NfZGV2KSk7CisJCX0KKwogCQkvKiBGbHVzaCBhbGwgQUMg cXVldWVzLiAqLwogCQl1cnR3bl93cml0ZV8xKHNjLCBSOTJDX1RYUEFVU0UsIDApOwogCkBA IC0xNTc2LDExICsxNjYxLDYgQEAKIAkJLyogU2V0IGJlYWNvbiBpbnRlcnZhbC4gKi8KIAkJ dXJ0d25fd3JpdGVfMihzYywgUjkyQ19CQ05fSU5URVJWQUwsIG5pLT5uaV9pbnR2YWwpOwog Ci0JCS8qIEFsbG93IFJ4IGZyb20gb3VyIEJTU0lEIG9ubHkuICovCi0JCXVydHduX3dyaXRl XzQoc2MsIFI5MkNfUkNSLAotCQkgICAgdXJ0d25fcmVhZF80KHNjLCBSOTJDX1JDUikgfAot CQkgICAgUjkyQ19SQ1JfQ0JTU0lEX0RBVEEgfCBSOTJDX1JDUl9DQlNTSURfQkNOKTsKLQog CQkvKiBFbmFibGUgVFNGIHN5bmNocm9uaXphdGlvbi4gKi8KIAkJdXJ0d25fdHNmX3N5bmNf ZW5hYmxlKHNjKTsKIApAQCAtMTc1NCw3ICsxODM0LDcgQEAKIAlzdHJ1Y3QgaWVlZTgwMjEx dmFwICp2YXAgPSBuaS0+bmlfdmFwOwogCXN0cnVjdCB1c2JfeGZlciAqeGZlcjsKIAlzdHJ1 Y3QgcjkyY190eF9kZXNjICp0eGQ7Ci0JdWludDhfdCByYWlkLCB0eXBlOworCXVpbnQ4X3Qg cmFpZCwgdHlwZSwgc3VidHlwZTsKIAl1aW50MTZfdCBzdW07CiAJaW50IGksIGhhc3Fvcywg eGZlcmxlbjsKIAlzdHJ1Y3QgdXNiX3hmZXIgKnVydHduX3BpcGVzWzRdID0gewpAQCAtMTc3 MSw2ICsxODUxLDcgQEAKIAkgKi8KIAl3aCA9IG10b2QobTAsIHN0cnVjdCBpZWVlODAyMTFf ZnJhbWUgKik7CiAJdHlwZSA9IHdoLT5pX2ZjWzBdICYgSUVFRTgwMjExX0ZDMF9UWVBFX01B U0s7CisJc3VidHlwZSA9IHdoLT5pX2ZjWzBdICYgSUVFRTgwMjExX0ZDMF9TVUJUWVBFX01B U0s7CiAKIAlpZiAod2gtPmlfZmNbMV0gJiBJRUVFODAyMTFfRkMxX1BST1RFQ1RFRCkgewog CQlrID0gaWVlZTgwMjExX2NyeXB0b19lbmNhcChuaSwgbTApOwpAQCAtMTgxOSw3ICsxOTAw LDcgQEAKIAkJaWYgKHNjLT5jaGlwICYgVVJUV05fQ0hJUF84OEUpIHsKIAkJCXR4ZC0+dHhk dzEgfD0gaHRvbGUzMigKIAkJCSAgICBTTShSODhFX1RYRFcxX01BQ0lELCBVUlRXTl9NQUNJ RF9CU1MpIHwKLQkJCSAgICBTTShSOTJDX1RYRFcxX1FTRUwsIFI5MkNfVFhEVzFfUVNFTF9C RSkgfAorCQkJICAgIFNNKFI5MkNfVFhEVzFfUVNFTCwgUjg4RV9UWERXMV9RU0VMX0JFKSB8 CiAJCQkgICAgU00oUjkyQ19UWERXMV9SQUlELCByYWlkKSk7CiAJCQl0eGQtPnR4ZHcyIHw9 IGh0b2xlMzIoUjg4RV9UWERXMl9BR0dCSyk7CiAJCX0gZWxzZSB7CkBAIC0xODQzLDkgKzE5 MjQsMjAgQEAKIAkJLyogU2VuZCBkYXRhIGF0IE9GRE01NC4gKi8KIAkJdHhkLT50eGR3NSB8 PSBodG9sZTMyKFNNKFI5MkNfVFhEVzVfREFUQVJBVEUsIDExKSk7CiAJfSBlbHNlIHsKKwkJ LyoKKwkJICogSWYgYmVhY29uIGZyYW1lIGlzIHB1c2hlZCBpbnRvIHdyb25nIHF1ZXVlLCB0 aGUgY2hpcCB3b24ndAorCQkgKiBzdGFydCByZXBlYXRpbmcgaXQuCisJCSAqLworCQlpZiAo c3VidHlwZSA9PSBJRUVFODAyMTFfRkMwX1NVQlRZUEVfQkVBQ09OICYmCisJCSAgICBzYy0+ Y2hpcCAmIFVSVFdOX0NISVBfODhFKQorCQkJdHhkLT50eGR3MSB8PSBodG9sZTMyKFNNKFI5 MkNfVFhEVzFfUVNFTCwKKwkJCSAgICBSODhFX1RYRFcxX1FTRUxfTUdOVCkpOworCQllbHNl CisJCQl0eGQtPnR4ZHcxIHw9IGh0b2xlMzIoU00oUjkyQ19UWERXMV9RU0VMLAorCQkJICAg IFI5MkNfVFhEVzFfUVNFTF9NR05UKSk7CisKIAkJdHhkLT50eGR3MSB8PSBodG9sZTMyKAog CQkgICAgU00oUjkyQ19UWERXMV9NQUNJRCwgMCkgfAotCQkgICAgU00oUjkyQ19UWERXMV9R U0VMLCBSOTJDX1RYRFcxX1FTRUxfTUdOVCkgfAogCQkgICAgU00oUjkyQ19UWERXMV9SQUlE LCBSOTJDX1JBSURfMTFCKSk7CiAKIAkJLyogRm9yY2UgQ0NLMS4gKi8KSW5kZXg6IHN5cy9k ZXYvdXNiL3dsYW4vaWZfdXJ0d25yZWcuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L3Vz Yi93bGFuL2lmX3VydHducmVnLmgJKHJldmlzaW9uIDI4NzM0MikKKysrIHN5cy9kZXYvdXNi L3dsYW4vaWZfdXJ0d25yZWcuaAkod29ya2luZyBjb3B5KQpAQCAtMTAxOSw3ICsxMDE5LDkg QEAKICNkZWZpbmUgUjkyQ19UWERXMV9RU0VMX00JMHgwMDAwMWYwMAogI2RlZmluZSBSOTJD X1RYRFcxX1FTRUxfUwk4CiAjZGVmaW5lIFI5MkNfVFhEVzFfUVNFTF9CRQkweDAwCisjZGVm aW5lIFI4OEVfVFhEVzFfUVNFTF9CRQkweDAzCiAjZGVmaW5lIFI5MkNfVFhEVzFfUVNFTF9N R05UCTB4MTIKKyNkZWZpbmUgUjg4RV9UWERXMV9RU0VMX01HTlQJMHgxMAogI2RlZmluZSBS OTJDX1RYRFcxX1JBSURfTQkweDAwMGYwMDAwCiAjZGVmaW5lIFI5MkNfVFhEVzFfUkFJRF9T CTE2CiAjZGVmaW5lIFI5MkNfVFhEVzFfQ0lQSEVSX00JMHgwMGMwMDAwMAo= --------------080104090206010805030600-- From owner-freebsd-wireless@freebsd.org Thu Sep 17 14:47:44 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 AAD3D9CF3E6 for ; Thu, 17 Sep 2015 14:47:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 96F62157F for ; Thu, 17 Sep 2015 14:47:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8HEliTa095742 for ; Thu, 17 Sep 2015 14:47:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203105] [new driver] Port openbsd rtwn, new rtl8188ce driver Date: Thu, 17 Sep 2015 14:47:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kevlo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 17 Sep 2015 14:47:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203105 Kevin Lo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kevlo@FreeBSD.org --- Comment #5 from Kevin Lo --- Well, I remember someone would send this wifi card to me, but unfortunately, I haven't received it yet. Porting OpenBSD's rtwn(4) to FreeBSD is not hard, the harder part would be maintaining rtwn(4) stability and performance. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Thu Sep 17 15:13:21 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 ED2C89CE07C for ; Thu, 17 Sep 2015 15:13:20 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A1E181A8C for ; Thu, 17 Sep 2015 15:13:19 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id t8HFCnDH068217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 17 Sep 2015 23:12:50 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id t8HFCni1068216; Thu, 17 Sep 2015 23:12:49 +0800 (CST) (envelope-from kevlo) Date: Thu, 17 Sep 2015 23:12:49 +0800 From: Kevin Lo To: Matthew Grooms Cc: Adrian Chadd , "freebsd-wireless@freebsd.org" Subject: Re: urtwn and hostap Message-ID: <20150917151249.GA68201@ns.kevlo.org> References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FA6022.8090609@shrew.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Thu, 17 Sep 2015 15:13:21 -0000 On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote: > Seems to behave better now and hostap appears to be working ... > > #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap > #ifconfig wlan0 list caps > drivercaps=2181c401 > > #ifconfig wlan0 up ssid freebsdap mode 11g channel 1 > #ifconfig bridge0 create up addm em0 addm wlan0 > > #ifconfig wlan0 > wlan0: flags=8943 metric > 0 mtu 1500 > ether 00:c3:e1:16:11:32 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32 > country US authmode OPEN privacy OFF txpower 0 scanvalid 60 > protmode CTS dtimperiod 1 -dfs > groups: wlan > > #ifconfig bridge0 > bridge0: flags=8843 metric 0 mtu > 1500 > ether 02:df:20:d2:42:00 > nd6 options=1 > groups: bridge > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: wlan0 flags=143 > ifmaxaddr 0 port 3 priority 128 path cost 370370 > member: em0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 20000 > > The speed leaves a lot to be desired. Throughput for the associated host > is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative > of a problem. Occasionally I also see the this message on the console > when I'm bringing the adapter up ... > > wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost > > If I down and up the adapter again, it seems to correct itself. Not sure > what that's all about. I am passing the USB adapter through to a VM > inside of ESXi to test the patch, so maybe that has something to do with > these quirks. I'll try to run some tests with the adapter associated to > a physical AP tomorrow to get a baseline. I knew OpenBSD had patches about hostap support for urtwn(4), but those don't look quite right. I think that's why OpenBSD developers didn't commit them. BTW, NetBSD adopted OpenBSD's patches, I tested it on NetBSD about four months ago, the connection was not stable... > Thanks, > > -Matthew Kevin > On 9/16/2015 11:24 AM, Adrian Chadd wrote: > > The only one to look at is ath(4). I've not fixed/hacked on any other > > hostap chips. :) > > > > if_ath_beacon.c has the logic - it gets a reference when creating a > > beacon frame. > > > > > > > > -adrian > > > > > > On 16 September 2015 at 09:21, Matthew Grooms wrote: > >> On 9/16/2015 10:58 AM, Adrian Chadd wrote: > >>> I think the net80211 beacon create routine doesn't allocate a node > >>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after > >>> calling becaon_create(), and deref it if the tx fails. The TX success > >>> will free the node ref for you. > >>> > >> Got it. I'll take another look at one of the drivers that support hostap to > >> make sure I'm following the same pattern. Thanks again for the feedback! > >> > >> -Matthew > >> > >> > >>> -adrian > >>> > >>> > >>> On 16 September 2015 at 04:27, Idwer Vollering wrote: > >>>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : > >>>> > >>>>> It looks like my screenshot got scrubbed. Here is my hopefully faithful > >>>>> transcription ... > >>>>> > >>>>> Fatal trap 9: general protection fault while in kernel mode > >>>>> cpuid = 3; apic id = 03 > >>>>> instruction pointer = 0x20:0xffffffff80a01105 > >>>>> stack pointer = 0x28:0xfffffe0092fe86f0 > >>>>> frame pointer = 0x28:0xfffffe0092fe8740 > >>>>> code segment = base 0x0, limit 0xfffff, type 0x1b > >>>>> = DPL 0, pres 1, long 1, def32 0, gran > >>>>> 1 > >>>>> processor eflags = interrupt enabled, resume, IOPL = 0 > >>>>> current process = 716 (ifconfig) > >>>>> [thread pid 716 tid 100082 ] > >>>>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax > >>>>> db> bt > >>>>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 > >>>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 > >>>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame > >>>>> 0xfffffe0092fe8780 > >>>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame > >>>>> 0xfffffe0092fe87a0 > >>>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame > >>>>> 0xfffffe0092fe87d0 > >>>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 > >>>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame > >>>>> 0xfffffe0092fe8840 > >>>>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 > >>>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 > >>>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 > >>>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 > >>>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 > >>>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = > >>>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- > >>>>> db> > >>>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have > >>>> entered 'dump' at the db> blinker :) > >>>> > >>>> The trap details are found in /var/crash/, run kgdb: "kgdb > >>>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at > >>>> its prompt. > >>>> > >>>>> -Matthew > >>>>> _______________________________________________ > >>>>> freebsd-wireless@freebsd.org mailing list > >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >>>>> To unsubscribe, send any mail to > >>>>> "freebsd-wireless-unsubscribe@freebsd.org" > >>>> _______________________________________________ > >>>> freebsd-wireless@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >>>> To unsubscribe, send any mail to > >>>> "freebsd-wireless-unsubscribe@freebsd.org" > >>> _______________________________________________ > >>> freebsd-wireless@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >>> To unsubscribe, send any mail to > >>> "freebsd-wireless-unsubscribe@freebsd.org" > >> > >> _______________________________________________ > >> freebsd-wireless@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > > Index: sys/dev/usb/wlan/if_urtwn.c > =================================================================== > --- sys/dev/usb/wlan/if_urtwn.c (revision 287342) > +++ sys/dev/usb/wlan/if_urtwn.c (working copy) > @@ -181,6 +181,8 @@ > static struct mbuf * urtwn_rxeof(struct usb_xfer *, struct urtwn_data *, > int *, int8_t *); > static void urtwn_txeof(struct usb_xfer *, struct urtwn_data *); > +int urtwn_txbcn(struct ieee80211vap *vap, > + struct ieee80211_node *); > static int urtwn_alloc_list(struct urtwn_softc *, > struct urtwn_data[], int, int); > static int urtwn_alloc_rx_list(struct urtwn_softc *); > @@ -436,6 +438,10 @@ > | IEEE80211_C_WPA /* 802.11i */ > ; > > + if (sc->chip & URTWN_CHIP_88E) > + ic->ic_caps |= > + IEEE80211_C_HOSTAP; /* HostAp mode supported */ > + > bands = 0; > setbit(&bands, IEEE80211_MODE_11B); > setbit(&bands, IEEE80211_MODE_11G); > @@ -857,6 +863,39 @@ > sc->sc_txtimer = 0; > } > > +/* > + * Push a beacon frame into the chip and check if it was accepted. Beacon will > + * be repeated by the chip every R92C_BCN_INTERVAL. > + */ > +int > +urtwn_txbcn(struct ieee80211vap *vap, struct ieee80211_node *ni) > +{ > + struct ieee80211com *ic = ni->ni_ic; > + struct urtwn_softc *sc = ic->ic_softc; > + struct urtwn_data *bf; > + struct mbuf *m; > + > + ieee80211_ref_node(ni); > + m = ieee80211_beacon_alloc(ni, &URTWN_VAP(vap)->bo); > + > + bf = urtwn_getbuf(sc); > + if (bf == NULL) { > + ieee80211_free_node(ni); > + m_freem(m); > + return (ENOBUFS); > + } > + > + if (urtwn_tx_start(sc, ni, m, bf) != 0) { > + ieee80211_free_node(ni); > + STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next); > + return (EIO); > + } > + > + sc->sc_txtimer = 5; > + > + return (0); > +} > + > static void > urtwn_bulk_tx_callback(struct usb_xfer *xfer, usb_error_t error) > { > @@ -1466,6 +1505,7 @@ > struct ieee80211_node *ni; > enum ieee80211_state ostate; > uint32_t reg; > + int error; > > ostate = vap->iv_state; > DPRINTF("%s -> %s\n", ieee80211_state_name[ostate], > @@ -1553,23 +1593,68 @@ > } > > ni = ieee80211_ref_node(vap->iv_bss); > - /* Set media status to 'Associated'. */ > - reg = urtwn_read_4(sc, R92C_CR); > - reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); > - urtwn_write_4(sc, R92C_CR, reg); > > - /* Set BSSID. */ > - urtwn_write_4(sc, R92C_BSSID + 0, LE_READ_4(&ni->ni_bssid[0])); > - urtwn_write_4(sc, R92C_BSSID + 4, LE_READ_2(&ni->ni_bssid[4])); > + if (ic->ic_opmode == IEEE80211_M_STA) { > + /* Set BSSID. */ > + urtwn_write_4(sc, R92C_BSSID + 0, > + LE_READ_4(&ni->ni_bssid[0])); > + urtwn_write_4(sc, R92C_BSSID + 4, > + LE_READ_2(&ni->ni_bssid[4])); > > - if (ic->ic_curmode == IEEE80211_MODE_11B) > - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); > - else /* 802.11b/g */ > - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); > + if (ic->ic_curmode == IEEE80211_MODE_11B) > + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); > + else /* 802.11b/g */ > + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); > > - /* Enable Rx of data frames. */ > - urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); > + /* Enable Rx of data frames. */ > + urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); > > + /* Allow Rx from our BSSID only. */ > + urtwn_write_4(sc, R92C_RCR, urtwn_read_4(sc, R92C_RCR) | > + R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); > + > + /* Set media status to 'Associated'. */ > + reg = urtwn_read_4(sc, R92C_CR); > + reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); > + urtwn_write_4(sc, R92C_CR, reg); > + } > + > + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { > + /* Set media status to 'AP'. */ > + reg = urtwn_read_4(sc, R92C_CR); > + reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_AP); > + urtwn_write_4(sc, R92C_CR, reg); > + > + /* Set BSSID. */ > + urtwn_write_4(sc, R92C_BSSID + 0, > + LE_READ_4(&ni->ni_bssid[0])); > + urtwn_write_4(sc, R92C_BSSID + 4, > + LE_READ_2(&ni->ni_bssid[4])); > + > + /* > + * If 3rd or 4th bits are set to zero chip will stop > + * repeating beacon after first transmission for port0 > + * and port1 respectively. This will cause STAs to > + * disconnect after short period of time. > + */ > + reg = urtwn_read_1(sc, R92C_MBID_NUM); > + reg |= 0x8; > + reg |= 0x10; > + urtwn_write_1(sc, R92C_MBID_NUM, reg); > + > + /* Invalidate cam entries */ > + urtwn_cam_init(sc); > + > + /* Set chan/bw */ > + urtwn_set_chan(sc, ic->ic_curchan, NULL); > + > + /* Push beacon frame into the chip */ > + error = urtwn_txbcn(vap, ni); > + if (error != 0) > + printf("%s: unable to push beacon into the" > + " chip\n", device_get_nameunit(sc->sc_dev)); > + } > + > /* Flush all AC queues. */ > urtwn_write_1(sc, R92C_TXPAUSE, 0); > > @@ -1576,11 +1661,6 @@ > /* Set beacon interval. */ > urtwn_write_2(sc, R92C_BCN_INTERVAL, ni->ni_intval); > > - /* Allow Rx from our BSSID only. */ > - urtwn_write_4(sc, R92C_RCR, > - urtwn_read_4(sc, R92C_RCR) | > - R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); > - > /* Enable TSF synchronization. */ > urtwn_tsf_sync_enable(sc); > > @@ -1754,7 +1834,7 @@ > struct ieee80211vap *vap = ni->ni_vap; > struct usb_xfer *xfer; > struct r92c_tx_desc *txd; > - uint8_t raid, type; > + uint8_t raid, type, subtype; > uint16_t sum; > int i, hasqos, xferlen; > struct usb_xfer *urtwn_pipes[4] = { > @@ -1771,6 +1851,7 @@ > */ > wh = mtod(m0, struct ieee80211_frame *); > type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; > + subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; > > if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) { > k = ieee80211_crypto_encap(ni, m0); > @@ -1819,7 +1900,7 @@ > if (sc->chip & URTWN_CHIP_88E) { > txd->txdw1 |= htole32( > SM(R88E_TXDW1_MACID, URTWN_MACID_BSS) | > - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_BE) | > + SM(R92C_TXDW1_QSEL, R88E_TXDW1_QSEL_BE) | > SM(R92C_TXDW1_RAID, raid)); > txd->txdw2 |= htole32(R88E_TXDW2_AGGBK); > } else { > @@ -1843,9 +1924,20 @@ > /* Send data at OFDM54. */ > txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); > } else { > + /* > + * If beacon frame is pushed into wrong queue, the chip won't > + * start repeating it. > + */ > + if (subtype == IEEE80211_FC0_SUBTYPE_BEACON && > + sc->chip & URTWN_CHIP_88E) > + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, > + R88E_TXDW1_QSEL_MGNT)); > + else > + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, > + R92C_TXDW1_QSEL_MGNT)); > + > txd->txdw1 |= htole32( > SM(R92C_TXDW1_MACID, 0) | > - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_MGNT) | > SM(R92C_TXDW1_RAID, R92C_RAID_11B)); > > /* Force CCK1. */ > Index: sys/dev/usb/wlan/if_urtwnreg.h > =================================================================== > --- sys/dev/usb/wlan/if_urtwnreg.h (revision 287342) > +++ sys/dev/usb/wlan/if_urtwnreg.h (working copy) > @@ -1019,7 +1019,9 @@ > #define R92C_TXDW1_QSEL_M 0x00001f00 > #define R92C_TXDW1_QSEL_S 8 > #define R92C_TXDW1_QSEL_BE 0x00 > +#define R88E_TXDW1_QSEL_BE 0x03 > #define R92C_TXDW1_QSEL_MGNT 0x12 > +#define R88E_TXDW1_QSEL_MGNT 0x10 > #define R92C_TXDW1_RAID_M 0x000f0000 > #define R92C_TXDW1_RAID_S 16 > #define R92C_TXDW1_CIPHER_M 0x00c00000 > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Thu Sep 17 15:22:44 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 4873D9CE624 for ; Thu, 17 Sep 2015 15:22:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 1308C1213; Thu, 17 Sep 2015 15:22:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofb144 with SMTP id b144so25678825iof.1; Thu, 17 Sep 2015 08:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NujILDstc25HsM1A/WyUaE+9rK6UDcGyjo3y4ASUK0Y=; b=Q13KioPaHrrU2XHSJ+cXqGzBhouT9JMOmX/BZU/wqxwE1MRemD0Yon4w+Q8tWIoAh/ 0sbzgGZhVY+aPsD5A9HcXb0cUbNT3HN8SNCwisTPbnsP9L0A76rQkHY1LlLCglhYD2Hd 3zSs1llIXHLTCeD5NvTEBLIuPTTCdg89eK2QzkRR5fC6/U/5d1YK2nPDolpPrQh66rYR DC0Kj7S9MLNDyKrSWhKRz5bQIoixQVEy6PwuZOmD0X36Z884NTlPx7hmuuYOJ2jj3OVn LTXu7J0EL6XY5N39NuQtq9rCTHl9YROD4wrvnGsYJ1sa+cjZmN+NYSeL3gVGNY9IOdZw mRuQ== MIME-Version: 1.0 X-Received: by 10.107.46.228 with SMTP id u97mr6974982iou.165.1442503363394; Thu, 17 Sep 2015 08:22:43 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Thu, 17 Sep 2015 08:22:43 -0700 (PDT) In-Reply-To: <20150917151249.GA68201@ns.kevlo.org> References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> Date: Thu, 17 Sep 2015 08:22:43 -0700 Message-ID: Subject: Re: urtwn and hostap From: Adrian Chadd To: Kevin Lo Cc: Matthew Grooms , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Thu, 17 Sep 2015 15:22:44 -0000 I think this patch is missing beacon updates - it just transmits the same beacon over and oveR? -a On 17 September 2015 at 08:12, Kevin Lo wrote: > On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote: >> Seems to behave better now and hostap appears to be working ... >> >> #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap >> #ifconfig wlan0 list caps >> drivercaps=2181c401 >> >> #ifconfig wlan0 up ssid freebsdap mode 11g channel 1 >> #ifconfig bridge0 create up addm em0 addm wlan0 >> >> #ifconfig wlan0 >> wlan0: flags=8943 metric >> 0 mtu 1500 >> ether 00:c3:e1:16:11:32 >> nd6 options=29 >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> status: running >> ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32 >> country US authmode OPEN privacy OFF txpower 0 scanvalid 60 >> protmode CTS dtimperiod 1 -dfs >> groups: wlan >> >> #ifconfig bridge0 >> bridge0: flags=8843 metric 0 mtu >> 1500 >> ether 02:df:20:d2:42:00 >> nd6 options=1 >> groups: bridge >> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> member: wlan0 flags=143 >> ifmaxaddr 0 port 3 priority 128 path cost 370370 >> member: em0 flags=143 >> ifmaxaddr 0 port 1 priority 128 path cost 20000 >> >> The speed leaves a lot to be desired. Throughput for the associated host >> is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative >> of a problem. Occasionally I also see the this message on the console >> when I'm bringing the adapter up ... >> >> wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost >> >> If I down and up the adapter again, it seems to correct itself. Not sure >> what that's all about. I am passing the USB adapter through to a VM >> inside of ESXi to test the patch, so maybe that has something to do with >> these quirks. I'll try to run some tests with the adapter associated to >> a physical AP tomorrow to get a baseline. > > I knew OpenBSD had patches about hostap support for urtwn(4), but those > don't look quite right. I think that's why OpenBSD developers didn't > commit them. BTW, NetBSD adopted OpenBSD's patches, I tested it on NetBSD > about four months ago, the connection was not stable... > >> Thanks, >> >> -Matthew > > Kevin > >> On 9/16/2015 11:24 AM, Adrian Chadd wrote: >> > The only one to look at is ath(4). I've not fixed/hacked on any other >> > hostap chips. :) >> > >> > if_ath_beacon.c has the logic - it gets a reference when creating a >> > beacon frame. >> > >> > >> > >> > -adrian >> > >> > >> > On 16 September 2015 at 09:21, Matthew Grooms wrote: >> >> On 9/16/2015 10:58 AM, Adrian Chadd wrote: >> >>> I think the net80211 beacon create routine doesn't allocate a node >> >>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after >> >>> calling becaon_create(), and deref it if the tx fails. The TX success >> >>> will free the node ref for you. >> >>> >> >> Got it. I'll take another look at one of the drivers that support hostap to >> >> make sure I'm following the same pattern. Thanks again for the feedback! >> >> >> >> -Matthew >> >> >> >> >> >>> -adrian >> >>> >> >>> >> >>> On 16 September 2015 at 04:27, Idwer Vollering wrote: >> >>>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : >> >>>> >> >>>>> It looks like my screenshot got scrubbed. Here is my hopefully faithful >> >>>>> transcription ... >> >>>>> >> >>>>> Fatal trap 9: general protection fault while in kernel mode >> >>>>> cpuid = 3; apic id = 03 >> >>>>> instruction pointer = 0x20:0xffffffff80a01105 >> >>>>> stack pointer = 0x28:0xfffffe0092fe86f0 >> >>>>> frame pointer = 0x28:0xfffffe0092fe8740 >> >>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >> >>>>> = DPL 0, pres 1, long 1, def32 0, gran >> >>>>> 1 >> >>>>> processor eflags = interrupt enabled, resume, IOPL = 0 >> >>>>> current process = 716 (ifconfig) >> >>>>> [thread pid 716 tid 100082 ] >> >>>>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >> >>>>> db> bt >> >>>>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >> >>>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >> >>>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >> >>>>> 0xfffffe0092fe8780 >> >>>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >> >>>>> 0xfffffe0092fe87a0 >> >>>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >> >>>>> 0xfffffe0092fe87d0 >> >>>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >> >>>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >> >>>>> 0xfffffe0092fe8840 >> >>>>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >> >>>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >> >>>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >> >>>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >> >>>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >> >>>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >> >>>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >> >>>>> db> >> >>>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have >> >>>> entered 'dump' at the db> blinker :) >> >>>> >> >>>> The trap details are found in /var/crash/, run kgdb: "kgdb >> >>>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at >> >>>> its prompt. >> >>>> >> >>>>> -Matthew >> >>>>> _______________________________________________ >> >>>>> freebsd-wireless@freebsd.org mailing list >> >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> >>>>> To unsubscribe, send any mail to >> >>>>> "freebsd-wireless-unsubscribe@freebsd.org" >> >>>> _______________________________________________ >> >>>> freebsd-wireless@freebsd.org mailing list >> >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> >>>> To unsubscribe, send any mail to >> >>>> "freebsd-wireless-unsubscribe@freebsd.org" >> >>> _______________________________________________ >> >>> freebsd-wireless@freebsd.org mailing list >> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> >>> To unsubscribe, send any mail to >> >>> "freebsd-wireless-unsubscribe@freebsd.org" >> >> >> >> _______________________________________________ >> >> freebsd-wireless@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" >> > >> Index: sys/dev/usb/wlan/if_urtwn.c >> =================================================================== >> --- sys/dev/usb/wlan/if_urtwn.c (revision 287342) >> +++ sys/dev/usb/wlan/if_urtwn.c (working copy) >> @@ -181,6 +181,8 @@ >> static struct mbuf * urtwn_rxeof(struct usb_xfer *, struct urtwn_data *, >> int *, int8_t *); >> static void urtwn_txeof(struct usb_xfer *, struct urtwn_data *); >> +int urtwn_txbcn(struct ieee80211vap *vap, >> + struct ieee80211_node *); >> static int urtwn_alloc_list(struct urtwn_softc *, >> struct urtwn_data[], int, int); >> static int urtwn_alloc_rx_list(struct urtwn_softc *); >> @@ -436,6 +438,10 @@ >> | IEEE80211_C_WPA /* 802.11i */ >> ; >> >> + if (sc->chip & URTWN_CHIP_88E) >> + ic->ic_caps |= >> + IEEE80211_C_HOSTAP; /* HostAp mode supported */ >> + >> bands = 0; >> setbit(&bands, IEEE80211_MODE_11B); >> setbit(&bands, IEEE80211_MODE_11G); >> @@ -857,6 +863,39 @@ >> sc->sc_txtimer = 0; >> } >> >> +/* >> + * Push a beacon frame into the chip and check if it was accepted. Beacon will >> + * be repeated by the chip every R92C_BCN_INTERVAL. >> + */ >> +int >> +urtwn_txbcn(struct ieee80211vap *vap, struct ieee80211_node *ni) >> +{ >> + struct ieee80211com *ic = ni->ni_ic; >> + struct urtwn_softc *sc = ic->ic_softc; >> + struct urtwn_data *bf; >> + struct mbuf *m; >> + >> + ieee80211_ref_node(ni); >> + m = ieee80211_beacon_alloc(ni, &URTWN_VAP(vap)->bo); >> + >> + bf = urtwn_getbuf(sc); >> + if (bf == NULL) { >> + ieee80211_free_node(ni); >> + m_freem(m); >> + return (ENOBUFS); >> + } >> + >> + if (urtwn_tx_start(sc, ni, m, bf) != 0) { >> + ieee80211_free_node(ni); >> + STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next); >> + return (EIO); >> + } >> + >> + sc->sc_txtimer = 5; >> + >> + return (0); >> +} >> + >> static void >> urtwn_bulk_tx_callback(struct usb_xfer *xfer, usb_error_t error) >> { >> @@ -1466,6 +1505,7 @@ >> struct ieee80211_node *ni; >> enum ieee80211_state ostate; >> uint32_t reg; >> + int error; >> >> ostate = vap->iv_state; >> DPRINTF("%s -> %s\n", ieee80211_state_name[ostate], >> @@ -1553,23 +1593,68 @@ >> } >> >> ni = ieee80211_ref_node(vap->iv_bss); >> - /* Set media status to 'Associated'. */ >> - reg = urtwn_read_4(sc, R92C_CR); >> - reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); >> - urtwn_write_4(sc, R92C_CR, reg); >> >> - /* Set BSSID. */ >> - urtwn_write_4(sc, R92C_BSSID + 0, LE_READ_4(&ni->ni_bssid[0])); >> - urtwn_write_4(sc, R92C_BSSID + 4, LE_READ_2(&ni->ni_bssid[4])); >> + if (ic->ic_opmode == IEEE80211_M_STA) { >> + /* Set BSSID. */ >> + urtwn_write_4(sc, R92C_BSSID + 0, >> + LE_READ_4(&ni->ni_bssid[0])); >> + urtwn_write_4(sc, R92C_BSSID + 4, >> + LE_READ_2(&ni->ni_bssid[4])); >> >> - if (ic->ic_curmode == IEEE80211_MODE_11B) >> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); >> - else /* 802.11b/g */ >> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); >> + if (ic->ic_curmode == IEEE80211_MODE_11B) >> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); >> + else /* 802.11b/g */ >> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); >> >> - /* Enable Rx of data frames. */ >> - urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >> + /* Enable Rx of data frames. */ >> + urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >> >> + /* Allow Rx from our BSSID only. */ >> + urtwn_write_4(sc, R92C_RCR, urtwn_read_4(sc, R92C_RCR) | >> + R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >> + >> + /* Set media status to 'Associated'. */ >> + reg = urtwn_read_4(sc, R92C_CR); >> + reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); >> + urtwn_write_4(sc, R92C_CR, reg); >> + } >> + >> + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { >> + /* Set media status to 'AP'. */ >> + reg = urtwn_read_4(sc, R92C_CR); >> + reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_AP); >> + urtwn_write_4(sc, R92C_CR, reg); >> + >> + /* Set BSSID. */ >> + urtwn_write_4(sc, R92C_BSSID + 0, >> + LE_READ_4(&ni->ni_bssid[0])); >> + urtwn_write_4(sc, R92C_BSSID + 4, >> + LE_READ_2(&ni->ni_bssid[4])); >> + >> + /* >> + * If 3rd or 4th bits are set to zero chip will stop >> + * repeating beacon after first transmission for port0 >> + * and port1 respectively. This will cause STAs to >> + * disconnect after short period of time. >> + */ >> + reg = urtwn_read_1(sc, R92C_MBID_NUM); >> + reg |= 0x8; >> + reg |= 0x10; >> + urtwn_write_1(sc, R92C_MBID_NUM, reg); >> + >> + /* Invalidate cam entries */ >> + urtwn_cam_init(sc); >> + >> + /* Set chan/bw */ >> + urtwn_set_chan(sc, ic->ic_curchan, NULL); >> + >> + /* Push beacon frame into the chip */ >> + error = urtwn_txbcn(vap, ni); >> + if (error != 0) >> + printf("%s: unable to push beacon into the" >> + " chip\n", device_get_nameunit(sc->sc_dev)); >> + } >> + >> /* Flush all AC queues. */ >> urtwn_write_1(sc, R92C_TXPAUSE, 0); >> >> @@ -1576,11 +1661,6 @@ >> /* Set beacon interval. */ >> urtwn_write_2(sc, R92C_BCN_INTERVAL, ni->ni_intval); >> >> - /* Allow Rx from our BSSID only. */ >> - urtwn_write_4(sc, R92C_RCR, >> - urtwn_read_4(sc, R92C_RCR) | >> - R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >> - >> /* Enable TSF synchronization. */ >> urtwn_tsf_sync_enable(sc); >> >> @@ -1754,7 +1834,7 @@ >> struct ieee80211vap *vap = ni->ni_vap; >> struct usb_xfer *xfer; >> struct r92c_tx_desc *txd; >> - uint8_t raid, type; >> + uint8_t raid, type, subtype; >> uint16_t sum; >> int i, hasqos, xferlen; >> struct usb_xfer *urtwn_pipes[4] = { >> @@ -1771,6 +1851,7 @@ >> */ >> wh = mtod(m0, struct ieee80211_frame *); >> type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; >> + subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; >> >> if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) { >> k = ieee80211_crypto_encap(ni, m0); >> @@ -1819,7 +1900,7 @@ >> if (sc->chip & URTWN_CHIP_88E) { >> txd->txdw1 |= htole32( >> SM(R88E_TXDW1_MACID, URTWN_MACID_BSS) | >> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_BE) | >> + SM(R92C_TXDW1_QSEL, R88E_TXDW1_QSEL_BE) | >> SM(R92C_TXDW1_RAID, raid)); >> txd->txdw2 |= htole32(R88E_TXDW2_AGGBK); >> } else { >> @@ -1843,9 +1924,20 @@ >> /* Send data at OFDM54. */ >> txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); >> } else { >> + /* >> + * If beacon frame is pushed into wrong queue, the chip won't >> + * start repeating it. >> + */ >> + if (subtype == IEEE80211_FC0_SUBTYPE_BEACON && >> + sc->chip & URTWN_CHIP_88E) >> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >> + R88E_TXDW1_QSEL_MGNT)); >> + else >> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >> + R92C_TXDW1_QSEL_MGNT)); >> + >> txd->txdw1 |= htole32( >> SM(R92C_TXDW1_MACID, 0) | >> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_MGNT) | >> SM(R92C_TXDW1_RAID, R92C_RAID_11B)); >> >> /* Force CCK1. */ >> Index: sys/dev/usb/wlan/if_urtwnreg.h >> =================================================================== >> --- sys/dev/usb/wlan/if_urtwnreg.h (revision 287342) >> +++ sys/dev/usb/wlan/if_urtwnreg.h (working copy) >> @@ -1019,7 +1019,9 @@ >> #define R92C_TXDW1_QSEL_M 0x00001f00 >> #define R92C_TXDW1_QSEL_S 8 >> #define R92C_TXDW1_QSEL_BE 0x00 >> +#define R88E_TXDW1_QSEL_BE 0x03 >> #define R92C_TXDW1_QSEL_MGNT 0x12 >> +#define R88E_TXDW1_QSEL_MGNT 0x10 >> #define R92C_TXDW1_RAID_M 0x000f0000 >> #define R92C_TXDW1_RAID_S 16 >> #define R92C_TXDW1_CIPHER_M 0x00c00000 > >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" > From owner-freebsd-wireless@freebsd.org Thu Sep 17 16:30:10 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 2E7279CEA50 for ; Thu, 17 Sep 2015 16:30:10 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C56B61325; Thu, 17 Sep 2015 16:30:09 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t8HGS1SA048983; Thu, 17 Sep 2015 11:28:01 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id C662018BE07; Thu, 17 Sep 2015 11:27:50 -0500 (CDT) Subject: Re: urtwn and hostap To: Adrian Chadd , Kevin Lo References: <55F90187.10809@shrew.net> <55F906CB.9030007@shrew.net> <55F996FD.5060804@shrew.net> <55FA6022.8090609@shrew.net> <20150917151249.GA68201@ns.kevlo.org> Cc: "freebsd-wireless@freebsd.org" From: Matthew Grooms Message-ID: <55FAEA82.3060602@shrew.net> Date: Thu, 17 Sep 2015 11:29:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Thu, 17 Sep 2015 11:28:01 -0500 (CDT) 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: Thu, 17 Sep 2015 16:30:10 -0000 I just assumed that the card was doing the right thing with the beacon since it was being loaded into a specific queue. Like I said, I'm fumbling around here. Ok, I see the NetBSD commit now. It doesn't look anything like the patch I was working with. It also doesn't look specific to RTL8188E ... http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_urtwn.c.diff?r1=1.25&r2=1.26&only_with_tag=MAIN I should have checked NetBSD before hand :/ -Matthew On 9/17/2015 10:22 AM, Adrian Chadd wrote: > I think this patch is missing beacon updates - it just transmits the > same beacon over and oveR? > > > -a > > > On 17 September 2015 at 08:12, Kevin Lo wrote: >> On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote: >>> Seems to behave better now and hostap appears to be working ... >>> >>> #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap >>> #ifconfig wlan0 list caps >>> drivercaps=2181c401 >>> >>> #ifconfig wlan0 up ssid freebsdap mode 11g channel 1 >>> #ifconfig bridge0 create up addm em0 addm wlan0 >>> >>> #ifconfig wlan0 >>> wlan0: flags=8943 metric >>> 0 mtu 1500 >>> ether 00:c3:e1:16:11:32 >>> nd6 options=29 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>> status: running >>> ssid freebsdap channel 1 (2412 MHz 11g) bssid 00:c3:e1:16:11:32 >>> country US authmode OPEN privacy OFF txpower 0 scanvalid 60 >>> protmode CTS dtimperiod 1 -dfs >>> groups: wlan >>> >>> #ifconfig bridge0 >>> bridge0: flags=8843 metric 0 mtu >>> 1500 >>> ether 02:df:20:d2:42:00 >>> nd6 options=1 >>> groups: bridge >>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>> member: wlan0 flags=143 >>> ifmaxaddr 0 port 3 priority 128 path cost 370370 >>> member: em0 flags=143 >>> ifmaxaddr 0 port 1 priority 128 path cost 20000 >>> >>> The speed leaves a lot to be desired. Throughput for the associated host >>> is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative >>> of a problem. Occasionally I also see the this message on the console >>> when I'm bringing the adapter up ... >>> >>> wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost >>> >>> If I down and up the adapter again, it seems to correct itself. Not sure >>> what that's all about. I am passing the USB adapter through to a VM >>> inside of ESXi to test the patch, so maybe that has something to do with >>> these quirks. I'll try to run some tests with the adapter associated to >>> a physical AP tomorrow to get a baseline. >> I knew OpenBSD had patches about hostap support for urtwn(4), but those >> don't look quite right. I think that's why OpenBSD developers didn't >> commit them. BTW, NetBSD adopted OpenBSD's patches, I tested it on NetBSD >> about four months ago, the connection was not stable... >> >>> Thanks, >>> >>> -Matthew >> Kevin >> >>> On 9/16/2015 11:24 AM, Adrian Chadd wrote: >>>> The only one to look at is ath(4). I've not fixed/hacked on any other >>>> hostap chips. :) >>>> >>>> if_ath_beacon.c has the logic - it gets a reference when creating a >>>> beacon frame. >>>> >>>> >>>> >>>> -adrian >>>> >>>> >>>> On 16 September 2015 at 09:21, Matthew Grooms wrote: >>>>> On 9/16/2015 10:58 AM, Adrian Chadd wrote: >>>>>> I think the net80211 beacon create routine doesn't allocate a node >>>>>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after >>>>>> calling becaon_create(), and deref it if the tx fails. The TX success >>>>>> will free the node ref for you. >>>>>> >>>>> Got it. I'll take another look at one of the drivers that support hostap to >>>>> make sure I'm following the same pattern. Thanks again for the feedback! >>>>> >>>>> -Matthew >>>>> >>>>> >>>>>> -adrian >>>>>> >>>>>> >>>>>> On 16 September 2015 at 04:27, Idwer Vollering wrote: >>>>>>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : >>>>>>> >>>>>>>> It looks like my screenshot got scrubbed. Here is my hopefully faithful >>>>>>>> transcription ... >>>>>>>> >>>>>>>> Fatal trap 9: general protection fault while in kernel mode >>>>>>>> cpuid = 3; apic id = 03 >>>>>>>> instruction pointer = 0x20:0xffffffff80a01105 >>>>>>>> stack pointer = 0x28:0xfffffe0092fe86f0 >>>>>>>> frame pointer = 0x28:0xfffffe0092fe8740 >>>>>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>>>>> = DPL 0, pres 1, long 1, def32 0, gran >>>>>>>> 1 >>>>>>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>>>>>> current process = 716 (ifconfig) >>>>>>>> [thread pid 716 tid 100082 ] >>>>>>>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >>>>>>>> db> bt >>>>>>>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >>>>>>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame 0xfffffe0092fe8740 >>>>>>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >>>>>>>> 0xfffffe0092fe8780 >>>>>>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >>>>>>>> 0xfffffe0092fe87a0 >>>>>>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >>>>>>>> 0xfffffe0092fe87d0 >>>>>>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame 0xfffffe0092fe87f0 >>>>>>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >>>>>>>> 0xfffffe0092fe8840 >>>>>>>> if_clone_destroy() at if_clone_destroy()0x8e/frame 0xfffffe0092fe8860 >>>>>>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >>>>>>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >>>>>>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >>>>>>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >>>>>>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >>>>>>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >>>>>>>> db> >>>>>>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have >>>>>>> entered 'dump' at the db> blinker :) >>>>>>> >>>>>>> The trap details are found in /var/crash/, run kgdb: "kgdb >>>>>>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' at >>>>>>> its prompt. >>>>>>> >>>>>>>> -Matthew >>>>>>>> _______________________________________________ >>>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>>> To unsubscribe, send any mail to >>>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>>> _______________________________________________ >>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>> To unsubscribe, send any mail to >>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>> _______________________________________________ >>>>>> freebsd-wireless@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>> _______________________________________________ >>>>> freebsd-wireless@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" >>> Index: sys/dev/usb/wlan/if_urtwn.c >>> =================================================================== >>> --- sys/dev/usb/wlan/if_urtwn.c (revision 287342) >>> +++ sys/dev/usb/wlan/if_urtwn.c (working copy) >>> @@ -181,6 +181,8 @@ >>> static struct mbuf * urtwn_rxeof(struct usb_xfer *, struct urtwn_data *, >>> int *, int8_t *); >>> static void urtwn_txeof(struct usb_xfer *, struct urtwn_data *); >>> +int urtwn_txbcn(struct ieee80211vap *vap, >>> + struct ieee80211_node *); >>> static int urtwn_alloc_list(struct urtwn_softc *, >>> struct urtwn_data[], int, int); >>> static int urtwn_alloc_rx_list(struct urtwn_softc *); >>> @@ -436,6 +438,10 @@ >>> | IEEE80211_C_WPA /* 802.11i */ >>> ; >>> >>> + if (sc->chip & URTWN_CHIP_88E) >>> + ic->ic_caps |= >>> + IEEE80211_C_HOSTAP; /* HostAp mode supported */ >>> + >>> bands = 0; >>> setbit(&bands, IEEE80211_MODE_11B); >>> setbit(&bands, IEEE80211_MODE_11G); >>> @@ -857,6 +863,39 @@ >>> sc->sc_txtimer = 0; >>> } >>> >>> +/* >>> + * Push a beacon frame into the chip and check if it was accepted. Beacon will >>> + * be repeated by the chip every R92C_BCN_INTERVAL. >>> + */ >>> +int >>> +urtwn_txbcn(struct ieee80211vap *vap, struct ieee80211_node *ni) >>> +{ >>> + struct ieee80211com *ic = ni->ni_ic; >>> + struct urtwn_softc *sc = ic->ic_softc; >>> + struct urtwn_data *bf; >>> + struct mbuf *m; >>> + >>> + ieee80211_ref_node(ni); >>> + m = ieee80211_beacon_alloc(ni, &URTWN_VAP(vap)->bo); >>> + >>> + bf = urtwn_getbuf(sc); >>> + if (bf == NULL) { >>> + ieee80211_free_node(ni); >>> + m_freem(m); >>> + return (ENOBUFS); >>> + } >>> + >>> + if (urtwn_tx_start(sc, ni, m, bf) != 0) { >>> + ieee80211_free_node(ni); >>> + STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next); >>> + return (EIO); >>> + } >>> + >>> + sc->sc_txtimer = 5; >>> + >>> + return (0); >>> +} >>> + >>> static void >>> urtwn_bulk_tx_callback(struct usb_xfer *xfer, usb_error_t error) >>> { >>> @@ -1466,6 +1505,7 @@ >>> struct ieee80211_node *ni; >>> enum ieee80211_state ostate; >>> uint32_t reg; >>> + int error; >>> >>> ostate = vap->iv_state; >>> DPRINTF("%s -> %s\n", ieee80211_state_name[ostate], >>> @@ -1553,23 +1593,68 @@ >>> } >>> >>> ni = ieee80211_ref_node(vap->iv_bss); >>> - /* Set media status to 'Associated'. */ >>> - reg = urtwn_read_4(sc, R92C_CR); >>> - reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); >>> - urtwn_write_4(sc, R92C_CR, reg); >>> >>> - /* Set BSSID. */ >>> - urtwn_write_4(sc, R92C_BSSID + 0, LE_READ_4(&ni->ni_bssid[0])); >>> - urtwn_write_4(sc, R92C_BSSID + 4, LE_READ_2(&ni->ni_bssid[4])); >>> + if (ic->ic_opmode == IEEE80211_M_STA) { >>> + /* Set BSSID. */ >>> + urtwn_write_4(sc, R92C_BSSID + 0, >>> + LE_READ_4(&ni->ni_bssid[0])); >>> + urtwn_write_4(sc, R92C_BSSID + 4, >>> + LE_READ_2(&ni->ni_bssid[4])); >>> >>> - if (ic->ic_curmode == IEEE80211_MODE_11B) >>> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); >>> - else /* 802.11b/g */ >>> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); >>> + if (ic->ic_curmode == IEEE80211_MODE_11B) >>> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); >>> + else /* 802.11b/g */ >>> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); >>> >>> - /* Enable Rx of data frames. */ >>> - urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >>> + /* Enable Rx of data frames. */ >>> + urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >>> >>> + /* Allow Rx from our BSSID only. */ >>> + urtwn_write_4(sc, R92C_RCR, urtwn_read_4(sc, R92C_RCR) | >>> + R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >>> + >>> + /* Set media status to 'Associated'. */ >>> + reg = urtwn_read_4(sc, R92C_CR); >>> + reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); >>> + urtwn_write_4(sc, R92C_CR, reg); >>> + } >>> + >>> + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { >>> + /* Set media status to 'AP'. */ >>> + reg = urtwn_read_4(sc, R92C_CR); >>> + reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_AP); >>> + urtwn_write_4(sc, R92C_CR, reg); >>> + >>> + /* Set BSSID. */ >>> + urtwn_write_4(sc, R92C_BSSID + 0, >>> + LE_READ_4(&ni->ni_bssid[0])); >>> + urtwn_write_4(sc, R92C_BSSID + 4, >>> + LE_READ_2(&ni->ni_bssid[4])); >>> + >>> + /* >>> + * If 3rd or 4th bits are set to zero chip will stop >>> + * repeating beacon after first transmission for port0 >>> + * and port1 respectively. This will cause STAs to >>> + * disconnect after short period of time. >>> + */ >>> + reg = urtwn_read_1(sc, R92C_MBID_NUM); >>> + reg |= 0x8; >>> + reg |= 0x10; >>> + urtwn_write_1(sc, R92C_MBID_NUM, reg); >>> + >>> + /* Invalidate cam entries */ >>> + urtwn_cam_init(sc); >>> + >>> + /* Set chan/bw */ >>> + urtwn_set_chan(sc, ic->ic_curchan, NULL); >>> + >>> + /* Push beacon frame into the chip */ >>> + error = urtwn_txbcn(vap, ni); >>> + if (error != 0) >>> + printf("%s: unable to push beacon into the" >>> + " chip\n", device_get_nameunit(sc->sc_dev)); >>> + } >>> + >>> /* Flush all AC queues. */ >>> urtwn_write_1(sc, R92C_TXPAUSE, 0); >>> >>> @@ -1576,11 +1661,6 @@ >>> /* Set beacon interval. */ >>> urtwn_write_2(sc, R92C_BCN_INTERVAL, ni->ni_intval); >>> >>> - /* Allow Rx from our BSSID only. */ >>> - urtwn_write_4(sc, R92C_RCR, >>> - urtwn_read_4(sc, R92C_RCR) | >>> - R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >>> - >>> /* Enable TSF synchronization. */ >>> urtwn_tsf_sync_enable(sc); >>> >>> @@ -1754,7 +1834,7 @@ >>> struct ieee80211vap *vap = ni->ni_vap; >>> struct usb_xfer *xfer; >>> struct r92c_tx_desc *txd; >>> - uint8_t raid, type; >>> + uint8_t raid, type, subtype; >>> uint16_t sum; >>> int i, hasqos, xferlen; >>> struct usb_xfer *urtwn_pipes[4] = { >>> @@ -1771,6 +1851,7 @@ >>> */ >>> wh = mtod(m0, struct ieee80211_frame *); >>> type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; >>> + subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; >>> >>> if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) { >>> k = ieee80211_crypto_encap(ni, m0); >>> @@ -1819,7 +1900,7 @@ >>> if (sc->chip & URTWN_CHIP_88E) { >>> txd->txdw1 |= htole32( >>> SM(R88E_TXDW1_MACID, URTWN_MACID_BSS) | >>> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_BE) | >>> + SM(R92C_TXDW1_QSEL, R88E_TXDW1_QSEL_BE) | >>> SM(R92C_TXDW1_RAID, raid)); >>> txd->txdw2 |= htole32(R88E_TXDW2_AGGBK); >>> } else { >>> @@ -1843,9 +1924,20 @@ >>> /* Send data at OFDM54. */ >>> txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); >>> } else { >>> + /* >>> + * If beacon frame is pushed into wrong queue, the chip won't >>> + * start repeating it. >>> + */ >>> + if (subtype == IEEE80211_FC0_SUBTYPE_BEACON && >>> + sc->chip & URTWN_CHIP_88E) >>> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >>> + R88E_TXDW1_QSEL_MGNT)); >>> + else >>> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >>> + R92C_TXDW1_QSEL_MGNT)); >>> + >>> txd->txdw1 |= htole32( >>> SM(R92C_TXDW1_MACID, 0) | >>> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_MGNT) | >>> SM(R92C_TXDW1_RAID, R92C_RAID_11B)); >>> >>> /* Force CCK1. */ >>> Index: sys/dev/usb/wlan/if_urtwnreg.h >>> =================================================================== >>> --- sys/dev/usb/wlan/if_urtwnreg.h (revision 287342) >>> +++ sys/dev/usb/wlan/if_urtwnreg.h (working copy) >>> @@ -1019,7 +1019,9 @@ >>> #define R92C_TXDW1_QSEL_M 0x00001f00 >>> #define R92C_TXDW1_QSEL_S 8 >>> #define R92C_TXDW1_QSEL_BE 0x00 >>> +#define R88E_TXDW1_QSEL_BE 0x03 >>> #define R92C_TXDW1_QSEL_MGNT 0x12 >>> +#define R88E_TXDW1_QSEL_MGNT 0x10 >>> #define R92C_TXDW1_RAID_M 0x000f0000 >>> #define R92C_TXDW1_RAID_S 16 >>> #define R92C_TXDW1_CIPHER_M 0x00c00000 >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Thu Sep 17 17:07:44 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 4517A9CFBE1 for ; Thu, 17 Sep 2015 17:07:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31ADE1FE5 for ; Thu, 17 Sep 2015 17:07:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id t8HH7iox051534 for ; Thu, 17 Sep 2015 17:07:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 203177] [patch] wpa_supplicant(8): initialize interface before scanning (ap_scan=2) Date: Thu, 17 Sep 2015 17:07:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: s3erios@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 17 Sep 2015 17:07:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203177 Bug ID: 203177 Summary: [patch] wpa_supplicant(8): initialize interface before scanning (ap_scan=2) Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: s3erios@gmail.com Keywords: patch Created attachment 161152 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=161152&action=edit driver_bsd.c.diff -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-wireless@freebsd.org Thu Sep 17 17:11:12 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 CE1FF9CE22A for ; Thu, 17 Sep 2015 17:11:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 97D561A49; Thu, 17 Sep 2015 17:11:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcrk20 with SMTP id rk20so61604646igc.1; Thu, 17 Sep 2015 10:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vygi+wkT0BX4bUNxfBijo6H/V11K+yv35WTaMAeZrbI=; b=nbQz1FxUuiYh8bLiiCLGPq99P8+NJKG6vI16C1b7Lso9r9SamDeMjKAVFlehsFM8K4 mgsfGWYSDXLRb8syPq2ZTeAZethS5GWWzH+j6syNPTkicHgmz2vd6NouvwtlczeEBdxD PIqItx5Cj5TPzrm7gveqobEfswAubyw6ZiFfON/fhUROhz159UmG26UUNxbf0V0eia7o C9T7tlP27YN1JT1S+90ePQ3qMYSsgNfOWNSc6j0AbvUoDPHH7i3OhVVig72DGm4+u16I Y4cHSK8Nzg5/shdyn6yAJlCHbIWn4G0nnK6k1b7WnhQJJ3Kt55b35nfFG0GziPbzvOwq Sxyg== MIME-Version: 1.0 X-Received: by 10.50.45.33 with SMTP id j1mr7947697igm.61.1442509871926; Thu, 17 Sep 2015 10:11:11 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Thu, 17 Sep 2015 10:11:11 -0700 (PDT) In-Reply-To: <55FAEA82.3060602@shrew.net> 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> Date: Thu, 17 Sep 2015 10:11:11 -0700 Message-ID: Subject: Re: urtwn and hostap From: Adrian Chadd To: Matthew Grooms Cc: Kevin Lo , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Thu, 17 Sep 2015 17:11:13 -0000 hah, make no assumptions about correctness. :) Some of these NICs will do hostap mode themselves - you configure them in hostap mode and they take care of managing beaconing, station state, power save management, etc. This patch doesn't do that - it's just treating the NIC as a mostly dumb device and expecting the stack to do it. It's fine as a starting point, as long as the NIC and its firmware is happy with it. But yes, we do need to figure out how to get the beacon updates to push new beacon frames into the NIC as required. -adrian On 17 September 2015 at 09:29, Matthew Grooms wrote: > I just assumed that the card was doing the right thing with the beacon since > it was being loaded into a specific queue. Like I said, I'm fumbling around > here. Ok, I see the NetBSD commit now. It doesn't look anything like the > patch I was working with. It also doesn't look specific to RTL8188E ... > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_urtwn.c.diff?r1=1.25&r2=1.26&only_with_tag=MAIN > > I should have checked NetBSD before hand :/ > > -Matthew > > > On 9/17/2015 10:22 AM, Adrian Chadd wrote: >> >> I think this patch is missing beacon updates - it just transmits the >> same beacon over and oveR? >> >> >> -a >> >> >> On 17 September 2015 at 08:12, Kevin Lo wrote: >>> >>> On Thu, Sep 17, 2015 at 01:39:30AM -0500, Matthew Grooms wrote: >>>> >>>> Seems to behave better now and hostap appears to be working ... >>>> >>>> #ifconfig wlan0 create wlandev urtwn0 wlanmode hostap >>>> #ifconfig wlan0 list caps >>>> >>>> drivercaps=2181c401 >>>> >>>> #ifconfig wlan0 up ssid freebsdap mode 11g channel 1 >>>> #ifconfig bridge0 create up addm em0 addm wlan0 >>>> >>>> #ifconfig wlan0 >>>> wlan0: flags=8943 metric >>>> 0 mtu 1500 >>>> ether 00:c3:e1:16:11:32 >>>> nd6 options=29 >>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>>> >>>> status: running >>>> ssid freebsdap channel 1 (2412 MHz 11g) bssid >>>> 00:c3:e1:16:11:32 >>>> country US authmode OPEN privacy OFF txpower 0 scanvalid 60 >>>> protmode CTS dtimperiod 1 -dfs >>>> groups: wlan >>>> >>>> #ifconfig bridge0 >>>> bridge0: flags=8843 metric 0 mtu >>>> 1500 >>>> ether 02:df:20:d2:42:00 >>>> nd6 options=1 >>>> groups: bridge >>>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >>>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >>>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >>>> member: wlan0 flags=143 >>>> ifmaxaddr 0 port 3 priority 128 path cost 370370 >>>> member: em0 flags=143 >>>> ifmaxaddr 0 port 1 priority 128 path cost 20000 >>>> >>>> The speed leaves a lot to be desired. Throughput for the associated host >>>> is typically about 2Mbit down and 6Mbit up. I'm assume that's indicative >>>> of a problem. Occasionally I also see the this message on the console >>>> when I'm bringing the adapter up ... >>>> >>>> wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost >>>> >>>> If I down and up the adapter again, it seems to correct itself. Not sure >>>> what that's all about. I am passing the USB adapter through to a VM >>>> inside of ESXi to test the patch, so maybe that has something to do with >>>> these quirks. I'll try to run some tests with the adapter associated to >>>> a physical AP tomorrow to get a baseline. >>> >>> I knew OpenBSD had patches about hostap support for urtwn(4), but those >>> don't look quite right. I think that's why OpenBSD developers didn't >>> commit them. BTW, NetBSD adopted OpenBSD's patches, I tested it on >>> NetBSD >>> about four months ago, the connection was not stable... >>> >>>> Thanks, >>>> >>>> -Matthew >>> >>> Kevin >>> >>>> On 9/16/2015 11:24 AM, Adrian Chadd wrote: >>>>> >>>>> The only one to look at is ath(4). I've not fixed/hacked on any other >>>>> hostap chips. :) >>>>> >>>>> if_ath_beacon.c has the logic - it gets a reference when creating a >>>>> beacon frame. >>>>> >>>>> >>>>> >>>>> -adrian >>>>> >>>>> >>>>> On 16 September 2015 at 09:21, Matthew Grooms >>>>> wrote: >>>>>> >>>>>> On 9/16/2015 10:58 AM, Adrian Chadd wrote: >>>>>>> >>>>>>> I think the net80211 beacon create routine doesn't allocate a node >>>>>>> ref. Yeah, it doesn't. You have to do ieee80211_ref_node() after >>>>>>> calling becaon_create(), and deref it if the tx fails. The TX success >>>>>>> will free the node ref for you. >>>>>>> >>>>>> Got it. I'll take another look at one of the drivers that support >>>>>> hostap to >>>>>> make sure I'm following the same pattern. Thanks again for the >>>>>> feedback! >>>>>> >>>>>> -Matthew >>>>>> >>>>>> >>>>>>> -adrian >>>>>>> >>>>>>> >>>>>>> On 16 September 2015 at 04:27, Idwer Vollering >>>>>>> wrote: >>>>>>>> >>>>>>>> 2015-09-16 8:06 GMT+02:00 Matthew Grooms : >>>>>>>> >>>>>>>>> It looks like my screenshot got scrubbed. Here is my hopefully >>>>>>>>> faithful >>>>>>>>> transcription ... >>>>>>>>> >>>>>>>>> Fatal trap 9: general protection fault while in kernel mode >>>>>>>>> cpuid = 3; apic id = 03 >>>>>>>>> instruction pointer = 0x20:0xffffffff80a01105 >>>>>>>>> stack pointer = 0x28:0xfffffe0092fe86f0 >>>>>>>>> frame pointer = 0x28:0xfffffe0092fe8740 >>>>>>>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>>>>>>> = DPL 0, pres 1, long 1, def32 >>>>>>>>> 0, gran >>>>>>>>> 1 >>>>>>>>> processor eflags = interrupt enabled, resume, IOPL = 0 >>>>>>>>> current process = 716 (ifconfig) >>>>>>>>> [thread pid 716 tid 100082 ] >>>>>>>>> Stopped at __mtx_lock_flags+0x55: movq (%r13),%rax >>>>>>>>> db> bt >>>>>>>>> Tracing pid 716 tid 100082 td 0xffffff800512814d0 >>>>>>>>> __mtx_lock_flags() at __mtx_lock_flags+0x55/frame >>>>>>>>> 0xfffffe0092fe8740 >>>>>>>>> ieee80211_free_node() at ieee80211_free_node()_0x38/frame >>>>>>>>> 0xfffffe0092fe8780 >>>>>>>>> ieee80211_node_vdetach() at ieee80211_node_vdetach()+0x2d/frame >>>>>>>>> 0xfffffe0092fe87a0 >>>>>>>>> ieee80211_vap_detach() at ieee80211_vap_detach()+0x35e/frame >>>>>>>>> 0xfffffe0092fe87d0 >>>>>>>>> urtwn_vap_delete() at urtwn_vap_delete()+0xe/frame >>>>>>>>> 0xfffffe0092fe87f0 >>>>>>>>> if_clone_destroyif() at if_clone_destroyif()+0x1aa/frame >>>>>>>>> 0xfffffe0092fe8840 >>>>>>>>> if_clone_destroy() at if_clone_destroy()0x8e/frame >>>>>>>>> 0xfffffe0092fe8860 >>>>>>>>> kern_ioctl() at kern_ioctl()+0x230/frame 0xfffffe0092fe88c0 >>>>>>>>> sys_ioctl() at sys_ioctl()+0x153/frame 0xfffffe0092fe89a0 >>>>>>>>> amd64_syscall() at amd64_syscall()+0x282/frame 0xfffffe0092fe8ab0 >>>>>>>>> Xfast_syscall() at Xfast_syscall()+0xfb/frame 0xfffffe0092fe8ab0 >>>>>>>>> -- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011e8c8a, rsp = >>>>>>>>> 0x7fffffffe2f8, rbp = 0x7fffffffe310 -- >>>>>>>>> db> >>>>>>>> >>>>>>>> Assuming dumpdev="AUTO" is set in /etc/rc.conf, you should have >>>>>>>> entered 'dump' at the db> blinker :) >>>>>>>> >>>>>>>> The trap details are found in /var/crash/, run kgdb: "kgdb >>>>>>>> /boot/kernel/kernel /var/crash/vmcore.last", then run 'bt' and 'up' >>>>>>>> at >>>>>>>> its prompt. >>>>>>>> >>>>>>>>> -Matthew >>>>>>>>> _______________________________________________ >>>>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>>>> To unsubscribe, send any mail to >>>>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>>> To unsubscribe, send any mail to >>>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>>> >>>>>>> _______________________________________________ >>>>>>> freebsd-wireless@freebsd.org mailing list >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>>> To unsubscribe, send any mail to >>>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-wireless@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-wireless-unsubscribe@freebsd.org" >>>> >>>> Index: sys/dev/usb/wlan/if_urtwn.c >>>> =================================================================== >>>> --- sys/dev/usb/wlan/if_urtwn.c (revision 287342) >>>> +++ sys/dev/usb/wlan/if_urtwn.c (working copy) >>>> @@ -181,6 +181,8 @@ >>>> static struct mbuf * urtwn_rxeof(struct usb_xfer *, struct urtwn_data >>>> *, >>>> int *, int8_t *); >>>> static void urtwn_txeof(struct usb_xfer *, struct urtwn_data >>>> *); >>>> +int urtwn_txbcn(struct ieee80211vap *vap, >>>> + struct ieee80211_node *); >>>> static int urtwn_alloc_list(struct urtwn_softc *, >>>> struct urtwn_data[], int, int); >>>> static int urtwn_alloc_rx_list(struct urtwn_softc *); >>>> @@ -436,6 +438,10 @@ >>>> | IEEE80211_C_WPA /* 802.11i */ >>>> ; >>>> >>>> + if (sc->chip & URTWN_CHIP_88E) >>>> + ic->ic_caps |= >>>> + IEEE80211_C_HOSTAP; /* HostAp mode supported >>>> */ >>>> + >>>> bands = 0; >>>> setbit(&bands, IEEE80211_MODE_11B); >>>> setbit(&bands, IEEE80211_MODE_11G); >>>> @@ -857,6 +863,39 @@ >>>> sc->sc_txtimer = 0; >>>> } >>>> >>>> +/* >>>> + * Push a beacon frame into the chip and check if it was accepted. >>>> Beacon will >>>> + * be repeated by the chip every R92C_BCN_INTERVAL. >>>> + */ >>>> +int >>>> +urtwn_txbcn(struct ieee80211vap *vap, struct ieee80211_node *ni) >>>> +{ >>>> + struct ieee80211com *ic = ni->ni_ic; >>>> + struct urtwn_softc *sc = ic->ic_softc; >>>> + struct urtwn_data *bf; >>>> + struct mbuf *m; >>>> + >>>> + ieee80211_ref_node(ni); >>>> + m = ieee80211_beacon_alloc(ni, &URTWN_VAP(vap)->bo); >>>> + >>>> + bf = urtwn_getbuf(sc); >>>> + if (bf == NULL) { >>>> + ieee80211_free_node(ni); >>>> + m_freem(m); >>>> + return (ENOBUFS); >>>> + } >>>> + >>>> + if (urtwn_tx_start(sc, ni, m, bf) != 0) { >>>> + ieee80211_free_node(ni); >>>> + STAILQ_INSERT_HEAD(&sc->sc_tx_inactive, bf, next); >>>> + return (EIO); >>>> + } >>>> + >>>> + sc->sc_txtimer = 5; >>>> + >>>> + return (0); >>>> +} >>>> + >>>> static void >>>> urtwn_bulk_tx_callback(struct usb_xfer *xfer, usb_error_t error) >>>> { >>>> @@ -1466,6 +1505,7 @@ >>>> struct ieee80211_node *ni; >>>> enum ieee80211_state ostate; >>>> uint32_t reg; >>>> + int error; >>>> >>>> ostate = vap->iv_state; >>>> DPRINTF("%s -> %s\n", ieee80211_state_name[ostate], >>>> @@ -1553,23 +1593,68 @@ >>>> } >>>> >>>> ni = ieee80211_ref_node(vap->iv_bss); >>>> - /* Set media status to 'Associated'. */ >>>> - reg = urtwn_read_4(sc, R92C_CR); >>>> - reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA); >>>> - urtwn_write_4(sc, R92C_CR, reg); >>>> >>>> - /* Set BSSID. */ >>>> - urtwn_write_4(sc, R92C_BSSID + 0, >>>> LE_READ_4(&ni->ni_bssid[0])); >>>> - urtwn_write_4(sc, R92C_BSSID + 4, >>>> LE_READ_2(&ni->ni_bssid[4])); >>>> + if (ic->ic_opmode == IEEE80211_M_STA) { >>>> + /* Set BSSID. */ >>>> + urtwn_write_4(sc, R92C_BSSID + 0, >>>> + LE_READ_4(&ni->ni_bssid[0])); >>>> + urtwn_write_4(sc, R92C_BSSID + 4, >>>> + LE_READ_2(&ni->ni_bssid[4])); >>>> >>>> - if (ic->ic_curmode == IEEE80211_MODE_11B) >>>> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0); >>>> - else /* 802.11b/g */ >>>> - urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3); >>>> + if (ic->ic_curmode == IEEE80211_MODE_11B) >>>> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, >>>> 0); >>>> + else /* 802.11b/g */ >>>> + urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, >>>> 3); >>>> >>>> - /* Enable Rx of data frames. */ >>>> - urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >>>> + /* Enable Rx of data frames. */ >>>> + urtwn_write_2(sc, R92C_RXFLTMAP2, 0xffff); >>>> >>>> + /* Allow Rx from our BSSID only. */ >>>> + urtwn_write_4(sc, R92C_RCR, urtwn_read_4(sc, >>>> R92C_RCR) | >>>> + R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >>>> + >>>> + /* Set media status to 'Associated'. */ >>>> + reg = urtwn_read_4(sc, R92C_CR); >>>> + reg = RW(reg, R92C_CR_NETTYPE, >>>> R92C_CR_NETTYPE_INFRA); >>>> + urtwn_write_4(sc, R92C_CR, reg); >>>> + } >>>> + >>>> + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { >>>> + /* Set media status to 'AP'. */ >>>> + reg = urtwn_read_4(sc, R92C_CR); >>>> + reg = RW(reg, R92C_CR_NETTYPE, >>>> R92C_CR_NETTYPE_AP); >>>> + urtwn_write_4(sc, R92C_CR, reg); >>>> + >>>> + /* Set BSSID. */ >>>> + urtwn_write_4(sc, R92C_BSSID + 0, >>>> + LE_READ_4(&ni->ni_bssid[0])); >>>> + urtwn_write_4(sc, R92C_BSSID + 4, >>>> + LE_READ_2(&ni->ni_bssid[4])); >>>> + >>>> + /* >>>> + * If 3rd or 4th bits are set to zero chip will >>>> stop >>>> + * repeating beacon after first transmission for >>>> port0 >>>> + * and port1 respectively. This will cause STAs to >>>> + * disconnect after short period of time. >>>> + */ >>>> + reg = urtwn_read_1(sc, R92C_MBID_NUM); >>>> + reg |= 0x8; >>>> + reg |= 0x10; >>>> + urtwn_write_1(sc, R92C_MBID_NUM, reg); >>>> + >>>> + /* Invalidate cam entries */ >>>> + urtwn_cam_init(sc); >>>> + >>>> + /* Set chan/bw */ >>>> + urtwn_set_chan(sc, ic->ic_curchan, NULL); >>>> + >>>> + /* Push beacon frame into the chip */ >>>> + error = urtwn_txbcn(vap, ni); >>>> + if (error != 0) >>>> + printf("%s: unable to push beacon into >>>> the" >>>> + " chip\n", >>>> device_get_nameunit(sc->sc_dev)); >>>> + } >>>> + >>>> /* Flush all AC queues. */ >>>> urtwn_write_1(sc, R92C_TXPAUSE, 0); >>>> >>>> @@ -1576,11 +1661,6 @@ >>>> /* Set beacon interval. */ >>>> urtwn_write_2(sc, R92C_BCN_INTERVAL, ni->ni_intval); >>>> >>>> - /* Allow Rx from our BSSID only. */ >>>> - urtwn_write_4(sc, R92C_RCR, >>>> - urtwn_read_4(sc, R92C_RCR) | >>>> - R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN); >>>> - >>>> /* Enable TSF synchronization. */ >>>> urtwn_tsf_sync_enable(sc); >>>> >>>> @@ -1754,7 +1834,7 @@ >>>> struct ieee80211vap *vap = ni->ni_vap; >>>> struct usb_xfer *xfer; >>>> struct r92c_tx_desc *txd; >>>> - uint8_t raid, type; >>>> + uint8_t raid, type, subtype; >>>> uint16_t sum; >>>> int i, hasqos, xferlen; >>>> struct usb_xfer *urtwn_pipes[4] = { >>>> @@ -1771,6 +1851,7 @@ >>>> */ >>>> wh = mtod(m0, struct ieee80211_frame *); >>>> type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; >>>> + subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; >>>> >>>> if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) { >>>> k = ieee80211_crypto_encap(ni, m0); >>>> @@ -1819,7 +1900,7 @@ >>>> if (sc->chip & URTWN_CHIP_88E) { >>>> txd->txdw1 |= htole32( >>>> SM(R88E_TXDW1_MACID, URTWN_MACID_BSS) | >>>> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_BE) | >>>> + SM(R92C_TXDW1_QSEL, R88E_TXDW1_QSEL_BE) | >>>> SM(R92C_TXDW1_RAID, raid)); >>>> txd->txdw2 |= htole32(R88E_TXDW2_AGGBK); >>>> } else { >>>> @@ -1843,9 +1924,20 @@ >>>> /* Send data at OFDM54. */ >>>> txd->txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11)); >>>> } else { >>>> + /* >>>> + * If beacon frame is pushed into wrong queue, the chip >>>> won't >>>> + * start repeating it. >>>> + */ >>>> + if (subtype == IEEE80211_FC0_SUBTYPE_BEACON && >>>> + sc->chip & URTWN_CHIP_88E) >>>> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >>>> + R88E_TXDW1_QSEL_MGNT)); >>>> + else >>>> + txd->txdw1 |= htole32(SM(R92C_TXDW1_QSEL, >>>> + R92C_TXDW1_QSEL_MGNT)); >>>> + >>>> txd->txdw1 |= htole32( >>>> SM(R92C_TXDW1_MACID, 0) | >>>> - SM(R92C_TXDW1_QSEL, R92C_TXDW1_QSEL_MGNT) | >>>> SM(R92C_TXDW1_RAID, R92C_RAID_11B)); >>>> >>>> /* Force CCK1. */ >>>> Index: sys/dev/usb/wlan/if_urtwnreg.h >>>> =================================================================== >>>> --- sys/dev/usb/wlan/if_urtwnreg.h (revision 287342) >>>> +++ sys/dev/usb/wlan/if_urtwnreg.h (working copy) >>>> @@ -1019,7 +1019,9 @@ >>>> #define R92C_TXDW1_QSEL_M 0x00001f00 >>>> #define R92C_TXDW1_QSEL_S 8 >>>> #define R92C_TXDW1_QSEL_BE 0x00 >>>> +#define R88E_TXDW1_QSEL_BE 0x03 >>>> #define R92C_TXDW1_QSEL_MGNT 0x12 >>>> +#define R88E_TXDW1_QSEL_MGNT 0x10 >>>> #define R92C_TXDW1_RAID_M 0x000f0000 >>>> #define R92C_TXDW1_RAID_S 16 >>>> #define R92C_TXDW1_CIPHER_M 0x00c00000 >>>> _______________________________________________ >>>> freebsd-wireless@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>>> To unsubscribe, send any mail to >>>> "freebsd-wireless-unsubscribe@freebsd.org" > > From owner-freebsd-wireless@freebsd.org Fri Sep 18 17:49:27 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 4A04E9CF011 for ; Fri, 18 Sep 2015 17:49:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 0EDC61BB8 for ; Fri, 18 Sep 2015 17:49:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcrk20 with SMTP id rk20so23264454igc.1 for ; Fri, 18 Sep 2015 10:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=VewMhii16Q5e/r0y70wSX251Kn4Pq0yCAFbv6HwB/Fg=; b=rVXdaq4sND6aaAUmlKK1wjPWSDW+HZREvvyl7bXCmLIHs2huvreyfe9ydlwro1gNeO VUDnkMnuPM7VXXErWESEhXwyyLNDPtcof7ynM5B6xf5eYUb4fTbHGNVtOdy/AzApFMOn S0OthphLI+6tmIPKxB3hjGuwmd/I5xHU0t2crDwPO559h0hSqExAJU0AwFeAunfOsITh JT8p7cB4K5/CuM+7sKa76FT2emVaWUqiZFBDE1v+Hm7mdDZHZGh1LlkgbjlHXPI1YmDi 2rYRlLmKvSxaMWqugvW4Yz2MHUrFNPmCMIcDzLsgoclFAUTLxo9QQ/qGw7jfoxiK/+OL dpSw== MIME-Version: 1.0 X-Received: by 10.50.1.44 with SMTP id 12mr33275956igj.61.1442598566170; Fri, 18 Sep 2015 10:49:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Fri, 18 Sep 2015 10:49:26 -0700 (PDT) Date: Fri, 18 Sep 2015 10:49:26 -0700 X-Google-Sender-Auth: p1JX94QDRftCNbgsW_WRcIZx_90 Message-ID: Subject: if_rsu 11n - please test From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Fri, 18 Sep 2015 17:49:27 -0000 Hi! I've added enough dsupport to if_rsu to do basic 11n. RX aggregation/reordering works. It's enough to actually do 11n but it still fails an iperf test. To test: * update to today's HEAD * kldunload if_rsu; just to be sure * kenv hw.usb.rsu.enable_11n=1 * insert if_rsu NIC * check dmesg for "enabling 11n" or something like that. Ifconfig wlanX should show 11g/ht20 or 11g/ht40 when it's associated. See how it works for you. There are still transmit buffer exhaustion / TX hangs that aren't recovered from and I'm still not convinced it's transmitting at even remotely full TX power. That's next on my list. Thanks! -adrian