https://bugzilla.novell.com/show_bug.cgi?id=308830#c1 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cthiel@novell.com, coolo@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |jg@novell.com --- Comment #1 from Andreas Jaeger 2007-09-08 02:40:59 MST --- Others users have the experience that iwl has more problems. glad to hear that iwl works for you! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c3 Fred van Zwieten changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO --- Comment #3 from Fred van Zwieten 2007-09-21 10:08:24 MST --- In RC1 I still have both drivers available, and ipw3945 is used by default. Is this expected behaviour. If it is, the bug can be closed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c5 Christoph Thiel changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ke@novell.com Severity|Normal |Critical Status|NEEDINFO |ASSIGNED --- Comment #5 from Christoph Thiel 2007-09-21 17:13:52 MST --- Joe, I'd propose to make iwl* default on 10.3. In addition to that, I'd like to see a couple of words on the ipw -> iwl switch and a short note on how to make ipw default agian, in the release notes. Can you provide any input on that for Karl? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c7 --- Comment #7 from Crispin Cowan 2007-09-22 23:03:22 MST --- Ok, I've been using iwl* for a day now, and while it "works" it is painfully flaky. Uptime for my wireless connection is about 4 or 5 hours of operation. When it fails, I have found no way at all to recover wireless functionality short of a full reboot. The ipw3945 driver in openSUSE 10.2 worked *much* better than this iwl* driver works in 10.3. I mostly concur with Kulow that changing to iwl* would not be a great idea, but I definitely do wish that the ipw3945 driver actually worked at all in 10.3. iwl* in normal operation produces a large stream of events that look like this: Sep 22 20:14:31 groo kernel: wlan0_rename: No STA entry for own AP 00:06:25:51:6 4:22 Sep 22 20:14:31 groo kernel: wlan0_rename: Initial auth_alg=0 Sep 22 20:14:31 groo kernel: wlan0_rename: authenticate with AP 00:06:25:51:64:2 2 Sep 22 20:14:31 groo kernel: wlan0_rename: RX authentication from 00:06:25:51:64 :22 (alg=0 transaction=2 status=0) Sep 22 20:14:31 groo kernel: wlan0_rename: authenticated Sep 22 20:14:31 groo kernel: wlan0_rename: associate with AP 00:06:25:51:64:22 Sep 22 20:14:31 groo kernel: wlan0_rename: RX ReassocResp from 00:06:25:51:64:22 (capab=0x1 status=0 aid=5) Sep 22 20:14:31 groo kernel: wlan0_rename: associated Sep 22 20:14:31 groo kernel: wlan0_rename: Initial auth_alg=0 Sep 22 20:14:31 groo kernel: wlan0_rename: authenticate with AP 00:06:25:51:64:2 2 Sep 22 20:14:31 groo kernel: wlan0_rename: RX authentication from 00:06:25:51:64 :22 (alg=0 transaction=2 status=0) Sep 22 20:14:31 groo kernel: wlan0_rename: authenticated Sep 22 20:14:31 groo kernel: wlan0_rename: associate with AP 00:06:25:51:64:22 Sep 22 20:14:31 groo kernel: wlan0_rename: RX ReassocResp from 00:06:25:51:64:22 (capab=0x1 status=0 aid=5) Sep 22 20:14:31 groo kernel: wlan0_rename: associated Sep 22 20:16:44 groo kernel: wlan0_rename: No ProbeResp from current AP 00:06:25 :51:64:22 - assume out of range Sep 22 20:16:48 groo kernel: wlan0_rename: No STA entry for own AP 00:06:25:51:6 4:22 Sep 22 20:16:48 groo kernel: wlan0_rename: Initial auth_alg=0 Sep 22 20:16:48 groo kernel: wlan0_rename: authenticate with AP 00:06:25:51:64:2 2 Sep 22 20:16:48 groo kernel: wlan0_rename: RX authentication from 00:06:25:51:64 :22 (alg=0 transaction=2 status=0) Sep 22 20:16:48 groo kernel: wlan0_rename: authenticated Sep 22 20:16:48 groo kernel: wlan0_rename: associate with AP 00:06:25:51:64:22 Sep 22 20:16:48 groo kernel: wlan0_rename: RX ReassocResp from 00:06:25:51:64:22 (capab=0x1 status=0 aid=5) Sep 22 20:16:48 groo kernel: wlan0_rename: associated Sep 22 20:16:48 groo kernel: wlan0_rename: Initial auth_alg=0 Sep 22 20:16:48 groo kernel: wlan0_rename: authenticate with AP 00:06:25:51:64:2 2 Sep 22 20:16:48 groo kernel: wlan0_rename: Initial auth_alg=0 Sep 22 20:16:48 groo kernel: wlan0_rename: authenticate with AP 00:06:25:51:64:2 2 Sep 22 20:16:48 groo kernel: wlan0_rename: RX authentication from 00:06:25:51:64 :22 (alg=0 transaction=2 status=0) Sep 22 20:16:48 groo kernel: wlan0_rename: authenticated Sep 22 20:16:48 groo kernel: wlan0_rename: associate with AP 00:06:25:51:64:22 Sep 22 20:16:48 groo kernel: wlan0_rename: authentication frame received from 00 :06:25:51:64:22, but not in authenticate state - ignored Sep 22 20:16:48 groo kernel: wlan0_rename: RX ReassocResp from 00:06:25:51:64:22 (capab=0x1 status=0 aid=5) Sep 22 20:16:48 groo kernel: wlan0_rename: associated Sep 22 20:16:48 groo kernel: wlan0_rename: association frame received from 00:06 :25:51:64:22, but not in associate state - ignored iwl* failure looks like this: Sep 22 20:21:34 groo kernel: wlan0_rename: No ProbeResp from current AP 00:06:25 :51:64:22 - assume out of range Sep 22 20:21:37 groo kernel: wlan0_rename: No STA entry for own AP 00:06:25:51:6 4:22 Sep 22 20:21:46 groo kernel: wlan0_rename: No STA entry for own AP 00:06:25:51:6 4:22 Sep 22 20:21:50 groo dhclient: caught deadly SIGTERM Sep 22 20:21:50 groo dhclient: could not restore resolv.conf: No such file or di rectory Sep 22 20:21:50 groo dhclient: eth1: unknown hardware address type 801 Sep 22 20:21:50 groo dhclient: eth1: unknown hardware address type 801 Sep 22 20:21:50 groo dhclient: DHCPRELEASE on wlan0_rename to 10.0.9.1 port 67 Sep 22 20:21:50 groo dhcdbd: dhclient 20097 down (9) but si_code == 0 and releasing==0 ! Sep 22 20:21:51 groo avahi-daemon[2961]: Withdrawing address record for 10.0.9.225 on wlan0_rename. Sep 22 20:21:51 groo avahi-daemon[2961]: Leaving mDNS multicast group on interface wlan0_rename.IPv4 with address 10.0.9.225. Sep 22 20:21:51 groo avahi-daemon[2961]: Interface wlan0_rename.IPv4 no longer relevant for mDNS. Sep 22 20:21:52 groo kernel: ADDRCONF(NETDEV_CHANGE): wlan0_rename: link becomes ready Sep 22 20:22:06 groo kernel: ADDRCONF(NETDEV_UP): wlan0_rename: link is not ready Sep 22 20:23:27 groo kernel: ADDRCONF(NETDEV_UP): wlan0_rename: link is not ready -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c9 --- Comment #9 from Crispin Cowan 2007-09-23 14:54:01 MST --- There was an update over Saturday night. Because of bug 327404 I don't actually know what got updated :( but it REALLY broke networking. I rebooted after the update as the update requested (presumably a kernel update). On reboot, I had NO network interfaces (only lo and irda0). I ran the YaST network configurator, deleted all the old interfaces and created new ones. The result was that the wireless interface using iwl* did not work at all. Nothing. The hard-wired e1000 network interface is very confused. YaST claims that it is NOT CONFIGURED and yet it works. If I plug in the ethernet cable, suddenly I have an eth0 and it works, but YaST still claims I don't have such an interface. I had previously rpm -e the ipw3945 software to force the system to boot into iwl*. Since iwl* is now broken, I thought I would try ipw3945 again and see if it works better now. But the installer can't do that. I seletcted ipw3945-kmp-default and ipw3945d. The resolver said No valid solution found with just resovables of best architecture. Make a solver run with ALL possibilities This would invalidate atom:kernel-default-2.6.22.5-29.i586 delete kerne-default Naturally I am not comfortable doing this :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c11 --- Comment #11 from Fred van Zwieten 2007-09-23 16:14:01 MST --- Yep, I got the same problem. They upgrded the kernel, but forgot to include a new kernel-mode driver for ipw3945. Cool. I had to go back to iwl. Now I just have to wait for an up-to-date ipw3945 kmp driver. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c13 --- Comment #13 from Fred van Zwieten 2007-09-27 01:01:06 MST --- You're right, it's back to normal with the most recent update. I still have problems with this driver, thou, but that's reported in another bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=308830#c15 Joachim Gleissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #15 from Joachim Gleissner 2007-10-24 08:07:59 MST --- To summarise, ipw3945 has its flaws, and iwlwifi is still too unstable for many users. Both issues are work in progress, I hope situation improves soon. I am closing this particular bug "ipw3945 and iwl3945 get both installed", as it is actually intended that both get installed, with ipw3495 being preferred. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.