Intel wifi ipw showing up but not working

Discussion:

Stefan Sperling

2021-03-17 15:09:32 UTC

That means there is another bug. I will try to find it.

Could you show what 'netstat -W ipw0' looks like after an unsuccesful
attempt of connecting to a WEP access point?

ipw0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0c:f1:1f:b2:a0
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (DS11 mode 11b)
status: active
ieee80211: nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -61dBm
nwkey
then I run dhclient
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
2 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
3 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
0 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
1 active scan 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
2 input management packets discarded
3 input packets with mismatched channel
Riccardo

My best guess is that because ipw doesn't bother with calling into
the net80211 newstate function, the interface's link state is never
updated and packets cannot flow. With WPA, link state gets updated
as a side-effect of a successful WPA handshake.

Does this fix it?

diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src
blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -679,7 +679,11 @@ int
ipw_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
{
struct ipw_softc *sc = ic->ic_softc;
+ struct ifnet *ifp = &ic->ic_if;

+ if (LINK_STATE_IS_UP(ifp->if_link_state))
+ ieee80211_set_link_state(ic, LINK_STATE_DOWN);
+
switch (nstate) {
case IEEE80211_S_SCAN:
task_add(systq, &sc->sc_scantask);
@@ -690,6 +694,14 @@ ipw_newstate(struct ieee80211com *ic, enum ieee80211_s
break;

case IEEE80211_S_RUN:
+ if (!(ic->ic_flags & IEEE80211_F_RSNON)) {
+ /*
+ * NB: When RSN is enabled, we defer setting
+ * the link up until the port is valid.
+ */
+ ieee80211_set_link_state(ic, LINK_STATE_UP);
+ }
+ break;
case IEEE80211_S_INIT:
case IEEE80211_S_ASSOC:
/* nothing to do */

Stefan Sperling

2021-03-27 17:37:23 UTC

Permalink

Hi Riccardo,

Any feedback regarding the proposed patch below?

Thanks,
Stefan

Post by Stefan Sperling

That means there is another bug. I will try to find it.

Could you show what 'netstat -W ipw0' looks like after an unsuccesful
attempt of connecting to a WEP access point?

My best guess is that because ipw doesn't bother with calling into
the net80211 newstate function, the interface's link state is never
updated and packets cannot flow. With WPA, link state gets updated
as a side-effect of a successful WPA handshake.
Does this fix it?
diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src
blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -679,7 +679,11 @@ int
ipw_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
{
struct ipw_softc *sc = ic->ic_softc;
+ struct ifnet *ifp = &ic->ic_if;
+ if (LINK_STATE_IS_UP(ifp->if_link_state))
+ ieee80211_set_link_state(ic, LINK_STATE_DOWN);
+
switch (nstate) {
task_add(systq, &sc->sc_scantask);
@@ -690,6 +694,14 @@ ipw_newstate(struct ieee80211com *ic, enum ieee80211_s
break;
+ if (!(ic->ic_flags & IEEE80211_F_RSNON)) {
+ /*
+ * NB: When RSN is enabled, we defer setting
+ * the link up until the port is valid.
+ */
+ ieee80211_set_link_state(ic, LINK_STATE_UP);
+ }
+ break;
/* nothing to do */

Stefan Sperling

2021-03-28 18:04:20 UTC

Permalink

However, if you can read this message, it means that I am connected through
the internal ipw card to WEP WiFi at the first attempt. Wonderful. Great
work, Stefan,

Great, thank you for confirming! I have committed the fix.

Glad to know that old hardware and drivers like this are still useful.

Cheers,
Stefan