From owner-freebsd-mobile@FreeBSD.ORG Sun May 1 05:40:02 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814571065674 for ; Sun, 1 May 2011 05:40:02 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id ABB9E8FC16 for ; Sun, 1 May 2011 05:40:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p415dOGo027201; Sun, 1 May 2011 15:39:24 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 1 May 2011 15:39:24 +1000 (EST) From: Ian Smith To: Anton Shterenlikht In-Reply-To: <20110430220055.GB31905@mech-cluster241.men.bris.ac.uk> Message-ID: <20110501144052.M85801@sola.nimnet.asn.au> References: <20110427221701.GA63285@mech-cluster241.men.bris.ac.uk> <4DB8A3D9.7000705@chillt.de> <20110430220055.GB31905@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Bartosz Fabianowski , freebsd-mobile@freebsd.org Subject: Re: acpiconf shows 100%, but laptop switches off X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 05:40:02 -0000 On Sat, 30 Apr 2011, Anton Shterenlikht wrote: > On Thu, Apr 28, 2011 at 01:16:41AM +0200, Bartosz Fabianowski wrote: > > >Design capacity: 1 mAh > > >Last full capacity: 1 mAh > > > > Those are obviously bogus values. Your battery quite likely is actually > > dead and provides 20 minutes of run-time only. But since its capacity is > > not being reported properly via ACPI for some reason, FreeBSD has no way > > of knowing that. > > > > - Bartosz > > Thanks. I wonder whether ACPI is working correctly > at all. What other things can I check? If there were problems with ACPI, you would most likely see some ACPI messages in dmesg regarding battery status, or problems showing the EC (embedded controller) having trouble communicating with the battery. This seems more likely a battery failure than a problem with ACPI, both from misreporting its capacity and the actual behaviour of the battery under load. The best course would be to replace the battery, preferably with a genuine or at least fully compatible one, and see how that goes. The little chips on the battery that record charge in and out, voltage and estimated capacity can get well out of synch with the real situation especially when there isn't regular use of the laptop on battery, which is why many manufacturers recommend 'conditioning' cycles - where the battery is run down to total exhaustion without shutting down (best done from eg the BIOS setup screen, where no filesystems are at risk), then fully charging the battery - sometimes repeating that twice or thrice. 'Conditioning' can a) raise 'Last full capacity' to a greater fraction of the original 'Design capacity' (likely in the range 3,000 - 5,000mAh) and b) improve the battery's estimate of capacity and/or time remaining. That said, I've not seen a battery misreport 'Design capacity' before, nor show silly values (also 1mAh) for 'warn' and 'low' capacities which are usually about 2-3% and 1% of full capacity, respectively. But then, what's 1%, or even 100%, of (the misreported) 1mAh remaining capacity? Only one cell needs to die, either short or high internal resistance, to render a battery pack useless, unless you're prepared to open the pack to replace single cells. At 4 years old, I wouldn't bother trying. It should be useful to compare acpiconf -i0 data with your new battery. cheers, Ian From owner-freebsd-mobile@FreeBSD.ORG Sun May 1 09:39:25 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC07106564A; Sun, 1 May 2011 09:39:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D01968FC18; Sun, 1 May 2011 09:39:24 +0000 (UTC) Received: by vws18 with SMTP id 18so4861721vws.13 for ; Sun, 01 May 2011 02:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=B9VTnHk5KTOEmmJwLRYYFb1z9RoAujfyIF7CT6WcH2E=; b=JFjpz7FeLWPaZCmvfNEGMTw3ndobxuncBlF6t16wrlYgBF+RnPBx+6Mci2pE5n4fTE X2LzIgbfOeHBtgpGg2UFODuP8POE+XXN4Vy540a2Racn03OqZoe8G+oAWA5Go+nll6mU crJqREjS68+ahzEEEUw0GbZ9B33D9Vkim8L5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xqFlD4yYglIPDlbuaRJ2vbrdwgTubPFOLocfLBTFVFPfhFDQXJVRTPCPZCI4xMfiRg iEwnN3Cfb6AYWUNPoOAMg3nl/xkyBQu5Op8iQuzInH7Ci1QqFuxSLY+YAeuGM11bixl+ sKQon0TClESWi5mqyXzsEY9/AWDH4kgPsYMRM= MIME-Version: 1.0 Received: by 10.52.180.104 with SMTP id dn8mr7761159vdc.302.1304242763939; Sun, 01 May 2011 02:39:23 -0700 (PDT) Received: by 10.52.157.202 with HTTP; Sun, 1 May 2011 02:39:23 -0700 (PDT) Date: Sun, 1 May 2011 17:39:23 +0800 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mobile@freebsd.org Subject: [wireless] Request for help - iperf TCP tests and out of order packets X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 09:39:25 -0000 Hi all, I'm just trying to trace down some out of order TCP packet issues that I'm seeing with my ath wireless development. I'm currently lacking non-atheros hardware (I know, it's quite silly :-) so I'm after testing from both ath and other wifi device users. What I'd like done is this: On the FreeBSD station: * clear the statistics # netstat -sp tcp -z * run iperf in the background # iperf -s & On some device connected via ethernet: $ iperf -c -t 120 * then on the station # netstat -sp tcp | grep order If you can then repeat the same tests with the freebsd station instead connected directly via ethernet (via a switch is fine), that'd be great. Then please email me (privately) the results, so we don't spam up the lists. I'll post a summary. Thanks, Adrian From owner-freebsd-mobile@FreeBSD.ORG Sun May 1 11:18:17 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464C3106564A; Sun, 1 May 2011 11:18:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBD1D8FC17; Sun, 1 May 2011 11:18:16 +0000 (UTC) Received: by vws18 with SMTP id 18so4892357vws.13 for ; Sun, 01 May 2011 04:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=paPAoaP3H39gAWxELukfhOj3mn/OcZ9C6WFo3yklJ+g=; b=B3OVn3h+tnCliNmbeOnJadDxRG9h5Ds99xLSjECsvu0cXV6NQ72Dl8lgi69geIxHL9 69rn045hD4xvCya7DDPGNBf8148WslAWInzNXS4e2DbQN+0F87g8IKX9v7GqoybU0Z9Z wYLn97huTRcyO9QqpmxH/xa7yEnelClNJ1Tn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Z8r5hqPdXReV3CQACpFxwrmx2gQCJtpzKCvf8aKMh7DlVXH76NXXzO0a++XKLkO+9Z rU/1u4j6kDDwLv+xdYz+0KOpa5K7o+f85F55Y2MYbUmuSMTyT2WJmo8QH7iF/zIB5+U+ QWTC2Px8zywMM0AekDbwiKmhcdmF2T7bEa1E0= MIME-Version: 1.0 Received: by 10.52.175.165 with SMTP id cb5mr2971838vdc.62.1304248696128; Sun, 01 May 2011 04:18:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.157.202 with HTTP; Sun, 1 May 2011 04:18:16 -0700 (PDT) In-Reply-To: <20110501111327.GL1664@albert.catwhisker.org> References: <20110501111327.GL1664@albert.catwhisker.org> Date: Sun, 1 May 2011 19:18:16 +0800 X-Google-Sender-Auth: ylyiQ70qelJdz-7xKLfvVGOVGYw Message-ID: From: Adrian Chadd To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-wireless@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [wireless] Request for help - iperf TCP tests and out of order packets X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 11:18:17 -0000 (Replying with useful info to the MLs.) Any/all versions of FreeBSD are appreciated. :) Please report the FreeBSD version on the client/server, the wifi hardware type, the dmesg describing said wifi hardware, and the details of the access point. Thanks, Adrian On 1 May 2011 19:13, David Wolfskill wrote: > On Sun, May 01, 2011 at 05:39:23PM +0800, Adrian Chadd wrote: >> ... >> What I'd like done is this: >> >> On the FreeBSD station: >> >> * clear the statistics >> >> =A0 # netstat -sp tcp -z >> >> * run iperf in the background >> >> =A0 # iperf -s & >> >> On some device connected via ethernet: >> >> =A0 $ iperf -c -t 120 >> >> * then on the station >> >> # netstat -sp tcp | grep order >> >> If you can then repeat the same tests with the freebsd station instead >> connected directly via ethernet (via a switch is fine), that'd be >> great. >> .... > > Running any particular version of FreeBSD? > > Peace, > david > -- > David H. Wolfskill =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > From owner-freebsd-mobile@FreeBSD.ORG Sun May 1 19:55:09 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CC751065676 for ; Sun, 1 May 2011 19:55:09 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id AFC588FC22 for ; Sun, 1 May 2011 19:55:08 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1QGcjS-0006iF-AZ; Sun, 01 May 2011 20:55:06 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QGcjR-0000lq-M7; Sun, 01 May 2011 20:55:05 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id p41Jt5bs039272; Sun, 1 May 2011 20:55:05 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id p41Jt4Aa039271; Sun, 1 May 2011 20:55:04 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Sun, 1 May 2011 20:55:04 +0100 From: Anton Shterenlikht To: Ian Smith Message-ID: <20110501195504.GA39246@mech-cluster241.men.bris.ac.uk> References: <20110427221701.GA63285@mech-cluster241.men.bris.ac.uk> <4DB8A3D9.7000705@chillt.de> <20110430220055.GB31905@mech-cluster241.men.bris.ac.uk> <20110501144052.M85801@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110501144052.M85801@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: Bartosz Fabianowski , Anton Shterenlikht , freebsd-mobile@freebsd.org Subject: Re: acpiconf shows 100%, but laptop switches off X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 19:55:09 -0000 On Sun, May 01, 2011 at 03:39:24PM +1000, Ian Smith wrote: > On Sat, 30 Apr 2011, Anton Shterenlikht wrote: > > On Thu, Apr 28, 2011 at 01:16:41AM +0200, Bartosz Fabianowski wrote: > > > >Design capacity: 1 mAh > > > >Last full capacity: 1 mAh > > > > > > Those are obviously bogus values. Your battery quite likely is actually > > > dead and provides 20 minutes of run-time only. But since its capacity is > > > not being reported properly via ACPI for some reason, FreeBSD has no way > > > of knowing that. > > > > > > - Bartosz > > > > Thanks. I wonder whether ACPI is working correctly > > at all. What other things can I check? > > If there were problems with ACPI, you would most likely see some ACPI > messages in dmesg regarding battery status, or problems showing the EC > (embedded controller) having trouble communicating with the battery. > > This seems more likely a battery failure than a problem with ACPI, both > from misreporting its capacity and the actual behaviour of the battery > under load. The best course would be to replace the battery, preferably > with a genuine or at least fully compatible one, and see how that goes. > > The little chips on the battery that record charge in and out, voltage > and estimated capacity can get well out of synch with the real situation > especially when there isn't regular use of the laptop on battery, which > is why many manufacturers recommend 'conditioning' cycles - where the > battery is run down to total exhaustion without shutting down (best done > from eg the BIOS setup screen, where no filesystems are at risk), then > fully charging the battery - sometimes repeating that twice or thrice. > > 'Conditioning' can a) raise 'Last full capacity' to a greater fraction > of the original 'Design capacity' (likely in the range 3,000 - 5,000mAh) > and b) improve the battery's estimate of capacity and/or time remaining. > > That said, I've not seen a battery misreport 'Design capacity' before, > nor show silly values (also 1mAh) for 'warn' and 'low' capacities which > are usually about 2-3% and 1% of full capacity, respectively. But then, > what's 1%, or even 100%, of (the misreported) 1mAh remaining capacity? > > Only one cell needs to die, either short or high internal resistance, to > render a battery pack useless, unless you're prepared to open the pack > to replace single cells. At 4 years old, I wouldn't bother trying. > > It should be useful to compare acpiconf -i0 data with your new battery. > > cheers, Ian Many thanks Anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-mobile@FreeBSD.ORG Wed May 4 02:26:17 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CD67106566B; Wed, 4 May 2011 02:26:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4DB8FC17; Wed, 4 May 2011 02:26:16 +0000 (UTC) Received: by vxc34 with SMTP id 34so934127vxc.13 for ; Tue, 03 May 2011 19:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l1ElypN4UVXqEbOCEGRgjRPit5eBeuNjK45qJVILIW8=; b=g5f6zjm4gWdkJyIwbHCx4P4L8za6NbPOvJx3W+TBVE7sHUtpPg3rwg0L82VQEg8FWN k9l6eosXrH+ovA4dX9tbdPP0oyVvCdjg7U/T3YhHjm/dPZLXV5VIxm0RNSDHttNNW8G3 XKycF6eMzDm3H8BIgabzPjtxgIxpU/glzKQ2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ctFAxGTbAhoDqsRJ41XUxu2SoJWOM2SYqz4hduE41P8FaKKIBddQNBNE3eWzhMg0TX YSy5eMVedCji0Pq86Sa8qtek351SLzy0lqBRaN4g8XDRHjLBQgWJ7EBpfkiHNvuutgeH IIlRF0MhdKVHC6Ct/FPRAnxk8lqOr38Q9jZMk= MIME-Version: 1.0 Received: by 10.52.183.136 with SMTP id em8mr656979vdc.262.1304475975528; Tue, 03 May 2011 19:26:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.157.202 with HTTP; Tue, 3 May 2011 19:26:15 -0700 (PDT) In-Reply-To: <201105040223.p442Nx1r026636@svn.freebsd.org> References: <201105040223.p442Nx1r026636@svn.freebsd.org> Date: Wed, 4 May 2011 10:26:15 +0800 X-Google-Sender-Auth: HnTPwcFqwYEXKnfHNOSAGZhKlHY Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current , freebsd-mobile@freebsd.org Subject: Fwd: svn commit: r221418 - head/sys/net80211 X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 02:26:17 -0000 This has the potential to subtly break things, so I'd appreciate it if users of wireless devices would please test this out and let me know if it breaks anything. Thanks, Adrian ---------- Forwarded message ---------- From: Adrian Chadd Date: 4 May 2011 10:23 Subject: svn commit: r221418 - head/sys/net80211 To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Author: adrian Date: Wed May =A04 02:23:59 2011 New Revision: 221418 URL: http://svn.freebsd.org/changeset/base/221418 Log: =A0Fix some corner cases in the net80211 sequence number retransmission =A0handling. =A0The current sequence number code does a few things incorrectly: =A0* It didn't try eliminating duplications from HT nodes. I guess it's ass= umed =A0 =A0that out of order / retransmission handling would be handled by the = AMPDU RX =A0 =A0routines. If a HT node isn't doing AMPDU RX, then retransmissions ne= ed to =A0 =A0be eliminated. Since most of my debugging is based on this (as AMPDU= TX =A0 =A0software packet aggregation isn't yet handled), handle this corner c= ase. =A0* When a sequence number of 4095 was received, any subsequent sequence n= umber =A0 =A0is going to be (by definition) less than 4095. So if the following s= equence =A0 =A0number (0) doesn't initially occur and the retransmit is received, i= t's =A0 =A0incorrectly eliminated by the IEEE80211_FC1_RETRY && SEQ_LEQ() check= . =A0 =A0Try to handle this better. =A0This almost completely eliminates out of order TCP statistics showing up= during =A0iperf testing for the 11a, 11g and non-aggregate 11n AMPDU RX case. The = only =A0other packet loss conditions leading to this are due to baseband resets = or =A0heavy interference. Modified: =A0head/sys/net80211/ieee80211_adhoc.c =A0head/sys/net80211/ieee80211_hostap.c =A0head/sys/net80211/ieee80211_input.h =A0head/sys/net80211/ieee80211_mesh.c =A0head/sys/net80211/ieee80211_sta.c =A0head/sys/net80211/ieee80211_wds.c Modified: head/sys/net80211/ieee80211_adhoc.c =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_adhoc.c Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_adhoc.c Wed May =A04 02:23:59 2011 =A0(r221418) @@ -285,7 +285,6 @@ doprint(struct ieee80211vap *vap, int su =A0static int =A0adhoc_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -412,9 +411,7 @@ adhoc_input(struct ieee80211_node *ni, s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bssi= d, "duplicate", @@ -660,7 +657,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static int Modified: head/sys/net80211/ieee80211_hostap.c =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_hostap.c =A0 =A0 =A0 =A0Wed May =A04 01:39:= 44 2011 =A0 =A0 =A0 =A0(r221417) +++ head/sys/net80211/ieee80211_hostap.c =A0 =A0 =A0 =A0Wed May =A04 02:23:= 59 2011 =A0 =A0 =A0 =A0(r221418) @@ -472,7 +472,6 @@ doprint(struct ieee80211vap *vap, int su =A0static int =A0hostap_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf= ) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -572,9 +571,7 @@ hostap_input(struct ieee80211_node *ni, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bssi= d, "duplicate", @@ -914,7 +911,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static void Modified: head/sys/net80211/ieee80211_input.h =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_input.h Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_input.h Wed May =A04 02:23:59 2011 =A0(r221418) @@ -142,6 +142,104 @@ ishtinfooui(const uint8_t *frm) =A0 =A0 =A0 =A0return frm[1] > 3 && LE_READ_4(frm+2) =3D=3D ((BCM_OUI_HTINF= O<<24)|BCM_OUI); =A0} +#include =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* For le16toh() */ + +/* + * Check the current frame sequence number against the current TID + * state and return whether it's in sequence or should be dropped. + * + * Since out of order packet and duplicate packet eliminations should + * be done by the AMPDU RX code, this routine blindly accepts all + * frames from a HT station w/ a TID that is currently doing AMPDU-RX. + * HT stations without WME or where the TID is not doing AMPDU-RX + * are checked like non-HT stations. + * + * The routine only eliminates packets whose sequence/fragment + * match or are less than the last seen sequence/fragment number + * AND are retransmits It doesn't try to eliminate out of order packets. + * + * Since all frames after sequence number 4095 will be less than 4095 + * (as the seqnum wraps), handle that special case so packets aren't + * incorrectly dropped - ie, if the next packet is sequence number 0 + * but a retransmit since the initial packet didn't make it. + */ +static __inline int +ieee80211_check_rxseq(struct ieee80211_node *ni, struct ieee80211_frame *w= h) +{ +#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) +#define =A0 =A0 =A0 =A0SEQ_EQ(a,b) =A0 =A0 ((int)((a)-(b)) =3D=3D 0) +#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) +#define =A0 =A0 =A0 =A0SEQNO(a) =A0 =A0 =A0 =A0((a) >> IEEE80211_SEQ_SEQ_S= HIFT) +#define =A0 =A0 =A0 =A0FRAGNO(a) =A0 =A0 =A0 ((a) & IEEE80211_SEQ_FRAG_MAS= K) + =A0 =A0 =A0 uint16_t rxseq; + =A0 =A0 =A0 uint8_t type; + =A0 =A0 =A0 uint8_t tid; + =A0 =A0 =A0 struct ieee80211_rx_ampdu *rap; + + =A0 =A0 =A0 rxseq =3D le16toh(*(uint16_t *)wh->i_seq); + =A0 =A0 =A0 type =3D wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; + + =A0 =A0 =A0 /* Types with no sequence number are always treated valid */ + =A0 =A0 =A0 if (! HAS_SEQ(type)) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1; + + =A0 =A0 =A0 tid =3D ieee80211_gettid(wh); + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* Only do the HT AMPDU check for WME stations; non-WME HT = stations + =A0 =A0 =A0 =A0* shouldn't exist outside of debugging. We should at least + =A0 =A0 =A0 =A0* handle that. + =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 if (tid < WME_NUM_TID) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rap =3D &ni->ni_rx_ampdu[tid]; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* HT nodes currently doing RX AMPDU are alwa= ys valid */ + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211_NODE_HT) && + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (rap->rxa_flags & IEEE80211_AGGR_RUNN= ING)) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1; + =A0 =A0 =A0 } + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* Otherwise, retries for packets below or equal to the las= t + =A0 =A0 =A0 =A0* seen sequence number should be dropped. + =A0 =A0 =A0 =A0*/ + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* Treat frame seqnum 4095 as special due to boundary + =A0 =A0 =A0 =A0* wrapping conditions. + =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 if (SEQNO(ni->ni_rxseqs[tid]) =3D=3D 4095) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Drop retransmits on seqnum 4095/current = fragment for itself. + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (SEQ_EQ(rxseq, ni->ni_rxseqs[tid]) && + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80211_FC1_RETRY)) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Treat any subsequent frame as fine if th= e last seen frame + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* is 4095 and it's not a retransmit for th= e same sequence + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* number. However, this doesn't capture in= correctly ordered + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* fragments w/ sequence number 4095. It sh= ouldn't be seen + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* in practice, but see the comment above f= or further info. + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 1; + =A0 =A0 =A0 } + + =A0 =A0 =A0 /* + =A0 =A0 =A0 =A0* At this point we assume that retransmitted seq/frag numb= ers below + =A0 =A0 =A0 =A0* the current can simply be eliminated. + =A0 =A0 =A0 =A0*/ + =A0 =A0 =A0 if ((wh->i_fc[1] & IEEE80211_FC1_RETRY) && + =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni_rxseqs[tid])) + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0; + + =A0 =A0 =A0 return 1; +#undef SEQ_LEQ +#undef SEQ_EQ +#undef HAS_SEQ +#undef SEQNO +#undef FRAGNO +} + =A0void =A0 ieee80211_deliver_data(struct ieee80211vap *, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct ieee80211_node *, struct mbuf *); =A0struct mbuf *ieee80211_defrag(struct ieee80211_node *, Modified: head/sys/net80211/ieee80211_mesh.c =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_mesh.c =A0Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_mesh.c =A0Wed May =A04 02:23:59 2011 =A0(r221418) @@ -1040,7 +1040,6 @@ mesh_isucastforme(struct ieee80211vap *v =A0static int =A0mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -1094,9 +1093,7 @@ mesh_input(struct ieee80211_node *ni, st =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wh->= i_addr1, "duplicate", Modified: head/sys/net80211/ieee80211_sta.c =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_sta.c =A0 Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_sta.c =A0 Wed May =A04 02:23:59 2011 =A0(r221418) @@ -512,7 +512,6 @@ doprint(struct ieee80211vap *vap, int su =A0static int =A0sta_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -591,9 +590,7 @@ sta_input(struct ieee80211_node *ni, str =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >= =3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.w= me_hipri_traffic++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t= *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211= _NODE_HT) =3D=3D 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80= 211_FC1_RETRY) && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni= _rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(n= i, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate= , discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DI= SCARD_MAC(vap, IEEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bssi= d, "duplicate", @@ -910,7 +907,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static void Modified: head/sys/net80211/ieee80211_wds.c =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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/sys/net80211/ieee80211_wds.c =A0 Wed May =A04 01:39:44 2011 =A0(r221417) +++ head/sys/net80211/ieee80211_wds.c =A0 Wed May =A04 02:23:59 2011 =A0(r221418) @@ -406,7 +406,6 @@ wds_newstate(struct ieee80211vap *vap, e =A0static int =A0wds_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf) =A0{ -#define =A0 =A0 =A0 =A0SEQ_LEQ(a,b) =A0 =A0((int)((a)-(b)) <=3D 0) =A0#define =A0 =A0 =A0 =A0HAS_SEQ(type) =A0 ((type & 0x4) =3D=3D 0) =A0 =A0 =A0 =A0struct ieee80211vap *vap =3D ni->ni_vap; =A0 =A0 =A0 =A0struct ieee80211com *ic =3D ni->ni_ic; @@ -495,9 +494,7 @@ wds_input(struct ieee80211_node *ni, str =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TID_TO_WME_AC(tid) >=3D WME_AC_VI) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ic->ic_wme.wme_hipri_traffic= ++; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rxseq =3D le16toh(*(uint16_t *)wh->i_seq); - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((ni->ni_flags & IEEE80211_NODE_HT) =3D=3D= 0 && - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (wh->i_fc[1] & IEEE80211_FC1_RETRY) &= & - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 SEQ_LEQ(rxseq, ni->ni_rxseqs[tid])) { + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (! ieee80211_check_rxseq(ni, wh)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* duplicate, discard */ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_DISCARD_MAC(vap, I= EEE80211_MSG_INPUT, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wh->i_addr1, "duplic= ate", @@ -741,7 +738,6 @@ out: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0return type; -#undef SEQ_LEQ =A0} =A0static void From owner-freebsd-mobile@FreeBSD.ORG Sat May 7 10:52:10 2011 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35BA8106564A; Sat, 7 May 2011 10:52:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id D7CA18FC12; Sat, 7 May 2011 10:52:09 +0000 (UTC) Received: by yie12 with SMTP id 12so1793093yie.13 for ; Sat, 07 May 2011 03:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=vpVLvJdbcisy47Vx6GQefaW5m4AEFxB+4gFXv4+lE1I=; b=Vw+R9YFTwmtjE3B0/LQmxttoG9fBPlkHtRZR4zQmrQbii5M8oFxzkzbfxX4BjjHQuB R6rzmW6UeFZhh9f4V0AXEI2/R7g0fovkjLrOY5AoEez1qwrJ7wOayn5KRQngz55M6dfw Vk/NRD6HywSfK1jM5C+Hw352VenS2M/50n8zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=UyawjB8z32/Sq7FzlR1B/HAG0LLBEjEEx0aTai6WcNlaJhCZq2gmbL8dAJ0kV7fmwQ A+c0qJo6pcpVJOXUMrqzf7gNvhOxY7Qy5ApnZD8EAXxoM4/uSZaS5DIcIklcRyU2cD1U wj5l7uXuhk0aUxNZDbQXwaUP/a1rXblVQFdjU= MIME-Version: 1.0 Received: by 10.150.66.14 with SMTP id o14mr265842yba.353.1304765529089; Sat, 07 May 2011 03:52:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.136.8 with HTTP; Sat, 7 May 2011 03:52:09 -0700 (PDT) Date: Sat, 7 May 2011 18:52:09 +0800 X-Google-Sender-Auth: fVHaZwxfoDOtI02n2a42Fwrpni0 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mobile@freebsd.org Subject: Does anyone have a laptop with an AR9280/AR9285 and Bluetooth in it? X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 10:52:10 -0000 Hi all, Does anyone have a laptop with an AR9280/AR9285 in it, along with Bluetooth? I'm looking for someone who's interested in getting bluetooth coexistence support working in the atheros driver and has the hardware. I'd like to stay focused on 11n and general radio/chipset support. Please let me know if you've got something with this and know a little bit about C. It's likely a good project to get down and dirty with the atheros wireless codebase. Thanks! Adrian