From owner-freebsd-current@FreeBSD.ORG Tue Jul 5 16:25:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9538E16A41C for ; Tue, 5 Jul 2005 16:25:14 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D86943D46 for ; Tue, 5 Jul 2005 16:25:14 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j65GNrms036968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2005 09:25:14 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42CAB549.7010409@errno.com> Date: Tue, 05 Jul 2005 09:28:57 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johann Hugo References: <200507051430.04322.jhugo@icomtek.csir.co.za> In-Reply-To: <200507051430.04322.jhugo@icomtek.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath client loose connection to ath hostap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2005 16:25:14 -0000 Johann Hugo wrote: > Hi > > I have 2x soekris 4501 units with atheros adapters, 1=hostap mode, 1=client. > With a continues ping, everything keeps running (16+ hours), but after an > inactive period they lose connectivity. The client still reports it is > associated, but there is no IP connectivity. After "ath down" + "ath up" it > does not want to associated with hostap any more. After client reboot it > works fine again. After inactive period - same problem. I believe Tai-hwa Liang has a fix for this pending re approval. You're seeing beacon misses on the client but when the client scans to reassociate it bogusly creates a new entry in the scan cache and things get confused. If his commit doesn't fix your problem check on the ap side to see if there are auth+associate requests coming in when you get a beacon miss on the client. Sam