Category Archives: All things Unix

Linux Wireless: the saga continues

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.

Ubuntu and Laptops

In an earlier thread, I mentioned I was going to upgrade our Ubuntu versions.  Well, I had been putting it off because you never know what cans of worms you are going to open when you do that.

One of the problem children in the Linux world in general has been Wi-Fi.  It seems everyone makes Windows drivers for their hardware, but a lot of them don’t support Linux.  Our laptop, a Compaq C714NR, has a Broadcom 4311 chipset in it, which has been a struggle.  Through three or four iterations of Ubuntu, we have managed to get it working [most of the time] by using ndiswrappers and the Windows XP drivers.  Well, with Ubuntu 9.10 (Karmic Koala), Broadcom has finally got with the program and provided buildable sources for Linux.  But, that said, their track record for solid results has been less than stellar.  I’m still working the problem, but I did get the new Broadcom drivers built and loaded.  The main issue is getting rid of all the ndiswrapper stuff and a plethora of helpful scripts and settings provided by others, for various previous versions of Ubuntu.

In the middle of the WiFi issue, my machine went into a kernel panic, evidenced by a sudden blank screen a few minutes after logging in and a blinking Caps Lock light on the keyboard.  Booting to recovery mode (what us old-time Unixers call Single-User Mode) allows one to fix driver issues in command-line mode.  After some tweaking of the startup scripts, rebooting went to command-line mode right away.  A few more adjustments, and the Gnome desktop came back next boot–for about 30 seconds, giving way to an almost-blank screen with “LVDS-8 setmode 1280×800 17” displayed in the upper left of the screen, no flashing Caps Lock…  A ‘Net search produced yet another /etc/modprobe.d script to set the video mode — seems there is some instability in the video settings.

Now, you might think that Linux isn’t any better than Windows in terms of grief.  But, this is more an issue of too many different configurations to test and not a lot of tight specifications to test to.  Being open source, these things get discussed by a lot of smart people and fixed fairly promptly, as long as they come to the attention of someone who understands the issues–like driver developers and other systems programmers who contribute to the various distributions or to the kernel code base.

But, I digress.  Meanwhile, looking through the dmesg output, it appears that the wifi is working just fine, but I still haven’t been able to wean the machine off its Ethernet cable.  With a road trip coming up in a few days, it is imperative to get the wifi up and running, or look for another alternative.  The latter is not a good prospect because of the huge number of add-on packages and custom software integrated into my system, it would take weeks to teach a fresh install to do all the things the current configuration could do–if we can keep it running and on-line…

Ubuntu upgrades

Well, as much as we hate to take down a production system, maintenance has to be done.  Earlier this week, it became obvious that some of our applications, like OpenOffice and others, could stand a bit of upgrading to get new features, so we undertook the always scary and sometimes painful steps to upgrade our Ubuntu workstations from 8.10 to 9.10.  Of course, this involves two upgrades for each machine, first to 9.04 and then to 9.10.

The first phase is complete, and both machines are now at 9.04, with few consequences:  My development machine needed to have the Apache configuration file tweaked, as I keep the webs in a slightly different place.  And, Judy’s machine somehow announced it wasn’t going to start the HP printer management tool for her new multi-function printer.  But, it still prints and faxes and scans, so I’m not sure if it is all that important, but I suppose we’ll have to find it and reconfigure after the whole upgrade is done.  The only scary part was a brief glitch in the power while the desktop machine was downloading packages, but the UPS held…  Good idea to test those before a major upgrade, as dumping power in the middle of an upgrade can ruin your whole day.  Yes, we do keep backups.  I do the laptop manually, since it isn’t always connected, but the desktop machine does hourly, daily, weekly, and monthly snapshots to the external drive we use for backups.

Update:  OK, spent all day Friday downloading the 9.10 update on my Compaq C714NR laptop, finally rebooted at 8:00pm and, of course, the wireless is broken again, which happens about every other Ubuntu update with the built-in Broadcom 4318 chip.  Part of the problem seems to be the crutches applied last time, but always something new.

Not only does the wireless not work, but the machine emits a loud clicking noise every few seconds.  I did get that to go away after I switched to wired connection, but after fiddling with the ndiswrapper and drivers for the wireless, it is back.  Now, I am a great fan of Linux, and have used it for 14 years, but some days it is a bit too on the edge.  Oh, the distros are plenty stable enough, but there are still problems with certain hardware peripherals that are not well supported.  Broadcom products fall into this category.  I’m not faulting HP/Compaq or Linux on this one–I’ve been a professional sysadmin for those 14 years, managing Solaris, Tru64, and other commercial Unices as well as Linux.  A few years ago, I had an IBM x-series server with a Broadcom Ethernet card in it that I had to build the driver from source for RedHat, and then it broke on a kernel upgrade and wouldn’t recompile.  I had to upgrade the entire system from RHEL3 to RHEL4 and port the 3rd-party application running on the server to get the system back up.   The market is full of otherwise good hardware with brittle firmware and drivers written by folks who don’t really understand how Unix works and couple their code tightly to specific library versions rather than the basic interfaces and system calls.

So, here we are, Saturday morning, trying to get wireless back up on our main development and road machine, for a road trip coming up the middle of next week.  The Ubuntu forums are great, but always just one person’s experience, which doesn’t always work for the next guy, depending on exact hardware, whether the system is a fresh install or upgrade, etc.  In my case, some of the problem appears to be left-over hacks from an earlier upgrade.