The Great Ubuntu Upgrade project has been underway for nearly a week now. the upgrades to 9.04 went absolutely smoothly–almost everything worked afterwords (printers and drivers needed to be reinstalled). But, I upgraded my Compaq C714NR to 9.10 on Friday, and did a fresh install on Sunday, with the ensuing gigabytes of system patches and additional package installs to restore essential functionality to my development system, and still no wireless. This particular model, along with a few others that use the Broadcom wireless chips, have been the bane of the Linux users’ existence. With diligence, one can get the wireless networking to function, but it is never clean or straight-forward.
Today, we even resorted to booting Windows Vista (and suffering through the six months of upgrades since we last booted it) just to make sure we had the wireless chip turned on. But, this time, when we rebooted to Linux, the red light was on. One of the most frustrating parts of the whole roll-your-own solution and follow the footsteps of others–who have had a slightly different model chipset and on a different version of Ubuntu–is that is is really easy to make things worse.
The Broadcom STA driver is an abomination. It compiles, and you can insmod it and talk to the chips, but removing the b43 and ssb drivers and trying to use just the wl driver gets nothing. The Broadcom documentation is essential a demo version–the procedure is not persistent through a reboot. I finally reinstated the b43 and ssb drivers, booted, removed those drivers, and did a manual insmod, on wl, per the Broadcom README, and I got a blue light, and can even do iwlist scanning, but the dhcpclient still won’t talk to the chip. In this current episode, I used a modified version of Sampbar’s (Samuel Barrett) procedure for 8.04, and created a script that allows the b43 and ssb drivers to load to turn on the chip, then dumps them and substitutes the wl driver. Looks good, but still doesn’t work.
One of the issues is that, despite all the messages to the forums and helpful hints, I haven’t found a comprehensive documented guide to the design of the networking startup process so we know what is happening where and when. The /etc/network/interfaces file has a lot to do with the configuration, but doesn’t seem to be the whole answer. The device driver modules have everything to do with it, but also interact with a lot of other utilities.
Wifi-radar I have used for some time, but have never actually gotten it to work–I always end up fiddling with the network settings and just use wifi-radar to verify I have connections. Looking more closely this time, it looks like the default settings in wifi-radar apply to a machine with a DHCP server, not the client. Lots of tweaking with very little guidance.
The path of least resistance seems to be to get away from the Broadcom chipset altogether and get a USB wifi adapter. But, the mileage with those seems to vary also–some folks say it works out of the box (or at least imply that installation was “normal,” which could include ndiswrapper setup or that the drivers were in Linux already). Looking through the specs on various manufacturer’s adapaters, it appears that slightly different models or even production runs of the “same” model may have different chipsets in them, some of which work with Linux and some of which don’t.
Essentially, this miasma is created by the open standard to which the “PC” class of Intel/AMD machines are built. When you buy a machine from Sun or Apple, it just plain works out of the box, but you can’t add anything to it that isn’t in the hardware compatibility list for the OS (Solaris or OS/X)–it is guaranteed not to work. Only devices with tested and certified drivers will work with these machines. Now, Unix generally expects devices and device drivers to be solid and well-behaved, since they link with the kernel, so this seems to be a very good plan. On the other hand, vendors make a lot of money just grinding out Windows drivers for their proprietary chipsets. Supplying drivers for Linux means a couple of things: 1) the code is open, which then reveals the chip settings and the design of the device, and 2) the devices need to be well-behaved and the drivers written to cover all cases without locking up or crashing.
So it goes. the outcomes of this diversion is yet to be concluded. One of the things we did learn was that you really shouldn’t keep upgrading a highly-customized machine. Eventually, it becomes necessary to backup the data, clean off the machine, and start over. There are a number of glitchy problems that have been observed in 9.10 that seem to be related more to upgrading from earlier versions: The panics and black screens and graphics blowups that evolved as we fought with the wireless driver issues have not resurfaced with the fresh install. But, the “powersave click” started up right from the install CD boot, requiring tweaking the modprobe.d configuration file for the sound card.
So, what’s next? I may decide to try one of the more stable industrial-strength distros, like CentOS, which I have used in clusters and production servers, as the base system, and run Ubuntu and other distros as virtual machines. A new machine is not yet in the budget, but a new disk drive and more RAM will run about $100, which would provide enough power to do virtualization.