Re: Intel wifi ipw showing up but not working
Hi Stefan!
sorry for the even longer delay - but dayjob was demanding, working
even on sunday.
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,
Both patches together applied, of course.
Outside on the balcony... battery works too checked with GNUstep's
battery monitor (written.. by me). Mail written with GNUMail... it got
me some tricks to get GNUstep linking, but also that was solved.
Riccardo
On 2021-03-17 16:09:32 +0100 Stefan Sperling wrote:
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_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_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 */
--
GNUMail running on GNUstep on OpenBSD/i386 Toshiba Tecra
Re: Intel wifi ipw showing up but not working
On Sun, Mar 28, 2021 at 05:58:31PM +0200, Riccardo Mottola wrote: > 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
Re: Intel wifi ipw showing up but not working
Hi Riccardo, Any feedback regarding the proposed patch below? Thanks, Stefan On Wed, Mar 17, 2021 at 04:09:32PM +0100, Stefan Sperling wrote: > On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote: > > Stefan Sperling wrote: > > > > 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 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 > > > > 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 > > 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 > > > > > > The two "suspect" values im my humble opinion are: > > 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
Re: Intel wifi ipw showing up but not working
On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote:
> Stefan Sperling wrote:
> > > 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 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
>
> 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
> 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
>
>
> The two "suspect" values im my humble opinion are:
> 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_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_scantask);
@@ -690,6 +694,14 @@
Re: Intel wifi ipw showing up but not working
Hi Stefan, Stefan Sperling wrote: 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 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 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 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 The two "suspect" values im my humble opinion are: 2 input management packets discarded 3 input packets with mismatched channel Riccardo
Re: Intel wifi ipw showing up but not working
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 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 0xff00 broadcast 192.168.1.255
fxp0: flags=808843 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
Re: Intel wifi ipw showing up but not working
On Fri, Mar 12, 2021 at 07:01:10PM +0100, Stefan Sperling wrote: > On Fri, Mar 12, 2021 at 06:37:30PM +0100, Riccardo Mottola wrote: > > 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. > > 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?
Re: Intel wifi ipw showing up but not working
On Fri, Mar 12, 2021 at 06:37:30PM +0100, Riccardo Mottola wrote:
> > 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
> :)
Yes, thanks for testing! I have committed the patch.
> 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.
I don't think there is much that can be done about this.
I'd be glad that an 11b device is even usable. The presence of this device
will slow down any networks using the same channel so you might not make
a lot of friends while using this device on public wifi networks ;)
Some APs won't allow 11b clients for this reason.
> 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.
That means there is another bug. I will try to find it.
Cheers,
Stefan
Re: Intel wifi ipw showing up but not working
Hi Stefan, sorry for the delayed response, but dayjob took over and for that I unfortunately cannot use an old OpenBSD laptop with no wireless :) Also I had to use another system to conveniently do the tests you asked me. Stefan Sperling wrote: With WEP, if the key is wrong, the interface will appear connected but it will be unable to communicate. There is no setup phase in WEP. You either encrypt and decrypt packets with the correct key, or you don't. With WPA, the link should no reach 'active' state unless you are using the correct passphrase. This is because the AP and client will try to negotiate a per-client session key, and if this key cannot be obtained, the link will stay down. The interface flags will show UP, however. Thank you for this confirmation. Right now in my studio I have thi setup - Router which runs DHCP and offers WiFi-WPA + Wired connectivity - Second wireless router which offers WiFi WEP, which DHCP deactivated So, I have 3 networks, but they all the the address from the same DHCP, it should help "debugging" Wired network works perfectly and I just connected remotely so I can easily type this email while tinkering and it restricts the issue on the Network part, not a fundamental incompatibility between OpenBSD and that DHCP server (fact that was also refuted when being able to connect with a Cardbus WiFi) OK, thanks for confirming. The script proves that the network settings if applied are correct and do work and that I do not "mistype"! Yes, since the WPA link is 'active' the key should be correct. Perfect let's concentrate on WPA, since also being with one device less in the chain makes it easier to debug. I hope he older onboard card has no issues with WPA? The next step is getting a DHCP lease. If DHCP does not manage to obtain a lease, something is wrong. Perhaps this driver was broken somehow for multicast encryption or decryption. Ok. Let me follow yours. I run the commancs in the script -except removing the defaults routes, to keep my wired connection alive. What does this command print before, and after, an attempt to connect? netstat -W ipw0 Before: tecra$ netstat -W ipw0 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 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 0 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
Re: Intel wifi ipw showing up but not working
On Thu, Mar 11, 2021 at 08:05:53PM +0100, Riccardo Mottola wrote:
> Hi Stefan,
>
> sorry for the delayed response, but dayjob took over and for that I
> unfortunately cannot use an old OpenBSD laptop with no wireless :) Also I
> had to use another system to conveniently do the tests you asked me.
No worries! I am not in a rush :)
> 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.
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,
Re: Intel wifi ipw showing up but not working
On Tue, Feb 16, 2021 at 11:51:12PM +0100, Riccardo Mottola wrote: > Hi Stefan, > > > Stefan Sperling wrote: > > Sounds like a wrong key, or the wrong type of crypto. > > Are you the AP is using WEP? Perhaps you need 'wpakey' instead of 'nwkey'? > > If the key is wrong or the crypto is wrong, would the interface still be > active and connected? With WEP, if the key is wrong, the interface will appear connected but it will be unable to communicate. There is no setup phase in WEP. You either encrypt and decrypt packets with the correct key, or you don't. With WPA, the link should no reach 'active' state unless you are using the correct passphrase. This is because the AP and client will try to negotiate a per-client session key, and if this key cannot be obtained, the link will stay down. The interface flags will show UP, however. > I am sure the AP is using WEP: I connect to that access point with many > computer since years. > Also, I tried connectiong to another access point which has WPA, same > failure. OK, thanks for confirming. > The script proves that the network settings if applied are correct and do > work and that I do not "mistype"! Yes, since the WPA link is 'active' the key should be correct. The next step is getting a DHCP lease. If DHCP does not manage to obtain a lease, something is wrong. Perhaps this driver was broken somehow for multicast encryption or decryption. What does this command print before, and after, an attempt to connect? netstat -W ipw0 What does this command display while you are trying to connect? tcpdump -n -i ipw0 -y IEEE802_11_RADIO -D in -s 4096
Re: Intel wifi ipw showing up but not working
Hi Stefan, Stefan Sperling wrote: Sounds like a wrong key, or the wrong type of crypto. Are you the AP is using WEP? Perhaps you need 'wpakey' instead of 'nwkey'? If the key is wrong or the crypto is wrong, would the interface still be active and connected? I am sure the AP is using WEP: I connect to that access point with many computer since years. Also, I tried connectiong to another access point which has WPA, same failure. If you want more help, please show commands you are typing and their output. It is much easier to provide help when we can see what you are seeing, instead of trying to guess what happened based on your verbal description. Sure, to be more scientific about determining the issue, I proceeded making a small script. I invoked the script once with ipw0 - the internal interface, then with a CardBus WiFi card I grabbed from another computer. I actually tested two. sudo route delete default sudo pkill dhclient sudo ifconfig $1 up sudo ifconfig $1 nwid westernesse-hlwpakey xx sudo dhclient $1 whhere westernesse-hlis the access point with WPA, for the one with WEP, I use the corresponding nwkey. This I love of OpenBSD: the lack of wpasupplicant: ipw0: internal 2100; ipw0: flags=808843 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-hl chan 2 bssid 78:b2:13:69:9e:91 -48dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp ral0: ral0: flags=808843 mtu 1500 lladdr 00:22:b0:64:44:06 index 5 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (OFDM36 mode 11g) status: active ieee80211: nwid westernesse-hl chan 2 bssid 78:b2:13:69:9e:91 -115dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.1.137 netmask 0xff00 broadcast 192.168.1.255 of course the old card can connect only in 11b to the access point. The script proves that the network settings if applied are correct and do work and that I do not "mistype"! If I try to scan, I see networks: $ sudo ifconfig ipw0 scan ipw0: flags=808843 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-hl chan 2 bssid 78:b2:13:69:9e:91 -48dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp nwid Paredi chan 2 bssid 60:32:b1:d1:7e:96 -19dBm HT-MCS15 privacy,short_preamble,short_slottime,wep nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -46dBm 54M privacy,short_preamble,short_slottime,wep nwid westernesse-hl chan 2 bssid 78:b2:13:69:9e:91 -52dBm HT-MCS23 privacy,wpa2 you can see both a WPA and WEP network which I can use plus another network, apparently WEP enabled too. This proves that the card is capable of receiving. Riccardo
Re: Intel wifi ipw showing up but not working
On Sun, Feb 14, 2021 at 02:23:08PM +0100, Riccardo Mottola wrote: > Hi Stuart and others,, > > > Stuart Henderson wrote: > > > > > I installed the firmware with fw_update. I try to bring the interface > > > up, I can set the nwid, but it never connects. > > What do you type to bring the interface up? > > If you are using /etc/hostname.ipw0 and "sh /etc/netstart ipw0", what > > are the contents of the file? > > I am typing "ifconfig ipw0 up" as root (or sudo) and then directly starting > the interface with dhclient. > > > > I set the WEP password and it does not get saved if I check back with > > > ifconfig. > > WEP password definitely won't get displayed back if you check as non-root. > > I don't recall if it is displayed for root or not. > > It is not - I was confused with another BSD which does, as root, display > back the used key. > > > What does "ifconfig ipw0" say? > > > > Is there an "RF kill" (wifi on/off) switch on the laptop, if so did you > > try toggling it? > > Actually, that was the solution. The laptop has both a "soft" button with > Fn-F8 and a HW toggle, I forgot about the latter. I am not accustomed to > having "both". (Add to that that it is invisible gray and acts the opposite, > sliding right "kills" and not "activates" but the icon hints to right with > an antenna not a off-antenna) > > I am used that on other laptops, the toggle issues a send connect/disconnect > of the device, here it seems that the device is up but with no antenna. > > > If I try to scan, nothing is shown, I get no errors on the console/dmesg. > > > > I tried enabling debug and I see: > > > > ifconfig debug ipw0 list > > ifconfig: SIOCDIFADDR: Device not configured > > Syntax for that is "ifconfig ipw0 debug", if you get any messages they'll > > appear in dmesg and/or /var/log/messages > > > Thanks for the pinpoint. Now with the correct settings I finally see the LED > on. The interface comes up and finally says "active" when it attaches to the > correct SSID. A scan shows all network, so I believe the radio is fine. > > dhclient however fails to get an address. It waits a few instants and then > prints "no link". > > That is very strange, if with ifconfig I got the interface to active and > thus connected. Am I overseeing again something obvious? > > Riccardi > > Sounds like a wrong key, or the wrong type of crypto. Are you the AP is using WEP? Perhaps you need 'wpakey' instead of 'nwkey'? If you want more help, please show commands you are typing and their output. It is much easier to provide help when we can see what you are seeing, instead of trying to guess what happened based on your verbal description.
Re: Intel wifi ipw showing up but not working
Hi Stuart and others,, Stuart Henderson wrote: I installed the firmware with fw_update. I try to bring the interface up, I can set the nwid, but it never connects. What do you type to bring the interface up? If you are using /etc/hostname.ipw0 and "sh /etc/netstart ipw0", what are the contents of the file? I am typing "ifconfig ipw0 up" as root (or sudo) and then directly starting the interface with dhclient. I set the WEP password and it does not get saved if I check back with ifconfig. WEP password definitely won't get displayed back if you check as non-root. I don't recall if it is displayed for root or not. It is not - I was confused with another BSD which does, as root, display back the used key. What does "ifconfig ipw0" say? Is there an "RF kill" (wifi on/off) switch on the laptop, if so did you try toggling it? Actually, that was the solution. The laptop has both a "soft" button with Fn-F8 and a HW toggle, I forgot about the latter. I am not accustomed to having "both". (Add to that that it is invisible gray and acts the opposite, sliding right "kills" and not "activates" but the icon hints to right with an antenna not a off-antenna) I am used that on other laptops, the toggle issues a send connect/disconnect of the device, here it seems that the device is up but with no antenna. If I try to scan, nothing is shown, I get no errors on the console/dmesg. I tried enabling debug and I see: ifconfig debug ipw0 list ifconfig: SIOCDIFADDR: Device not configured Syntax for that is "ifconfig ipw0 debug", if you get any messages they'll appear in dmesg and/or /var/log/messages Thanks for the pinpoint. Now with the correct settings I finally see the LED on. The interface comes up and finally says "active" when it attaches to the correct SSID. A scan shows all network, so I believe the radio is fine. dhclient however fails to get an address. It waits a few instants and then prints "no link". That is very strange, if with ifconfig I got the interface to active and thus connected. Am I overseeing again something obvious? Riccardi
Re: Intel wifi ipw showing up but not working
On 2021-02-12, Riccardo Mottola wrote: > The laptop has this network card: > > ipw0 at pci2 dev 4 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq > 11, address 00:0c:f1:1f:b2:a0 Please send full dmesg, not an excerpt. > I installed the firmware with fw_update. I try to bring the interface > up, I can set the nwid, but it never connects. What do you type to bring the interface up? If you are using /etc/hostname.ipw0 and "sh /etc/netstart ipw0", what are the contents of the file? > I set the WEP password and it does not get saved if I check back with > ifconfig. WEP password definitely won't get displayed back if you check as non-root. I don't recall if it is displayed for root or not. What does "ifconfig ipw0" say? Is there an "RF kill" (wifi on/off) switch on the laptop, if so did you try toggling it? > If I try to scan, nothing is shown, I get no errors on the console/dmesg. > > Also I notice the LED does never blink, there is no activity on the card > > > I tried enabling debug and I see: > > ifconfig debug ipw0 list > ifconfig: SIOCDIFADDR: Device not configured Syntax for that is "ifconfig ipw0 debug", if you get any messages they'll appear in dmesg and/or /var/log/messages (preemptive: please reply on-list not to me personally).
Re: Intel wifi ipw showing up but not working
Riccardo, Have you created the file in /etc/hostname.interface ? in your case it would be /etc/hostname.ipw0 if your interface is ipw0 and the WEP Key or WPA KEY should be added, also remember to add dhcp. After you created the file with the content I added below, you should be able to execute netstart as root with: # sh /etc/netstart -- example of hostname file -- join "Network-WIFI" wpakey password dhcp -- end of example -- On Fri, Feb 12, 2021 at 10:10:32PM +0100, Riccardo Mottola wrote: > Hello > > > I just installed OpenBSD 6.8 on a Toshiba Tecra S1. It is a fresh install, > so i can't say if it worked on previous OpenBSD versions (I have seen > something in the mailing list about that). the BIOS has no special options > regarding the wireless card. > > The laptop has this network card: > > ipw0 at pci2 dev 4 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq 11, > address 00:0c:f1:1f:b2:a0 > > I installed the firmware with fw_update. I try to bring the interface up, I > can set the nwid, but it never connects. > > I set the WEP password and it does not get saved if I check back with > ifconfig. > > If I try to scan, nothing is shown, I get no errors on the console/dmesg. > > Also I notice the LED does never blink, there is no activity on the card > > > I tried enabling debug and I see: > > ifconfig debug ipw0 list > ifconfig: SIOCDIFADDR: Device not configured > > > what am I missing? some magic sysctl? > > > Thank you, > > Riccardo > -- Jose Figueroa
