Opened 9 years ago

Closed 10 months ago

#5709 closed bug (not reproducible)

iprowifi3945 fatal firmware error

Reported by: andrewbachmann Owned by: colin
Priority: normal Milestone: R1
Component: Drivers/Network/iprowifi3945 Version: R1/Development
Keywords: iprowifi3945 wireless fatal firmware error Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by 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

Attachments (10)

syslog (66.8 KB) - added by andrewbachmann 9 years ago.
syslog
syslog-gbe (2.8 KB) - added by gbe 9 years ago.
20110413_001.jpg (849.3 KB) - added by gbe 8 years ago.
20110413_002.jpg (1.0 MB) - added by gbe 8 years ago.
20110413_003.jpg (987.2 KB) - added by gbe 8 years ago.
20110413_004.jpg (1.2 MB) - added by gbe 8 years ago.
20110413_005.jpg (1.0 MB) - added by gbe 8 years ago.
20110413_006.jpg (1.2 MB) - added by gbe 8 years ago.
20110413_007.jpg (1.1 MB) - added by gbe 8 years ago.
20110414_002.jpg (920.5 KB) - added by gbe 8 years ago.

Change History (38)

Changed 9 years ago by andrewbachmann

Attachment: syslog added

syslog

comment:1 Changed 9 years ago by andrewbachmann

Description: modified (diff)

comment:2 Changed 9 years ago by korli

Owner: changed from nobody to colin
Status: newassigned

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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.

comment:5 in reply to:  4 Changed 9 years ago by colin

Status: assignedin-progress

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!

comment:6 Changed 9 years ago by andrewbachmann

Resolution: fixed
Status: in-progressclosed

This was fixed as of build 37267.

comment:7 Changed 9 years ago by gbe

Resolution: fixed
Status: closedreopened

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.

Changed 9 years ago by gbe

Attachment: syslog-gbe added

comment:8 Changed 8 years ago by gbe

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

comment:9 Changed 8 years ago by korli

Hello,

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

Bye,

comment:10 Changed 8 years ago by colin

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

Last edited 8 years ago by colin (previous) (diff)

comment:11 Changed 8 years ago by 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 :)

comment:12 Changed 8 years ago by 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).

comment:13 Changed 8 years ago by 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

comment:14 Changed 8 years ago by 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.

Changed 8 years ago by gbe

Attachment: 20110413_001.jpg added

Changed 8 years ago by gbe

Attachment: 20110413_002.jpg added

Changed 8 years ago by gbe

Attachment: 20110413_003.jpg added

Changed 8 years ago by gbe

Attachment: 20110413_004.jpg added

Changed 8 years ago by gbe

Attachment: 20110413_005.jpg added

Changed 8 years ago by gbe

Attachment: 20110413_006.jpg added

Changed 8 years ago by gbe

Attachment: 20110413_007.jpg added

comment:15 Changed 8 years ago by 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).

comment:16 Changed 8 years ago by korli

Please try again with hrev41247 or newer. Thanks.

comment:17 Changed 8 years ago by 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".

Changed 8 years ago by gbe

Attachment: 20110414_002.jpg added

comment:18 Changed 8 years ago by korli

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

comment:19 Changed 8 years ago by 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 :)

comment:20 Changed 8 years ago by korli

Do you manage to connect at all ? Without encryption?

comment:21 Changed 8 years ago by 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 :)

comment:22 Changed 8 years ago by 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).

comment:23 Changed 8 years ago by korli

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

comment:24 Changed 8 years ago by 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.

comment:25 Changed 7 years ago by diver

Component: Drivers/NetworkDrivers/Network/iprowifi3945

comment:26 Changed 4 years ago by diver

Is this still an issue?

comment:27 Changed 4 years ago by 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.

comment:28 Changed 10 months ago by waddlesplash

Resolution: not reproducible
Status: reopenedclosed
Note: See TracTickets for help on using tickets.