From owner-freebsd-wireless@freebsd.org Thu Oct 27 23:54:57 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BE57C244A1 for ; Thu, 27 Oct 2016 23:54:57 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (wsip-72-214-30-30.sd.sd.cox.net [72.214.30.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33AC8D8C for ; Thu, 27 Oct 2016 23:54:56 +0000 (UTC) (envelope-from papowell@astart.com) Received: from laptop_103.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.9/8.14.9) with ESMTP id u9RNi7uc056288 for ; Thu, 27 Oct 2016 16:44:07 -0700 (PDT) (envelope-from papowell@astart.com) Reply-To: papowell@astart.com Subject: Re: [Bug 213621] WIFI connection is lost periodically on ath0 References: To: freebsd-wireless@freebsd.org From: Patrick Powell Organization: Astart Technologies Message-ID: Date: Thu, 27 Oct 2016 16:44:07 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Oct 2016 23:54:57 -0000 On 10/22/16 13:30, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213621 > > --- Comment #12 from Adrian Chadd --- > Hiya, > > So the beacon miss / TSFOOR is the driver side. I can go take another look at > fixing that up. > > The CCMP replay attack thing - that we need another NIC to sniff the air in > monitor mode and try to capture the invalid PN showing up in the air. If it's > coming over the air then sure, we can nail it down. If it's not coming over the > air, and instead it's corrupted by the AR9380 NIC, we're in trouble. > > I need to go double / triple-check to see if we pass frames that fail > CRC/FCS/decrypt up to the stack for incorrect processing. I'm kinda worried > that we're processing invalid frames a little too far along the input / > decryption path. > Ummm... I am not familiar with this device, but I have run into similar issues on other IO devices. Do you have a spare/replacement device you can substitute in? It turned out that on one system one of the device chip registers was magically 'losing' a bit. We did not discover the cause of this problem until after much pain and effort and we replaced the motherboard. After that experience, I always try a replacement device first. Also, if is software related then the replacement will continue to show the problem. If it is hardware then you will get NO problems, or if Murphy's Law is active, DIFFERENT problems. Good luck, Adrian, you have solved some REALLY weird problems before. -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting 858-874-6543 FAX 858-751-2435 Web: www.astart.com