From owner-freebsd-wireless@FreeBSD.ORG Sun Jun 5 22:24:57 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B266106566C for ; Sun, 5 Jun 2011 22:24:57 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id DDF038FC08 for ; Sun, 5 Jun 2011 22:24:56 +0000 (UTC) Received: by pxi6 with SMTP id 6so2140115pxi.17 for ; Sun, 05 Jun 2011 15:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qbKe7v3Z/ETmy4CImhjAWxP/+4FosINX3OSlYodxj+w=; b=Hqft3zGUJel7g9voU1SqTCtMLddb1yT1QkPzU3pBCsewzm03QliR/d/GwBko21tpMb tsUA1VlWfzHpHYx+LnjyNufj7PMpgs30ZAmu69dlt+WBTyzGK9ZB8DowNGp4WnSs1zLF xdUgmH8RMpSr3qre+AEP078I/At5d/qEdYdGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Si0Z28DMUjxCCyqumZyxNlE/EcgMKiUY/+Eh+X1Gd+IMEjqkFnNk7dNcRV060MEZIG 1GZsVjm9SOIn2Rudrv+tZBjrwK/rftIMIdyMqwbyPUphLwlO8TqhIJoLo11K6QNjUib8 ja1iU+hDLf6ZJ5GaXuBgyBfnSoggPisFjaOKY= Received: by 10.68.54.170 with SMTP id k10mr1671249pbp.522.1307312696400; Sun, 05 Jun 2011 15:24:56 -0700 (PDT) Received: from sidhe.local ([75.111.37.204]) by mx.google.com with ESMTPS id y2sm3193169pbg.88.2011.06.05.15.24.53 (version=SSLv3 cipher=OTHER); Sun, 05 Jun 2011 15:24:54 -0700 (PDT) Message-ID: <4DEC0234.8030300@gmail.com> Date: Sun, 05 Jun 2011 15:24:52 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org References: <4DD365A2.3090106@gmail.com> <20110518100203.7bfa63be@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2011 22:24:57 -0000 On 05/18/11 00:36, Adrian Chadd wrote: > On 18 May 2011 15:02, Sergey V. Dyatko wrote: > >> As far I know Alexandr is too busy now (ported fbsd into one of >> d-link device). Hi have plans port ral code from openbsd. IIRC it was >> discussed not so long ago, in current@ > This thread reads to me like "hi, would someone like to pick up Alex's > work, liase with Alex/Bernhard, and bring the code up to scratch so we > can commit it to FreeBSD". > > Matt, how's your C? :) > > > Adrian > I've successfully got Alexandr's code worked into the Ral driver. This mainly involved some changes to if_ral_pci.c, renaming some softc stuff and pulling PCI code out of rt2860_attach. It's stable so far, WPA2 works fine as does Host AP etc (haven't tried with encryption). I haven't tested AHdemo, I assume monitor mode works. I want to eventually go through and place some chip specific fixes for 3090 etc., and possibly compare functions between different sources and make sure we're doing it right. Some questions: 1) If I kldunload if_ral while associated and flood pinging, I get "no route" for a while and then a page fault (only bug I've found so far). I assume this is something dumb I've done during detach? 2) My LED does not work. I have this in a Thinkpad WWAN slot, which are known to have issues with LED on some chips. A broadcom 4321 did activate the led in this slot. Can anyone confirm if they had a working LED using Alexandr's RT2860 stand alone driver? Or does work on LED code need to occur? Cheers, I'll remove my ugly printfs and post a patch or tarball later today. Matt From owner-freebsd-wireless@FreeBSD.ORG Sun Jun 5 23:48:28 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876FE106566B for ; Sun, 5 Jun 2011 23:48:28 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 22F828FC17 for ; Sun, 5 Jun 2011 23:48:27 +0000 (UTC) Received: by fxm11 with SMTP id 11so3168214fxm.13 for ; Sun, 05 Jun 2011 16:48:27 -0700 (PDT) Received: by 10.223.95.197 with SMTP id e5mr2720149fan.110.1307316199336; Sun, 05 Jun 2011 16:23:19 -0700 (PDT) Received: from rnote.ddteam.net (144-10-133-95.pool.ukrtel.net [95.133.10.144]) by mx.google.com with ESMTPS id g8sm1146755fai.20.2011.06.05.16.23.17 (version=SSLv3 cipher=OTHER); Sun, 05 Jun 2011 16:23:18 -0700 (PDT) Date: Mon, 6 Jun 2011 02:22:57 +0300 From: Aleksandr Rybalko To: Matt Message-Id: <20110606022257.39093142.ray@ddteam.net> In-Reply-To: <4DEC0234.8030300@gmail.com> References: <4DD365A2.3090106@gmail.com> <20110518100203.7bfa63be@gmail.com> <4DEC0234.8030300@gmail.com> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Jun 2011 23:48:28 -0000 Hi folks, On Sun, 05 Jun 2011 15:24:52 -0700 Matt wrote: > On 05/18/11 00:36, Adrian Chadd wrote: > > On 18 May 2011 15:02, Sergey V. Dyatko > > wrote: > > > >> As far I know Alexandr is too busy now (ported fbsd into one of > >> d-link device). Hi have plans port ral code from openbsd. IIRC it > >> was discussed not so long ago, in current@ > > This thread reads to me like "hi, would someone like to pick up > > Alex's work, liase with Alex/Bernhard, and bring the code up to > > scratch so we can commit it to FreeBSD". > > > > Matt, how's your C? :) > > > > > > Adrian > > > I've successfully got Alexandr's code worked into the Ral driver. > This mainly involved some changes to if_ral_pci.c, renaming some > softc stuff and pulling PCI code out of rt2860_attach. Must say, that code not mine, wrote by Alexander Egorenkov (based on OpenBSD one) + OpenBSD part for 3090 (but seems w/o LEDs :) ) and plus my part for wireless embedded into SoC like RT3052F. > > It's stable so far, WPA2 works fine as does Host AP etc (haven't > tried with encryption). I haven't tested AHdemo, I assume monitor > mode works. > > I want to eventually go through and place some chip specific fixes > for 3090 etc., and possibly compare functions between different > sources and make sure we're doing it right. > > Some questions: > 1) If I kldunload if_ral while associated and flood pinging, I get > "no route" for a while and then a page fault (only bug I've found so > far). I assume this is something dumb I've done during detach? > > 2) My LED does not work. I have this in a Thinkpad WWAN slot, which > are known to have issues with LED on some chips. A broadcom 4321 did > activate the led in this slot. Can anyone confirm if they had a > working LED using Alexandr's RT2860 stand alone driver? Or does work > on LED code need to occur? > > Cheers, I'll remove my ugly printfs and post a patch or tarball later > today. Anyway, we (Adrian, Bernhard, PseudoCylon and me) discuss what there is preferred to port current version of OpenBSD `ral` driver, and keep it sync in future. But only one problem here, we all don't have time right now for that :) > > Matt I hope someone found a time for it :) WBW -- Aleksandr Rybalko From owner-freebsd-wireless@FreeBSD.ORG Mon Jun 6 01:42:12 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2C39106566B for ; Mon, 6 Jun 2011 01:42:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B31C58FC08 for ; Mon, 6 Jun 2011 01:42:12 +0000 (UTC) Received: by gyg13 with SMTP id 13so2034429gyg.13 for ; Sun, 05 Jun 2011 18:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=Pg1fSmlpBoxMvQS8do6VvrstMbP1FqquFYoy4A9/tws=; b=OH/ncN+ELjhnoQyCBXOXUD76ki2wJmm8dZNNywvArUeBV7cRNe9rEop6xG9EwYV82V j3g8+/WHtgSGW6LzjjgbqaRwtuEdkNKel2HmYSuVqxmfomt9G3doRoGgWjLhvV303Rjb kfmeiG580F6Ue+hmi1Akgh+y9LC9UXgLYUYOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Sxg7j+WktNMna54xEV6srEyxHRX8vy6cGWPQRkfDkB2e7BtI2QOndFfFM4qJZfZDKD tVvKw33h+qrnnqY3TNr10JDFa3x3azEBrk/BPdGAGcWFJWtEMtKBtGK06JLvig9iY3xe vbWVsfCrJlirucX38UKSwp2ttgZ/wN4sHmHx4= MIME-Version: 1.0 Received: by 10.150.72.30 with SMTP id u30mr3835616yba.14.1307324531726; Sun, 05 Jun 2011 18:42:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.107.15 with HTTP; Sun, 5 Jun 2011 18:42:11 -0700 (PDT) Date: Mon, 6 Jun 2011 09:42:11 +0800 X-Google-Sender-Auth: nSA1jiMlzRvhAi_PP7ayS1-qe64 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: wishlist: wpa_supplicant should pay attention to the currently forced SSID? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2011 01:42:13 -0000 Hi, Something that keeps irking me is that wpa_supplicant will try scanning its config file in order and fail to associate to ssids that don't match the one which is hard-coded. I hard-code SSIDs so I can force the network I'm associating to, without having to reconfigure wpa_supplicant. Is this intended behaviour? Is there another easy way to tell wpa_supplicant what to associate to? Or could we modify wpa_supplicant to only try assocating to APs that match the currently configured SSID? Thanks, Adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Jun 6 06:11:07 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C363E106564A; Mon, 6 Jun 2011 06:11:07 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9848FC1A; Mon, 6 Jun 2011 06:11:07 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id AB5D2CA; Mon, 6 Jun 2011 08:11:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gQh0R3SkGFSz; Mon, 6 Jun 2011 08:11:00 +0200 (CEST) Received: from snifi.laptop (178-36-172-104.adsl.inetia.pl [178.36.172.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id 3C8FC8F; Mon, 6 Jun 2011 08:11:00 +0200 (CEST) From: Maciej Milewski To: freebsd-wireless@freebsd.org Date: Mon, 6 Jun 2011 08:10:56 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-CURRENT; KDE/4.6.3; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106060810.57656.milu@dat.pl> Cc: Subject: Re: wishlist: wpa_supplicant should pay attention to the currently forced SSID? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2011 06:11:07 -0000 On Monday 06 of June 2011 03:42:11 Adrian Chadd wrote: > Hi, > > Something that keeps irking me is that wpa_supplicant will try > scanning its config file in order and fail to associate to ssids that > don't match the one which is hard-coded. > > I hard-code SSIDs so I can force the network I'm associating to, > without having to reconfigure wpa_supplicant. > > Is this intended behaviour? Is there another easy way to tell > wpa_supplicant what to associate to? Or could we modify wpa_supplicant > to only try assocating to APs that match the currently configured > SSID? > > Thanks, > > > Adrian Hi Adrian, The only thing which I found useful at current state is: # priority: priority group (integer) # By default, all networks will get same priority group (0). If some of the # networks are more desirable, this field can be used to change the order in # which wpa_supplicant goes through the networks when selecting a BSS. The # priority groups will be iterated in decreasing priority (i.e., the larger the # priority value, the sooner the network is matched against the scan results). # Within each priority group, networks will be selected based on security # policy, signal strength, etc. # Please note that AP scanning with scan_ssid=1 is not using this priority to # select the order for scanning. Instead, it uses the order the networks are in # the configuration file. It's not 100% what you need but may be enough in some cases. Additional setting is: # AP scanning/selection # By default, wpa_supplicant requests driver to perform AP scanning and then # uses the scan results to select a suitable AP. Another alternative is to # allow the driver to take care of AP scanning and selection and use # wpa_supplicant just to process EAPOL frames based on IEEE 802.11 association # information from the driver. # 1: wpa_supplicant initiates scanning and AP selection # 0: driver takes care of scanning, AP selection, and IEEE 802.11 association # parameters (e.g., WPA IE generation); this mode can also be used with # non-WPA drivers when using IEEE 802.1X mode; do not try to associate with # APs (i.e., external program needs to control association). This mode must # also be used when using wired Ethernet drivers. # 2: like 0, but associate with APs using security policy and SSID (but not # BSSID); this can be used, e.g., with ndiswrapper and NDIS driver to # enable operation with hidden SSIDs and optimized roaming; in this mode, # only the first network block in the configuration file is used and this # configuration should have explicit security policy (i.e., only one option # in the lists) for key_mgmt, pairwise, group, proto variables I admit that I haven't been using this on FreeBSD but used this in tha past on Linux STA's. Maciek From owner-freebsd-wireless@FreeBSD.ORG Mon Jun 6 07:45:39 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6787D106564A for ; Mon, 6 Jun 2011 07:45:39 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC2158FC0A for ; Mon, 6 Jun 2011 07:45:38 +0000 (UTC) Received: by bwz12 with SMTP id 12so4704201bwz.13 for ; Mon, 06 Jun 2011 00:45:37 -0700 (PDT) Received: by 10.204.75.40 with SMTP id w40mr4430240bkj.12.1307346337612; Mon, 06 Jun 2011 00:45:37 -0700 (PDT) Received: from jessie.localnet (p5B2ECC05.dip0.t-ipconnect.de [91.46.204.5]) by mx.google.com with ESMTPS id t23sm3122093bkf.4.2011.06.06.00.45.36 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 00:45:36 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Date: Mon, 6 Jun 2011 09:43:50 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <201106060810.57656.milu@dat.pl> In-Reply-To: <201106060810.57656.milu@dat.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106060944.16002.bschmidt@freebsd.org> Cc: Subject: Re: wishlist: wpa_supplicant should pay attention to the currently forced SSID? X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org 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, 06 Jun 2011 07:45:39 -0000 On Monday, June 06, 2011 08:10:56 Maciej Milewski wrote: > On Monday 06 of June 2011 03:42:11 Adrian Chadd wrote: > > Hi, > > > > Something that keeps irking me is that wpa_supplicant will try > > scanning its config file in order and fail to associate to ssids that > > don't match the one which is hard-coded. > > > > I hard-code SSIDs so I can force the network I'm associating to, > > without having to reconfigure wpa_supplicant. > > > > Is this intended behaviour? Is there another easy way to tell > > wpa_supplicant what to associate to? Or could we modify wpa_supplicant > > to only try assocating to APs that match the currently configured > > SSID? That would be a bug actually. wpa_supplicant tries its best to get rid of as much as pre-configured stuff as possible, so it can just do its thing. > > Thanks, > > > > > > Adrian > Hi Adrian, > > The only thing which I found useful at current state is: > > # priority: priority group (integer) > # By default, all networks will get same priority group (0). If some of the > # networks are more desirable, this field can be used to change the order in > # which wpa_supplicant goes through the networks when selecting a BSS. The > # priority groups will be iterated in decreasing priority (i.e., the larger > the > # priority value, the sooner the network is matched against the scan results). > # Within each priority group, networks will be selected based on security > # policy, signal strength, etc. > # Please note that AP scanning with scan_ssid=1 is not using this priority to > # select the order for scanning. Instead, it uses the order the networks are > in > # the configuration file. > > It's not 100% what you need but may be enough in some cases. There is also wpa_cli, which should allow you to select the network to which you want to connect. > Additional setting is: > > # AP scanning/selection > # By default, wpa_supplicant requests driver to perform AP scanning and then > # uses the scan results to select a suitable AP. Another alternative is to > # allow the driver to take care of AP scanning and selection and use > # wpa_supplicant just to process EAPOL frames based on IEEE 802.11 association > # information from the driver. > # 1: wpa_supplicant initiates scanning and AP selection > # 0: driver takes care of scanning, AP selection, and IEEE 802.11 association > # parameters (e.g., WPA IE generation); this mode can also be used with > # non-WPA drivers when using IEEE 802.1X mode; do not try to associate with > # APs (i.e., external program needs to control association). This mode must > # also be used when using wired Ethernet drivers. > # 2: like 0, but associate with APs using security policy and SSID (but not > # BSSID); this can be used, e.g., with ndiswrapper and NDIS driver to > # enable operation with hidden SSIDs and optimized roaming; in this mode, > # only the first network block in the configuration file is used and this > # configuration should have explicit security policy (i.e., only one option > # in the lists) for key_mgmt, pairwise, group, proto variables > > I admit that I haven't been using this on FreeBSD but used this in tha past on > Linux STA's. And you shouldn't use it on FreeBSD ;) ap_scan should always be 1 (except one special case which I consider a bug, adhoc). -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Mon Jun 6 11:07:18 2011 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2D371065673 for ; Mon, 6 Jun 2011 11:07:18 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A0DDF8FC15 for ; Mon, 6 Jun 2011 11:07:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p56B7Ito037796 for ; Mon, 6 Jun 2011 11:07:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p56B7I5V037794 for freebsd-wireless@FreeBSD.org; Mon, 6 Jun 2011 11:07:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jun 2011 11:07:18 GMT Message-Id: <201106061107.p56B7I5V037794@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-wireless@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2011 11:07:18 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/157449 wireless [ath] MAC address conflict causes system to freeze o kern/157243 wireless [ath] investigate beacon TX (AP) / RX (STA) when under o kern/156904 wireless [ath] AR9285 antenna diversity algorithm is buggy and o kern/156884 wireless [ath] ath instablity o kern/156327 wireless [bwn] bwn driver causes 20%-50% packet loss o kern/156322 wireless [wpi] no ahdemo support for if_wpi o kern/156321 wireless [ath] ahdemo doesn't work with if_ath o kern/155100 wireless [ath] ath driver on busy channel: "stuck beacon" p kern/154598 wireless [ath] Atheros 5424/2424 can't connect to WPA network o kern/154567 wireless [ath] ath(4) lot of bad series(0) o kern/154327 wireless [ath] AR5416 in station mode hangs when transmitting f o kern/154284 wireless [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154153 wireless [ath] AR5213 + MIPS + WPA group key packet corruption o kern/153448 wireless [ath] ath networking device loses association after a o kern/152750 wireless [ath] ath0 lot of bad series hwrate o kern/151198 wireless [ath] ath/5416 fails bgscan with "ath0: ath_chan_set: o kern/149786 wireless [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149516 wireless [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 wireless [realtek/atheros]: None of my network card working o kern/149307 wireless [ath] Doesn't work Atheros 9285 o kern/148322 wireless [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 wireless [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148112 wireless [ath] Atheros 9285 cannot register with wifi AP (timeo o kern/148078 wireless [ath] wireless networking stops functioning o kern/145826 wireless [panic] [ath] Unable to configure adhoc mode on ath0/w o kern/144987 wireless [wpi] [panic] injecting packets with wlaninject using o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o kern/143868 wireless [ath] [patch] [request] allow Atheros watchdog timeout o conf/143079 wireless hostapd(8) startup missing multi wlan functionality o kern/140796 wireless [ath] [panic] Cannot attach (unable to attach hardware p kern/140567 wireless [ath] [patch] ath is not worked on my notebook PC o kern/140245 wireless [ath] [panic] Kernel panic during network activity on o kern/137592 wireless [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne p bin/137484 wireless [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/136943 wireless [wpi] [lor] wpi0_com_lock / wpi0 o kern/136836 wireless [ath] atheros card stops functioning after about 12 ho o kern/132722 wireless [ath] Wifi ath0 associates fine with AP, but DHCP or I o bin/131549 wireless ifconfig(8) can't clear 'monitor' mode on the wireless o kern/126475 wireless [ath] [panic] ath pcmcia card inevitably panics under o kern/125721 wireless [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 wireless [ath] [panic] ath(4) related panic o kern/125501 wireless [ath] atheros cardbus driver hangs o kern/125332 wireless [ath] [panic] crash under any non-tiny networking unde o kern/124767 wireless [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 wireless [ieee80211] net80211 discards power-save queue packets o docs/120456 wireless ath(4) needs to specify requirement on wlan_scan_sta o kern/119513 wireless [ath] [irq] inserting dlink dwl-g630 wireless card res o kern/116747 wireless [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile f kern/105348 wireless [ath] ath device stopps TX 49 problems total. From owner-freebsd-wireless@FreeBSD.ORG Tue Jun 7 00:53:53 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 383A61065672 for ; Tue, 7 Jun 2011 00:53:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 073138FC08 for ; Tue, 7 Jun 2011 00:53:52 +0000 (UTC) Received: by pxi6 with SMTP id 6so2911311pxi.17 for ; Mon, 06 Jun 2011 17:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yvBAxE34uLe9xZD2vjBN+2ehwC8NdHN5PiMdEAFteP4=; b=wM1JsYJrX5tn/6s8SIXN44Y+DdiJQLjcVUkCeB4rkfbtLFLSq9FSmXAWvXra6mSq7t fnWM+tAhPgAEfEI5uUBwU0rdQ52ra9aI3rToAII4WQDWmUusDJ2p7vVBxluqL/aPrFkg gr4rZkbWBNUDD8M0wUmz232KzlUV9YhNz4ahM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=suucAr489EBoW9IfWtX5PjfXVRfTlrKouG7oeHT3dM9L69AlQbMEOAAOhN06IGB0eU eX3jmaj/MgXtLRPSWL5k0ZIbrtiEAoh7QkuGGwUWmLJO0PpmY8UYE95vDoQ8bRGraow7 Zuckx/FqN14EtCs+Weot5xSwbQ1axCJzSqC9E= Received: by 10.68.65.78 with SMTP id v14mr13470pbs.204.1307408032403; Mon, 06 Jun 2011 17:53:52 -0700 (PDT) Received: from sidhe.local ([75.111.37.204]) by mx.google.com with ESMTPS id k4sm4054308pbl.75.2011.06.06.17.53.49 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 17:53:50 -0700 (PDT) Message-ID: <4DED769A.6040405@gmail.com> Date: Mon, 06 Jun 2011 17:53:46 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: Aleksandr Rybalko References: <4DD365A2.3090106@gmail.com> <20110518100203.7bfa63be@gmail.com> <4DEC0234.8030300@gmail.com> <20110606022257.39093142.ray@ddteam.net> In-Reply-To: <20110606022257.39093142.ray@ddteam.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2011 00:53:53 -0000 On 06/05/11 16:22, Aleksandr Rybalko wrote: > Hi folks, > > On Sun, 05 Jun 2011 15:24:52 -0700 > Matt wrote: > >> On 05/18/11 00:36, Adrian Chadd wrote: >>> On 18 May 2011 15:02, Sergey V. Dyatko >>> wrote: >>> >>>> As far I know Alexandr is too busy now (ported fbsd into one of >>>> d-link device). Hi have plans port ral code from openbsd. IIRC it >>>> was discussed not so long ago, in current@ >>> This thread reads to me like "hi, would someone like to pick up >>> Alex's work, liase with Alex/Bernhard, and bring the code up to >>> scratch so we can commit it to FreeBSD". >>> >>> Matt, how's your C? :) >>> >>> >>> Adrian >>> >> I've successfully got Alexandr's code worked into the Ral driver. >> This mainly involved some changes to if_ral_pci.c, renaming some >> softc stuff and pulling PCI code out of rt2860_attach. > Must say, that code not mine, wrote by Alexander Egorenkov (based on > OpenBSD one) + OpenBSD part for 3090 (but seems w/o LEDs :) ) and plus > my part for wireless embedded into SoC like RT3052F. > >> It's stable so far, WPA2 works fine as does Host AP etc (haven't >> tried with encryption). I haven't tested AHdemo, I assume monitor >> mode works. >> >> I want to eventually go through and place some chip specific fixes >> for 3090 etc., and possibly compare functions between different >> sources and make sure we're doing it right. >> >> Some questions: >> 1) If I kldunload if_ral while associated and flood pinging, I get >> "no route" for a while and then a page fault (only bug I've found so >> far). I assume this is something dumb I've done during detach? >> >> 2) My LED does not work. I have this in a Thinkpad WWAN slot, which >> are known to have issues with LED on some chips. A broadcom 4321 did >> activate the led in this slot. Can anyone confirm if they had a >> working LED using Alexandr's RT2860 stand alone driver? Or does work >> on LED code need to occur? >> >> Cheers, I'll remove my ugly printfs and post a patch or tarball later >> today. > Anyway, we (Adrian, Bernhard, PseudoCylon and me) discuss what there is > preferred to port current version of OpenBSD `ral` driver, and keep it > sync in future. But only one problem here, we all don't have time > right now for that :) > >> Matt > I hope someone found a time for it :) > > WBW Well, in anycase here is the patch I made for Ral. If no one wants to work on trying to port OpenBSD ral, I can try, but I am still learning very much! http://pastebin.com/GeAGVjtR Please add manually rt2860.c to Makefile @ /usr/src/sys/modules/ral/Makefile Note about patch, it's still alpha quality in that it has a known bug (do not kldunload while interface is running!) and it is largely untested. Changes include softc, pci code & all functions put in monolithic file (to help compare against OpenBSD ral, mainly). They are in the wrong order for now, however. Ultimate plan was to compare side-by-side with OpenBSD ral to assist porting. There is still an "ecosystem" of includes per rt2860 original, didn't get around to combining them. From owner-freebsd-wireless@FreeBSD.ORG Tue Jun 7 01:26:14 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DEDE106566B for ; Tue, 7 Jun 2011 01:26:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA7EE8FC17 for ; Tue, 7 Jun 2011 01:26:13 +0000 (UTC) Received: by gxk28 with SMTP id 28so2574958gxk.13 for ; Mon, 06 Jun 2011 18:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3s6fHlRjsH5wLWy1tFOmY2sNGsrj+VvzyqEV0e4xkjA=; b=cI0wD2KFk69tOp5IwxaMq1J3PneMuLDXoMvz+lKDozBc18ks3QRfYTUX/yXb/4wX3E E8JTmbTqHNzZ2mrAG27FcSWdxn3Ln9ZiwRL5lYuCN469GCfQbOQHb9ukD6excyOzggCP kEU8Ps0+gnZkKk+c+K1CS1+QHyFb6VRpNro6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tregYVAIV4OCsfqFS1PvgtWztTj7z/tStAfWzOQDM5Egxcc2DtupKtgCRIZ5rA+pMk op7VuNJSpOG8X7F9c47A8k3zHuN0Yy/xVUBnHeNu5yWpVOWAExJJKfHEpKOMaeqSb95I WeakBAGbPPuKANGcE49/ZlxqGuAceTm2iZAV0= MIME-Version: 1.0 Received: by 10.150.163.17 with SMTP id l17mr1092808ybe.71.1307409972985; Mon, 06 Jun 2011 18:26:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.107.15 with HTTP; Mon, 6 Jun 2011 18:26:12 -0700 (PDT) In-Reply-To: <4DED769A.6040405@gmail.com> References: <4DD365A2.3090106@gmail.com> <20110518100203.7bfa63be@gmail.com> <4DEC0234.8030300@gmail.com> <20110606022257.39093142.ray@ddteam.net> <4DED769A.6040405@gmail.com> Date: Tue, 7 Jun 2011 09:26:12 +0800 X-Google-Sender-Auth: biqR4igAwMg1Lg8bJtpoVzRkueY Message-ID: From: Adrian Chadd To: Matt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2011 01:26:14 -0000 On 7 June 2011 08:53, Matt wrote: > > Well, in anycase here is the patch I made for Ral. If no one wants to work > on trying to port OpenBSD ral, I can try, but I am still learning very much! > > http://pastebin.com/GeAGVjtR That's great work! > Please add manually rt2860.c to Makefile @ /usr/src/sys/modules/ral/Makefile > > Note about patch, it's still alpha quality in that it has a known bug (do > not kldunload while interface is running!) and it is largely untested. > Changes include softc, pci code & all functions put in monolithic file (to > help compare against OpenBSD ral, mainly). They are in the wrong order for > now, however. Ultimate plan was to compare side-by-side with OpenBSD ral to > assist porting. > > There is still an "ecosystem" of includes per rt2860 original, didn't get > around to combining them. Well, I'm all for throwing this in if Matt's up for helping debug and look after it in the meantime. I gather the long-term goal is to update to the OpenBSD driver but this seems like a good middle-step, no? Adrian From owner-freebsd-wireless@FreeBSD.ORG Tue Jun 7 01:50:19 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1945D106564A; Tue, 7 Jun 2011 01:50:19 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id D459B8FC14; Tue, 7 Jun 2011 01:50:18 +0000 (UTC) Received: by pxi6 with SMTP id 6so2936603pxi.17 for ; Mon, 06 Jun 2011 18:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FpCNjhzZMJWuwGjpb7DeU1f9ACohrclocSc2lqJiIyI=; b=N+QoE11TT1owk83JYKuOOS7oZkeXFk4tx2eKDmRAfZqGd0KBt2GkHkCqKU9FWOf6Hb a8pi9eCLDo/uOQnhFC+mGmUAj3VoOdiArEg8DwZA4s2xK3PcFdrlYTK/xw6OFodWcVyE lOOERXV5DqmU+WPN1OJbRyrjB/WcY6LTHo00o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=H/iXbjS2kDCaiVkvFHiF039CB/A1ry7M9rNIPhwNGImWW8I1iXtwIHAHp7zs6v+kpE xp5n1uyGjGF9p6mymACXfvNqCBUK94oJEZwlYqKKHjbXgAlNdi8FxVdFM2pBcpTce4dy mvRMn+86Ep9iQE75rI524fbwBdZFuX6QcQ5do= Received: by 10.68.36.69 with SMTP id o5mr27085pbj.74.1307411418317; Mon, 06 Jun 2011 18:50:18 -0700 (PDT) Received: from sidhe.local ([75.111.37.204]) by mx.google.com with ESMTPS id x1sm4090833pbb.34.2011.06.06.18.50.16 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 18:50:17 -0700 (PDT) Message-ID: <4DED83D6.3020805@gmail.com> Date: Mon, 06 Jun 2011 18:50:14 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: Adrian Chadd References: <4DD365A2.3090106@gmail.com> <20110518100203.7bfa63be@gmail.com> <4DEC0234.8030300@gmail.com> <20110606022257.39093142.ray@ddteam.net> <4DED769A.6040405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2011 01:50:19 -0000 On 06/06/11 18:26, Adrian Chadd wrote: > On 7 June 2011 08:53, Matt wrote: > >> Well, in anycase here is the patch I made for Ral. If no one wants to work >> on trying to port OpenBSD ral, I can try, but I am still learning very much! >> >> http://pastebin.com/GeAGVjtR > That's great work! > >> Please add manually rt2860.c to Makefile @ /usr/src/sys/modules/ral/Makefile >> >> Note about patch, it's still alpha quality in that it has a known bug (do >> not kldunload while interface is running!) and it is largely untested. >> Changes include softc, pci code& all functions put in monolithic file (to >> help compare against OpenBSD ral, mainly). They are in the wrong order for >> now, however. Ultimate plan was to compare side-by-side with OpenBSD ral to >> assist porting. >> >> There is still an "ecosystem" of includes per rt2860 original, didn't get >> around to combining them. > Well, I'm all for throwing this in if Matt's up for helping debug and > look after it in the meantime. > > I gather the long-term goal is to update to the OpenBSD driver but > this seems like a good middle-step, no? > > > Adrian > I didn't touch much in the actual "talks to hardware" part. I did however end up needing to change quite a bit in softc and steal parts of OpenBSD & Alexander's attach. Probably Alexander's copyright line from rt2860.c needs to be copied to if_ral_pci.c due to inclusion of vendor id detection and softc/opns assignment. Is there any value in condensing the includes to match the other devices? I can do this and touch up copyrights (there is some code from rt2860_pci.c that made it into if_ral_pci.c). If anyone with good eyes can look and make sure mutexes and memory are handled as sanely as possible, I'd appreciate it. I will make a new patch with some sanity changes, the LNA gain fix (there should only be one LNA per antenna needed, I think?) & some other hardware specific cases, as well as any fixes anyone notices in the next few days. Glad I can contribute to a very great operating system. I promise to read kernel normal style! Thanks Matt ("In The Hat", for disambiguation :) From owner-freebsd-wireless@FreeBSD.ORG Tue Jun 7 06:13:22 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5A70106564A for ; Tue, 7 Jun 2011 06:13:22 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5084D8FC08 for ; Tue, 7 Jun 2011 06:13:21 +0000 (UTC) Received: by bwz12 with SMTP id 12so5905760bwz.13 for ; Mon, 06 Jun 2011 23:13:20 -0700 (PDT) Received: by 10.204.39.68 with SMTP id f4mr5905712bke.17.1307427200238; Mon, 06 Jun 2011 23:13:20 -0700 (PDT) Received: from jessie.localnet (p5B2ECAB1.dip0.t-ipconnect.de [91.46.202.177]) by mx.google.com with ESMTPS id x6sm3868040bkv.0.2011.06.06.23.13.18 (version=SSLv3 cipher=OTHER); Mon, 06 Jun 2011 23:13:18 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Date: Tue, 7 Jun 2011 08:11:55 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <4DD365A2.3090106@gmail.com> <20110606022257.39093142.ray@ddteam.net> <4DED769A.6040405@gmail.com> In-Reply-To: <4DED769A.6040405@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106070811.56236.bschmidt@freebsd.org> Cc: Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org 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, 07 Jun 2011 06:13:22 -0000 On Tuesday, June 07, 2011 02:53:46 Matt wrote: > On 06/05/11 16:22, Aleksandr Rybalko wrote: > > Hi folks, > > > > On Sun, 05 Jun 2011 15:24:52 -0700 > > Matt wrote: > > > >> On 05/18/11 00:36, Adrian Chadd wrote: > >>> On 18 May 2011 15:02, Sergey V. Dyatko > >>> wrote: > >>> > >>>> As far I know Alexandr is too busy now (ported fbsd into one of > >>>> d-link device). Hi have plans port ral code from openbsd. IIRC it > >>>> was discussed not so long ago, in current@ > >>> This thread reads to me like "hi, would someone like to pick up > >>> Alex's work, liase with Alex/Bernhard, and bring the code up to > >>> scratch so we can commit it to FreeBSD". > >>> > >>> Matt, how's your C? :) > >>> > >>> > >>> Adrian > >>> > >> I've successfully got Alexandr's code worked into the Ral driver. > >> This mainly involved some changes to if_ral_pci.c, renaming some > >> softc stuff and pulling PCI code out of rt2860_attach. > > Must say, that code not mine, wrote by Alexander Egorenkov (based on > > OpenBSD one) + OpenBSD part for 3090 (but seems w/o LEDs :) ) and plus > > my part for wireless embedded into SoC like RT3052F. > > > >> It's stable so far, WPA2 works fine as does Host AP etc (haven't > >> tried with encryption). I haven't tested AHdemo, I assume monitor > >> mode works. > >> > >> I want to eventually go through and place some chip specific fixes > >> for 3090 etc., and possibly compare functions between different > >> sources and make sure we're doing it right. > >> > >> Some questions: > >> 1) If I kldunload if_ral while associated and flood pinging, I get > >> "no route" for a while and then a page fault (only bug I've found so > >> far). I assume this is something dumb I've done during detach? > >> > >> 2) My LED does not work. I have this in a Thinkpad WWAN slot, which > >> are known to have issues with LED on some chips. A broadcom 4321 did > >> activate the led in this slot. Can anyone confirm if they had a > >> working LED using Alexandr's RT2860 stand alone driver? Or does work > >> on LED code need to occur? > >> > >> Cheers, I'll remove my ugly printfs and post a patch or tarball later > >> today. > > Anyway, we (Adrian, Bernhard, PseudoCylon and me) discuss what there is > > preferred to port current version of OpenBSD `ral` driver, and keep it > > sync in future. But only one problem here, we all don't have time > > right now for that :) > > > >> Matt > > I hope someone found a time for it :) > > > > WBW > Well, in anycase here is the patch I made for Ral. If no one wants to > work on trying to port OpenBSD ral, I can try, but I am still learning > very much! > > http://pastebin.com/GeAGVjtR > > Please add manually rt2860.c to Makefile @ /usr/src/sys/modules/ral/Makefile > > Note about patch, it's still alpha quality in that it has a known bug > (do not kldunload while interface is running!) and it is largely > untested. Changes include softc, pci code & all functions put in > monolithic file (to help compare against OpenBSD ral, mainly). They are > in the wrong order for now, however. Ultimate plan was to compare > side-by-side with OpenBSD ral to assist porting. > > There is still an "ecosystem" of includes per rt2860 original, didn't > get around to combining them. Doesn't look bad at first glance, thx! At least the if_ral_pci.c part looks like I'd have done it. ;) Do you have some unified diff also? I'd take a closer look then, maybe we can get that into the tree. -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Tue Jun 7 22:01:53 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE782106564A; Tue, 7 Jun 2011 22:01:53 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B73A98FC0A; Tue, 7 Jun 2011 22:01:53 +0000 (UTC) Received: by pxi6 with SMTP id 6so3597262pxi.17 for ; Tue, 07 Jun 2011 15:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t1fIEyPsVdb4DHbqBtF7in4DnaKGkgBDaMNfSdyCink=; b=ZSzVUoX7VemPJFqO9mhNofWxtrtgCtbQ9P0fIdk4G9WwkpB0kq7RE3cbcU+36aI6T7 ApaOPC36zh/6jgI4paDsL0l5Kdwuq0aN+SEa//J4CN/AF9PvHjYY4w4D3w48drkJlaIS YQusCwwc6B4UHuvz0CGznj/Hm87DjoKRUU3lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LLwm5hyJW509+PNWyB/udnAsH/qs4pFL9pJTEa/8GB9Z2WIv3fMb8GNWzhW4iTXWKx sdQfudJAQWnV/AqLcI+CtiYEZH56vYD7sLDC13uQilWfsRT8EjMsEAW9gKrIXRWIfkzJ 8htat6yLUIBNyNjbHP4xUW92yMMYWT3ngtvqc= Received: by 10.142.201.7 with SMTP id y7mr189396wff.82.1307484113206; Tue, 07 Jun 2011 15:01:53 -0700 (PDT) Received: from sidhe.local ([75.101.87.90]) by mx.google.com with ESMTPS id k9sm589546pbc.86.2011.06.07.15.01.50 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 15:01:51 -0700 (PDT) Message-ID: <4DEE9FCA.7030302@gmail.com> Date: Tue, 07 Jun 2011 15:01:46 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: bschmidt@freebsd.org References: <4DD365A2.3090106@gmail.com> <20110606022257.39093142.ray@ddteam.net> <4DED769A.6040405@gmail.com> <201106070811.56236.bschmidt@freebsd.org> In-Reply-To: <201106070811.56236.bschmidt@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: Ralink RT3090/RT2860 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2011 22:01:54 -0000 On 06/06/11 23:11, Bernhard Schmidt wrote: > On Tuesday, June 07, 2011 02:53:46 Matt wrote: >> On 06/05/11 16:22, Aleksandr Rybalko wrote: >>> Hi folks, >>> >>> On Sun, 05 Jun 2011 15:24:52 -0700 >>> Matt wrote: >>> >>>> On 05/18/11 00:36, Adrian Chadd wrote: >>>>> On 18 May 2011 15:02, Sergey V. Dyatko >>>>> wrote: >>>>> >>>>>> As far I know Alexandr is too busy now (ported fbsd into one of >>>>>> d-link device). Hi have plans port ral code from openbsd. IIRC it >>>>>> was discussed not so long ago, in current@ >>>>> This thread reads to me like "hi, would someone like to pick up >>>>> Alex's work, liase with Alex/Bernhard, and bring the code up to >>>>> scratch so we can commit it to FreeBSD". >>>>> >>>>> Matt, how's your C? :) >>>>> >>>>> >>>>> Adrian >>>>> >>>> I've successfully got Alexandr's code worked into the Ral driver. >>>> This mainly involved some changes to if_ral_pci.c, renaming some >>>> softc stuff and pulling PCI code out of rt2860_attach. >>> Must say, that code not mine, wrote by Alexander Egorenkov (based on >>> OpenBSD one) + OpenBSD part for 3090 (but seems w/o LEDs :) ) and plus >>> my part for wireless embedded into SoC like RT3052F. >>> >>>> It's stable so far, WPA2 works fine as does Host AP etc (haven't >>>> tried with encryption). I haven't tested AHdemo, I assume monitor >>>> mode works. >>>> >>>> I want to eventually go through and place some chip specific fixes >>>> for 3090 etc., and possibly compare functions between different >>>> sources and make sure we're doing it right. >>>> >>>> Some questions: >>>> 1) If I kldunload if_ral while associated and flood pinging, I get >>>> "no route" for a while and then a page fault (only bug I've found so >>>> far). I assume this is something dumb I've done during detach? >>>> >>>> 2) My LED does not work. I have this in a Thinkpad WWAN slot, which >>>> are known to have issues with LED on some chips. A broadcom 4321 did >>>> activate the led in this slot. Can anyone confirm if they had a >>>> working LED using Alexandr's RT2860 stand alone driver? Or does work >>>> on LED code need to occur? >>>> >>>> Cheers, I'll remove my ugly printfs and post a patch or tarball later >>>> today. >>> Anyway, we (Adrian, Bernhard, PseudoCylon and me) discuss what there is >>> preferred to port current version of OpenBSD `ral` driver, and keep it >>> sync in future. But only one problem here, we all don't have time >>> right now for that :) >>> >>>> Matt >>> I hope someone found a time for it :) >>> >>> WBW >> Well, in anycase here is the patch I made for Ral. If no one wants to >> work on trying to port OpenBSD ral, I can try, but I am still learning >> very much! >> >> http://pastebin.com/GeAGVjtR >> >> Please add manually rt2860.c to Makefile @ /usr/src/sys/modules/ral/Makefile >> >> Note about patch, it's still alpha quality in that it has a known bug >> (do not kldunload while interface is running!) and it is largely >> untested. Changes include softc, pci code& all functions put in >> monolithic file (to help compare against OpenBSD ral, mainly). They are >> in the wrong order for now, however. Ultimate plan was to compare >> side-by-side with OpenBSD ral to assist porting. >> >> There is still an "ecosystem" of includes per rt2860 original, didn't >> get around to combining them. > Doesn't look bad at first glance, thx! At least the if_ral_pci.c > part looks like I'd have done it. ;) > > Do you have some unified diff also? I'd take a closer look then, > maybe we can get that into the tree. > I'll make unified diffs tonight...that's diff -u oldfile newfile >> bigpatch.patch, right? I'll keep hacking some changes into it...it sounds like LEDs never worked on x86/amd64 non-embedded platforms? It complains about extension channels some as well, so I may see what that's about. Thanks all! Matt In the Hat From owner-freebsd-wireless@FreeBSD.ORG Fri Jun 10 07:15:15 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24AB106566B for ; Fri, 10 Jun 2011 07:15:15 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFDC8FC16 for ; Fri, 10 Jun 2011 07:15:14 +0000 (UTC) Received: by bwz12 with SMTP id 12so2788418bwz.13 for ; Fri, 10 Jun 2011 00:15:13 -0700 (PDT) Received: by 10.204.154.74 with SMTP id n10mr1552411bkw.33.1307690111949; Fri, 10 Jun 2011 00:15:11 -0700 (PDT) Received: from jessie.localnet (p5B2EC7C2.dip0.t-ipconnect.de [91.46.199.194]) by mx.google.com with ESMTPS id g2sm2271770bkz.23.2011.06.10.00.15.10 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 00:15:10 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Jim Bryant Date: Fri, 10 Jun 2011 09:12:47 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.32-32-generic; KDE/4.4.5; i686; ; ) References: <4DF12E4A.5020906@gmail.com> In-Reply-To: <4DF12E4A.5020906@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201106100913.42480.bschmidt@freebsd.org> Cc: weongyo@freebsd.org, freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: problem with urtw X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org 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, 10 Jun 2011 07:15:15 -0000 On Thursday, June 09, 2011 22:34:18 Jim Bryant wrote: > I just bought one of those chinese (apparently the same unit relabeled > and being sold by multiple companies) realtek RTL8187B wifi units. The > price is right. > > The label name on this one is WiFySky 1500mW. > > other than the fact that the case it is enclosed in is really cheesy, > there is a more immediate problem with this. > > the current urtw driver returns a 6. > > here we go: > > on insert: > > ugen3.2: at usbus3 > > after kldload if_urtw.ko: > > urtw0: > on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > urtw0: > on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > urtw0: > on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > urtw0: > on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > > 3:28:35pm argus(48): usbconfig -u 3 -a 2 dump_device_desc > ugen3.2: at usbus3, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x0000 > bDeviceSubClass = 0x0000 > bDeviceProtocol = 0x0000 > bMaxPacketSize0 = 0x0040 > idVendor = 0x0bda > idProduct = 0x8187 > bcdDevice = 0x0200 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0000 > bNumConfigurations = 0x0001 > > 3:28:48pm argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc > ugen3.2: at usbus3, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x0051 > bNumInterfaces = 0x0001 > bConfigurationValue = 0x0001 > iConfiguration = 0x0004 > bmAttributes = 0x0080 > bMaxPower = 0x00fa > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0000 > bAlternateSetting = 0x0000 > bNumEndpoints = 0x0009 > bInterfaceClass = 0x00ff > bInterfaceSubClass = 0x00ff > bInterfaceProtocol = 0x00ff > iInterface = 0x0002 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0083 I have no clue what I'm talking about, so, this might be wrong.. Anyways.. the urtw(4) driver supports two different chips the 8187B and 8187L. One difference between those is the number of endpoints and its addresses. The 8187L uses 3 endpoints with 0x81 as the RX endpoint, the 8187B uses 7 endpoints with 0x83 as RX. % vendor REALTEK 0x0bda Realtek % product REALTEK RTL8187 0x8187 RTL8187 Wireless Adapter Quoting from the driver: % #define URTW_DEV_B(v,p) \ % { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, URTW_REV_RTL8187B) } % #define URTW_DEV_L(v,p) \ % { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, URTW_REV_RTL8187L) } % .. % static const struct usb_device_id urtw_devs[] = { % URTW_DEV_L(REALTEK, RTL8187), % .. % static const struct usb_config urtw_8187b_usbconfig[URTW_8187B_N_XFERS] = { % [URTW_8187B_BULK_RX] = { % .type = UE_BULK, % .endpoint = 0x83, % .. % static const struct usb_config urtw_8187l_usbconfig[URTW_8187L_N_XFERS] = { % [URTW_8187L_BULK_RX] = { % .type = UE_BULK, % .endpoint = 0x81, It occurs to me that yours might actually be a B chip not a L, because there is a 0x83 endpoint but none for 0x81. Wanna give that a shot? Index: if_urtw.c =================================================================== --- if_urtw.c (revision 222807) +++ if_urtw.c (working copy) @@ -112,7 +112,7 @@ static const struct usb_device_id urtw_devs[] = { URTW_DEV_L(BELKIN, F5D7050E), URTW_DEV_L(LINKSYS4, WUSB54GCV2), URTW_DEV_L(NETGEAR, WG111V2), - URTW_DEV_L(REALTEK, RTL8187), + URTW_DEV_B(REALTEK, RTL8187), URTW_DEV_L(SITECOMEU, WL168V1), URTW_DEV_L(SURECOM, EP9001G2A), { USB_VPI(0x1b75, 0x8187, URTW_REV_RTL8187L) }, > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 1 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0004 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 2 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0005 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 3 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0006 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 4 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0007 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 5 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0089 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 6 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x000a > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 7 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x000b > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 8 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x000c > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > If a verbose boot or any other info is needed to get this working, > please tell me, and I'll get you the info. > > I do have to admit, at the price these are going for, they are rather > nice, and do reach out and touch a router. Review complaints: heat > dissipation. If you buy one, don't operate it in a hot environment. > I'd like to see it working in FreeBSD, but I don't have a handle on the > wifi driver structure. Linux source code was included on the driver > disk. I can email that directly to whomever needs it for comparison. > > > Thanks, > > Jim, KC5VDJ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Bernhard From owner-freebsd-wireless@FreeBSD.ORG Fri Jun 10 10:14:26 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7960106566B for ; Fri, 10 Jun 2011 10:14:26 +0000 (UTC) (envelope-from rodrigo.dcarmo@seemoo.tu-darmstadt.de) Received: from lnx141.hrz.tu-darmstadt.de (lnx141.hrz.tu-darmstadt.de [130.83.156.236]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF478FC1A for ; Fri, 10 Jun 2011 10:14:25 +0000 (UTC) Received: from lnx503.hrz.tu-darmstadt.de (lnx503.hrz.tu-darmstadt.de [130.83.156.232]) by lnx141.hrz.tu-darmstadt.de (8.14.4/8.13.8) with ESMTP id p5A9dDj0026463 for ; Fri, 10 Jun 2011 11:39:13 +0200 (envelope-from rodrigo.dcarmo@seemoo.tu-darmstadt.de) Received: from mail.cased.de (mail.cased.de [130.83.33.42]) by lnx503.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id p5A9ZtEV026338 for ; Fri, 10 Jun 2011 11:35:55 +0200 (envelope-from rodrigo.dcarmo@seemoo.tu-darmstadt.de) Received: by mail.cased.de (Postfix, from userid 106) id 84DBF162191; Fri, 10 Jun 2011 11:35:55 +0200 (CEST) Received: from cased134.cased.tu-darmstadt.de (s0235.dyn.hrz.tu-darmstadt.de [130.83.104.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cased.de (Postfix) with ESMTPSA id 791FF16218B for ; Fri, 10 Jun 2011 11:35:55 +0200 (CEST) Message-ID: <4DF1E517.30105@seemoo.tu-darmstadt.de> Date: Fri, 10 Jun 2011 11:34:15 +0200 From: Rodrigo do Carmo User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.10.92715 X-PMX-RELAY: outgoing Subject: Compiling meshd in FreeBSD 8.2 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2011 10:14:26 -0000 Hi, First of all, I'm sorry if this is the wrong place to put this kind of questions. I would like to ask you, if someone could give me a hand with this. I'm trying to compile the meshd in a FreeBSD 8.2, but I can't get rid of this error message when doing make: "meshd.c:83: error: 'struct ' has no member named 'variable'"... I've applied the patch to the kernel, the path to the openssl libraries are OK, in fact I also used the 1.0.0-beta2 as stated in the example, compiled from scratch. I also get the same error in a FreeBSD 6.4. Does anyone went to something similar? Thanks so much in advance, Rodrigo. From owner-freebsd-wireless@FreeBSD.ORG Fri Jun 10 10:18:57 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70118106564A for ; Fri, 10 Jun 2011 10:18:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF628FC1A for ; Fri, 10 Jun 2011 10:18:56 +0000 (UTC) Received: by gxk28 with SMTP id 28so2303243gxk.13 for ; Fri, 10 Jun 2011 03:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tKIQrLgtzri/vx648rvIbgyq5O8Z+aCwsGb3WiJkKLQ=; b=g1fcEVS6CINDIkQA79HZoEL12gL4ozG1ruU5MIbQXsfUhj3YHn2Y0QBIaVGe24D+nw LORW6OkCblNFjbDIQeZLYWlKFp/XJZ/Iu4j8KOAlPB35CnvSDX9KIM2niLrFKuz9djy0 ecSGqW30JjJN+1JzciVKU7yYHA8K9dQxXE7KI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=LUrkALpzGIokyS7Dnwgen5VeEFAmcAb/KUcdFxnERV7s+xoeNvfABzgB1EDeXgUhaz uQ1qnYQZcIxpTs8kMBCxengjCu0ppBeFMzaAA2rMfAy8P45p/48+Qwa//dd8Gkfb2fEW XkHB8nLaYRg3+ypVdh9PnHBJtiywj2x3jJKr0= MIME-Version: 1.0 Received: by 10.150.13.15 with SMTP id 15mr2954765ybm.103.1307701136086; Fri, 10 Jun 2011 03:18:56 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.216.3 with HTTP; Fri, 10 Jun 2011 03:18:56 -0700 (PDT) In-Reply-To: <4DF1E517.30105@seemoo.tu-darmstadt.de> References: <4DF1E517.30105@seemoo.tu-darmstadt.de> Date: Fri, 10 Jun 2011 18:18:56 +0800 X-Google-Sender-Auth: aPCg_Gfb4ZA_kCHMjvCtYdbgccQ Message-ID: From: Adrian Chadd To: Rodrigo do Carmo Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Compiling meshd in FreeBSD 8.2 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2011 10:18:57 -0000 I'm currently doing exams at the moment, but I can likely help you in ten or so days if you remind me. (I can't guarantee i'll get it working, only that I'll see if I can figure out why it's not compiling. Frame injection may require some love..) Thanks, Adrian On 10 June 2011 17:34, Rodrigo do Carmo wrote: > Hi, > > First of all, I'm sorry if this is the wrong place to put this kind of > questions. I would like to ask you, if someone could give me a hand with > this. I'm trying to compile the meshd in a FreeBSD 8.2, but I can't get rid > of this error message when doing make: "meshd.c:83: error: 'struct > ' has no member named 'variable'"... I've applied the patch to > the kernel, the path to the openssl libraries are OK, in fact I also used > the 1.0.0-beta2 as stated in the example, compiled from scratch. I also get > the same error in a FreeBSD 6.4. Does anyone went to something similar? > > Thanks so much in advance, > Rodrigo. > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://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 Jun 10 20:16:49 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8100106566B; Fri, 10 Jun 2011 20:16:48 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDB28FC13; Fri, 10 Jun 2011 20:16:48 +0000 (UTC) Received: by iwn33 with SMTP id 33so3543000iwn.13 for ; Fri, 10 Jun 2011 13:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WtRfyROM73H5pm2YnI4v2JM9naiIA6N3qtrijouY2yo=; b=aBtdEjn4fxxC38T9oVmBr4fVi4CrN45y7WGNHDHiujc3DRDIB7zaXoEAUoueob/NWz G0lGLVE2rRrQuexunhkOmVz9UJB4A3Vd9mGQPw27a7pknrbg26WevI27TSmdr7sAKE2x tgnYF1dvtWfhYuW+tB78WSwHN8PqsjEuYNiEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NjgvfQ4P9zJpYC+2pz8zSKFaYK12tjtTcDLcDOxA8vAP0dTOdkQxxTwpaurWIjVxdN 1EkIS7oHKvgJfjYU5UesyhpfMsTVc0Dn+rDuuwsIV/4f4XfmnBBN8kWmapllUH+bPs8d gauDOjMKhKTAMXPMaJKRJVBLDD7hfXns0yvZk= Received: by 10.231.112.88 with SMTP id v24mr2713981ibp.80.1307735333427; Fri, 10 Jun 2011 12:48:53 -0700 (PDT) Received: from argus.electron-tube.net (desm-45-047.dsl.netins.net [167.142.45.47]) by mx.google.com with ESMTPS id 4sm1457653ibc.42.2011.06.10.12.48.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2011 12:48:52 -0700 (PDT) Message-ID: <4DF274F6.6050905@gmail.com> Date: Fri, 10 Jun 2011 14:48:06 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: bschmidt@freebsd.org References: <4DF12E4A.5020906@gmail.com> <201106100913.42480.bschmidt@freebsd.org> In-Reply-To: <201106100913.42480.bschmidt@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: weongyo@freebsd.org, freebsd-wireless@freebsd.org, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: problem with urtw X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2011 20:16:49 -0000 the patch didn't get it. ugen3.2: at usbus3 urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 urtw0: on usbus3 urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE device_attach: urtw0 attach returned 6 ugen3.2: at usbus3 (disconnected) [the last line was me unplugging it] this is with if_urtw.c patched to change L to B as you supplied. I'm here for testing.. any more ideas? If anyone wants to play themselves, look on ebay for WiFiSky 1500mW B/G with 6dBi antenna. It seems that half of Hong Kong is selling these for under $20 USD. Bernhard Schmidt wrote: > On Thursday, June 09, 2011 22:34:18 Jim Bryant wrote: > >> I just bought one of those chinese (apparently the same unit relabeled >> and being sold by multiple companies) realtek RTL8187B wifi units. The >> price is right. >> >> The label name on this one is WiFySky 1500mW. >> >> other than the fact that the case it is enclosed in is really cheesy, >> there is a more immediate problem with this. >> >> the current urtw driver returns a 6. >> >> here we go: >> >> on insert: >> >> ugen3.2: at usbus3 >> >> after kldload if_urtw.ko: >> >> urtw0: >> on usbus3 >> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >> device_attach: urtw0 attach returned 6 >> urtw0: >> on usbus3 >> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >> device_attach: urtw0 attach returned 6 >> urtw0: >> on usbus3 >> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >> device_attach: urtw0 attach returned 6 >> urtw0: >> on usbus3 >> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >> device_attach: urtw0 attach returned 6 >> >> 3:28:35pm argus(48): usbconfig -u 3 -a 2 dump_device_desc >> ugen3.2: at usbus3, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON >> >> bLength = 0x0012 >> bDescriptorType = 0x0001 >> bcdUSB = 0x0200 >> bDeviceClass = 0x0000 >> bDeviceSubClass = 0x0000 >> bDeviceProtocol = 0x0000 >> bMaxPacketSize0 = 0x0040 >> idVendor = 0x0bda >> idProduct = 0x8187 >> bcdDevice = 0x0200 >> iManufacturer = 0x0001 >> iProduct = 0x0002 >> iSerialNumber = 0x0000 >> bNumConfigurations = 0x0001 >> >> 3:28:48pm argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc >> ugen3.2: at usbus3, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON >> >> >> Configuration index 0 >> >> bLength = 0x0009 >> bDescriptorType = 0x0002 >> wTotalLength = 0x0051 >> bNumInterfaces = 0x0001 >> bConfigurationValue = 0x0001 >> iConfiguration = 0x0004 >> bmAttributes = 0x0080 >> bMaxPower = 0x00fa >> >> Interface 0 >> bLength = 0x0009 >> bDescriptorType = 0x0004 >> bInterfaceNumber = 0x0000 >> bAlternateSetting = 0x0000 >> bNumEndpoints = 0x0009 >> bInterfaceClass = 0x00ff >> bInterfaceSubClass = 0x00ff >> bInterfaceProtocol = 0x00ff >> iInterface = 0x0002 >> >> Endpoint 0 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x0083 >> > > I have no clue what I'm talking about, so, this might be wrong.. > > Anyways.. the urtw(4) driver supports two different chips the > 8187B and 8187L. One difference between those is the number of > endpoints and its addresses. The 8187L uses 3 endpoints with > 0x81 as the RX endpoint, the 8187B uses 7 endpoints with 0x83 as > RX. > > % vendor REALTEK 0x0bda Realtek > % product REALTEK RTL8187 0x8187 RTL8187 Wireless Adapter > > Quoting from the driver: > > % #define URTW_DEV_B(v,p) \ > % { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, URTW_REV_RTL8187B) } > % #define URTW_DEV_L(v,p) \ > % { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, URTW_REV_RTL8187L) } > % .. > % static const struct usb_device_id urtw_devs[] = { > % URTW_DEV_L(REALTEK, RTL8187), > % .. > % static const struct usb_config urtw_8187b_usbconfig[URTW_8187B_N_XFERS] = { > % [URTW_8187B_BULK_RX] = { > % .type = UE_BULK, > % .endpoint = 0x83, > % .. > % static const struct usb_config urtw_8187l_usbconfig[URTW_8187L_N_XFERS] = { > % [URTW_8187L_BULK_RX] = { > % .type = UE_BULK, > % .endpoint = 0x81, > > It occurs to me that yours might actually be a B chip not a L, > because there is a 0x83 endpoint but none for 0x81. > > Wanna give that a shot? > > Index: if_urtw.c > =================================================================== > --- if_urtw.c (revision 222807) > +++ if_urtw.c (working copy) > @@ -112,7 +112,7 @@ static const struct usb_device_id urtw_devs[] = { > URTW_DEV_L(BELKIN, F5D7050E), > URTW_DEV_L(LINKSYS4, WUSB54GCV2), > URTW_DEV_L(NETGEAR, WG111V2), > - URTW_DEV_L(REALTEK, RTL8187), > + URTW_DEV_B(REALTEK, RTL8187), > URTW_DEV_L(SITECOMEU, WL168V1), > URTW_DEV_L(SURECOM, EP9001G2A), > { USB_VPI(0x1b75, 0x8187, URTW_REV_RTL8187L) }, > > > > >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 1 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x0004 >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 2 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x0005 >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 3 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x0006 >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 4 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x0007 >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 5 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x0089 >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 6 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x000a >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 7 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x000b >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> Endpoint 8 >> bLength = 0x0007 >> bDescriptorType = 0x0005 >> bEndpointAddress = 0x000c >> bmAttributes = 0x0002 >> wMaxPacketSize = 0x0200 >> bInterval = 0x0000 >> bRefresh = 0x0000 >> bSynchAddress = 0x0000 >> >> If a verbose boot or any other info is needed to get this working, >> please tell me, and I'll get you the info. >> >> I do have to admit, at the price these are going for, they are rather >> nice, and do reach out and touch a router. Review complaints: heat >> dissipation. If you buy one, don't operate it in a hot environment. >> I'd like to see it working in FreeBSD, but I don't have a handle on the >> wifi driver structure. Linux source code was included on the driver >> disk. I can email that directly to whomever needs it for comparison. >> >> >> Thanks, >> >> Jim, KC5VDJ >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > -- > Bernhard > > From owner-freebsd-wireless@FreeBSD.ORG Sat Jun 11 02:02:26 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E2FD106566B for ; Sat, 11 Jun 2011 02:02:26 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B74D8FC0C for ; Sat, 11 Jun 2011 02:02:26 +0000 (UTC) Received: by pzk27 with SMTP id 27so1904975pzk.13 for ; Fri, 10 Jun 2011 19:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=du3GNGb5cKleXV0cdknjbVKmuSfDpko9Grc0BmahJ9E=; b=HUdbvtY29Byx33pzPpZ2Th5j/h9LQDD7dF/WLltAucgJ4B7ZC5Dtsz6F0GTB/Y+QFV B/StCID6HNIddCXW/GJdKhg2MMfeIACqI8LnR9JeJpB/yDI1obsOh3Nc7WiNFpZc8aMh Skb+tIPthnigOlDj5ZheBR1m9Mq8JcQLTVgDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=NZbGPoyCIaaV1PIRpDo/ZadkvIS+lHPdH2sTu3QBF+dQuJyUJmJpEsTAgjKOfoBqqE p8OR24ocWxtbjP63YKnO+Jn7iGn706HTC+nW0+1g8H/SbwCt6YleaY7aMdU7fjoK48il fJlhv7jVEOTxqZ3yMT2DzRfv8bxXZeHUEV198= Received: by 10.68.22.35 with SMTP id a3mr1176967pbf.477.1307757745897; Fri, 10 Jun 2011 19:02:25 -0700 (PDT) Received: from sidhe.local ([75.111.37.204]) by mx.google.com with ESMTPS id o2sm2761748pbj.65.2011.06.10.19.02.23 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 19:02:24 -0700 (PDT) Message-ID: <4DF2CCAA.2050500@gmail.com> Date: Fri, 10 Jun 2011 19:02:18 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110502 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-wireless@freebsd.org References: <4DF12E4A.5020906@gmail.com> <201106100913.42480.bschmidt@freebsd.org> <4DF274F6.6050905@gmail.com> In-Reply-To: <4DF274F6.6050905@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: problem with urtw X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 11 Jun 2011 02:02:26 -0000 On 06/10/11 12:48, Jim Bryant wrote: > the patch didn't get it. > > ugen3.2: at usbus3 > urtw0: 2> on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > urtw0: 2> on usbus3 > urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE > device_attach: urtw0 attach returned 6 > ugen3.2: at usbus3 (disconnected) > > [the last line was me unplugging it] > > this is with if_urtw.c patched to change L to B as you supplied. > > I'm here for testing.. any more ideas? If anyone wants to play > themselves, look on ebay for WiFiSky 1500mW B/G with 6dBi antenna. It > seems that half of Hong Kong is selling these for under $20 USD. > > Bernhard Schmidt wrote: >> On Thursday, June 09, 2011 22:34:18 Jim Bryant wrote: >>> I just bought one of those chinese (apparently the same unit >>> relabeled and being sold by multiple companies) realtek RTL8187B >>> wifi units. The price is right. >>> >>> The label name on this one is WiFySky 1500mW. >>> >>> other than the fact that the case it is enclosed in is really >>> cheesy, there is a more immediate problem with this. >>> >>> the current urtw driver returns a 6. >>> >>> here we go: >>> >>> on insert: >>> >>> ugen3.2: at usbus3 >>> >>> after kldload if_urtw.ko: >>> >>> urtw0: >> 2> on usbus3 >>> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >>> device_attach: urtw0 attach returned 6 >>> urtw0: >> 2> on usbus3 >>> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >>> device_attach: urtw0 attach returned 6 >>> urtw0: >> 2> on usbus3 >>> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >>> device_attach: urtw0 attach returned 6 >>> urtw0: >> 2> on usbus3 >>> urtw0: could not allocate USB transfers, err=USB_ERR_NO_PIPE >>> device_attach: urtw0 attach returned 6 >>> >>> 3:28:35pm argus(48): usbconfig -u 3 -a 2 dump_device_desc >>> ugen3.2: at usbus3, cfg=0 md=HOST >>> spd=HIGH (480Mbps) pwr=ON >>> >>> bLength = 0x0012 >>> bDescriptorType = 0x0001 >>> bcdUSB = 0x0200 >>> bDeviceClass = 0x0000 >>> bDeviceSubClass = 0x0000 >>> bDeviceProtocol = 0x0000 >>> bMaxPacketSize0 = 0x0040 >>> idVendor = 0x0bda >>> idProduct = 0x8187 >>> bcdDevice = 0x0200 >>> iManufacturer = 0x0001 >>> iProduct = 0x0002 >>> iSerialNumber = 0x0000 >>> bNumConfigurations = 0x0001 >>> >>> 3:28:48pm argus(49): usbconfig -u 3 -a 2 dump_curr_config_desc >>> ugen3.2: at usbus3, cfg=0 md=HOST >>> spd=HIGH (480Mbps) pwr=ON >>> >>> >>> Configuration index 0 >>> >>> bLength = 0x0009 >>> bDescriptorType = 0x0002 >>> wTotalLength = 0x0051 >>> bNumInterfaces = 0x0001 >>> bConfigurationValue = 0x0001 >>> iConfiguration = 0x0004 >>> bmAttributes = 0x0080 >>> bMaxPower = 0x00fa >>> >>> Interface 0 >>> bLength = 0x0009 >>> bDescriptorType = 0x0004 >>> bInterfaceNumber = 0x0000 >>> bAlternateSetting = 0x0000 >>> bNumEndpoints = 0x0009 >>> bInterfaceClass = 0x00ff >>> bInterfaceSubClass = 0x00ff >>> bInterfaceProtocol = 0x00ff >>> iInterface = 0x0002 >>> >>> Endpoint 0 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x0083 >> >> I have no clue what I'm talking about, so, this might be wrong.. >> >> Anyways.. the urtw(4) driver supports two different chips the >> 8187B and 8187L. One difference between those is the number of >> endpoints and its addresses. The 8187L uses 3 endpoints with >> 0x81 as the RX endpoint, the 8187B uses 7 endpoints with 0x83 as >> RX. >> >> % vendor REALTEK 0x0bda Realtek >> % product REALTEK RTL8187 0x8187 RTL8187 Wireless Adapter >> >> Quoting from the driver: >> >> % #define URTW_DEV_B(v,p) \ >> % { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, >> URTW_REV_RTL8187B) } >> % #define URTW_DEV_L(v,p) \ >> % { USB_VPI(USB_VENDOR_##v, USB_PRODUCT_##v##_##p, >> URTW_REV_RTL8187L) } >> % .. >> % static const struct usb_device_id urtw_devs[] = { >> % URTW_DEV_L(REALTEK, RTL8187), >> % .. >> % static const struct usb_config >> urtw_8187b_usbconfig[URTW_8187B_N_XFERS] = { >> % [URTW_8187B_BULK_RX] = { >> % .type = UE_BULK, >> % .endpoint = 0x83, >> % .. >> % static const struct usb_config >> urtw_8187l_usbconfig[URTW_8187L_N_XFERS] = { >> % [URTW_8187L_BULK_RX] = { >> % .type = UE_BULK, >> % .endpoint = 0x81, >> >> It occurs to me that yours might actually be a B chip not a L, >> because there is a 0x83 endpoint but none for 0x81. >> >> Wanna give that a shot? >> >> Index: if_urtw.c >> =================================================================== >> --- if_urtw.c (revision 222807) >> +++ if_urtw.c (working copy) >> @@ -112,7 +112,7 @@ static const struct usb_device_id urtw_devs[] = { >> URTW_DEV_L(BELKIN, F5D7050E), >> URTW_DEV_L(LINKSYS4, WUSB54GCV2), >> URTW_DEV_L(NETGEAR, WG111V2), >> - URTW_DEV_L(REALTEK, RTL8187), >> + URTW_DEV_B(REALTEK, RTL8187), >> URTW_DEV_L(SITECOMEU, WL168V1), >> URTW_DEV_L(SURECOM, EP9001G2A), >> { USB_VPI(0x1b75, 0x8187, URTW_REV_RTL8187L) }, >> >> >> >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 1 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x0004 >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 2 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x0005 >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 3 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x0006 >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 4 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x0007 >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 5 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x0089 >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 6 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x000a >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 7 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x000b >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> Endpoint 8 >>> bLength = 0x0007 >>> bDescriptorType = 0x0005 >>> bEndpointAddress = 0x000c >>> bmAttributes = 0x0002 >>> wMaxPacketSize = 0x0200 >>> bInterval = 0x0000 >>> bRefresh = 0x0000 >>> bSynchAddress = 0x0000 >>> >>> If a verbose boot or any other info is needed to get this working, >>> please tell me, and I'll get you the info. >>> >>> I do have to admit, at the price these are going for, they are >>> rather nice, and do reach out and touch a router. Review >>> complaints: heat dissipation. If you buy one, don't operate it in a >>> hot environment. I'd like to see it working in FreeBSD, but I don't >>> have a handle on the wifi driver structure. Linux source code was >>> included on the driver disk. I can email that directly to whomever >>> needs it for comparison. >>> >>> >>> Thanks, >>> >>> Jim, KC5VDJ >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to >>> "freebsd-stable-unsubscribe@freebsd.org" >> >> -- >> Bernhard >> > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to > "freebsd-wireless-unsubscribe@freebsd.org" > The classic engineering question as far as I know is "Did it ever work?" Is any other operating system capable of bringing this device up & connecting to wireless networks etc? China's street market (now on eBay!) is known as the residence of the true spirit of caveat emptor. Matt From owner-freebsd-wireless@FreeBSD.ORG Sat Jun 11 02:47:35 2011 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E68F106566C; Sat, 11 Jun 2011 02:47:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC6BD8FC0C; Sat, 11 Jun 2011 02:47:34 +0000 (UTC) Received: by yxm34 with SMTP id 34so275244yxm.13 for ; Fri, 10 Jun 2011 19:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AVUNT3na6BEeA7N4mlQWYOCpj2I4JqTe+do2V+Pkq9M=; b=Opfv0WvaRTleG4XzbdStfXPv31RLgVXYlUoY5E4nL7oQb90c4RyXdjE7mRj5srE9Od A5VnBbTEz/FwsqUMjWnORmHemQlhGIo5Xz8RhCfznnoDiqjwQxyPNB39YXObkAY0H2a2 +Us+/CRaR/3GKkUGmp3V9Jkb1aPJnijIqu72Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PN1diwKqOxPBpsd60Fwq6Noe5U/4iyuMUisKHbe7B08l0l3PN1iQvwVGbrN5Dpw/kH JrwKVUxrFEtR0sRQ/2vGZHpYTj7oYkVctoxDluoPa4k4mTT4EI8QS41Ey2bDEo0Q0d5/ d4WeAtHP8pH09WlPrrOEIa8xwCMcYeOLAO7CA= MIME-Version: 1.0 Received: by 10.151.95.16 with SMTP id x16mr4149737ybl.46.1307760454084; Fri, 10 Jun 2011 19:47:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.216.3 with HTTP; Fri, 10 Jun 2011 19:47:34 -0700 (PDT) In-Reply-To: <4DF274F6.6050905@gmail.com> References: <4DF12E4A.5020906@gmail.com> <201106100913.42480.bschmidt@freebsd.org> <4DF274F6.6050905@gmail.com> Date: Sat, 11 Jun 2011 10:47:34 +0800 X-Google-Sender-Auth: nOeR2esA9tyl5WyrkBtgVKkcSrg Message-ID: From: Adrian Chadd To: Jim Bryant Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, freebsd-wireless@freebsd.org, weongyo@freebsd.org, freebsd-usb@freebsd.org, bschmidt@freebsd.org Subject: Re: problem with urtw X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 11 Jun 2011 02:47:35 -0000 On 11 June 2011 03:48, Jim Bryant wrote: > this is with if_urtw.c patched to change L to B as you supplied. > > I'm here for testing.. =A0any more ideas? =A0If anyone wants to play them= selves, > look on ebay for WiFiSky 1500mW B/G with 6dBi antenna. =A0It seems that h= alf > of Hong Kong is selling these for under $20 USD. I've enough wireless hardware. :) If someone: * buys me a pair; * demonstrates it runs fine under linux or some other open source operating system; * gives me enough time; Then sure, I may make this work. (The offer stands for Linux carl9170 compatible devices btw. I'll likely take a crack at porting that driver after my exams, but only once I've finished off the Atheros 11n TX code.) Adrian