iprowifi3945 fatal firmware error

[andrewbachmann]

Version: hrev36122

At SuperHappyDevHouse, trying to connect to the open wireless (no encryption, no password) with my laptop I failed to connect. Last portion of the syslog here, complete syslog attached. Note, the target SSID is: "SHDH37"

KERN: [00:26:3e:05:a1:c1] caps 0x401 bintval 100 erp 0x0KERN:  country [US  36-39,12 149-153,14KERN: ]
KERN: [00:26:3e:05:a1:c3] new beacon on chan 165 (bss chan 165) KERN: "speedracer" rssi 61
KERN: [00:26:3e:05:a1:c3] caps 0x411 bintval 100 erp 0x0KERN:  country [US  36-39,12 149-153,14]
KERN: [00:26:3e:05:a1:c1] new beacon on chan 165 (bss chan 165) "KERN: SHKERN: DKERN: HKERN: 3KERN: 7KERN: "KERN:  rssi 57
KERN: [00:26:3e:05:a1:c1] caps 0x401 bintval 100 erp 0x0KERN:  country [US KERN:  36-39,12KERN:  149-153,14KERN: ]KERN: 
KERN: [00:26:3e:05:a1:c3] new beacon on chan 165 (bss chan 165) "speedracer" rssi 57
KERN: [00:26:3e:05:a1:c3] caps 0x411 bintval 100 erp 0x0 country [US  36-39,12 149-153,14]
KERN: [net/iprowifi3945/0]  macaddr          bssid         chan  rssi  rate flag  wep  essid
KERN:  - 00:1a:1e:15:21:e0 00:1a:1e:15:21:e0 KERN:    1    +7! 54M   ess  wep! KERN: "KERN: PLast message repeated 1 time
KERN: LKERN: 4Last message repeated 2 times
KERN: CKERN: OKERN: RKERN: PKERN: "KERN: 
KERN:  - 00:23:69:ef:bf:5aKERN:  00:23:69:ef:bf:5a KERN:    1 KERN:   +17 KERN:  54M KERN:   ess KERN:  wep! KERN: "KERN: PKERN: uKERN: bMatic"
KERN:  - 00:1e:f7:76:4d:c0 00:1e:f7:76:4d:c0    6    +4! 54M   ess   no  "Guest"
KERN:  - f8:1e:df:fa:56:4b f8:1e:df:fa:56:4b    6   +10  54M   ess  wep! "Anna's Network"
KERN:  + 00:26:3e:05:b1:00 00:26:3e:05:b1:00   11   +37  54M   ess   no  "SHDH37"
KERN:  - 00:26:3e:05:b1:02 00:26:3e:05:b1:02   11   +38  54M   ess  wep! "speedracer"
KERN:  + 00:0b:0e:e4:db:80 00:0b:0e:e4:db:80   11    +8  54M   ess   no  "SHDH37"
KERN:  + 00:0b:0e:e3:a2:41 00:0b:0e:e3:a2:41   44   +16  54M   ess   no  "SHDH37"
KERN:  - 00:1a:70:4a:14:e0 00:1a:70:4a:14:e0   10    +6! 54M   ess  wep! "FlyingFish"
KERN:  + 00:0b:0e:e3:95:01 00:0b:0e:e3:95:01  149   +13  54M   ess   no  KERN: "KERN: SKERN: HKERN: DKERN: HKERN: 3KERN: 7KERN: "KERN: 
KERN:  - 00:0b:0e:e3:95:03KERN:  00:0b:0e:e3:95:03 KERN:  149 KERN:   +13 KERN:  54M KERN:   ess KERN:  wep! KERN: "KERN: sKERN: pKERN: eLast message repeated 1 time
KERN: dKERN: rKERN: aKERN: cKERN: eKERN: rKERN: "KERN: 
KERN:  + 00:26:3e:05:b3:41KERN:  00:26:3e:05:b3:41  157   +42  54M   ess   no  "SHDH37"
KERN:  - 00:26:3e:05:b3:43 00:26:3e:05:b3:43  157   +41  54M   ess  wep! "speedracer"
KERN:  - 00:26:3e:05:b2:81 00:26:3e:05:b2:81  157   +10  54M   ess  wep! "speedracer"
KERN:  + 00:26:3e:05:b1:01 00:26:3e:05:b1:01  161   +46  54M   ess   no  "SHDH37"
KERN:  - 00:26:3e:05:b1:03 00:26:3e:05:b1:03  161   +46  54M   ess  wep! "speedracer"
KERN:  + 00:26:3e:05:a1:c1 00:26:3e:05:a1:c1  165   +58  54M   ess   no  "SHDH37"
KERN:  - 00:26:3e:05:a1:c3 00:26:3e:05:a1:c3  165   +59  54M   ess  wep! "speedracer"
KERN: [net/iprowifi3945/0] ieee80211_alloc_node 0x831f9000<00:26:3e:05:a1:c1> in station table
KERN: [net/iprowifi3945/0] [00:26:3e:05:a1:c1] ieee80211_alloc_node: inact_reload 2
KERN: [net/iprowifi3945/0] ieee80211_new_state_locked: SCAN -> AUTH (nrunning 0 nscanning 0)
KERN: [net/iprowifi3945/0] scan_task: done, [ticks 46347, dwell min 20000 scanend 2147484709]
KERN: [net/iprowifi3945/0] ieee80211_newstate_cb: SCAN -> AUTH arg 192
KERN: wpi_newstate: SCAN -> AUTH flags 0x0
KERN: config chan 165 flags 8005 cck 0 ofdm 15
KERN: [net/iprowifi3945/0] sta_newstate: SCAN -> AUTH (192)
KERN: [net/iprowifi3945/0] ieee80211_ref_node (ieee80211_send_mgmt:1788) 0x831f9000<00:26:3e:05:a1:c1> refcnt 3
KERN: [iprowifi3945] (wpi) fatal firmware error
DAEMON 'DHCP': DHCP for /dev/net/iprowifi3945/0, status: Operation timed out

[andrewbachmann]

syslog

[colin]

Thanks for this bug report.
The important part in the syslog is the message "[iprowifi3945] (wpi) fatal firmware error". This means that the firmware, seems to have some problem with Extended WiFi-Networks (termini: ESS, these are Networks where you have several Access Points, all announcing the same SSID, so that you can cover a larger area). "SHDH37" is such an ESS.
As discussed here: ​https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/147439/comments/11 the 3945 WiFi-Hardware seems to have trouble in such Environments.
A way to verify this theory could be to deactivate Roaming in the WiFi-stack and retest it in an ESS-environment: change the assignment in ​http://dev.haiku-os.org/browser/haiku/trunk/src/libs/compat/freebsd_wlan/net80211/ieee80211_scan.c#L183 to IEEE80211_ROAMING_MANUAL and recompile your driver with jam iprowifi3945
As a side note: Haiku ships with the newest firmware for the FreeBSD driver (2.14.1.5), so there is no newer one, one could try.

[andrewbachmann]

Thanks for the quick reply. I agree that it does seem likely that the cause is as you described. Since it was a one-day event I can't retest the exact conditions. I do note that at my apartment I don't see this firmware error. (although it doesn't seem to connect to the open GoogleWiFi at my apartment either, there is no visible error and it keeps scanning)

I may have a chance to recompile and try at work. I will comment if I have more information.

[colin]

Replying to andrewbachmann:

(although it doesn't seem to connect to the open GoogleWiFi at my apartment either, there is no visible error and it keeps scanning)

This would be a bug report on its own. A syslog could give a hint why it doesn't connect.

I may have a chance to recompile and try at work. I will comment if I have more information.

Thx!

[andrewbachmann]

This was fixed as of build 37267.

[gbe]

I'm using 39021 here and still see the problem. The relevant (I think) part of the syslog is attached. I'm in an ESS environment here (university) and I can reliably reproduce this problem.

[gbe]

Wow, half a year and not even a "Yeah, there still might be issues"? Kind of disappointing :(

[korli]

Hello,

I'll try a new firmware release locally and let you know when anything is to be tested on your side.

Bye,

[colin]

I'll guess the problem has a lot to do with hour wifi-stack not being configured for an ESS-Environment, as gbe wrote about. Hardly anything the firmware could be blamed for.

[gbe]

I don't think the firmware is the issue here. I tried the firmware my Gentoo Linux uses on the same hardware and the error persists. Doesn't the wpi driver come from FreeBSD? In that case I guess the error is not exactly in the wpi driver since FreeBSD used to work in this environment (with a few general stability problems regarding WiFi, but that's a task for later :)

[korli]

I've gone ahead anyway and updated drivers and firmwares from FreeBSD 8.2. The firmware we had previously for 3945 was 4 years old, the "new" one is only two years old. I think it's worth testing again on your side (41240 or newer).

[gbe]

I will as soon as the build is finished. Might be until tomorrow though, because I don't want to spend the night at the university waiting for Haiku to build :D

[gbe]

The latest nightly build (41245) lands me in KDL during ieee80211_ratectl_init + 0x003a in iprowifi3945 with an unhandled page fault. Is there a way to disable a certain kernel add-on (in this case wpi) from loading during boot? I'll attach a few photos I made of the screen content to provide a bit more info.

[korli]

OK my fault. It seems a bit of glue is needed to have ratectl modules loaded (as for crypto modules). Registering only the IEEE80211_RATECTL_NONE module should be enough for a start. I'll take care of this tonight hopefully. Sorry for the inconvenience, thanks for testing.

I dunno a way to not load a driver on boot (except removing the device physically).

[korli]

Please try again with hrev41247 or newer. Thanks.

[gbe]

hrev41247 boots fine but drops into KDL upon the first or one of the first sent packets. "Muting" the card with the hardware killswitch solves that but of course then the card is kinda useless :D I'll attach yet another "screenshot".

[korli]

Please try again with hrev41251 or newer. I had patched iprowifi4965 before and forgot it wasn't the case for ipro3945. Thanks.

[gbe]

The fatal firmware error is fixed with hrev41251, so I guess this bug can be closed. I still have some issues connecting (the card won't associate with an ominous 'reason 17') but I don't think they have anything to do with this. Thanks a lot :)

[korli]

Do you manage to connect at all ? Without encryption?

[gbe]

No, not yet. I can't connect to my universities network (which is the non-encrypted ESS network as mentioned before) and I can't connect to my neighbours WEP network. I'll see whether I can set up my old WiFi AP with an unencrypted network tonight but if I don't get around to do it, I'd need to wait until wednesday evening. Is there a kind of reference sheet for the error codes reported by the firmware? I haven't been able to find one with a few Google searches and looking at the OpenBSD wpi and the Linux ipw3945 didn't exactly turn up anything. On the bright side, I have a build environment now so I can test your patches as soon as you commit them :)

[gbe]

I wasn't able to make a connection to any network after trying a few. Some networks fail with reason 17 (such as my universities unencrypted ESS network), some fail without saying anything, i.e. it looks as if I didn't do ifconfig /dev/... join bla and for some the fatal firmware error has resurfaced (for example the one at the Easterhegg in Hamburg).

[korli]

Could you please check again with hrev41559 or newer on trunk?

[gbe]

I just tried hrev41565, but the assoc still fails with reason 17. If there's anything I can do to aid debugging, I'd be happy to do that.

[diver]

Is this still an issue?

[andrewbachmann]

I don't know if this is an issue any longer. I am not in a position to test. Perhaps you can close it and if someone else can reproduce they can reopen it.