Subject: Re: Back to an old ath association issue
To: Konstantin KABASSANOV <Konstantin.Kabassanov@lip6.fr>
From: Chavdar Ivanov <firstname.lastname@example.org>
Date: 05/01/2006 23:09:26
On 01/05/06, Konstantin KABASSANOV <Konstantin.Kabassanov@lip6.fr> wrote:
> Some mounts ago, there was a discussion about unexpected disassociations =
> ath clients from access points. After that, a number of important changes
> occurred in the source code, but the problem still remains unchanged.
> May 1 16:49:33 pc-04 /netbsd: ath1: link state changed to DOWN
> May 1 16:49:40 pc-04 /netbsd: ath1: link state changed to UP
Same happens to me with a ral client when using WPA with
wpa_supplicant; not as often as it used to, but still enough as to be
> What are the debug options to enable and the sysctl to set in order to tr=
> to discover the origin of the problem?
> BTW, where the interface disassociates, I suppose, it starts a channel sc=
> trying to re-associate. But I wonder if the scans start from the current
> channel, the next one or from the first channel in the range... Anyway, t=
> re-association process takes several seconds...
It could take up to several minutes for me.
No problem whatsoever without encryption.
You may have seen some times earlier Steve Belovin's utilities:
sysctl -w net.link.ieee80211.debug=3D1
> Konstantin K. KABASSANOV
> 8, rue du Capitaine Scott
> 75015 Paris, France
> Phone: +33 (0) 1 44 27 71 26
> Fax: +33 (0) 1 44 27 74 95
> E-mail: email@example.com
> Web: http://www.kabassanov.com
> IMPORTANT! If you have tried to reply to this mail and you received a
> stupid message, announcing that the mail had been rejected as spam,
> please, resend your reply to the address above.
> The certificate used to sign this e-mail can be verified at:
> Mediocrity is the worst kind of failure...