Date: Sun, 01 Nov 2009 23:20:05 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: hostapd "deauthenticated due to local deauth request" - possibly a rum(4) problem? Message-ID: <hcl1im$gus$1@ger.gmane.org> In-Reply-To: <3a142e750911010802l1a4183edh9d92eabdc21ab661__46192.910653963$1257091427$gmane$org@mail.gmail.com> References: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> <3a142e750911010802l1a4183edh9d92eabdc21ab661__46192.910653963$1257091427$gmane$org@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul B Mahol wrote: > On 10/31/09, Paul B Mahol <onemda@gmail.com> wrote: >> On 10/31/09, Ivan Voras <ivoras@gmail.com> wrote: >>> I'm trying to setup an AP with a run0 interface on latest 8-STABLE but >>> apparently 802.11 association fails: >>> >>> Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >>> 802.11: associated >>> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >>> 802.11: deauthenticated due to local deauth request >>> Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE >>> 802.11: deassociated >>> >>> etc. Apparently the client never comes to the phase to receive DHCP >>> address. >>> >>> The client in this case is WinXP and the setup did work with 7-STABLE, >>> though with a bug in the rum driver which caused regular kernel panics >>> on the AP. >>> >> I tried same one with rum(4) as AP and ndis(4) as client on same >> machine(some version of 8.0 - CURRENT). ndis client (configured via >> wpa_supplicant) >> would keep auth and deauth all the time. >> I came to conclusion that rum is broken. But I think I remmember that >> bwi(4) (as a client) >> did not have such problem ... (I will test again to see) > > Well, I tried again and I got similar output like yours if I use wrong > password. And with correct password client reauth all the time, maybe > I need to setup ndis_events(8) .... I Googled a bit and it looks like in the Linuxworld problems such as this appear to be caused at the driver level :( It seems the only improvement in rum(4) between 7-stable and 8-stable are that it doesn't promptly panic the kernel any more :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hcl1im$gus$1>