Hi,
Stefan Sperling wrote:
tecra$ netstat -W ipw0
ieee80211 on ipw0:
10 input management packets discarded
This one looks bad. I think it means the net80211 stack ends up ignoring
the AP's assoc response frame. I believe your situation is that the
firmware is in associated state, the driver itself sets media status to
'active' in response to the firmware signalling successful association,
but the net80211 stack has not participated in the association sequence so
no WPA handshake can happen. The incoming data packets indicate that the
AP is trying to initiate the WPA handshake but net80211 doesn't expect
such packets and doesn't respond.
At a high-level I understand, a mismatch between the driver status and
what net80211 expects.
The way the association sequence works in this driver is pretty weird...
Can you try this patch? Does it change anything?
diff dfcb0a350e790649cafe6bd5f9f4cf2319ce75fd /usr/src
blob - 20a9b617e6d7ae0e179370512376ce8142c96986
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -1781,6 +1781,12 @@ ipw_auth_and_assoc(void *arg1)
if (error != 0)
goto fail;
+ /*
+ * net80211 won't see the AP's AUTH response. Move to ASSOC state
+ * in order to make net80211 accept the AP's assoc response.
+ */
+ ic->ic_newstate(ic, IEEE80211_S_ASSOC, -1);
+
return;
fail:
printf("%s: association failed (error=%d)\n", sc->sc_dev.dv_xname,
I just tried your patch against 6.8 release sources, compiled... and
yay! ipw0 connects to WPA WiFi just fine! Thanks, I hope it will make it
in 6.9 :)
It took quite some time.. after one hour compiling with the fan
incredibly quiet. I remebered/discovered APM set my CPU frequency to
whopping 748 MHz.. "apm -A" fixed it quickly.
ipw0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu
1500
lladdr 00:0c:f1:1f:b2:a0
index 1 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (DS11 mode 11b)
status: active
ieee80211: nwid westernesse-hl chan 5 bssid 78:b2:13:69:9e:91
-58dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.150 netmask 0xffffff00 broadcast 192.168.1.255
fxp0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu
1500
lladdr 00:a0:d1:d7:e5:66
index 2 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
enc0: flags=0<>
ieee80211 on ipw0:
0 input packets with bad version
0 input packets too short
0 input packets from wrong bssid
0 input packet duplicates discarded
0 input packets with wrong direction
0 input multicast echo packets discarded
0 input packets from unassociated station discarded
0 input encrypted packets without wep/wpa config discarded
0 input unencrypted packets with wep/wpa config discarded
0 input wep/wpa packets processing failed
0 input packet decapsulations failed
0 input management packets discarded
0 input control packets discarded
0 input packets with truncated rate set
0 input packets with missing elements
0 input packets with elements too big
0 input packets with elements too small
0 input packets with invalid channel
0 input packets with mismatched channel
0 node allocations failed
0 input packets with mismatched ssid
0 input packets with unsupported auth algorithm
0 input authentications failed
0 input associations from wrong bssid
0 input associations without authentication
0 input associations with mismatched capabilities
0 input associations without matching rates
0 input associations with bad rsn ie
0 input deauthentication packets
0 input disassociation packets
0 input packets with unknown subtype
0 input packets failed for lack of mbufs
0 input decryptions failed on crc
0 input ahdemo management packets discarded
0 input packets with bad auth request
4 input eapol-key packets
0 input eapol-key packets with bad mic
0 input eapol-key packets replayed
0 input packets with bad tkip mic
0 input tkip mic failure notifications
0 input packets on unauthenticated port
0 output packets failed for lack of mbufs
0 output packets failed for no nodes
0 output packets of unknown management type
0 output packets on unauthenticated port
5 active scans started
0 passive scans started
0 nodes timed out
0 failures with no memory for crypto ctx
0 ccmp decryption errors
0 ccmp replayed frames
0 cmac icv errors
0 cmac replayed frames
0 tkip icv errors
0 tkip replays
0 pbac errors
0 HT negotiation failures because peer does not support MCS 0-7
0 HT negotiation failures because we do not support basic MCS set
0 HT negotiation failures because peer uses bad crypto
0 HT protection changes
0 new input block ack agreements
0 new output block ack agreements
0 input frames below block ack window start
0 input frames above block ack window end
0 input block ack window slides
0 input block ack window jumps
0 duplicate input block ack frames
0 expected input block ack frames never arrived
0 input block ack window gaps timed out
0 input block ack agreements timed out
0 output block ack agreements timed out
how does this look to you?
I did a test of sending 187MB over scp I getabout 500K/s, A little slow,
even for 11b, I think. I'd expect more like 700, but anyway.
Happy and bold, I tried WEP too... but it does not connect.
It says interface is up (key is correct) but "nothing", dhclient doesn't
get a link.
Fearing WEP is broken, I got my other laptop, a ThinkPad with 6.8, where
I have since long a small script. Launched it and works. Good. I copied
over the script... so I am sure I do the things the same way, but it
does not work.
What is very strange is that if I first connect to the WPA network, then
bring the interface down, kill dhclient, then run the WEP script, it
works and really connects to WEP and gets a lease.
I am so puzzled, that I tried rebooting a couple of times to have clean
status:
1) launch WEP script -> fails
2) wait, launch WEP script again -> fails
3) try again ad libitum -> fails
(tried.. just to exclude the fact that "second attempt" works)
1) launch WPA script -> works
2) bring down WPA
3) launch WEP script -> works
My guess... is that some initing is not completed interface, which WPA
instead does, once it is it works, even if the networks are different
and interface is brought down and up.
even
1) launch WEP -> fails
2) launch WPA -> works
3) bring down ipw0
4) launch WEP -> works
And yes, it is really connected to the WEP access point, not the other
one :)
Nice trick, but it works only when two networks are available and in
that case... anyway WPA is preferrable
Riccardo
