evad.zone

I’ve been using ipw3945 driver ever since I’ve had a laptop with Intel 3945ABG wireless adapter. Despite few issues it had in the beginning, I was really happy to have that driver on-board, as the very latest version 1.2.1 of ipw3945 proved to be very stable and reliable. However, some time ago, someone decided to drop ipw3945 development in favour of iwl3945 / mac80211 projects. If you’re interested what do I think about it, read on.

Disclaimer

Just to make it clear – I really don’t want to get into details why exactly ipw has been dropped, who decided on that, what are the issues standing behind it, or anything like that. I am just a regular user, who expect things just work, and this post is written solely from that perspective.

Say hello to iwl3945 (or at least try)

Anyway, iwl3945 was included by default in Fedora 7, hence Intel 3945ABG cards were supposed to work in F7 out of the box. In fact, they didn’t very well. But I wasn’t worried too much, disabling iwl and installing ipw manually solved issues straight away, so my laptop was wireless again.

Fedora 7 has been released, time was passing by, Fedora 8 has been released (again with iwl, that I quickly replaced with ipw), time was passing by… But one day, around few weeks ago, I’ve had an idea – hey, let’s check how iwl3945 is going on? Because what is the point of using external and no longer developed driver, while fresh driver for my wireless card is already built into kernel. Sounds reasonable, right? So I’ve uninstalled ipw3945, removed iwl3945 from /etc/modprobe.d/blacklist, and… reverted back to ipw3945 after less than two days. I just couldn’t bear with opening terminal and reloading iwl3945 kernel module all the time. During that couple of days I’ve had way more issues with iwl, than I used to have with ipw during a month. So, despite my truly good intentions towards iwl3945, I’ve found out that since Fedora 7 release it hasn’t been really much improved, and ipw3945 was again the driver of my choice. Comparing to iwl3945 it was just flawless…

Kernel 2.6.24 – welcome on board!

Flawlessness of ipw3945 finished couple of days ago along with 2.6.24 kernel release in Fedora updates. While booting machine with new and shiny kernel, dkms_autoinstaller refused to compile ipw3945 kernel module, just throwing meaningless Bad exit status: 10 error. Google wasn’t much helpful, so I was forced to get iwl3945 and mac80211 out of blacklist again, hoping that since my horrible experience it gained some improvement. However, it was needless to look too far – modinfo iwl3945 command revealed that new kernel brings exactly the same iwl3945 module version as before, when I first tried to use it couple of months before! What a whopping improvement that is! Oh, what a joy…

So, why exactly iwl3945 sucks?

OK, to be honest, I must admit that I get the general idea of iwl3945 / mac80211 project. Here is the driver that doesn’t require any extra daemon (ipw3945d), that is built into kernel and enabled by default, and provides wireless networking out of the box. That’s great. There is only one slight issue – it doesn’t work quite right. What exactly? Here you go:

• LED light doesn’t work
  Ha! That tiny, green light with WiFi logo on it – who’d care about it anyway?! – you might ask. I bet everyone who used ipw3945 before would be an answer. That little, green light had three simple states: OFF – wireless switched off; blinking green – wireless switched on, but not connected to any network (scanning mode); solid green – on and associated with network. These three simple states used to give me instant and exact overview of current state of wireless hardware in my laptop, as quite often software connection managers are reacting with little delay to hardware state changes. So, what iwl3945 gives mi instead? Nothing. Literally.
   
• Scanning for networks? You’d be better off playing the lottery
  If you ever felt hunger for excitement, please try to scan for wireless networks with iwl3945. (Dis)satisfaction guaranteed. It’s slow and returns inaccurate results. When I first stepped into that problem, I thought there might be something wrong with my home router, as iwl3945 DID find wireless networks from across the street, but DIDN’T find a router which was just behind the wall, and the one it was actually connected to! Sometimes it’s even funnier – it cannot find ANY network at all. However, to be fair, I need to admit that sometimes it actually finds all nearby networks, including mine. Nice. Needless to say, ipw3945 never had such issues.
   
• Using hardware kill switch a lot? Better leave terminal window opened
  Speaking about little, simple things, like LED light above? Take wireless hardware switch as another example. My Dell D620 has convenient on/off switch on the left side of chassis, which is extremely helpful to conserve battery power while on the move and WiFi is not needed. Even monkey could use it, but not with iwl3945. Driver is kind enough to detect switch being in OFF position (sometimes), but never bothers to notice it back into ON position. Solution? rmmod iwl3945 && modprobe iwl3945 – quite convenient, isn’t it?
   
• Using sleep/resume a lot? Better leave terminal window opened
  I’m not sure, but I believe I’ve stepped into article on the web saying that ipw3945d regulatory daemon prevented computer from being successfully resumed out of suspend/hibernation. Indeed, that was the case with earlier versions of ipw3945, but the latest one had absolutely no issues with it. After resume I’ve just had to wait ~10 secs for automagic reconnection, and I was back on track. The new and shiny iwl3945 gives way better experience, however. When computer wakes up, it seems that network connection is present straight away (hence way better experience). Gnome-panel network icon shows full coverage, eth1 interface is up, just perfect. In fact, nothing works. Connection is up, but simply dead. Like a dummy in crash-test. Solution? You know the solution already.
   
• I just want to use the internet, can I?
  Yes you can. Just keep terminal opened at all times, for quick driver reload when needed. Here’s another example – I wanted to listen to my favourite online radio station yesterday. I’ve fired up Rhythmbox, selected radio from the list, hit play, and music filled the room instantly. But shortly after, every few seconds connection to the server was dropped, forcing player to re-buffer the stream over and over again. Initially I thought maybe connection to the ISP was slower than usual, but I did quick test first – connected my mobile phone to home router, and fired up Proton Radio from that little device. Sound stream was flawless, with no re-buffering at all. Surprised? Ha! You’ve guessed it. Reloading iwl3945 driver made 128kbps audio stream over 3 Mbps connection just work…
   

Who cares, anyway?

Initially I thought I would be good thing to submit all these things to the bugzilla dedicated exclusively to ipw* / iwl* / mac80211 projects. Before submitting any bugs into official project bugtracks, I usually check if someone did that already, just to avoid annoying duplicates. First off I’ve tried with LED light issue. Bingo! But.. hang on, issue has been submitted on 14th of February 2007, which makes it a little over a year old now. It’s still open, unresolved and there were several duplicate bugs submitted in-between. OK, there are some patches attached, that are supposed to make LED light work in certain kernel environments, but these are still just patches, hence issue itself is not resolved, and doesn’t seem to be resolved anytime soon! Over a year later! Lovely. I wasn’t even bothered to look for other issues, not to mention submitting anything there… :/

The ultimate solution

Since it looks like iwl3945 won’t get into decent state anytime in near future, and ipw3945 won’t work with 2.6.24 kernel, I somehow need to survive. To make my life easier, I’ve wrote /usr/local/bin/iwl_reload bash script:

#!/bin/sh
ifconfig eth1 down
rmmod iwl3945
sleep 2
modprobe iwl3945
sleep 5
/opt/wicd/autoconnect.py &    <-- I'm using wicd to manage connections, so please change that line accordingly

So, reloading a driver and reconnecting to the network is now just a matter of running that single script. Unfortunately, I need to run it quite often lately…

Also, it’s nice to have /etc/pm/sleep.d/06iwl_reload file:

#!/bin/sh

case "$1" in
        resume|thaw)
            /usr/local/bin/iwl_reload
            ;;
        *)
            ;;
esac

exit $?

Hence iwl gets reloaded automatically after resuming from suspend or hibernation, saving manual reload in terminal. Note: that file has to be executable, so chmod a+x /etc/pm/sleep.d/06iwl_reload is probably a good thing to do.

Final word

I am a web developer. I don’t use any kind of low level language. I don’t know how to write a device driver. I know, however, how hard it is to hear complaints about my own software, especially not supported by any details. I also understand that certain things in programming world are not as easy as it seems. This is why I’m always trying to resolve a problem myself instead of moaning out loud about it. But in this particular case I just couldn’t resist to shout. Someone, somewhere decided to replace good thing with much worse, and then convince all of us it’s actually better. While in fact it’s anywhere, but not even next to good, and it doesn’t seem like to be better (at least anytime soon)…

Oh, almost forgot
Version of iwl3945 module that I’m spilling all my beans onto, is 1.2.23kds running under kernel 2.6.24.3-12.fc8 (at the moment of writing). I know there is 1.2.25 version released already, and I truly wanted to try it out, but make simply fails with several error messages. I don’t know why. I’m too annoyed and tired to go through any README / INSTALL / GOF*CKYOURSELF files at the moment. Please check back later…

This entry was posted on Sunday, March 9, 2008 at 6:52 and is filed under Linux. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.