Bugzilla – Bug 308830
ipw3945 _and_ iwl3945 get both installed, ipw used, no wireless
Last modified: 2007-10-24 14:07:59 UTC
After a fresh install of 64bit KDE 10.3 beta3 install, both ipw3945 and iwl3945 get installed. Appearently, ipw3945 is being used, resulting in non-working wireless. After removing alle ipw related packages _and_ reconfiguring the wireless card with Yast, wireless workes like a charm with iwl3945, Even better than beta2. Reconnects after S2R and S2D seem to initiate faster. What's it going to be? ipw or iwl? I say iwl, so make sure ipw is only installed if the user explicitly wants to.
Others users have the experience that iwl has more problems. glad to hear that iwl works for you!
We'll, I cheered too soon. iwl gives me also problems. After some time of idling (I went for groceries :-), the wireless is diconnected. Sometimes I can reconnect, sometimes i can't.
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.
the ipw3945 driver does not work at all for me (Thinkpad T60). I removed the ipw3945 stuff, and the system automatically reverted to iwl, which seems to be working.
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?
We won't change defaults now. But the release notes are missing infos about it, right.
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
I agree with Cripin. both drivers have problems. iwl works great on getting a connection, both at startup and from resume, but is not able to maintain a stable connection. With ipw, the reverse seem to be happening. Both at startup and resume, I have to do manual interventions, but if the connection is up, it stays up. My bet for the time being is on ipw, allthough I unerstand it is a very ugly piece of software, but iwl is highly experimental and unstable. The current problems with ipw can be solved. Kubuntu Feisty's implementation is stable as hell, (re)connect's all the time, so it _is_ possible and I think we're close. It's something ipw vs NM related.
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 :)
On the problem of ipw3945, I now suspect that the problem is that the ipw3945 module on the RC DVD is not compatible with the new kernel that was built overnight, and that no new module has been built. I tried blocking my ISO as a source of installation and looking for an ipw3945 module. It found one, but still claimed that it would invalidate my default kernel.
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.
you're talking about bug 327595, that has little to do with RC1 itself.
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.
I did a complete online reinstall of 10.3 GM (x86_64) (1CD KDE) a few days ago. The ipw3945 get's choosen reliably. After adding ipw3945 to SUSPEND_MODULES, I can't break it. It autoconnect on every boot for a number of days. I'll keep monitoring this for another week and then I declare this bug as closed, but maybe other's have problems still.
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.