Discussion:
wpa_supplicant and ral(4): RTM_IEEE80211: disassoc (102)
(too old to reply)
Torsten Harenberg
2010-02-05 09:45:07 UTC
Permalink
Dear list,

on my netbook, running NetBSD 5.0_STABLE/i386, I try to get an internal wireless card running which is a Ralink RT2790.

The ral(4) driver does not support it in STABLE, but there has been some efford going on to support this one [1], [2]. Finally, Quentin Garnier kindly prodived a patch which makes this card working (and he reports that it runs at least with WEP encyrption) [3].

WIth this patch, the card is properly recognized by the kernel:

th-akoya# dmesg | grep ral0
ral0 at pci2 dev 0 function 0: vendor 0x1814 product 0x0781 (rev. 0x00)
ral0: interrupting at ioapic0 pin 17
ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (1T2R)
ral0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ral0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

However, when trying to use wpa_supplicant with this card, the connection seems to be established but gets broken:

State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
WPA: RX message 3 of 4-Way Handshake from 00:1a:e3:5d:54:b0 (ver=1)
WPA: IE KeyData - hexdump(len=26): dd 18 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 01 00 00
WPA: Sending EAPOL-Key 4/4
WPA: Installing PTK to the driver.
WPA: RSC - hexdump(len=6): 00 00 00 00 00 00
wpa_driver_bsd_set_key: alg=TKIP addr=00:1a:e3:5d:54:b0 key_idx=0 set_tx=1 seq_len=6 key_len=32
State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE
RTM_IEEE80211: disassoc (102)
Setting scan request: 0 sec 100000 usec
Added BSSID 00:1a:e3:5d:54:b0 into blacklist
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

I thought that it might be related to the patch from Quentin, but after searching a bit I found that another user has opened a PR [4] which seems to show exactly my problem, but he is using an USB based device which is supported by the ral(4) driver in 5.0 without any additional patch.

There has been a lenght thread already about a year ago on this list [5] and I applied the patch to wpa_supplicant given in [6] in the same thread. Finally there has been a pullup-request to the netbsd-5 branch, which has been applied [7].

Still, the problem exists at least here and also at the user submitting the PR [4]. I tried two networks (one at home and one commercially operated at my office), both show this problem.

I attached a full "-d" output of wpa_supplicant to the PR.

Is there way to proceed from here?

Thanks a lot and best regards,

Torsten



[1] kern/41418
[2] http://mail-index.netbsd.org/current-users/2010/02/04/msg012380.html
[3] http://mail-index.netbsd.org/current-users/2010/02/04/msg012389.html
[4] bin/42581
[5] http://mail-index.netbsd.org/tech-net/2009/03/30/msg001183.html
[6] http://mail-index.netbsd.org/tech-net/2009/05/11/msg001303.html
[7] http://releng.netbsd.org/cgi-bin/req-5.cgi?show=755
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> <>
<> Dr. Torsten Harenberg ***@physik.uni-wuppertal.de <>
<> Bergische Universitaet <>
<> FB C - Physik Tel.: +49 (0)202 439-3521 <>
<> Gaussstr. 20 Fax : +49 (0)202 439-2811 <>
<> 42097 Wuppertal <>
<> <>
<><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><>




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young
2010-02-07 22:28:14 UTC
Permalink
Post by Torsten Harenberg
Dear list,
sorry for self-replying.
After setting net.link.ieee80211.vap0.debug = -1 and
net.link.ieee80211.debug = -1, I got the following lines in syslog.
Maybe that helps to find the source of the problem. Anybody has some
experience in interpreting the output?
In the kernel, net80211's state transitions (SCAN -> INIT, ..., INIT
-> INIT) make me wonder, what states is wpa_supplicant in, and what
commands does it send the kernel, at the same time?

FWIW, I have seen APs disassociate clients for several reasons,
including an out-of-order crypto sequence number, or the client's
failure to complete re-keying before the AP timed out (after 200ms,
IIRC).

I do not remember whether you use ***@cardbus, or whether ral uses
hardware crypto, but I have seen drivers do silly things like try to
read/write a crypto register while the Cardbus slot was powered down.
Usually it was harmless.

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Torsten Harenberg
2010-02-08 18:28:37 UTC
Permalink
Post by David Young
hardware crypto, but I have seen drivers do silly things like try to
read/write a crypto register while the Cardbus slot was powered down.
Usually it was harmless.
no.. this is a build-in card:

ral0 at pci2 dev 0 function 0: vendor 0x1814 product 0x0781 (rev. 0x00)
ral0: interrupting at ioapic0 pin 17
ral0: MAC/BBP RT2872 (rev 0x0200), RF RT2720 (1T2R)
ral0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ral0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36Mbps 48Mbps 54Mbps

Best regards,

Torsten
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> <>
<> Dr. Torsten Harenberg ***@physik.uni-wuppertal.de <>
<> Bergische Universitaet <>
<> FB C - Physik Tel.: +49 (0)202 439-3521 <>
<> Gaussstr. 20 Fax : +49 (0)202 439-2811 <>
<> 42097 Wuppertal <>
<> <>
<><><><><><><>< Of course it runs NetBSD http://www.netbsd.org ><>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...