I was going to post this at the Puppy Linux forum, but I realized it was more of a journal entry than a useful reply. So here's a story, of a box named Puppy...
Well, after getting a cheap 802.11b card (linksys WPC11 v.4) and seeing almost two dozen networks (1/3 nonencrypted) just using WAG, I figured it would be fun to try out this wardriving thing. I've had my laptop puppy running around the house for a month or so, and he's responding well to paper training... he seldom dumps unexpectedly. :) So I'm going to try installing kismet, my first installation of something in Linux other than a ready-to-execute program, a dotpup, or a Debian .deb install (when I was running slow-as-molasses Knoppix).
* Go to http://www.kismetwireless.net/ and read the documentation.
Great, I'm going to compile a C program! I'm a programmer, so I should be able to do this. But I haven't compiled from the command line since DOS...
* Download the file.
I have to do this from my Win2K box, because my laptop isn't connected to the network... at least, not yet. For some strange reason, the file is named with .tar.tar on the end.
* Rename the file.
Attempts to extract the .tar.tar file are fruitless in Windows and on the Puppy. Then, I notice that the file name I'm clicking on ends with .tar.gz -- but Opera keeps renaming it to .tar.tar. Once I rename it back to .tar.gz, it extracts just fine. Did they add this step to throw off n00bs? ph34r my 1337 haxx0r sk177z!
* Wonder if I extracted to a good place
I ended up with the files in /my-applications/kismet/kismet-2005-08-R1/ -- though I wonder if that's really the best place, I press forward anyway.
* Run ./configure
And get the message "No acceptable C compiler found". Did some searching and found out about usr_devx.sfs. Download-copy-reboot.
* Run ./configure again
Well, the compiler was found, and a bunch of other things were found, but I saw some messages scroll by saying "no" and saying that somethings might not work. The Kismet site says "If Kismet cannot find all the headers and libraries it needs, it won't be able to do many things." I decide that since I don't need it to do many things, I'll press forward.
* Run "make"
I go straight to this step instead of following the instructions given by the output from ./configure, because that's what the Kismet site says to do. Messages go by, and I decide that I'd better go out to the car and get the battery charger that I inadvertently left when I came into the office. Nothing like powering down in the middle of a build to ruin your day! By the time I get back, it's done, and I don't see any obvious errors... of course, I can only scroll back so far...
* make suidinstall
After reading all the dire warnings, I think the suidinstall is more compatible with Puppy Linux. One of the distro's features is that it's single-user -- everything runs as root, which tends to drive Linux purists batty. This step also seemed to complete without errors, but of course with a dire warning about how other users on the system could Break Things.
* edit kismet.conf (and fake a user)
The original thread included one very helpful hint. Puppy doesn't have users, but kismet expects them. So I looked for the /home directory... and didn't find one. A quick search showed a /mnt/home, but no /home. So I created it, and then created /home/kismet (as though there were a user named "kismet"). Then, I edited kismet.conf to include "suiduser=kismet". I also put /home/kismet in front of the logtemplate= variable.
* Reboot
Although the Kismet site says to run it, I'm sure I won't hurt anything by rebooting. Besides, I suppose I need to put my wireless card in the slot now. It's times like these that I love Puppy -- reboots are quick.
* Run it!
I open an xterm window in the /home/kismet directory (just in case it needs me to be there), and enter "kismet". I get the message "FATAL: Could not find user 'your_user_name' for dropping priviledges [sic]." I look at the kismet.conf file again and sure enough, I forgot to actually *do* the step above. I changed the log path, but not the suiduser= setting.
* Run it again, and do it right this time?
Bzzt. "FATAL: Could not find user 'kismet' for dropping priviledges." I take comfort in knowing how to spell "privileges", but not in my ability to use Linux.
*Sigh*
Back to the original thread, to ask if anyone has any suggestions. But at least they only have to read this installation epic if they really want to. Updates coming soon (hopefully).
Updates, as hoped
In the thread, user "spot" is used as the fake Kismet user. What I didn't know was that "spot" isn't fake -- it's configured as a real user. That means it'll be in the /etc/passwd and related files (as suggested in the replies to this journal entry). So I changed kismet.conf to reference suiduser=spot (like the original example). Just in case, I also changed the log path to reference /home/spot, and renamed the /home/kismetspot directory to /home/spot. Although "spot" is a user, the poor thing has no home. There's a lost puppy joke in there somewhere.
Result: It didn't fail on dropping privileges!
It failed somewhere else. "FATAL: Please configure at least one packet source." I'll have to go get some work done (the kind I get paid for), but it looks like I'm getting closer.
Back again
Thanks to the Puppy forum, I've set up my source parameter to source=rt8180,eth0,addme. Sure, "addme" isn't a terribly descriptive name, but I can always change it after I find out what it's actually used for.
Didn't work. "FATAL: mode get ioctl failed 95:Operation not supported". I hope this doesn't mean that the card doesn't support "monitor mode"!
Tried:
* Change to eth1. That wasn't it ("No such device")
* Use a different sourcetype, one that shouldn't match at all. Got the same error. That's a good sign... maybe "rt8180" is just the wrong sourcetype for the card? But Googling on Linksys WPC11 and rt8180 shows that it should be correct.
* Tried a bogus sourcetype. "FATAL: Unknown capture source type 'dohhhh'. At least I know I didn't misspell it.
* Tried running WAG (Puppy's Wireless Access Gadget), then Kismet. No difference.
I'm hoping that it doesn't turn out that this card doesn't support monitor mode. I think there's a way to find this out from the terminal window...
OK, some searching mentioned "iwconfig", which I've run before but not with any parameters. I knew that was safe, so I tried it. It showed what it usually does, eth0 "no wireless extensions" and wlan0 with all the business.
Wait. wlan0? Aw crap. I change the kismet.conf source param to rt8180,wlan0,addme and... I get an all-new error.
FATAL: Failed to set monitor mode: Invalid argument. This usually means your drivers either do not support monitor mode...
Argh. Will keep poking around.
* I find some indications that wireless cards don't often support monitor mode and regular mode at the same time. So I reboot and try again... no luck.
* I finally read the man page for iwconfig, and try: iwconfig wlan0 mode monitor. Result: "SET failed on device wlan0 ; Invalid argument." Oddly, though, setting a totally bogus mode gives a different error: "invalid argument "bogusmode"." So there's something going on.
* Googling like crazy, it looks like the WPC11 v4 may use a Prism2 chipset, which the Kismet site lists as using the "hostap" source. Try that in the .conf file. Same result as before.
* Also try wlanng. That gives a whole new bunch of errors, including 4x "wlanctl-ng: No such file or directory" and ending with "FATAL: pcap reported netlink type 1 (EN10MB) for wlan0. This probably means you're not in RFMON mode..." Try rebooting, in case the previous dinking with iwconfig messed things up. Same error. Try with wlanng_avs (noted as a newer version). Ditto.
Sigh. Back to work.
Update!
I had to do two things to get Monitor Mode to work: load a different set of driver modules (helpfully supplied by a forum member), and remove the rc.local commands that I added to support the SMC 802.11a wireless card I use at home.
Then, it failed because of permission problems in that newly-created /users/spot directory. Fixing that let the program start running all the way to where it opens up the user interface. And then:
ERROR: Panels support not compiled in.
The quote from above comes back to haunt me: "If Kismet cannot find all the headers and libraries it needs, it won't be able to do many things." Apparently, one of those many things includes the ability to run. Panels is a library for window management, apparently.
I don't really *need* a graphical interface, though. I'd be happy with a scrolling screen of text showing what's happening in the neighborhood. Some poking around the documentation shows that there's something called a "drone" that just writes logs, so maybe there's a way to set up like that... but it's also pretty clear that Kismet is designed to be a window-y application.
More to come...
It works!
I've been so busy enjoying Kismet, I forgot to post an update. Sure enough, I needed the Panels libraries, but the folks on the forum were kind enough to put together a zipfile^W tarball with the libraries. Once I realized that library means "recompile" (you'd think I'd never run a makefile from the DOS prompt), Kismet was up and running!
So far, all I've been able to do is marvel at the number of networks found on a drive across town. Two interesting correlations I've found:
* The total number of networks is directly proportional to the income level. Tons more networks on the more properous side of town.
* The security of the networks is inversely proportional to the income level. You're a lot more likely to see red lines on the Kismet display (indicating factory-default AP configurations) on the poor side of town, especially compared to the smaller number of total networks.
I'm a total wireless n00b, but I learn something every time I hit the "H" key for onscreen help. See you on the road!