From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 10 02:46:53 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97CD72BA; Sun, 10 Nov 2013 02:46:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4815820F5; Sun, 10 Nov 2013 02:46:53 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id b10so807469qcw.36 for ; Sat, 09 Nov 2013 18:46:52 -0800 (PST) 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:cc:content-type; bh=4UG5nlmYxNK3xvZyyWTdB42dbKKwLUYFuk13IgDSHr4=; b=F/LRxzfgPCV5w1gOddIK5lNQAJ2ZGYPwc2vGYBys7YMDJqvQT7uYRvT7F26y37lJN6 Nkj6xZ/Bfu2EQFeQAy3AUoKm4Hg1CmIqDjkZrmscrTCvgKmSO445rAo9hvopK46cqen3 kMP813uOQ/cBnbiywetKkVbqNMVa+QK9FGHEcS7bSbCGzaZUKsZfHFc171BUK07iwQXZ fLU7Ub2orUrlkH2H4igRbP2OTbpW9iOxZOFpA1yGdWW8leD8ldHddJA2OpzJMp2feR8z Qx/q0o4R5EAkHgrk/tM0MObFltxjunxhHdAi6QPZr6K0WqhpFv+CoIkDUMX/Dgvlu5mH jZWA== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr36627690qac.98.1384051612539; Sat, 09 Nov 2013 18:46:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 18:46:52 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 18:46:52 -0800 X-Google-Sender-Auth: 8AOEOwHf3l0Y9jjERyrAjDQDoSg Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch , "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Nov 2013 02:46:53 -0000 Hi! On 9 November 2013 18:29, Brandon Gooch wrote: > Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link > 5300 to hang after only a few moments of use. That's .. odd. Ok. > For now, I've just reverted only those aspects of r257133, enabling > MRR and keeping the rate index lookup, which seems to do something on > my hardware at least (I assume it's not the right thing based on > Adrian's analysis, but it works never-the-less). > > Has anyone else hit this with Intel WiFi hardware? > > Also, what needs to be done to have MRR working properly? So, it could be a fall out of how utterly crap AMRR is at 11n rates. Please compile with IWN_DEBUG, then do this before you associate: sysctl dev.iwn.0.debug=0x1 (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) You can do the same on a kernel with and without the MRR stuff enabled. I'd like to see what the actual rate selection looks like and what the final rate selection is. We may have to patch the kernel to print out the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. The MRR stuff is a bit special. I don't know how the link table works in great depth yet. I know it's broken for 11n; it's plainly using the wrong indexes now. That's why I disabled it. It shouldn't take that much work to get it in the tree again; it'll just be fiddly. The easy bit is populating the table. The hard bit is knowing which index to set linkq to when transmitting a frame. -adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 10 05:08:28 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF9695E9; Sun, 10 Nov 2013 05:08:28 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8B44D2642; Sun, 10 Nov 2013 05:08:28 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y13so968839pdi.14 for ; Sat, 09 Nov 2013 21:08:28 -0800 (PST) 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=a/QEp6YVg5k7svHJjmkqSC6hisv5Y0acsD+v7AocXnQ=; b=GBOhh/Ng/sg2urCPCo25t4pReDPWd24SXDJXfbXaOEhl6sfQm0gSilxhICakRxtKZP NV6UZlW2V8obNr4nIkdQDzzeiyZbGEjEOwC5Ocgu4A4T9dHiDtfQ7tIgWQ1JiS7972kE aExMT4A65wM+xhugdD6WKY6YQS45oZZ9ZVpKkO1u5naUQ5TJYUsMKSxQpF1zI5CURxZU uTS2aLikJ5cZBLo3UdFJDfQP1469ydoQklbao7WkY+aUXApoQtzWVpdC9tGXO+X/hpZu O2wrqo/YgchEEhUfd4nN8ZHvWo71etvl5dLkPkZumwC5rU0MR19bgHVYZWfDP7MUg6HK EMPw== MIME-Version: 1.0 X-Received: by 10.68.191.3 with SMTP id gu3mr18959pbc.142.1384060108188; Sat, 09 Nov 2013 21:08:28 -0800 (PST) Received: by 10.68.57.72 with HTTP; Sat, 9 Nov 2013 21:08:28 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 23:08:28 -0600 Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Brandon Gooch To: Adrian Chadd Content-Type: multipart/mixed; boundary=e89a8ff1c37418c95804eacb9b8c X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Nov 2013 05:08:28 -0000 --e89a8ff1c37418c95804eacb9b8c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: > Hi! > > On 9 November 2013 18:29, Brandon Gooch wrote: >> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >> 5300 to hang after only a few moments of use. > > That's .. odd. Ok. > >> For now, I've just reverted only those aspects of r257133, enabling >> MRR and keeping the rate index lookup, which seems to do something on >> my hardware at least (I assume it's not the right thing based on >> Adrian's analysis, but it works never-the-less). >> >> Has anyone else hit this with Intel WiFi hardware? >> >> Also, what needs to be done to have MRR working properly? > > So, it could be a fall out of how utterly crap AMRR is at 11n rates. > > Please compile with IWN_DEBUG, then do this before you associate: > > sysctl dev.iwn.0.debug=0x1 > > (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) > > You can do the same on a kernel with and without the MRR stuff enabled. > > I'd like to see what the actual rate selection looks like and what the > final rate selection is. We may have to patch the kernel to print out > the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. I've attached the log output, both with and without MRR. The output looks very much the same within iwn_tx_data(); in iwn5000_tx_done() things are clearly different. If I'm reading the rate conversion bits correctly, I see anywhere from 6 Mbps to 60 Mbps, with the the non-MRR module "getting stuck" -- I really don't know what has happened when it does this. Is there any further debugging output that would be helpful? -Brandon > The MRR stuff is a bit special. I don't know how the link table works > in great depth yet. I know it's broken for 11n; it's plainly using the > wrong indexes now. That's why I disabled it. It shouldn't take that > much work to get it in the tree again; it'll just be fiddly. The easy > bit is populating the table. The hard bit is knowing which index to > set linkq to when transmitting a frame. > > > > -adrian --e89a8ff1c37418c95804eacb9b8c-- From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 10 06:18:42 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C76B1CC1; Sun, 10 Nov 2013 06:18:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 775132881; Sun, 10 Nov 2013 06:18:42 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id k18so3223526qcv.10 for ; Sat, 09 Nov 2013 22:18:41 -0800 (PST) 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:cc:content-type; bh=I2fy0r4ihOd9uO/QHPUiC8C5QGCdmPjxu2yPsj2Bzt4=; b=s9Tr0SwvdlHwGEoilPqRnmJee/R/wkvebBpBRErbx358sHQ1aRB5JVGu9byFuWTCjt qRe8EfeGEHe7d7OJvEw/cq3pThzFX2ziKivaM6KCuAOcs1UjoZ2v54Sv+8cGjzGB+pMC wNUGvOoRrQnc3Va8+C/Yb78NOEgBag7PlWFshptlsqC4pyOLqyklnvlxpgLGCvSsx6AI dRtw0FhW7hOA8aogAh9kg+mlo7Z1WpurSNba+DMiv3ncjQAoD/W1ywJvbGwIPekkHr1h THhwdqKxP3Egh0IdcnAev710KZOE7Fo/91uOYQS87XCZVAilp6EHSFa7ACvqnXWAr0D8 lMpw== MIME-Version: 1.0 X-Received: by 10.49.59.70 with SMTP id x6mr36083906qeq.17.1384064320964; Sat, 09 Nov 2013 22:18:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 22:18:40 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 22:18:40 -0800 X-Google-Sender-Auth: UlgghoWcP8q-e19zZ2xyCpWxk0Y Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Nov 2013 06:18:42 -0000 Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG) -a On 9 November 2013 21:08, Brandon Gooch wrote: > On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: >> Hi! >> >> On 9 November 2013 18:29, Brandon Gooch wrote: >>> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >>> 5300 to hang after only a few moments of use. >> >> That's .. odd. Ok. >> >>> For now, I've just reverted only those aspects of r257133, enabling >>> MRR and keeping the rate index lookup, which seems to do something on >>> my hardware at least (I assume it's not the right thing based on >>> Adrian's analysis, but it works never-the-less). >>> >>> Has anyone else hit this with Intel WiFi hardware? >>> >>> Also, what needs to be done to have MRR working properly? >> >> So, it could be a fall out of how utterly crap AMRR is at 11n rates. >> >> Please compile with IWN_DEBUG, then do this before you associate: >> >> sysctl dev.iwn.0.debug=0x1 >> >> (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) >> >> You can do the same on a kernel with and without the MRR stuff enabled. >> >> I'd like to see what the actual rate selection looks like and what the >> final rate selection is. We may have to patch the kernel to print out >> the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. > > I've attached the log output, both with and without MRR. > > The output looks very much the same within iwn_tx_data(); in > iwn5000_tx_done() things are > clearly different. > > If I'm reading the rate conversion bits correctly, I see anywhere from > 6 Mbps to 60 Mbps, with the > the non-MRR module "getting stuck" -- I really don't know what has > happened when it does this. > > Is there any further debugging output that would be helpful? > > -Brandon > >> The MRR stuff is a bit special. I don't know how the link table works >> in great depth yet. I know it's broken for 11n; it's plainly using the >> wrong indexes now. That's why I disabled it. It shouldn't take that >> much work to get it in the tree again; it'll just be fiddly. The easy >> bit is populating the table. The hard bit is knowing which index to >> set linkq to when transmitting a frame. >> >> >> >> -adrian From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 10 06:20:16 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DAC50DE7; Sun, 10 Nov 2013 06:20:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8BED32896; Sun, 10 Nov 2013 06:20:15 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id cy11so3471541qeb.12 for ; Sat, 09 Nov 2013 22:20:14 -0800 (PST) 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:cc:content-type; bh=nOAzUpuZLwiOZqBwM0MBrWAXgbhZQhYT/4l7z5/dtvU=; b=GE54VnHwvZL4j3EhyZ2SPIcH1NG13UZkvztBmmjusEipRyCub5Yuo1o3/fIVGPCdCT o3vIpXIWcJz5W5zl1k8oB4oJ8WK3I+FMD0nSN8GvKiP9bKbKiL25y9qtkcxZ+GmlT3bo Ev4e+bCIyHlI5Jb1VOEM3sszallJbcB6aSd5FOnX/tYDye8gLI+L8SBNrUazEdvw3G0x +A16OkQglAqxqr90cDPTtbwbFby2jUUVJOlQZGvng6uiIvaMfNb+Lv5GYkAeYfQD9ihK NLDVaMMP0tFbuLDowbJkxIPUfkI7NEYf7cfS1WBeNXnd7+7f1lf1wRQgr7EGPpFdF36L uGZA== MIME-Version: 1.0 X-Received: by 10.49.19.101 with SMTP id d5mr36206753qee.78.1384064414800; Sat, 09 Nov 2013 22:20:14 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sat, 9 Nov 2013 22:20:14 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Nov 2013 22:20:14 -0800 X-Google-Sender-Auth: 8_TWKL1JMD7jG1w5jlopM0PSCMk Message-ID: Subject: Re: iwn(4) hangs after r257133 From: Adrian Chadd To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Nov 2013 06:20:16 -0000 Oh, and you need to print out the tx->rate field using "0x%04x", rather than %d. The completion value is in hex. -adrian On 9 November 2013 22:18, Adrian Chadd wrote: > Sure, flip on 'wlandebug +rate' (assuming you compiled with IEEE80211_DEBUG) > > > -a > > On 9 November 2013 21:08, Brandon Gooch wrote: >> On Sat, Nov 9, 2013 at 8:46 PM, Adrian Chadd wrote: >>> Hi! >>> >>> On 9 November 2013 18:29, Brandon Gooch wrote: >>>> Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link >>>> 5300 to hang after only a few moments of use. >>> >>> That's .. odd. Ok. >>> >>>> For now, I've just reverted only those aspects of r257133, enabling >>>> MRR and keeping the rate index lookup, which seems to do something on >>>> my hardware at least (I assume it's not the right thing based on >>>> Adrian's analysis, but it works never-the-less). >>>> >>>> Has anyone else hit this with Intel WiFi hardware? >>>> >>>> Also, what needs to be done to have MRR working properly? >>> >>> So, it could be a fall out of how utterly crap AMRR is at 11n rates. >>> >>> Please compile with IWN_DEBUG, then do this before you associate: >>> >>> sysctl dev.iwn.0.debug=0x1 >>> >>> (that's IWN_DEBUG_XMIT in sys/dev/iwn/if_iwn_debug.h) >>> >>> You can do the same on a kernel with and without the MRR stuff enabled. >>> >>> I'd like to see what the actual rate selection looks like and what the >>> final rate selection is. We may have to patch the kernel to print out >>> the contents of 'rate' and 'tx->rate' in iwn_tx_data() to get that. >> >> I've attached the log output, both with and without MRR. >> >> The output looks very much the same within iwn_tx_data(); in >> iwn5000_tx_done() things are >> clearly different. >> >> If I'm reading the rate conversion bits correctly, I see anywhere from >> 6 Mbps to 60 Mbps, with the >> the non-MRR module "getting stuck" -- I really don't know what has >> happened when it does this. >> >> Is there any further debugging output that would be helpful? >> >> -Brandon >> >>> The MRR stuff is a bit special. I don't know how the link table works >>> in great depth yet. I know it's broken for 11n; it's plainly using the >>> wrong indexes now. That's why I disabled it. It shouldn't take that >>> much work to get it in the tree again; it'll just be fiddly. The easy >>> bit is populating the table. The hard bit is knowing which index to >>> set linkq to when transmitting a frame. >>> >>> >>> >>> -adrian From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 11 08:29:13 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B18A4138 for ; Mon, 11 Nov 2013 08:29:13 +0000 (UTC) (envelope-from mrxbody@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 412F4233B for ; Mon, 11 Nov 2013 08:29:13 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id er20so501525lab.36 for ; Mon, 11 Nov 2013 00:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2s2wKShrOcwEzXOQjO9e+WZFPOBQ5jU+OBkdt9QNoFw=; b=RcyvmPeawDJO7LCeE0zDVSyOgoE6B1kh82MInryON45HgpLcjZoj8P12qwgW7kIO8H o3wylz3sGsb5CVKYSWqL8ZrdGre74w59I+nEO5TZnLLmlQ+zR81ZK+3+VqajORkGq542 1a7KN/xe49OIFqFeZ3Z7e+nbtF+OPZvdVbpkV9gBjDM6dUXYBVVXpSMGOhlgkuz4d2vh rCAHrcfQ1+eFVz1/d1Lc3hglXFM6S+gu1OXFZtEzpYoyKvxZu2mqLKFeC5l1tr/CfDys qJysshslW4EOJiaSHZVtgMDBPwnSdSndX3Zb5vRABL/RbvJPHHbBPMpe6Hd3m0MMw8K1 9Q0g== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr21083012lbb.0.1384158551349; Mon, 11 Nov 2013 00:29:11 -0800 (PST) Received: by 10.114.94.193 with HTTP; Mon, 11 Nov 2013 00:29:11 -0800 (PST) Date: Mon, 11 Nov 2013 12:29:11 +0400 Message-ID: Subject: Ralink 802.11n chipset support From: xbody To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Nov 2013 08:29:13 -0000 Hello, I'm following the article at https://wiki.freebsd.org/WiFi Do you have any information about current status on Ralink 802.11n chipset support at Freebsd 9 ? Thank you. -- Best regards, Vadim From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 11 11:06:59 2013 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AA01AA3E for ; Mon, 11 Nov 2013 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9582E2CDA for ; Mon, 11 Nov 2013 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rABB6xIt082301 for ; Mon, 11 Nov 2013 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rABB6xsT082299 for freebsd-wireless@FreeBSD.org; Mon, 11 Nov 2013 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Nov 2013 11:06:59 GMT Message-Id: <201311111106.rABB6xsT082299@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 Subject: Current problem reports assigned to freebsd-wireless@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Nov 2013 11:06:59 -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/183759 wireless [iwn] [wlan] Interface dies, OACTIVE set on wlan0 o kern/183727 wireless [wlan] ENOBUFFS incorrectly returned when tx packet is o kern/183644 wireless [ath] [patch] ath(4) "stops" working o kern/183430 wireless [iwn] latest change to the rate code setup uses 11n ra o kern/183428 wireless [net80211] [iwn] Some APs seem to announce HT but no H o kern/181898 wireless [iwn] [patch] Centrino Advanced-N 6235 with latest iwn o kern/181694 wireless [iwn] [patch] Initialize hardware in iwn(4) resume cod o kern/181161 wireless [wl] config a old compaq wl-110 wireless card make ker o kern/181132 wireless [iwn] stream calculation is wrong for the Intel 4965 o kern/181100 wireless [bwi] Turning up bwi0 crashes / deadlocks the kernel o kern/180816 wireless [iwl] Intel Centrino Wireless-N 2200 not supported o kern/179847 wireless [ath] [patch] Update regdomain in ath drivers includin o kern/179709 wireless [ath] Atheros 5212 does not work: stuck beacon; resett o kern/179547 wireless [ath] Add AR9485 custom board fixes (CUS198) o kern/179482 wireless [ath] [patch] Fix AR9462 external LNA configuration o kern/179269 wireless [ath] [AR9285] RX antenna diversity is not functioning o kern/179232 wireless [ath] panic in ath o kern/178986 wireless [ath] Change mac address of ath(4) is not reflected wh o kern/178492 wireless [ath] ath0 (AR9287) panic o kern/178491 wireless [ath] ath0 (AR9287) stuck beacon o kern/178477 wireless [ath] missed beacon / soft reset in STA mode results i o kern/178470 wireless [panic][ath] bss vap can and does change o kern/178411 wireless [ral] [panic] FreeBSD kernel crash in rt2860 o kern/178379 wireless [net80211] [ath] WPA rekey on the STA side fails when o kern/178378 wireless [net80211] crypto state isn't reset during a reassocia o kern/178263 wireless [ath] review the use of ic_freq / ic_ieee / ic_flags / o kern/177847 wireless [ath] With TPC enabled, TX power values aren't clamped o kern/177846 wireless [ath] [net80211] net80211 TX power limit isn't correct o conf/177688 wireless WiFi regodmains information is inconsistent between "e o kern/177530 wireless [ath] ath driver isn't 32 bit int clean o kern/177465 wireless [iwn] 20%-100% packet loss with iwn driver o kern/177451 wireless [ieee80211] page fault in ieee80211_tx_mgt_timeout o kern/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o kern/170573 wireless [iwi] Intel 2200BG iwi NIC hangs with need multicast c o kern/170513 wireless [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: o kern/170433 wireless [ath] TX hang after a stuck beacon message with active o kern/170411 wireless [ath] Uninitialized variables in if_ath.c o kern/170397 wireless [ath] [patch] Uninitialized variables in ah_eeprom_928 o kern/170302 wireless [ath] 802.11n frames are not being transmitted with mu o kern/170281 wireless [ath] 802.11n locks up on aggregation setup (ampdutx) o kern/170098 wireless [ath] [net80211] VAPs (Virtual access points) with Ath o kern/170066 wireless [ral] ral(4) rt61pci Linksys freezes the machine as so o kern/169432 wireless [ath] BAR TX hang when aggregation session is reset du p kern/169362 wireless [ath] AR5416: radar pulse PHY errors sometimes include o kern/169336 wireless [ath] ANI isn't triggering in a busy/noisy environment o kern/169199 wireless [ath] Cannot set up static ip addresses for wireless w o kern/169084 wireless [ath] suspend/resume doesn't cause a rescan; the assoc o kern/168530 wireless [ath] Broken WEP probably o kern/168393 wireless AR9285: suspend/resume sometimes fails o kern/168170 wireless [net80211] ieee80211_send_bar() doesn't complete corre o kern/167870 wireless [ath] adhoc wifi client does not join an existing IBSS o kern/167834 wireless [ath] kickpcu; 'handled 0 packets' o kern/167828 wireless [iwn] iwn(4) doesn't recover automatically after firmw o kern/167798 wireless ifconfig(8): problem with "ifconfig list scan" command o kern/167491 wireless [ath] TID != hardware queue TID in ath_tx_aggr_comp_ag o kern/167113 wireless [ath] AR5210: "stuck" TX seems to be occuring, without o kern/167080 wireless [ath] channel switch on another VAP break channel setu o kern/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in a sysct o kern/165969 wireless [ath] Slower performance in adhoc mode vs Client/AP mo o kern/165966 wireless [ath] ath0: device timeout on SMP machines due to race o kern/165895 wireless [ath] overly busy cabq can tie up all tx buffers o kern/165870 wireless [bwn] bwn driver does not attach on HP Pavilion dv9420 o kern/165866 wireless [ath] TX hangs, requiring a "scan" to properly reset t o kern/165849 wireless [ath] [hang] network ath driver freeze o kern/165595 wireless [ipw] ipw(4): Can't load firmare for ipw2200bg o kern/165543 wireless [ath] ath0 endless scanning of channels without connec o kern/165517 wireless [net80211] bgscan isn't triggered when invalid beacons o kern/165475 wireless [ath] operational mode change doesn't poke the underly o kern/165382 wireless [kernel] taskqueue_unblock doesn't unblock currently q o kern/165306 wireless [ath] race conditions between scanning and beacon time o kern/165220 wireless [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" m o kern/165214 wireless [ieee80211] Kernel panic in ieee80211_output.c:2505 o kern/165212 wireless [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB6 o kern/165149 wireless [ath] [net80211] Ping with data length more than iv_fr o kern/165146 wireless [net80211] Net802.11 Fragment number is assigned 1 (sh o kern/165060 wireless [ath] vap->iv_bss race conditions causing crashes insi o kern/165021 wireless [ath] ath device timeout during scan/attach, if wlan_c o kern/164721 wireless [ath] ath device timeouts o kern/164382 wireless [ath] crash when down/deleting a vap - inside ieee8021 o kern/164365 wireless [iwi] iwi0: UP/DOWN in o bin/164102 wireless hostapd not configured for 802.11n o kern/163759 wireless [ath] ath(4) "stops working" in hostap mode o kern/163724 wireless [mwl] [patch] NULL check before dereference o kern/163719 wireless [ath] ath interface do not receive multicast o kern/163689 wireless [ath] TX timeouts when sending probe/mgmt frames durin o kern/163574 wireless [net80211] overly-frequent HT occupancy changes o kern/163573 wireless [ath] hostap mode TX buffer hang o kern/163559 wireless [ath] kernel panic AH_DEBUG o kern/163318 wireless [ath] ath(4) stops working p kern/163312 wireless [panic] [ath driver] kernel panic: page fault with ath o kern/163237 wireless [ath] AR5416 as HostAP. Delays among clients when a cl o kern/163082 wireless [ath] ar9285 diversity fixes o kern/162648 wireless [ath] AR9227 ADC DC calibration failure o kern/162647 wireless [ath] 11n TX aggregation session / TX hang o kern/161293 wireless [iwn] hang at startup when starting network o kern/161035 wireless [ieee80211] Incorrect number describing 11ng MCS rate o kern/160391 wireless [ieee80211] [patch] Panic in mesh mode o kern/160296 wireless [zyd] [panic] 802.11 usb device reboots system on 'ifc o misc/160176 wireless [mips] [panic] Kernel panic on AR7161 platform with AR 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/155498 wireless [ral] ral(4) needs to be resynced with OpenBSD's to ga 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/153594 wireless [wlan] netif/devd race 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/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/148078 wireless [ath] wireless networking stops functioning o kern/146426 wireless [mwl] 802.11n rates not possible on mwl o kern/146425 wireless [mwl] mwl dropping all packets during and after high u 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 kern/144755 wireless [wlan] netif/devd race o bin/144109 wireless hostapd(8) uses the MAC of the wireless interface, but o conf/143079 wireless hostapd(8) startup missing multi wlan functionality 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 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 kern/121061 wireless [ath] [panic] panic while ejecting ath(4)-adapter duri 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 183 problems total. From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 11 20:10:26 2013 Return-Path: Delivered-To: wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4F490B66 for ; Mon, 11 Nov 2013 20:10:26 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10D0D2371 for ; Mon, 11 Nov 2013 20:10:25 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 6so4992062qeb.31 for ; Mon, 11 Nov 2013 12:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=QT+QimcsC+UVRAnrxkf8Qt7MASZQVbwIl4+KjwTQclY=; b=XH74/HlLuORlmiWApcCSLdK35rzZJhTsEBpPbXE/EEitiileg4HVEVHmZ9K2glOSfo uyufIgfON8WibgeOscjGnVPznBr5XFTxuazLDwKZkWLp65mcsMB88jPKf1EePAeOHEyq vy5LD0L8XFb8LJ9KVaNIaQRVnaomlckCEbI/4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=QT+QimcsC+UVRAnrxkf8Qt7MASZQVbwIl4+KjwTQclY=; b=frjJKmuYCkgBsi7gfs7H0wyvbYKmUpgq7hS3H9Dy3gbHtJocQYRHe7fdfuLd0PoaTf Hh8yA+Z6SGAR3aoaO6SfacDGnPaEO0o08qbULVqKEvgOYtei21UMdf/dcLq8yJ2iDNIR /3UexTifdLzVVyd0WQ9gHBWLTQIOBAmU9qDq2iBvZlr0EtXQuQ2SBHJY7wKcoxrHJRoX z6LzvYfw4eKVf8ZqOnLFCNso3swyrF8qs1ieMFrjdNaD3ivE/0XMVTi6IRll6fwz1wrJ xOH8ln6yhYPjtBgGvqL40c03D3/Fe02jk0+JujrGb+cvryjqYsKqN99RrL0ZDJQjmo/d BPEg== X-Gm-Message-State: ALoCoQlbfHAE5AXEMO5mKPg5of3qaBUiWnonI7XLLWlU0PjBYJoQF9cfyRILb8T/5C8CYNyl/+v2 X-Received: by 10.224.69.132 with SMTP id z4mr52091665qai.78.1384200625194; Mon, 11 Nov 2013 12:10:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Mon, 11 Nov 2013 12:09:55 -0800 (PST) From: Eitan Adler Date: Mon, 11 Nov 2013 15:09:55 -0500 Message-ID: Subject: iwn is still working! To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Nov 2013 20:10:26 -0000 Cedric, Adrian, Thanks. load: 0.48 cmd: ping 92340 [select] 55334.70r 1.28u 4.48s 0% 1528k 53094/54469 packets received (97.5%) 9.345 min / 44.002 avg / 3404.123 max iwn_tx_data: qid 11 idx 180 len 76 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 180 retries 0 nkill 0 rate e10a duration 122 status 201 iwn_tx_data: qid 11 idx 181 len 108 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 181 retries 0 nkill 0 rate e10a duration 129 status 201 iwn_tx_data: qid 11 idx 182 len 76 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 182 retries 0 nkill 0 rate e10a duration 122 status 201 iwn_tx_data: qid 11 idx 183 len 131 nsegs 2 rate 008a plcp 0x0000e10a iwn_tx_data: qid 11 idx 184 len 131 nsegs 2 rate 008a plcp 0x0000e10a iwn_tx_data: qid 11 idx 185 len 131 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 183 retries 0 nkill 0 rate e10a duration 133 status 201 iwn5000_tx_done: qid 11 idx 184 retries 1 nkill 0 rate e10a duration 194 status 201 iwn5000_tx_done: qid 11 idx 185 retries 0 nkill 0 rate e10a duration 133 status 201 iwn_tx_data: qid 11 idx 186 len 76 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 186 retries 0 nkill 0 rate e10a duration 122 status 201 iwn_tx_data: qid 11 idx 187 len 76 nsegs 2 rate 008a plcp 0x0000e10a iwn_tx_data: qid 11 idx 188 len 76 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 187 retries 0 nkill 0 rate e10a duration 122 status 201 iwn5000_tx_done: qid 11 idx 188 retries 0 nkill 0 rate e10a duration 122 status 201 iwn_tx_data: qid 11 idx 189 len 108 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 189 retries 0 nkill 0 rate e10a duration 129 status 201 iwn_tx_data: qid 11 idx 190 len 108 nsegs 2 rate 008a plcp 0x0000e10a iwn5000_tx_done: qid 11 idx 190 retries 0 nkill 0 rate e10a duration 129 status 201 -- Eitan Adler From owner-freebsd-wireless@FreeBSD.ORG Mon Nov 11 20:42:02 2013 Return-Path: Delivered-To: wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94C8D153 for ; Mon, 11 Nov 2013 20:42:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5810025AB for ; Mon, 11 Nov 2013 20:42:02 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w8so2288342qac.13 for ; Mon, 11 Nov 2013 12:42:01 -0800 (PST) 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:cc:content-type; bh=ddcQmx8YxArrylpjPRYqYm1Uhgpmx2xQSQNev3v/K84=; b=wnRoezcti2aNOH4cIkUjqIUlSMpMGCpC2J3V74oJEAqbhwS+JEl9kkOV6aU0v4QG2B djgiyq0PgJAx62JKwK+fN5V/60tnzKkoaLkHHTHg4ycACMlS25niNvrjGuH+XlTJjk3d BlWG8xQmaen796zGpBC/31PoyXc3T5rP7k0LdKjBF0rCZ4WcqcsIDNk//SQKFMz/SYPJ 6OtpsH49b3cbC/qbr9fGw6gZcPiuA1n7Rfn5a25z3Y6wHGaBYgxKCdxMF5mA3O6m05hm CgdV9yZyGqIJvFm9LnTCj1RKU+RINTI4kjAno3wCxC8qtSt4tJ4IPbq8iltJmzcBvrSW lMVg== MIME-Version: 1.0 X-Received: by 10.229.13.69 with SMTP id b5mr50706777qca.13.1384202521391; Mon, 11 Nov 2013 12:42:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 11 Nov 2013 12:42:01 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Nov 2013 12:42:01 -0800 X-Google-Sender-Auth: oC3JKEV9etpL9rItsSPxcJEMzXE Message-ID: Subject: Re: iwn is still working! From: Adrian Chadd To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Nov 2013 20:42:02 -0000 Cool! Next is fixing linkq/MRR handling. I've been told by Johannes at Intel that we don't have to do software retry ourselves. Just do MRR, then send BAR frames if we ever get a "you lost!" notification. Also, we _can_ do background scans with active traffic. The firmware does this. So, we have to fix iwn and net80211 to correctly handle this crap. -adrian On 11 November 2013 12:09, Eitan Adler wrote: > Cedric, Adrian, > > Thanks. > > > load: 0.48 cmd: ping 92340 [select] 55334.70r 1.28u 4.48s 0% 1528k > 53094/54469 packets received (97.5%) 9.345 min / 44.002 avg / 3404.123 max > > iwn_tx_data: qid 11 idx 180 len 76 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 180 retries 0 nkill 0 rate e10a duration > 122 status 201 > iwn_tx_data: qid 11 idx 181 len 108 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 181 retries 0 nkill 0 rate e10a duration > 129 status 201 > iwn_tx_data: qid 11 idx 182 len 76 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 182 retries 0 nkill 0 rate e10a duration > 122 status 201 > iwn_tx_data: qid 11 idx 183 len 131 nsegs 2 rate 008a plcp 0x0000e10a > iwn_tx_data: qid 11 idx 184 len 131 nsegs 2 rate 008a plcp 0x0000e10a > iwn_tx_data: qid 11 idx 185 len 131 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 183 retries 0 nkill 0 rate e10a duration > 133 status 201 > iwn5000_tx_done: qid 11 idx 184 retries 1 nkill 0 rate e10a duration > 194 status 201 > iwn5000_tx_done: qid 11 idx 185 retries 0 nkill 0 rate e10a duration > 133 status 201 > iwn_tx_data: qid 11 idx 186 len 76 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 186 retries 0 nkill 0 rate e10a duration > 122 status 201 > iwn_tx_data: qid 11 idx 187 len 76 nsegs 2 rate 008a plcp 0x0000e10a > iwn_tx_data: qid 11 idx 188 len 76 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 187 retries 0 nkill 0 rate e10a duration > 122 status 201 > iwn5000_tx_done: qid 11 idx 188 retries 0 nkill 0 rate e10a duration > 122 status 201 > iwn_tx_data: qid 11 idx 189 len 108 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 189 retries 0 nkill 0 rate e10a duration > 129 status 201 > iwn_tx_data: qid 11 idx 190 len 108 nsegs 2 rate 008a plcp 0x0000e10a > iwn5000_tx_done: qid 11 idx 190 retries 0 nkill 0 rate e10a duration > 129 status 201 > > > -- > Eitan Adler > _______________________________________________ > 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 Mon Nov 11 20:47:21 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 280DB787; Mon, 11 Nov 2013 20:47:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAC02261B; Mon, 11 Nov 2013 20:47:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F3DD5B9B3; Mon, 11 Nov 2013 15:47:19 -0500 (EST) From: John Baldwin To: clutton Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Mon, 11 Nov 2013 15:44:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1382572583.1862.39.camel@eva02.mbsd> <201311061159.14824.jhb@freebsd.org> <1383862923.70321.87.camel@eva02.mbsd> In-Reply-To: <1383862923.70321.87.camel@eva02.mbsd> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201311111544.15187.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 11 Nov 2013 15:47:20 -0500 (EST) Cc: freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Nov 2013 20:47:21 -0000 On Thursday, November 07, 2013 5:22:03 pm clutton wrote: > On Wed, 2013-11-06 at 11:59 -0500, John Baldwin wrote: > > On Tuesday, November 05, 2013 5:17:30 pm John Baldwin wrote: > > > On Tuesday, November 05, 2013 2:33:50 pm Bernhard Schmidt wrote: > > > > On Tue, Nov 5, 2013 at 5:54 PM, John Baldwin wrot= e: > > > > > On Sunday, November 03, 2013 12:56:08 pm Adrian Chadd wrote: > > > > >> On 2 November 2013 12:13, clutton wrote: > > > > >> > > > > >> [snip] > > > > >> > > > > >> > What was happened? netif tries to setup wlan0 (clone, wpa, dhc= p,=20 etc), > > > > >> > when wlan0 interface occurs, devd runs another copy of netif. > > > > >> > > > > >> Well, it sounds like we need to pick an architecture _and_ fix t= he > > > > >> behaviour here. > > > > >> > > > > >> Which is: > > > > >> > > > > >> > > > > >> * I think wpa-supplicant should always run if it's required in=20 /etc/rc.conf; > > > > >> * netif should check if devd is configured and if so, just leave= =20 the > > > > >> configuration up to devd > > > > >> * if it isn't running, then devd should be responsible for > > > > >> dhclient/add-to-wpa-config > > > > >> > > > > >> What we first have to establish is whether add_interface and > > > > >> remove_interface (or whatever they're called) are correctly=20 working, > > > > >> for ethernet and wifi driver types. Then, we need to ensure they= =20 can > > > > >> coexist (ie, one wpa_supplicant, but with both ethernet/wifi=20 drivers > > > > >> loaded and active on their relevant interfaces.) _then_ we can=20 break > > > > >> out the "stuff devd does" out of netif and have _either_ netif=20 (x)or > > > > >> devd call this new script to setup/teardown the interface runtime > > > > >> state. > > > > >> > > > > >> How's that sound? > > > > > > > > > > Note that devd just runs netif (via /etc/pccard_ether), so it's=20 already > > > > > just one script, and having netif bail if devd is running would m= ake > > > > > netif not do anything in the common case. > > > > > > > > > > What normally happens during boot is that '/etc/rc.d/netif start'= =20 creates > > > > > wlan0 and runs wpa_supplicant via 'childif_create' making a neste= d=20 call to > > > > > ifn_start for wlan0. That is, childif_create autoruns=20 /etc/rc.d/netif > > > > > explicitly after it creates the device. Probably that is what=20 should be > > > > > removed. That would let devd always start wpa_supplicant via > > > > > /etc/pccard_ether. I've just tested this by doing a stop/start o= n=20 iwn0 > > > > > (parent of wlan0, so wlan0 gets destroyed and re-created) and it= =20 started > > > > > wpa_supplicant correctly. > > > > > > > > > > Index: head/etc/network.subr > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > --- network.subr (revision 257705) > > > > > +++ network.subr (working copy) > > > > > @@ -1429,9 +1429,6 @@ childif_create() > > > > > fi > > > > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > > > > fi > > > > > - if autoif $child; then > > > > > - ifn_start $child > > > > > - fi > > > > > done > > > > > > > > > > # Create vlan interfaces > > > > > > > > > > I also tested vlans created via vlans_ and they should use th= e=20 same fix as > > > > > well. Note that this model is more consistent with how=20 cloned_interfaces > > > > > works where ifn_start is not explicitly run when each interface i= s=20 created. > > > > > Instead, we rely on devd kicking off pccard_ether for those as we= ll. > > > >=20 > > > > That looks sane too me. > > > >=20 > > > > Just one question, I remember that devd is disabled during boot and > > > > activated later through a sysctl (to ignore events entirely), is th= is > > > > the case before or after netif is running? I guess it is activated > > > > after netif, otherwise we would have seen this issue on booting and > > > > not just during netif restart. > > >=20 > > > Hmm, devd starts after netif, but it just worked fine for me when I=20 booted up. > > > I also misspoke about cloned_interfaces. We manually add the=20 cloned_interface > > > list to the list of interfaces /etc/rc.d/netif iterates over. What I= am > > > puzzled by is that this just worked for me during a test boot. Hmm, = it=20 looks like > > > devctl is no longer disabled during boot and then explicitly enabled = by=20 devd. > > > devctl is now always enabled during boot, but capped at 1000 entries = to=20 avoid > > > leaking memory. In fact, it looks like devd tries to recreate a few= =20 interfaces > > > after netif finishes and is generally confused. I tried again with=20 devd_flags > > > set to "-n" to flush the initial set of events on boot. This removed= =20 the > > > multiple calls to netif on boot on my laptop, but somehow wpa_supplic= ant=20 is > > > still being started by devd (and I'm not sure how now). > >=20 > > I've hacked devd some more and can now see what is going on. -n doesn'= t=20 do what > > I thought it does. It does not throw away pending events on startup, i= t=20 just > > makes devd not fork until it has walked the initial set of events. The= =20 kernel > > changed (a while ago) to queue the first 1000 events until devd starts = up. =20 This > > means that in practice devd gets arrival events for all devices in the= =20 system as > > soon as it starts up and triggers duplicate invocations of netif after= =20 netif > > finishes. However, /etc/pccard_ether ignores attempts to start a devic= e=20 that > > is already up, so this should be a no-op on bootup (if my change is=20 reverted) > > as the interfaces should already be configured by the time devd starts.= I=20 suspect > > what happens in multiuser is that devd fires off pccard_ether and sees= =20 that the > > interface isn't up before the original netif has a chance to invoke the= =20 nested > > ifn_start. We could perhaps change it so we only invoke ifn_start if d= evd > > isn't running. > >=20 > > One other thought: I restart my wireless interfaces by doing > > 'sh /etc/rc.d/netif restart wlan0', not 'iwn0'. This doesn't=20 teardown/recreate > > the wlan0 device, so it doesn't suffer from the issue reported by the O= P. > >=20 > > Here is a change I've tested that seems to do the right thing both at b= oot=20 time > > and doing a restart of either iwn0 or wlan0 at runtime. If devd is=20 running > > it leaves the task of starting an interface up to devd, otherwise (such= as=20 during > > boot), it configures the new child interface synchronously. > >=20 > > Note that pgrep is in /bin. > >=20 > > Index: network.subr > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- network.subr (revision 257747) > > +++ network.subr (working copy) > > @@ -1406,10 +1406,14 @@ clone_down() > > # > > childif_create() > > { > > - local cfg child child_vlans child_wlans create_args debug_flags ifn i > > + local cfg child child_vlans child_wlans create_args debug_flags devd \ > > + ifn i > > cfg=3D1 > > ifn=3D$1 > > =20 > > + # Check if devd is running > > + devd=3D$(pgrep devd) > > + > > # Create wireless interfaces > > child_wlans=3D`get_if_var $ifn wlans_IF` > > =20 > > @@ -1429,6 +1433,9 @@ childif_create() > > fi > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > fi > > + if [ -z "$devd" ] && autoif $child; then > > + ifn_start $child > > + fi > > done > > =20 > > # Create vlan interfaces > > @@ -1452,6 +1459,9 @@ childif_create() > > ${IFCONFIG_CMD} $i name $child && cfg=3D0 > > fi > > fi > > + if [ -z "$devd" ] && autoif $child; then > > + ifn_start $child > > + fi > > done > > =20 > > return ${cfg} > >=20 >=20 > Yes, the "service netif restart wlan0" doesn't teardown/recreate the > wlan0 device. Anyway, a "service netif restart" does. >=20 > What about removing this functionality, instead? See the patch below. >=20 > The pros: > 1) creating the wlan interface by hand (by ifconfig) means that the > further configuration is going to be in that way, by hand (by ifconfig, > route, dhcpclient, etc). > 2) already written down configuration (in rc.conf) means working with rc > subsystem (netif) > 3) I have no idea why somebody would expect from a command "ifconfig > wlan0 create wlandev ath0" the same behaviour as from a "service netif > start wlan0". Eh, I work with vlans quite a bit at work and I certainly do a model where I edit rc.conf and then create it by hand to bring it up. This is one less step than having to manually ifconfig it after creating it and then going to write to rc.conf. > 4) Let's remove the unexpected behaviour at all, it's prone error, it's > not obviously at first glance, some kind of clever computer which knows > better what do you need. I think that we have this functionality > occasionally, no one had designed this on purpose, am I wrong? I don't agree. > The cons: > I have none. You told me. >=20 >=20 > =CE=9E ~ =E2=86=92 diff -u /usr/src/etc/devd.conf /etc/devd.conf =20 > --- /usr/src/etc/devd.conf 2013-09-29 17:24:16.759250174 +0300 > +++ /etc/devd.conf 2013-11-07 23:43:17.833616197 +0200 > @@ -38,7 +38,7 @@ > # > notify 0 { > match "system" "IFNET"; > - match "subsystem" "!usbus[0-9]+"; > + match "subsystem" "!(usbus|wlan|vlan)[0-9]+"; > match "type" "ATTACH"; > action "/etc/pccard_ether $subsystem start"; > }; This isn't complete at all. Now you need to exclude everything, because what if I do 'ifconfig tap0 create' by hand? Now do you expect it to not configure that if I have bits for it in rc.conf? The usbus example here is because usbus isn't a real ifnet, but an abuse of the subsystem. wlanX and vlanX are real interfaces, they are just clone interfaces similar to tap/tun, etc. rather than "physical" interfaces liek bge0, etc. Everyone expects bge0 to auto configure if you pop in a bge cardbus card or kldload the driver. =2D-=20 John Baldwin From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 04:48:17 2013 Return-Path: Delivered-To: freebsd-wireless@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA609F85; Tue, 12 Nov 2013 04:48:17 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A49D3E70; Tue, 12 Nov 2013 04:48:13 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id rAC4lr8L062173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Nov 2013 13:48:04 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id rAC4lpo8042403; Tue, 12 Nov 2013 13:47:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 12 Nov 2013 13:47:42 +0900 (JST) Message-Id: <20131112.134742.1669584178551946391.hrs@allbsd.org> To: jhb@FreeBSD.org Subject: Re: service netif restart [iface] runs a wpa_supplicant twice From: Hiroki Sato In-Reply-To: <201311051154.18872.jhb@freebsd.org> References: <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Nov_12_13_47_42_2013_488)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 12 Nov 2013 13:48:04 +0900 (JST) X-Spam-Status: No, score=-98.8 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,SPF_SOFTFAIL,USER_IN_WHITELIST,X_CHINESE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: clutton@zoho.com, freebsd-wireless@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 04:48:18 -0000 ----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Baldwin wrote in <201311051154.18872.jhb@freebsd.org>: jh> I also tested vlans created via vlans_ and they should use the same fix as jh> well. Note that this model is more consistent with how cloned_interfaces jh> works where ifn_start is not explicitly run when each interface is created. jh> Instead, we rely on devd kicking off pccard_ether for those as well. No, for cloned_interfaces, the ifn_start will be kicked even when devd is unavailable because rc.d/netif calls clone_up() and then ifn_start() sequentially. Since an IFNET ATTACH event is generated upon clone_up(), so actually the ifn_start() runs twice on every boot time (or rc.d/netif restart ifn). Since childif_*() is invoked at the end of ifn_*(), configuration of the child interfaces does not happen. This is the reason why there was ifn_start() in childif_create(). It is not efficient and it is reasonable to leave ifn_start() to devd if available, but it is difficult to detect it correctly because the IFNET ATTACH handler may be disabled in devd.conf. "pgrep devd" is not reliable enough. As pointed out, this duplication can be a problem when configuration is performed by a program because multiple instances of the program are invoked. In the other cases, there is no problem because ifn_start() is idempotent, though. As a workaround, dhclient is not invoked from ifconfig_up() like this: 222 if wpaif $1; then 223 /etc/rc.d/wpa_supplicant start $1 224 _cfg=0 # XXX: not sure this should count 225 elif hostapif $1; then 226 /etc/rc.d/hostapd start $1 227 _cfg=0 228 fi 229 230 if dhcpif $1; then 231 if [ $_cfg -ne 0 ] ; then 232 ${IFCONFIG_CMD} $1 up 233 fi 234 if syncdhcpif $1; then 235 /etc/rc.d/dhclient start $1 236 fi 237 _cfg=0 238 fi ifconfig_IF="DHCP" means to leave invoking dhclient to devd, and ifconfig_IF="SYNCDHCP" means rc.d/netif calls dhclient directly. I think similar workaround can be implemented for WPA and HOSTAP and solve the originally-reported problem. For inconsistency childif_*(), what do you think about integrating vlans_IF and wlans_IF into cloned_interfaces and removing the childif_*() stage in ifn_*()? We can keep vlans_IF and wlans_IF as well as introduce a new syntax into cloned_interfaces like cloned_interfaces="em0.100 em0.110 em0.myvlan ath0.wlan0" which is equivalent to vlans_em0="100 110 myvlan" wlans_ath0="wlan0" The rc.d/netif does clone_up() for the child interfaces first and then does ifn_start() for them, so # service netif restart wlan0 works as expected (tear down, recreate, and reconfigure the interface). Of course, this does not solve the duplicate invocation of the netif script. To solve it, I think we need a knob to disable IFNET events in a per-interface basis temporarily. -- Hiroki ----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlKBsu4ACgkQTyzT2CeTzy37MQCgpHsiUmxgrWJT9xbljklDRJPR r0wAnRdU90LfIZn7mgQFEwvNB42WZMGs =LYHy -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Nov_12_13_47_42_2013_488)---- From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 06:21:54 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CB39FCD for ; Tue, 12 Nov 2013 06:21:54 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9272226A for ; Tue, 12 Nov 2013 06:21:53 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id k4so2583994qaq.19 for ; Mon, 11 Nov 2013 22:21:53 -0800 (PST) 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=teke8mSTdQ9n4DiVkvG1+BtB2Nw+FARoGIYiO/Ikm78=; b=o3DrLBBEKE1pcj8tkIJOhHVkGYQpzBk4VrTflFr9rcuUtXVzcRDgIHOPqT1hD4Jwu4 eTKMiiyzueJ1McryjpL7VCXVEptv0CkY10P8lhmCHDKgx5aQXMqetLX8SE0i51DoDDMT 4UHyDFbWwRpNLm6MrpGlRng9Qyq8fkjoUzTciVy1vjHsmwCOVMOU0Pg2L9bmZlSpVrrT PdO2rL9xPWj984UyFT4qbfugxsTYVg7VaQ5qRsj7XsK5u0WxkhsdARUT3R01p3MaMXST rn0mBISvbZtk5hZSbtPGPwcD6pr80VJpwotu0KAmhACy79HDYP4UgnYbYx0XPJr6Hht/ eRpA== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr55018829qac.98.1384237312997; Mon, 11 Nov 2013 22:21:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 11 Nov 2013 22:21:52 -0800 (PST) Date: Mon, 11 Nov 2013 22:21:52 -0800 X-Google-Sender-Auth: EXSVYa93ouVzBfhpgfaguF8Pl-0 Message-ID: Subject: [iwn] Cedric's stuff is in -HEAD From: Adrian Chadd To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 06:21:54 -0000 Hi, I've just committed Cedric's stuff to -HEAD. I also fixed the MRR stuff to work. It's been fun. Kinda. There are still issues with the driver. I bet the TX handling for aggregation frames isn't entirely correct. I bet the bluetooth coexistence isn't right. There's still the bugs with scanning, background scanning and things getting wedged if the NIC loses association and starts a scan. I'll attack them if I get angry enough and I can't just throw an Atheros NIC in the thing. I encourage other people to tackle these issues. I'm happy to help, but I'm feeling a bit burnt out sorting through this stuff. -adrian From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 11:56:04 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 317491CE for ; Tue, 12 Nov 2013 11:56:04 +0000 (UTC) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EC84425C7 for ; Tue, 12 Nov 2013 11:56:03 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id g10so1884940vbg.6 for ; Tue, 12 Nov 2013 03:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=BfbCdr5nKC8hZtXukMSoXq4VvVC9ewaZmULxPSnBBrQ=; b=AHuSFbVVfPjNXFymV3HQLkxeLjftlAD6NhVuKdX7D8qylgg5QjPUzhopxjeSWpe0fY TEv61y4yu58iAgSfMFmipoxf2t/XC6rZLfiRJePJrPh8hn4DGuI3nXEKqHk8lcg4CVkk 5vyW2zf3IW3+61CHZGL26mtonObWebzZWzPO6zj0fgee8WJaHEDqUiJyODJIEFh1poWA /a8Q6p3mHTjCt5cpPRnXoHKAzslmpwVU5PFjKbktf8QFLY135DQckg/5Y8WNIdJqYdRX OIXJXRIa+JnEO06Wl5l4JX0TA5NTBcaHXOild2fcQEIxLdsjbOKxNFSCnFKUfeULcdub HVLg== X-Received: by 10.52.186.228 with SMTP id fn4mr1267325vdc.34.1384257363077; Tue, 12 Nov 2013 03:56:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.228.35 with HTTP; Tue, 12 Nov 2013 03:55:43 -0800 (PST) From: Sergey Ryazanov Date: Tue, 12 Nov 2013 15:55:43 +0400 Message-ID: Subject: Atheros AR5xxx DSSS-OFDM mode support To: ath5k-devel@lists.ath5k.org, freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 11:56:04 -0000 Hi list, we test pretty old hardware based on AR5414 chip with pretty old madwifi driver, which even use binary hal. Our spectral analyzer shows that in 2.4GHz band this chip transmits OFDM-preamble with any of the OFDM rates (6-54 mbps), instead of .11b-compatable DSSS-preamble. Does anybody could provide some clue: is this chip supports DSSS-OFDM mode according to section 19.7 of IEEE 802.11-2012? When I digging the ath5k code I faced the AR_PHY_MODE (0xa200) register, which seems to controls the behavior of chip. This register contains two interesting bit: AR_PHY_MODE_MOD_CCK bit 0 (0x00000001) AR_PHY_MODE_MOD_DYN bit 3 (0x00000004) If I am correctly understand, _MOD_DYN just enables the CCK (DSSS) block. But what the purpose of the AR_PHY_MODE_MOD_CCK bit? -- BR, Sergey From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 12:24:36 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A68DCC20 for ; Tue, 12 Nov 2013 12:24:36 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4529627E3 for ; Tue, 12 Nov 2013 12:24:36 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hm11so3541211wib.2 for ; Tue, 12 Nov 2013 04:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lJvDmnHQ6J2cMf7cnzDf3einWQQPWWP4jKSd6DXW3g8=; b=RYnOIwpNY2d5rimvPucki0inu+7cLY2w3cWrzz5wvHExAoTOX+3sI9K+3x0u6l43XI OkgZBHCX0Em/JK7P6eBhVl+jf48YceDEyGD2Q5q1AusM1/R11CM1rhh2/veAwA9tO50s 2/0SPOwZVm0YZnsJVWMS25sQQu4BfgS2KXqwHmk8a0ibDdy/ZcNRSjdrKmewTI/w1hhp 1NNHML8ibPYy17qBx6h0b5lRxaQl2aIKg2+lACzOnyj+Ww8c6Q4SDqnHvFIDZpqh+R1c rPJOKyV/E9ZYnr0/PwypTX3eDug0jGF7jnvrHL+0VTUohqMiZXgAm3vPFaK6FFzXAVF7 oAZg== X-Received: by 10.194.104.42 with SMTP id gb10mr26698447wjb.16.1384259074819; Tue, 12 Nov 2013 04:24:34 -0800 (PST) Received: from [172.16.54.174] ([157.83.97.1]) by mx.google.com with ESMTPSA id gm2sm10317597wib.4.2013.11.12.04.24.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 04:24:33 -0800 (PST) Message-ID: <52821DFC.60203@gmail.com> Date: Tue, 12 Nov 2013 12:24:28 +0000 From: Nick Kossifidis User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Sergey Ryazanov Subject: Re: [ath5k-devel] Atheros AR5xxx DSSS-OFDM mode support References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ath5k-devel@lists.ath5k.org, freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 12:24:36 -0000 On Tue 12 Nov 2013 11:55:43 AM GMT, Sergey Ryazanov wrote: > Hi list, > > we test pretty old hardware based on AR5414 chip with pretty old > madwifi driver, which even use binary hal. Our spectral analyzer shows > that in 2.4GHz band this chip transmits OFDM-preamble with any of the > OFDM rates (6-54 mbps), instead of .11b-compatable DSSS-preamble. Does > anybody could provide some clue: is this chip supports DSSS-OFDM mode > according to section 19.7 of IEEE 802.11-2012? > > When I digging the ath5k code I faced the AR_PHY_MODE (0xa200) > register, which seems to controls the behavior of chip. This register > contains two interesting bit: > AR_PHY_MODE_MOD_CCK bit 0 (0x00000001) > AR_PHY_MODE_MOD_DYN bit 3 (0x00000004) > > If I am correctly understand, _MOD_DYN just enables the CCK (DSSS) > block. But what the purpose of the AR_PHY_MODE_MOD_CCK bit? > >From what I know: MOD_DYN = CCK + OFDM (for g) MOD_CCK = CCK only (for b) From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 13:26:29 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FE24D8D for ; Tue, 12 Nov 2013 13:26:29 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2449E2BD3 for ; Tue, 12 Nov 2013 13:26:29 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id pa12so1746601veb.14 for ; Tue, 12 Nov 2013 05:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ie3FBtkaP7UNNjhflE2yIVyDtAEdeqiiNZn9GKafW8c=; b=VL6KviR0OTCq5rla3Cs45qFhBu/0Cs9ygm0MFAqxgWxkEQXD3LpwFT6r8vZ6f1wsX/ 2dse4DuD/wyqbM+UPJHwmZ3K7VgGS7WV6lM5zd/QXoudkr2W0cRPYnGQ9DLD+x12aSwF sH7rLB4DQ2F8b0U8mGzNdW7Ozuz93uGzL/0/OftZE8gvjzPiGXNx5amO++FCmxeYZGW4 794cAXLX30Gag3XF6QlX/6rkOmr9pZi0hHEAZZ30oDFzKF7MOvBlN5YtsOaHCAOjgRQh jVV/alLZP+3PncR+WSaEzpDVEEWsf8b12jJb0waF8TKr7mrjqTBRWw4w9wsfxdC1fhyR mHGw== X-Received: by 10.220.244.132 with SMTP id lq4mr1475657vcb.31.1384262788211; Tue, 12 Nov 2013 05:26:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.228.35 with HTTP; Tue, 12 Nov 2013 05:26:08 -0800 (PST) In-Reply-To: <52821DFC.60203@gmail.com> References: <52821DFC.60203@gmail.com> From: Sergey Ryazanov Date: Tue, 12 Nov 2013 17:26:08 +0400 Message-ID: Subject: Re: [ath5k-devel] Atheros AR5xxx DSSS-OFDM mode support To: Nick Kossifidis Content-Type: text/plain; charset=ISO-8859-1 Cc: ath5k-devel@lists.ath5k.org, freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 13:26:29 -0000 2013/11/12 Nick Kossifidis : > On Tue 12 Nov 2013 11:55:43 AM GMT, Sergey Ryazanov wrote: >> Hi list, >> >> we test pretty old hardware based on AR5414 chip with pretty old >> madwifi driver, which even use binary hal. Our spectral analyzer shows >> that in 2.4GHz band this chip transmits OFDM-preamble with any of the >> OFDM rates (6-54 mbps), instead of .11b-compatable DSSS-preamble. Does >> anybody could provide some clue: is this chip supports DSSS-OFDM mode >> according to section 19.7 of IEEE 802.11-2012? >> >> When I digging the ath5k code I faced the AR_PHY_MODE (0xa200) >> register, which seems to controls the behavior of chip. This register >> contains two interesting bit: >> AR_PHY_MODE_MOD_CCK bit 0 (0x00000001) >> AR_PHY_MODE_MOD_DYN bit 3 (0x00000004) >> >> If I am correctly understand, _MOD_DYN just enables the CCK (DSSS) >> block. But what the purpose of the AR_PHY_MODE_MOD_CCK bit? >> > > From what I know: > MOD_DYN = CCK + OFDM (for g) > MOD_CCK = CCK only (for b) > Thank you Nick, for your quick answer, may be you know, why we need such explicit option (I mean MOD_CCK bit)? If we would like to act as pure dot11b node, then we could simply limit rate set to DSSS/CCK rates only. Did you know something about DSSS-OFDM mode support in the AR5xxx chips, is it possible at all? -- BR, Sergey From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 18:41:40 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25BA3CC2; Tue, 12 Nov 2013 18:41:40 +0000 (UTC) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DEE82C1F; Tue, 12 Nov 2013 18:41:39 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id t10so3372728eei.10 for ; Tue, 12 Nov 2013 10:41:37 -0800 (PST) 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=EW0b0IthbGlWEN62i2TRpX53w137izp/0265jn0i7kY=; b=Zsx4qEg0yKOV8hIKTVpwRLY+v1k2oB/aY4lNBNJ2z+EVK6soSxYwcTPeMlh97/Fqtn 14lI3cnc/4aKcyW5qCA1+rFRg/FlI4vrKtN2kr3O2660J3n79Fz2ZGS/gsRXPexjRGP4 E6jcVxW3HTzHptpifVz5KvyXjh26MGU4tKlKcH7nTfpyqJNiL6s/ysBqnlNNptZSP8Us hHinBCGcfH2MK+ZeuRa0HsWphGaaRKxlPLri4AzEiKbrPLZXTqnLjq2iDcnw1AsHbL7W sIIiY6UFLB6XrvQbFNygz1AAACLBO4+52Tr6av2YJD3S/4aWnHFhP31Zs82wzEaXFo4L 7Q4A== MIME-Version: 1.0 X-Received: by 10.14.98.195 with SMTP id v43mr3600414eef.44.1384281697816; Tue, 12 Nov 2013 10:41:37 -0800 (PST) Received: by 10.14.127.195 with HTTP; Tue, 12 Nov 2013 10:41:37 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 10:41:37 -0800 Message-ID: Subject: Re: [iwn] Cedric's stuff is in -HEAD From: hiren panchasara To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 18:41:40 -0000 On Mon, Nov 11, 2013 at 10:21 PM, Adrian Chadd wrote: > Hi, > > I've just committed Cedric's stuff to -HEAD. I also fixed the MRR stuff to work. With latest everything + http://people.freebsd.org/~adrian/iwn/20131111-iwn-linkq-2stream-ant-fix-1.diff flymockour-l7% sysctl dev.iwn.0 dev.iwn.0.%desc: Intel Centrino Advanced-N 6205 dev.iwn.0.%driver: iwn dev.iwn.0.%location: slot=0 function=0 dev.iwn.0.%pnpinfo: vendor=0x8086 device=0x0085 subvendor=0x8086 subdevice=0x1311 class=0x028000 dev.iwn.0.%parent: pci3 dev.iwn.0.debug: 1 It stayed up for good 15 mins and then I saw this: Nov 12 10:25:47 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 114 retries 0 nkill 0 rate 8000e10d duration 139 status 201 Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 115 len 108 nsegs 2 rate 008d plcp 0x0000e10d Nov 12 10:25:48 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 115 retries 0 nkill 0 rate 8000e10d duration 139 status 201 Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 116 len 0 nsegs 0 rate 008d plcp 0x0000e10d Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 116 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 1 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 6 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 11 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 7 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel 13 status 1 Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 117 len 0 nsegs 0 rate 008d plcp 0x0000e10d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 118 len 108 nsegs 2 rate 008d plcp 0x0000e10d Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 117 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 118 retries 0 nkill 0 rate 8000e10d duration 139 status 201 Nov 12 10:25:50 flymockour-l7 kernel: iwn_notif_intr: scanning channel 13 status 1 Nov 12 10:25:50 flymockour-l7 kernel: received statistics without RSSI Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: wlan0: Trying to associate with 6c:f3:7f:4d:88:27 (SSID='Y!Office' freq=2437 MHz) Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 119 len 0 nsegs 0 rate 008d plcp 0x0000e10d Nov 12 10:25:50 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 119 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 0: nr=16, rate=0x8d, rateentry=0x8f Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 1: nr=16, rate=0x8d, rateentry=0x8e Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx 2: nr=16, rate=0x8d, rateentry=0x8d Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 120 len 0 nsegs 0 rate 008d plcp 0x0000e10d Nov 12 10:25:50 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 120 retries 0 nkill 0 rate 8000e10d duration 132 status 201 Nov 12 10:25:50 flymockour-l7 kernel: wlan0: link state changed to DOWN Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: wlan0: CTRL-EVENT-DISCONNECTED bssid=6c:f3:7f:4d:88:27 reason=0 Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address And yeah, dhclient never works. I have to kill is and restart it manually all the time. Let me know and I can get more info/logs. From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 18:45:07 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6C22E45 for ; Tue, 12 Nov 2013 18:45:07 +0000 (UTC) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79DD12C42 for ; Tue, 12 Nov 2013 18:45:07 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id n9so5467917qcw.29 for ; Tue, 12 Nov 2013 10:45:06 -0800 (PST) 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:cc:content-type; bh=uAUl2tERHIEjexO3FEO/bSUj8NxWzVKXAdwzoY3q/KE=; b=CYZibKvn/FxoqFXiCsQupuKCb00A4RFDV6tVimmm9/04MCC8hgp4S+k3/mRQ1Z//dF KX8l5EGGVBsK22BEKBpSp4KpKYs3gMk3HUjbDlPylO47ALSyqv4hkhZkZ4Sqip0hTJpl vWIqFYXuRZgSWCYAU4dMjtw8LXprhIMNZcu6FkgaiAveqNRUYI+/Lq1l8Mm+c42DwenN LuI3uf4fr+EEk+PSdvPx84PR1lQyfkPu5CqrJ1g2hX8NgFV0u370kILz4/nFGrH+oose AvFzVcQd3H6/GnSQCesrRzZ0uOA2aTlB0naaZhNLRZr3PbSPZzqIiY0clq187xQOo6Li qHZA== MIME-Version: 1.0 X-Received: by 10.224.98.200 with SMTP id r8mr61436224qan.26.1384281906700; Tue, 12 Nov 2013 10:45:06 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 12 Nov 2013 10:45:06 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 10:45:06 -0800 X-Google-Sender-Auth: KQ1gwX_7_XI8To_y7GEbWzDUYXE Message-ID: Subject: Re: [iwn] Cedric's stuff is in -HEAD From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 18:45:07 -0000 Run with wlandebug +assoc +state +debug +output +scan +crypto On 12 November 2013 10:41, hiren panchasara wrote: > On Mon, Nov 11, 2013 at 10:21 PM, Adrian Chadd wrote: >> Hi, >> >> I've just committed Cedric's stuff to -HEAD. I also fixed the MRR stuff to work. > > With latest everything + > http://people.freebsd.org/~adrian/iwn/20131111-iwn-linkq-2stream-ant-fix-1.diff > > flymockour-l7% sysctl dev.iwn.0 > dev.iwn.0.%desc: Intel Centrino Advanced-N 6205 > dev.iwn.0.%driver: iwn > dev.iwn.0.%location: slot=0 function=0 > dev.iwn.0.%pnpinfo: vendor=0x8086 device=0x0085 subvendor=0x8086 > subdevice=0x1311 class=0x028000 > dev.iwn.0.%parent: pci3 > dev.iwn.0.debug: 1 > > It stayed up for good 15 mins and then I saw this: > > Nov 12 10:25:47 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 114 > retries 0 nkill 0 rate 8000e10d duration 139 status 201 > Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 0: nr=16, rate=0x8d, rateentry=0x8f > Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 1: nr=16, rate=0x8d, rateentry=0x8e > Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 2: nr=16, rate=0x8d, rateentry=0x8d > Nov 12 10:25:48 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 115 len > 108 nsegs 2 rate 008d plcp 0x0000e10d > Nov 12 10:25:48 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 115 > retries 0 nkill 0 rate 8000e10d duration 139 status 201 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 0: nr=16, rate=0x8d, rateentry=0x8f > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 1: nr=16, rate=0x8d, rateentry=0x8e > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 2: nr=16, rate=0x8d, rateentry=0x8d > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 116 len 0 > nsegs 0 rate 008d plcp 0x0000e10d > Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 116 > retries 0 nkill 0 rate 8000e10d duration 132 status 201 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel > 1 status 1 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel > 6 status 1 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel > 11 status 1 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel > 7 status 1 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_notif_intr: scanning channel > 13 status 1 > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 0: nr=16, rate=0x8d, rateentry=0x8f > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 1: nr=16, rate=0x8d, rateentry=0x8e > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 2: nr=16, rate=0x8d, rateentry=0x8d > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 117 len 0 > nsegs 0 rate 008d plcp 0x0000e10d > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 0: nr=16, rate=0x8d, rateentry=0x8f > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 1: nr=16, rate=0x8d, rateentry=0x8e > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 2: nr=16, rate=0x8d, rateentry=0x8d > Nov 12 10:25:49 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 118 len > 108 nsegs 2 rate 008d plcp 0x0000e10d > Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 117 > retries 0 nkill 0 rate 8000e10d duration 132 status 201 > Nov 12 10:25:49 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 118 > retries 0 nkill 0 rate 8000e10d duration 139 status 201 > Nov 12 10:25:50 flymockour-l7 kernel: iwn_notif_intr: scanning channel > 13 status 1 > Nov 12 10:25:50 flymockour-l7 kernel: received statistics without RSSI > Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: wlan0: Trying to > associate with 6c:f3:7f:4d:88:27 (SSID='Y!Office' freq=2437 MHz) > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 0: nr=16, rate=0x8d, rateentry=0x8f > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 1: nr=16, rate=0x8d, rateentry=0x8e > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 2: nr=16, rate=0x8d, rateentry=0x8d > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 119 len 0 > nsegs 0 rate 008d plcp 0x0000e10d > Nov 12 10:25:50 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 119 > retries 0 nkill 0 rate 8000e10d duration 132 status 201 > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 0: nr=16, rate=0x8d, rateentry=0x8f > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 1: nr=16, rate=0x8d, rateentry=0x8e > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_rate_to_linkq_offset: idx > 2: nr=16, rate=0x8d, rateentry=0x8d > Nov 12 10:25:50 flymockour-l7 kernel: iwn_tx_data: qid 0 idx 120 len 0 > nsegs 0 rate 008d plcp 0x0000e10d > Nov 12 10:25:50 flymockour-l7 kernel: iwn5000_tx_done: qid 0 idx 120 > retries 0 nkill 0 rate 8000e10d duration 132 status 201 > Nov 12 10:25:50 flymockour-l7 kernel: wlan0: link state changed to DOWN > Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: ioctl[SIOCS80211, > op=20, val=0, arg_len=7]: Can't assign requested address > Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: wlan0: > CTRL-EVENT-DISCONNECTED bssid=6c:f3:7f:4d:88:27 reason=0 > Nov 12 10:25:50 flymockour-l7 wpa_supplicant[8743]: ioctl[SIOCS80211, > op=20, val=0, arg_len=7]: Can't assign requested address > > And yeah, dhclient never works. I have to kill is and restart it > manually all the time. > > Let me know and I can get more info/logs. From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 19:13:41 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1ED08A1; Tue, 12 Nov 2013 19:13:41 +0000 (UTC) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58C002E09; Tue, 12 Nov 2013 19:13:41 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id e53so3395831eek.0 for ; Tue, 12 Nov 2013 11:13:39 -0800 (PST) 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=c7D1txh5KWyhGH+1VdNiRd+0tTbpd/uq0F649JpZhW4=; b=mJGBqyjXAoLc3SJnxdrj6fI8zlGSR0Ug6AvX7Rimu+nYlXvjUgk/Ng20aT/7frdwoy f9nFACq9oqD3A76UvKmsln73jqMwxC5VNDzDoJFDKb3rOYZy61LVzYAID9vh1VGeZkSe tVUFrAsHZ5arFyGAN4PxRtdjXCxxk+b8uTZ2moJowN9nEomUl43FGys+pOHXPV5b8OLy fDGBeXf333gKHth5/COFq3ucgzc8h/6KqwNMT/lxilogVrvmMPixPwqYfhvPeRBn49+c NLEpnqJoQZ8Yc/3vbS1hv1I7avAv9fKFbK9gsOlkrA2eDuwN8MXmx9InsPGCJtdv8AYq WbrQ== MIME-Version: 1.0 X-Received: by 10.15.99.72 with SMTP id bk48mr44184113eeb.22.1384283619671; Tue, 12 Nov 2013 11:13:39 -0800 (PST) Received: by 10.14.127.195 with HTTP; Tue, 12 Nov 2013 11:13:39 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 11:13:39 -0800 Message-ID: Subject: Re: [iwn] Cedric's stuff is in -HEAD From: hiren panchasara To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 19:13:41 -0000 On Tue, Nov 12, 2013 at 10:45 AM, Adrian Chadd wrote: > Run with wlandebug +assoc +state +debug +output +scan +crypto http://people.freebsd.org/~hiren/20131112_iwnfail_atwork.txt Thanks a bunch Adrian! From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 19:54:57 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E17AF462; Tue, 12 Nov 2013 19:54:57 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1682F213F; Tue, 12 Nov 2013 19:54:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 11F4BB918; Tue, 12 Nov 2013 14:54:56 -0500 (EST) From: John Baldwin To: Hiroki Sato Subject: Re: service netif restart [iface] runs a wpa_supplicant twice Date: Tue, 12 Nov 2013 13:54:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <1383419596.3253.42.camel@eva02.mbsd> <201311051154.18872.jhb@freebsd.org> <20131112.134742.1669584178551946391.hrs@allbsd.org> In-Reply-To: <20131112.134742.1669584178551946391.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201311121354.03923.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 12 Nov 2013 14:54:56 -0500 (EST) Cc: clutton@zoho.com, freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 19:54:58 -0000 On Monday, November 11, 2013 11:47:42 pm Hiroki Sato wrote: > John Baldwin wrote > in <201311051154.18872.jhb@freebsd.org>: > > jh> I also tested vlans created via vlans_ and they should use the same fix as > jh> well. Note that this model is more consistent with how cloned_interfaces > jh> works where ifn_start is not explicitly run when each interface is created. > jh> Instead, we rely on devd kicking off pccard_ether for those as well. > > No, for cloned_interfaces, the ifn_start will be kicked even when > devd is unavailable because rc.d/netif calls clone_up() and then > ifn_start() sequentially. Since an IFNET ATTACH event is generated > upon clone_up(), so actually the ifn_start() runs twice on every boot > time (or rc.d/netif restart ifn). Yes, I missed this earlier. > Since childif_*() is invoked at the end of ifn_*(), configuration of > the child interfaces does not happen. This is the reason why there > was ifn_start() in childif_create(). Well, the child interfaces are not listed in list_network_interfaces. That explicitly adds cloned_interfaces to the list. > It is not efficient and it is reasonable to leave ifn_start() to devd > if available, but it is difficult to detect it correctly because the > IFNET ATTACH handler may be disabled in devd.conf. "pgrep devd" is > not reliable enough. Agreed that it is not perfect, and I don't really like it. However, I assumed that people who leave devd enabled but disable the IFNET ATTACH handler must already know enough about what they are doing to fix this on their own. :) I think there are two common use cases that we should make work out of the box: 1) People who use devd with a stock devd.conf. 2) People who don't use devd at all. I'm not sure we need to support the case of people hacking up a custom devd.conf directly in the base system. > As pointed out, this duplication can be a problem when configuration > is performed by a program because multiple instances of the program > are invoked. In the other cases, there is no problem because > ifn_start() is idempotent, though. Yes. One thought I had was to just fix /etc/rc.d/wpa_supplicant so that it was idempotent. If wpa_supplicant is the only one that really needs fixing I would favor that fix as the simplest one. > For inconsistency childif_*(), what do you think about integrating > vlans_IF and wlans_IF into cloned_interfaces and removing the > childif_*() stage in ifn_*()? We can keep vlans_IF and wlans_IF as > well as introduce a new syntax into cloned_interfaces like > > cloned_interfaces="em0.100 em0.110 em0.myvlan ath0.wlan0" > > which is equivalent to > > vlans_em0="100 110 myvlan" > wlans_ath0="wlan0" > > The rc.d/netif does clone_up() for the child interfaces first and > then does ifn_start() for them, so > > # service netif restart wlan0 > > works as expected (tear down, recreate, and reconfigure the > interface). cloned_interfaces already supports vlans (em0.100, etc.). The problems I had when we used that were: 1) if_vlan was not implicitly loaded, so we always cloned a vlan999 dummy device to load it 2) If we stopped an interface (typically on kldunload of the base driver), the vlan interfaces were orphaned. They stayed around, but with no parent. If a newer version of the driver was loaded via kldload, the vlan interfaces were not recreated. With vlans_IF, the right thing happens if you do 'stop foo0' and 'start foo0'. In particular if you do a 'stop foo0' before you kldunload foo, then all of foo0's subinterfaces are created and configured when you kldload foo. > Of course, this does not solve the duplicate invocation of the netif > script. To solve it, I think we need a knob to disable IFNET events > in a per-interface basis temporarily. Eh, I thought about doing some hackish thing to do that, but it seemed even more fragile and gross than the 'pgrep devd' hack. In particular, you could do this in /etc/rc.d/devd: devd_precmd() { touch /tmp/disable_netif } devd_postcmd() { rm /tmp/disable_netif } rc.conf: devd_flags="-n" And have /etc/pccard_ether bail if /tmp/disable_netif exists. This would let devd drain through all the queued up events at boot ignoring any IFNET ATTACH events by having pccard_ether bail. -- John Baldwin From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 20:19:41 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DA0D468 for ; Tue, 12 Nov 2013 20:19:41 +0000 (UTC) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40C4A2328 for ; Tue, 12 Nov 2013 20:19:41 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id t7so2784707qeb.38 for ; Tue, 12 Nov 2013 12:19:40 -0800 (PST) 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:cc:content-type; bh=NvxRfkAdjzD7ABQdUMM7Ip9n8s8HJZP0KoTOfNX9GoA=; b=TqknTN8eZ0hYUJ8OFYuN5anFn/iH7gHdJe71r3d+aOEZD5mqGQGnkh+h+RyvANcf7m o2k5Pk2um+bfFoBo+BXhgyJG2GC+5qqhhKj3LJFt3jLt/80Mw6VQvBr0QFtHITm/6U8n axFhbqURNwNtH97HSOptMupLk2YSDvHBOHWyzTTGp4LsnfXS9ufv3rb+R+dv2RP4ceex n7LtJE4gdPnuYmUHTn+6eWMAMFH6V1MQgePGF/oyYH2ulatXPxeM4W5IuJ0Zv6xC9/Pv Pnhs/YDXqCmMTjM6n52zedkFII2y3cBb3OPYJGc2lDPkoNqtuqr1LpMUIeo0W8Ij11Lw WvaA== MIME-Version: 1.0 X-Received: by 10.229.72.194 with SMTP id n2mr15753526qcj.7.1384287580344; Tue, 12 Nov 2013 12:19:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 12 Nov 2013 12:19:40 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 12:19:40 -0800 X-Google-Sender-Auth: lJYCU5NBUMUcXEjewtSqDDd0J44 Message-ID: Subject: Re: [iwn] Cedric's stuff is in -HEAD From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 20:19:41 -0000 On 12 November 2013 11:13, hiren panchasara wrote: > On Tue, Nov 12, 2013 at 10:45 AM, Adrian Chadd wrote: >> Run with wlandebug +assoc +state +debug +output +scan +crypto > > http://people.freebsd.org/~hiren/20131112_iwnfail_atwork.txt What's this showing? What was going on at this time? > Thanks a bunch Adrian! so, I have a feeling that for "best" iwn(4) behaviour, we should likely extend net80211 to not do its own scan stuff (by putting the VAP into power save mode whilst doing scanning) but just to fire off a scan request. I _think_ iwn(4) will do it itself. We should however still fix the scan code to not be a racy, unpredictable thing. -adrian From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 20:28:58 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 571418B5; Tue, 12 Nov 2013 20:28:58 +0000 (UTC) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C06AE23D1; Tue, 12 Nov 2013 20:28:57 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id c13so3388703eek.20 for ; Tue, 12 Nov 2013 12:28:56 -0800 (PST) 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=YDw7HXRMf8Hz7xyFRUBlUE+4Bj9gJ+7dooF6w3UctCY=; b=VLHveip4ZzrFx9/eNGX7GOlC/zxAKOv84/uuBz3oo5zZY2PX7Q0WuWCk9PAEjc8WZL NAyYRacaGyimxWRT3n8XgRcDvtPMSKN6sJECuesv2O/ZJJoawhsME5WtM6OX2QedJHaL 3bKNc1p2h1skKY7rL5bPIL7p41bI+NnW+v8USy4n4FJwvyfkdq/RgDInJ1ghZIjC9r8o Mw89/K/Chp1jo1Vhg+Sn6+X4wUewVEQGyfx/8GVcQsrFIxAX9+7xVl+whtW2Ako+CMa3 mJij6wBvytE1lWByNNLcaoJ67NnhSicrwdnQU3yMIAjaMMbmp0930gfgBF/TdU8nOhZ9 kZhA== MIME-Version: 1.0 X-Received: by 10.14.111.129 with SMTP id w1mr4167330eeg.83.1384288136180; Tue, 12 Nov 2013 12:28:56 -0800 (PST) Received: by 10.14.127.195 with HTTP; Tue, 12 Nov 2013 12:28:56 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 12:28:56 -0800 Message-ID: Subject: Re: [iwn] Cedric's stuff is in -HEAD From: hiren panchasara To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 20:28:58 -0000 On Tue, Nov 12, 2013 at 12:19 PM, Adrian Chadd wrote: > On 12 November 2013 11:13, hiren panchasara wrote: >> On Tue, Nov 12, 2013 at 10:45 AM, Adrian Chadd wrote: >>> Run with wlandebug +assoc +state +debug +output +scan +crypto >> >> http://people.freebsd.org/~hiren/20131112_iwnfail_atwork.txt > > What's this showing? What was going on at this time? I keep pings going on another window just to see when it stops. It was doing alright (pings going through) and suddenly "stops working" around following lines in logs: Nov 12 10:59:51 flymockour-l7 kernel: wlan0: ieee80211_bg_scan: active scan, ticks 7165936 duration 150 Nov 12 10:59:51 flymockour-l7 kernel: wlan0: [6c:f3:7f:4d:88:47] send QoS null data frame on channel 1, pwr mgt ena and then it tries scanning and what not but never recovers. Funny (read annoying) thing is, its not failing in the same way every time it disconnects. I do not see the same pattern. And by "stops working" I see, it still has ip and ssid but "status: no carrier" in ifconfig. > >> Thanks a bunch Adrian! > > so, I have a feeling that for "best" iwn(4) behaviour, we should > likely extend net80211 to not do its own scan stuff (by putting the > VAP into power save mode whilst doing scanning) but just to fire off a > scan request. I _think_ iwn(4) will do it itself. > > We should however still fix the scan code to not be a racy, unpredictable thing. I am not sure if I follow. Any more clues you can throw based on the logs? Thanks again, Hiren From owner-freebsd-wireless@FreeBSD.ORG Tue Nov 12 20:51:24 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 558B079B for ; Tue, 12 Nov 2013 20:51:24 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 17936256C for ; Tue, 12 Nov 2013 20:51:24 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id v2so1928343qcr.5 for ; Tue, 12 Nov 2013 12:51:23 -0800 (PST) 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:cc:content-type; bh=mnxDrl2VvZg2UXAN+ljtUZeAS88eqZWAYvnSUqKLhPc=; b=LbUpfQ49FGOlc5LWzkI0zxUsmNqe520O6KSue/XV7SfFt9vCO1zeMDEK0Nuru3UhNm YBMKyCU3rrONLyc5WBtJiNmseUI+80k0MDPA1+cUy9zDoo2Txl2ywgMeQshMUnAYml8v oySXqFWE769uB+0IglvJV07sN7O5SmiNbcXYdO9kSPWJL9OyywdE7Z6ov2hkjZmP77VJ soDyLxr3qV7ag0v3fbuYsIMM7vTSLDaBGtWT5lrAKcvBRZo0Ki71wiHkEiWGnl2pyEgG xMmOjdgUhFp/axxz6peAt2BxZhvAazZ/7h8sxnoH6pJE3belJjZ63CjvUJ1mHT4lqJE6 llfA== MIME-Version: 1.0 X-Received: by 10.224.64.200 with SMTP id f8mr62479383qai.55.1384289483111; Tue, 12 Nov 2013 12:51:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Tue, 12 Nov 2013 12:51:23 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Nov 2013 12:51:23 -0800 X-Google-Sender-Auth: pMT2cFIGB9SOpYmEqEu5UoTjDXY Message-ID: Subject: Re: [iwn] Cedric's stuff is in -HEAD From: Adrian Chadd To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 12 Nov 2013 20:51:24 -0000 ok, try recreating the vap but with -bgscan -ampdutx -adrian From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 13 21:40:47 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4237D83 for ; Wed, 13 Nov 2013 21:40:47 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8F72E21DB for ; Wed, 13 Nov 2013 21:40:47 +0000 (UTC) Received: from [74.130.196.19] ([74.130.196.19:20591] helo=localhost) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 4B/D9-02506-7D1F3825; Wed, 13 Nov 2013 21:40:39 +0000 Date: Wed, 13 Nov 2013 21:40:39 +0000 Message-ID: <4B.D9.02506.7D1F3825@cdptpa-oedge01> From: "Thomas Mueller" To: freebsd-wireless@freebsd.org Subject: 802.11b or g compared to n or ac X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 13 Nov 2013 21:40:47 -0000 Is there any support for 802.11n in FreeBSD? I notice at least some of the drivers support b and g but not n. This is also true on NetBSD and OpenBSD. Is this particular to some particular drivers such as rsu and urtwn or is it more general, BSD-wide? I've been unable to pick up any network scanning from FreeBSD with rsu (Hiro 50191 USB-stick adapter, chipset RTL8191SU). I wonder if this could be dus to limitations of b and g. >From D-Link http://resource.dlink.com/articles/buying-guides/router-wireless-adapter-buying-guide/ 802.11b is good for a paperweight, 802.11g is good for a replacement paperweight, 802.11n is good, 802.11ac is better yet. Tom From owner-freebsd-wireless@FreeBSD.ORG Wed Nov 13 22:01:20 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DB94744 for ; Wed, 13 Nov 2013 22:01:20 +0000 (UTC) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 038F32397 for ; Wed, 13 Nov 2013 22:01:19 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so718938qeb.33 for ; Wed, 13 Nov 2013 14:01:19 -0800 (PST) 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:cc:content-type; bh=e3W2SFYGYN/aSk00+K1A7AOYfw+0D5IaAMU9oDgpY5Y=; b=h2YK9Mp1A3n7DVhaxgiRA5GGRpaLfoN5yj8u/V7Z6/PmBJxtRLogsjRkwGK0tFttOk NMWA2eUtIneR1C3wIDYg8uix2y0eGIetnYiMIAOUYVT+eKEkwXFuS5LYB8zdSDVd0PJf 82IFMrWWJQe1KdLsAF78jbiO0JlM/0J0zwXqxnxurZVo+fuBPyFlh1EhxMMMECzuZq2O ejjovG7F/cv8ZOD3XbP4IQQmDHPXhWd3+x8ZuGawu00v+OLnc3ZcKHVxBoHZZ0gsMynT jqrmotlpqv4a89Yx59SJ6Lt3HvN3WmoDEZafylkA/3ltUzH03CB1bvlXwMxP/0Y0ZBe9 Zvjw== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr70544047qac.98.1384380079189; Wed, 13 Nov 2013 14:01:19 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 13 Nov 2013 14:01:19 -0800 (PST) In-Reply-To: <4B.D9.02506.7D1F3825@cdptpa-oedge01> References: <4B.D9.02506.7D1F3825@cdptpa-oedge01> Date: Wed, 13 Nov 2013 14:01:19 -0800 X-Google-Sender-Auth: se2S-jNmQKb6EVSleX53OYSsAMA Message-ID: Subject: Re: 802.11b or g compared to n or ac From: Adrian Chadd To: Thomas Mueller Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 13 Nov 2013 22:01:20 -0000 Hi! The stack supports 11n. There's a bunch of 11n capable PCI/PCIe and USB hardware. All the Atheros PCI/PCIe 11n hardware is supported. I'm fixing up the intel support to do 11n "right". Which version of FreeBSD are you using? You should be running 10.0 for "working" 11n. -adrian On 13 November 2013 13:40, Thomas Mueller wrote: > Is there any support for 802.11n in FreeBSD? > > I notice at least some of the drivers support b and g but not n. > > This is also true on NetBSD and OpenBSD. > > Is this particular to some particular drivers such as rsu and urtwn or is it more general, BSD-wide? > > I've been unable to pick up any network scanning from FreeBSD with rsu (Hiro 50191 USB-stick adapter, chipset RTL8191SU). > > I wonder if this could be dus to limitations of b and g. > > From D-Link > > http://resource.dlink.com/articles/buying-guides/router-wireless-adapter-buying-guide/ > > 802.11b is good for a paperweight, > 802.11g is good for a replacement paperweight, > 802.11n is good, > 802.11ac is better yet. > > > Tom > > _______________________________________________ > 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 Thu Nov 14 04:38:16 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE108C8C for ; Thu, 14 Nov 2013 04:38:16 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id 78E7B2B08 for ; Thu, 14 Nov 2013 04:38:15 +0000 (UTC) Received: from [74.130.196.19] ([74.130.196.19:16182] helo=localhost) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 72/87-27821-6B354825; Thu, 14 Nov 2013 04:38:15 +0000 Date: Thu, 14 Nov 2013 04:38:14 +0000 Message-ID: <72.87.27821.6B354825@cdptpa-oedge02> From: "Thomas Mueller" To: freebsd-wireless@freebsd.org References: <4B.D9.02506.7D1F3825@cdptpa-oedge01> Subject: Re: 802.11b or g compared to n or ac X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 14 Nov 2013 04:38:16 -0000 > The stack supports 11n. > There's a bunch of 11n capable PCI/PCIe and USB hardware. > All the Atheros PCI/PCIe 11n hardware is supported. > I'm fixing up the intel support to do 11n "right". > Which version of FreeBSD are you using? You should be running 10.0 for > "working" 11n. -adrian On the computer with MSI Z77 MPOWER motherboard, I have installations of FreeBSD 10.0-BETA1 for both amd64 and i386, and FreBSD-HEAD also for both amd64 and i386. This motherboard has onboard Atheros AR9271 wi-fi, quasi-USB, and I also have Hiro H50191 USB-stick wi-fi adapter, driver rsu. On the other computer, I have FreeBSD 9.2-STABLE, have compiled ndis driver for this Hiro for WinXP, Vista and 7, all 64-bit, but this awaits testing with my USB-stick installation of FreeBSD 9.2-STABLE. I noticed that rsu and urtwn are in FreeBSD beginning with 10.0, and athn is in NetBSD beginning with HEAD (6.99.xx). Tom From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 14 22:42:33 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70CC9EE8 for ; Thu, 14 Nov 2013 22:42:33 +0000 (UTC) Received: from denrei.darkbsd.org (denrei.darkbsd.org [IPv6:2001:41d0:1:f442::1]) by mx1.freebsd.org (Postfix) with ESMTP id 38150246F for ; Thu, 14 Nov 2013 22:42:33 +0000 (UTC) Received: from denrei.darkbsd.org (localhost [127.0.0.1]) by denrei.darkbsd.org (Postfix) with ESMTP id 559C0DC8 for ; Thu, 14 Nov 2013 23:42:29 +0100 (CET) X-Virus-Scanned: amavisd-new at darkbsd.org Received: from denrei.darkbsd.org ([127.0.0.1]) by denrei.darkbsd.org (denrei.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uq6pxIP9pt9Y for ; Thu, 14 Nov 2013 23:42:23 +0100 (CET) Received: from fusen (lns-bzn-49f-62-147-170-46.adsl.proxad.net [62.147.170.46]) (Authenticated sender: c.prevotaux@rural-networks.com) by denrei.darkbsd.org (Postfix) with ESMTPSA id 5C076DC7 for ; Thu, 14 Nov 2013 23:42:22 +0100 (CET) Date: Thu, 14 Nov 2013 23:42:20 +0100 From: Christophe Prevotaux To: freebsd-wireless@freebsd.org Subject: Using 3T3R Atheros 802.11n PCIe card in 2T2R mode Message-ID: <20131114234220.68ab67d7@fusen> Organization: Rural Networks X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 14 Nov 2013 22:42:33 -0000 Hi everyone, I would like to know a few things: Is it possible to configure a 3T3R PCIe Atheros based card to turn it into a 2T2R equivalent ? ( ie using only 2 antennas and voiding the use of the 3rd one). If so how do you do this in FreeBSD ? Which version of FreeBSD will support that ( I guess 10 >) Any of you have recommendation on a known good card ? If there are multiple chipset that can do this I would like to know which one. Regards Christophe From owner-freebsd-wireless@FreeBSD.ORG Thu Nov 14 22:47:54 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2E8DF8B for ; Thu, 14 Nov 2013 22:47:54 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7860124A2 for ; Thu, 14 Nov 2013 22:47:54 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id cm18so104309qab.16 for ; Thu, 14 Nov 2013 14:47:53 -0800 (PST) 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:cc:content-type; bh=f6Ki3I29poOzbZDQWeouTlbw4grX0R4DcitYNOi/K8Y=; b=bnX6huq6BT5g1eAkOpGaFmoMe59iEdXuOJwtSvmb6xAFNqt8ATaLFmXYpLWN/Vu+0F bqC14qYq5JZCjegSC5P7UX8XHqh5/vh1vAbYpKlWwsT+q5OOyY5SZqj8Jid7L5jNhS0K 82bOxsYluXHwhtdczjoCDjM/cWZu0sA8dYtiduDMgOsoeufxmSVEcAlkQ8A5kblwVOaj 2BHE2PXqvwwuy3Cr5sgCBroLhpzJMdwhwWEoceN5D5yqRXrmnOT9IIUjYzmhuDQIqt1V ZurJuPtZgT3jizlwSMLihxALRW69OUQxorWuxvRF4DQjtwp/vepTiL0JCsBKZebqDmaa nOyQ== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr5943635qac.98.1384469273628; Thu, 14 Nov 2013 14:47:53 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 14 Nov 2013 14:47:53 -0800 (PST) In-Reply-To: <20131114234220.68ab67d7@fusen> References: <20131114234220.68ab67d7@fusen> Date: Thu, 14 Nov 2013 14:47:53 -0800 X-Google-Sender-Auth: neGnStOev47WMG9Ztvxmu_XOSPA Message-ID: Subject: Re: Using 3T3R Atheros 802.11n PCIe card in 2T2R mode From: Adrian Chadd To: Christophe Prevotaux Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 14 Nov 2013 22:47:54 -0000 Hi! On 14 November 2013 14:42, Christophe Prevotaux wrote: > > Hi everyone, > > I would like to know a few things: > > Is it possible to configure a 3T3R PCIe Atheros based card > to turn it into a 2T2R equivalent ? ( ie using only 2 antennas and > voiding the use of the 3rd one). Yup. But you can only do it on certain combinations. I think the only supported combination is enabling chain 0 and chain 2. > > If so how do you do this in FreeBSD ? You set a kenv variable that resource_int_value() can read at bootup. I _think_ it's: hint.ath.X.rx_chainmask= hint.ath.X.tx_chainmask= It's in ath_attach() in if_ath.c. Look for resource_int_value(). > Which version of FreeBSD will support that ( I guess 10 >) Yup, > 10 and later. > Any of you have recommendation on a known good card ? > > If there are multiple chipset that can do this I would > like to know which one. It should work for all of them. The one thing I need to validate though is the whole "calibration" versus "use" thing. In theory, we should be calibrating all of the chainmasks that are present in the EEPROM but only _using_ the ones we override for transmit and receive. I don't know if the HAL code is doing this. It would certainly be a simple enough project for someone to tackle. Thanks, -adrian From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 16 10:54:25 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C9E7C4E for ; Sat, 16 Nov 2013 10:54:25 +0000 (UTC) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.225]) by mx1.freebsd.org (Postfix) with ESMTP id 575162A5F for ; Sat, 16 Nov 2013 10:54:24 +0000 (UTC) Received: from [96.28.178.143] ([96.28.178.143:47008] helo=localhost) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 87/6E-31125-9DE47825; Sat, 16 Nov 2013 10:54:17 +0000 Date: Sat, 16 Nov 2013 10:54:17 +0000 Message-ID: <87.6E.31125.9DE47825@cdptpa-oedge03> From: "Thomas Mueller" To: freebsd-wireless@freebsd.org Subject: Question about online ath man page regarding access point X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 16 Nov 2013 10:54:25 -0000 I see in the man page for ath, and assume much would apply to other wireless adapters, Create an 802.11g host-based access point: ifconfig wlan0 create wlandev ath0 wlanmode hostap ifconfig wlan0 inet 192.168.0.10 netmask 0xffffff00 ssid my_ap \ mode 11g but would the access point, with wired connection, have or use the wireless adapter? Access point, if I understand correctly, would have a wired connection, such as cable or DSL, and the other computer, with the wireless adapter, would have the Atheros or other wireless adapter. Or is this done from the wireless client? Situation I'm thinking of is where a wireless router has Ethernet connection and perheps one computer connects by Ethernet, and one or more other computers or wireless devices want to connect wirelessly. Tom From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 16 15:28:59 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D9EF68E for ; Sat, 16 Nov 2013 15:28:59 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CA7BD2620 for ; Sat, 16 Nov 2013 15:28:58 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rAGFSuD2042225; Sat, 16 Nov 2013 08:28:56 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rAGFSu98042222; Sat, 16 Nov 2013 08:28:56 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 16 Nov 2013 08:28:56 -0700 (MST) From: Warren Block To: Thomas Mueller Subject: Re: Question about online ath man page regarding access point In-Reply-To: <87.6E.31125.9DE47825@cdptpa-oedge03> Message-ID: References: <87.6E.31125.9DE47825@cdptpa-oedge03> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 16 Nov 2013 08:28:56 -0700 (MST) Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.16 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, 16 Nov 2013 15:28:59 -0000 On Sat, 16 Nov 2013, Thomas Mueller wrote: > I see in the man page for ath, and assume much would apply to other wireless adapters, > > Create an 802.11g host-based access point: > > ifconfig wlan0 create wlandev ath0 wlanmode hostap > ifconfig wlan0 inet 192.168.0.10 netmask 0xffffff00 ssid my_ap \ > mode 11g > > > but would the access point, with wired connection, have or use the wireless adapter? "hostap" is to make a FreeBSD system with a wireless card into a wireless router. > Access point, if I understand correctly, would have a wired > connection, such as cable or DSL, and the other computer, with the > wireless adapter, would have the Atheros or other wireless adapter. No, a router generally has at least two network interfaces. A FreeBSD wireless router would have both wired and wireless interfaces.