darkness

Here’s how I got Kismet to work to my satisfaction in Red Hat 9. Note that this won’t work with the mini-PCI cards AFAIK, but only because I didn’t build a driver for them below. This was done with Red Hat 9, kernel-2.4.20-20.9, and Kismet 3.0.1.

First problem: airo-linux drivers, latest (CVS) or the ones in the latest errata kernel (2.4.20-20 IIRC) don’t work right. The Kismet forums seem to indicate that the last real working airo-linux driver was the one included with 2.4.19. I grabbed the source for 2.4.19, ripped out the Airo drivers, stole the Makefile from orinoco_cs’s distributions, and made a tar of the working airo-linux drivers. To compile these you will, of course, need development tools and a kernel-source package for your current kernel. Typing make should be sufficient to build the drivers. If your card is running, stop it at this time (I like cardctl eject). Now you have two choices to go about using the drivers you just built. The first, and probably easiest way, would be to copy airo.o and airo_cs.o over the ones in /lib/modules/`uname -r`/kernel/drivers/net/wireless/ (you might want to backup the existing modules first) then depmod -a. Hopefully you don’t get any (important) errors from depmod — but I haven’t tried this method, so I have no idea if it works. The second choice, and the choice that I’ve made, is to simply insert the modules manually before I start the card. insmod ./airo.o ./airo_cs.o to insert your modules. dmesg should show some messages about them loading.

When you’ve done all of the above to install the modules, you can cardctl insert or just physically insert your card if it wasn’t already in the laptop. Hopefully you’re now using the right drivers. (You should see something like $Revision 0.2$ in dmesg I think.) Take down your card if it’s set up to associate to a network: ifdown eth1 (I’m assuming your card is eth1; change to match your setup if necessary). Set it for any SSID and no encryption with iwconfig eth1 essid any enc off.

Cisco cards have a built-in channel hopper. Mine, unfortunately, doesn’t work too well: it gets stuck on a strong channel. Several (many?) people have reported this behavior. I mainly noticed it because my Orinoco card, which requires a software hopper, was finding APs that my Cisco card was not. To get around this, I made darkyhopper. Read the comment at the beginning of the file for compilation and usage instructions. Go ahead and compile darkyhopper and start it: darkyhopper eth1 & will work nicely.

A word about Kismet configuration. Here’s a few critical lines. (Here’s my kismet.conf file.)

source=cisco,eth1,thecisco
enablesources=thecisco
channelhop=false

Now run Kismet as you would normally and you’re in business. Hopefully. When you’re all done with your card, a good cardctl eject; cardctl insert is probably in order if you actually want to use it in a normal (not Wardriving) fashion.

I spent pretty much the entire day working feverishly at getting support for /proc/cpufreq into the 2.4 kernel. /proc/cpufreq allows you to tinker with the processor speed on those systems that allow it, like my ThinkPad T40 with Pentium M (Centrino) processor.

In short: this was a royal pain in the nuts. I tried several patches, fixed several more… whine whine whine. I eventually ended up making a patch against Red Hat’s 2.4.20-20.9 kernel RPM. This kernel, by default, will not work on a (or, at least, my) Centrino processor. I’ve posted my patch for /proc/cpufreq against RH kernel-2.4.20-20.9 and kernel-2.4.20-20.9+codefu.1, containing Centrino SpeedStep support. Both of these are using the cpufreq snapshot (I think) from 2003-09-09. It took me for-fucking-ever to find this. Along the way I also found http://www.codemonkeys.org.uk/projects/cpufreq/ which appears to have some patches for this against specific kernel versions (and may be too old, as of this writing, to support my processor) and what I suspect is the origin of the cpufreq stuff, or at least a CVS repository for it, at http://www.arm.linux.org.uk/cvs/. Scary, scary stuff. One bug I’ve noticed: I have to write a command to /proc/cpufreq twice for /proc/cpuinfo to reflect it, and by inference (and testing with time perl -e 'for($i=0;$i<10000000;$i++){}') for the change to take effect. For example, echo '0%42%42%userspace' >/proc/cpufreq the first time and no change reflected in /proc/cpuinfo, perl still running fast (assuming it was at 100% of speed prior to the command). echo again, and everything reflects the new lower speed. This might just be with the userspace governor; I didn’t test other governors except to note that they work. I might be using this governor wrong, in fact.

I installed cpudyn RPMs and it really seems to be working quite nicely thus far. Its polling seems to generate nothing noticeable in top, and it’s very responsive.

I got a ThinkPad T40, model 2379 (2379-D3U really) and I’m trying to stick Linux on it.

RH9 installed fine, but slowly: no DMA. Install latest kernel errata and you get DMA. DRI with the on-board Radeon Mobility 7500 seems fine too. PCMCIA didn’t work with the kernel RH9 ships; I got no insert notification when I inserted a card, no power, etc. Updated kernel seems to have fixed that. I’ll also note that I’m having no problem with sound after suspend/resume, as some people have apparently reported on T40p notebooks, at least.

There are some warnings on the Internet about not deleting the IBM recovery “partition.” On my ThinkPad, this data is actually hidden and immutable by you, the user; so fdisk freely. I deleted the XP partition and made the whole disk Linux except…

For the hibernate (suspend to disk) partition. I actually realized that I needed this after I had already installed RH9. What I ended up having to do was boot to rescue disc, resize_reiserfs (copy it from /mnt/sysimage — but make sure /mnt/sysimage isn’t mounted before continuing) on my Reiser extended root partition down about 2GiB, rewrite the partition table to include some free space at the end (a little over 1GiB), reboot (important! I think) onto the rescue disc again, then make a new primary partition type A0 from you free space. Then run tphdisk on the partition like tphdisk 1024 >/dev/hda4, probably another reboot, and hibernation should work. I did another resize_reiserfs /dev/hda4 after I was done, which expands the Reiser file system back out to the full size of the partition.

Now, if you manage to get this up and running, you may notice that you can hibernate fine from console, but in X you lock up when you resume. I grabbed XFree86-4.3.0-24 from Rawhide and applied the “DRI-RESUME” patch (link at the bottom). After doing that I could successfully come back from hibernation.

Some stuff is still broken. Closing the lid or pressing Fn+F4 (suspend) doesn’t work when a PCMCIA card is in; sometimes I get a weird combination of beeps. apm --suspend works, however. I tried the 2.4.22 kernel from Rawhide which has ACPI enabled, but it gives some nasty warnings along these lines when booting:

ACPI-0165: *** Warning: The ACPI AML in your computer contains errors, please nag the manufacturer to correct it.
ACPI-0168: *** Warning: Allowing relaxed access to fields; turn on CONFIG_ACPI_DEBUG for details.

Then I end up getting an oops in the kernel in some os_acpi_memory_write function or something like that. I’m hoping to get by with ACPI. I haven’t looked at any of the speedstep stuff yet. I don’t really know if that’s going to require ACPI or not.