DaedTech

Stories about Software

By

Ubuntu and Belkin Dongles Revisited

Previously, I posted about odyssey to get belkin wireless dongles working with Ubuntu. Actually, the previous post was tame compared to what I’ve hacked together with these things over the years, including getting them to work on Damn Small Linux where I had to ferret out the text for the entire wpa_supplicant configuration using kernel messages from demsg. But, I digress.

I’m in the middle of creating an ad-hoc “music throughout the house” setup for my home automation, and this involves a client computer in most rooms in the house. Over the years, I’ve accepted donations of computers that range in manufacture date from 1995 to 2008, and these are perfect for my task. Reappropriated and freed from their Windows whatever, they run ably if not spectacularly with XUbunutu (and, in some cases DSL or Slackware when that’s too much for a machine that maxes out at 64 meg of RAM).

So, I have this setup in most rooms, and I just remodeled my basement, which was the last room to get the setup. I had one of these things working with the dongle and everything, but the sound card was this HP Pavilion special that was integrated with a fax card or something, and the sound just wasn’t happening. So, after sort of borking it while trying to configure, I scrapped the effort and reappropriated an old Dell.

Each time I do this, I grab the latest and greatest Ubuntu, and this time was no different. Each time, I check to see if maybe, just maybe, I won’t have to pull the Belkin drivers off of the CD and use ndiswrapper, and lo and behold, this was the breaking point – I finally didn’t.

I wish I could say it worked out of the box, but alas, not quite. I plugged in the dongle and the network manager popped up, and sure enough it was detecting wireless networks, but when I put in all of my credentials, it just kept prompting me for a password. I remembered that Network manager had difficulty with these cards and WPA-PSK security protocol, so I tried another network manager: wicd. Bam! Up and running.

So, for those keeping score at home, if you have Ubuntu 11.10 (Ocelot) and a belkin dongle, all you need to do is:

And, that’s it. You should be twittering and facebooking and whatever else in no time.

Edit:

Since making this post, I set up another machine in this fashion, and realized that I made an important omission. The wicd wireless setup did not just work out of the box with WPA2. I had to modify my /etc/network/interfaces file to look like this:

For my network, I use static IPs and this setup was necessary to get that going as well as the encryption protocol. Without this step, the setup I mentioned above does not work out of the box — wicd continuously fails with a “bad password” message. Adding this in fixed it.

Cheers

By

A Small, Functional Makefile

I don’t write C++ all that often these days, but I suppose that I spent so many years with it that it never really feels foreign to me when I come back to it. What does oftentimes feel foreign is generating a Makefile when developing in Linux. I’ve made enough of them over the years that I know what I’m doing but not so many that I can go off the cuff after six months or a year break from them.

So I’m sticking a sample Makefile here. This is somewhat for me to refer back to whenever I need to, but I’ll also explain some of the basics. In this example, I’m creating a little C++ application for calculating the odds of poker hands, given what is on the table at the moment. At the time of writing, the example, in its infancy, has only one class: Card. So the files at play here are card.h, card,cc and main.cpp. The main class references card.cpp, which, in turn, references its class definition header file, card.h.

So there’s the simple Makefile. If you take a look at this, the main purpose of the Makefile is, obviously, to compile the source, but also to automate linking so that, as projects grow, you don’t have increasingly unwieldy g++ command line statements. So we define a few Makefile rules. First, card.o is generated by compiling card.cc. Second, main.o is generated by compiling main.cpp. The executable is generated by linking the two object files, and “all” is the executable.

That’s all well and good, but I can eliminate some duplication and make this more configurable. I’ll use Makefile variables so that I don’t have to repeat things like “card,” “oddscalc,” and “g++” everywhere.

In addition, I can see the inevitable redundancy coming from our previous Makefile. As soon as I add hand.cpp/hand.h and deck.cpp/deck.h, I’m going to have to create rules for them as well. Well, I don’t want to do that, so I’m introducing a scheme that, in essence, says, “compile every .cpp file I give you into a .o file and link it in the main assembly.” This will be expressed with a “.cpp.o” rule.

With this Makefile, if I want to add a new class, all I need to do is add the class’s .cpp file to the “SOURCES” definition line and it will get compiled and linked for the application. (Well, obviously, I need to write the class as well, but we’re just talking about the Makefile here.)

So that’s it. There are a lot of things you can do with Makefiles. Some people create a variety of build configurations. “make tar” is a popular option as well. But I think that this Makefile is relatively simple and elegant, and it’s easy to add to.

By

New Ubuntu and Weird Old Sound Cards

In an earlier post, I described how one can go about installing a Belkin USB dongle and a very recent version of Ubuntu on a dinosaur PC. Tonight, I’m going to describe a similar thing, except that instead a new piece of hardware, it’s a dinosaur that came with the PC itself. I must admit, this is more likely to be useful to me the next time I encounter this on an old PC than it will be to anyone else, but, hey, you never know.

First, a bit of back story here. As I’ve alluded in previous posts, one of my main interests these days is developing a prototype affordable home automation system with the prototype being my house. So far, I have a server driving lights throughout the house. This can be accessed by any PC on the local network and by my Android phone and iPod. The thing I’m working on now is a scheme for playing music in any room from anywhere in the house. Clearly the main goal of this is to be able to scare my girlfriend by spontaneously playing music when I’m in the basement and she’s in the bedroom, but I think it’s also nice to be able to pull out your phone and queue up some music in the kitchen for while you’re making dinner.

Anyway, one of the cogs in this plan of mine is reappropriating old computers to serve as nodes for playback (the goal being affordability, as I’m not going to buy some kind of $3000 receiver and wire speakers all over the house). I should also mention that I’m using Gmote server for the time being, until I write an Android wrapper app for my web interface. So, for right now, the task is getting these computers onto the network and ready to act as servers for “play song” instructions.

The computers I have for this task are sort of strewn around my basement. They’re machines that are so old that they were simply given to me by various people because I expressed a willingness to thoroughly wipe the hard drive and I’m the only person most people know that’s interested in computers that shipped with Windows 98 and weigh in with dazzling amounts of RAM in the 64-256 megabyte range. These are the recipients of the aforementioned Ubuntu and Belkin dongles.

So, I’ve got these puppies up and humming along with the OS and the wireless networking, and I was feeling pretty good about the prospect of playing music. I setup Gmote, and everything was ready, so I brought my girlfriend in for my triumphant demonstration of playing music through my bedroom’s flatscreen TV, controlled purely by my phone. I plugged in the audio, queued up Gmote, and everything worked perfectly–except that there was no sound. My phone found the old computer, my old computer mounted the home automation server’s music directory (itself mounted on an external drive), Gmote server kicked in… heck, there was even some psychedelic old school graphic that accompanied the song that was playing on the VGA output to the flat screen. But, naturally, no sound.

So, I got out my screwdriver and poked around the internals of the old computer. I reasoned that the sound card must be fried, so I pried open another computer and extracted its card, and put everything back together, and viola! Sound was now functional (half a day later, thus taking a bit of the wind out of my grand unveiling’s sails). So, I pitched the sound card and moved onto getting the next PC functional. This PC had the same sound card, and I got the same result.

I smelled a rat, reasoning that it was unlikely that two largely unused sound cards were fried. After a bit of investigation, I discovered that the problem was the card in question was an ESS ES169, which is actually a plug and play ISA device and not a PCI device. I had reasoned the previous card was fried when I didn’t see it in BIOS PCI list. But, there it was in BIOS ISA list. Because, naturally, a sound card inside of the computer, like a printer or USB external hard drive, is a plug-and-play device.

But anyway, with that figured out, I was all set… kind of. It took me an hour or two of googling and experimenting to figure it out, but I got it. I had to experiment because this card was pretty dated even five years (or roughly the 438 version of Ubuntu) ago, and so I wasn’t dealing with the same utilities or configuration files.

So anyway, with the grand lead up now complete, here is the nitty gritty.

When you boot into Ubuntu, it, like me or any other sane entity, has no idea what this thing is. You’ll see nothing in lspci about it, of course, and if you sudo apt-get install the toolset that gives you lspnp, you’ll see it as an unknown device. Don’t let that get you down, though; it was, at some time, known to someone. The first thing to do is use sudo and your favorite text editor to modify /etc/modules. You’re going to add “snd-es18xx” to that file and save it.

Next, add the following text to the configuration file “/etc/modprobe.d/alsa-base.conf”:

And that’s that. Now, if you reboot you should see a working audio driver and all that goes with it. You can see that it’s working by playing a sound, or by opening up volume control and seeing that you no longer are looking at “Dummy Output” but a realio-trulio sound output.

I confess that I don’t know all of the exact details of what that configuration setup means, but I know enough mundane computer architecture to know that you’re more or less instructing this device on how to handle interrupts like the PCI device it’s pretending to be and Ubuntu thinks it ought to be.

I’d also say that this is by no means a high-performance proposition. I’d probably be better served to get a regular sound card, but there’s just something strangely satisfying about getting a twelve-year-old computer with a stripped down OS to chug along as well as someone’s new, high powered rig that’s been loaded down with unnecessaries. I suppose that’s just the hopeless techie in me.

By

Old Linux Computer with new Wireless Encryption

As I’ve previously mentioned, one of the things that I spend a good bit of time doing is home automation. For prototyping, I have a bunch of very old computers that I’ve acquired for free. These are scattered around the house (much to the dismay of anyone with a sense of decor) and I use them as dumb terminals for interfacing with the home automation system. That is, I have a client/server setup, and these guys put the “thin” in thin-client.

Now, because many of these were made in the 90s, I don’t exactly put Windows 7 (or even Windows XP) on them. Most of them range between 64 and 256 megs of RAM and are of the P-series intel processors from that era. So, the natural choice is Linux. I have had luck using Damn Small Linux (DSL), TinyCore linux, Slackware, and Ubuntu. Since most of these are not for the faint of heart or anyone who isn’t comfortable editing low level configuration files in pico or VI, I’ll focus this post on Ubuntu (more specifically, Xubuntu, since the standard windows manager is a little much for these machines).

Because of the nature of what I’m doing–allowing machines on my network to control things in the house like lights and temperature–network security is not a convenience. It has to be there, it has to be close to bulletproof, and I can’t simply say “the heck with it — I’ll compromise a little on the settings to make configuration easier.” So I use a WPA-PSK encryption scheme with a non-broadcasting network.

Now, my house has three stories including the basement, and while I enjoy home improvement, I’m not such a glutton for punishment that I’ve retrofitted cat-5 connections in every room. Getting these old Linux machines connecting to the network is an interesting problem that I’ve ultimately solved by buying a series of Belkin wireless USB dongles. For the most part, these old computers do have a couple of USB jacks. So what I’ll document is how I’ve had success setting up the networking.

The first thing I do after installing the Xubuntu OS is to go to my main office computer and download ndiswrapper. This link is helpful, as it points you to where you can go about downloading the debian package to install from the command line: Ndiswrapper.. Ubuntu OS generally assumes for the purpose of their package manager (which, as an aside, makes me smile every time someone says that the Android/Apple walled app garden is a newfangled concept) that you have an internet connection or that the CD has the packages that you need. If I had the former, this post would be moot, and the nature of the slimmed-down Xubuntu install precludes the latter.

So, you can find the version for which you need ndiswrapper and grab it from the mirrors. From there, you can install the packages by following the instructions at the link for using dpkg from the command line. After doing so, you will be equipped with everything you need from ndiswrapper. Ndiswrapper is a cool little utility that essentially inserts a logical layer between the drivers and Linux, thus allowing Linux to use Windows drivers as if they were native to that OS. The FOSS folks are generally cool this way — no one writes anything with Linux in mind, so they bend over backwards to be compatible.

Once you have ndiswrapper installed, the next thing to do is to grab the CD that came with the Belkin dongle and pop it into the Linux machine. Mount the CD (if it doesn’t automount — I tend to do all this from TTY4 rather than the UI because when you only have a few hundred meg of RAM, the UI is a little slow) and navigate to the folder containing the .INF file. If you’re doing anything like I am, this is going to be inside of a folder with a name like WinXP2000. The key thing here is to be sure that you find the driver that matches your processor architecture — probably i386. This can easily be accomplished if you know what version of Windows came installed on the machine before you wiped it to put Linux on. If the machine didn’t initially come with Windows, you probably know what you’re doing anyway.

From here, you can execute a “sudo ndiswrapper -i {yourfile}.inf”. This will install the driver in the configurables of the ndiswrapper utility and ndiswrapper should take care of loading it on your next and any subsequent reboots. While you’re at it, you may as well reboot now and get the driver loading. If you’re feeling intrepid, you can try restarting the networking service to see if you start to connect, but I make no guarantees that this will work.

Once you’ve rebooted, Linux should recognize the driver, but you won’t be connecting to your network. I’m not sure off the top what it loads for default settings, but it sure isn’t a requester configured for encrypted access to your network. So now, I edit my /etc/network/interfaces file to look like the following:

If you fill in your own info for the {}, you should be set to go. This will configure you as a supplicant (connecting client) to a network with WPA/PSK, static rather than DHCP addresses, and non-broadcasting status (though this doesn’t really matter on Linux — iwlist, the linux utility, sees networks whether or not they broadcast). And, best of all, it will do all of this when you boot since it’s part of the interfaces file. No adding things to rc.local or your login script like in the old days.

The only extra thing here is generating your PSK. That is a little beyond the scope of what I’m explaining here, but if there is some interest in the comments for this post, I can create a follow up explaining how to do that.

I’m not sure how many people are fellow enthusiasts of re-appropriating old clunker machines to do cool, new things, but I hope this helps someone, as these sorts of configuration issues can be maddening.