Quake Packet Sniffer v0.3 by Damian Frank (damianf@wpi.edu) ------------------------------------------------------------------------------ This program is covered under the GNU copyleft. Please read the accompanying file COPYING if you are unclear on what this means, ESPECIALLY IF YOU PLAN TO MODIFY THE PROGRAM! (ahem) Thanks. This program is based upon (and therefore a derivative work of) an IPX sample program written by Greg Page (greg@caldera.com) and Caldera, Inc. This in no way indicates endorsement by Greg Page OR Caldera. I doubt either of them are even aware of qsniff's existence. But without them, the IPX code would not be where it is today, and I wouldn't have had a sample program to learn it from. So, thanks guys! :) This version of the packet sniffer is intended to work only with Quake Test 1, and will only sniff IPX packets (hence, it only works with the MSDOS version since, as far as I'm aware, the Linux version neither works over the net nor even tries to support IPX yet). Every few seconds, qsniff broadcasts a message over IPX asking if there are any Quake servers listening - exactly like Quake itself does when you type SLIST. It then displays any answers to its query in a readable format. The information available is limited to the IPX address of the server, the server's hostname (set within Quake), the map name, the number of players currently playing, and the maximum number of players for the server. Please note that, for this to work, your kernel must support IPX networking. This is NOT the default! It's one of the options in newer kernels. If your kernel configuration doesn't mention IPX at all, get a newer release. ALSO note that, to use any IPX programs, you must enable the IPX interface. This is done by running a program called ipx_interface which is usually located in /sbin. If you don't have it, get the IPX utilities package by Greg Page from ftp://ftp.caldera.com/pub/ipx which includes ipx_interface. For most people using just one ethernet card, running the following command as root should suffice: /sbin/ipx_interface add -p eth0 802.3 You only need to do this once per boot, so I recommend placing it in /etc/rc.d/rc.M or /etc/rc.d/rc.inet2 if you use qsniff often and ipx_interface doesn't cause any problems. qsniff has a few command line options, detailed below: -h or --help display a brief summary of these options -d display debug info (not very useful - see below) -s check for Quake servers on IPX socket (default 26000) -p set the polling delay in seconds. this is the number of seconds to wait before broadcasting another query. It is a floating-point number, and can have any value between 0.2 and infinity. DO NOT MAKE THIS TOO LOW OR YOU WILL FLOOD THE NETWORK! This is not a good way to get on the good side of your network administrators. Don't be a jerk. A value of 1 is probably the lowest I can imagine anyone wanting to set this anyway. I'd love to display more information, but the server doesn't return more, nor is any more information ever broadcast. Without more detailed information on the Quake protocol, it would be impossible to tell more. Getting more information on the Quake protocol would require a better sniffing tool than I have. Which means that may be my next project..;) If you know of a good ipx packet sniffer, especially for Linux, please let me know! Debug mode: This is mostly useless to mere mortals. ;) It will tell you whenever it gets query packets (so you can see if there are a lot of people looking for a game), whenever it gets a packet it doesn't understand, and when it gets interrupted by a signal, which will happen every time it sends out another query packet. It will _also_ display an additional byte from the server's information packet, right after the player number information. I'm not sure what this byte means. From what I've seen, it's always 1. If you have any ideas as to what it is, let me know. If it's NOT 1 for you, then please mail me at damianf@wpi.edu with what value it was, and some information about the game that was running. My current guess is that it's a version indicator. Anyway, I make no guarantees that this will work right, ever, on any machine for any person. Furthermore, I will assume NO responsibility for any damage you might cause by running this program, either to yourself or to others. Basically, if you screw up, it's your problem. If you screw up by running the program I wrote, it's your problem. It's very unlikely that anything bad will happen, but if it does, well, it's your problem. I wrote qsniff fairly quickly, and have only tested it on a few Linux boxes. It was developed on v1.3.61 w/ gcc 2.7.0, so if it doesn't work for you, try upgrading. Don't mail me with questions on how to compile it; I don't have time to help with that. Do, on the other hand, mail me with suggestions on improvements, or any info on the protocol you might have. If you want to change the source code and redistribute it, that's fine with me, but be sure to read the GPL (GNU Public License), which is included in the file COPYING. You must include that file with any derivative works, as well as attributions. Also, if you base any other programs on protocol info that you determined from qsniff, then please provide credit where credit is due. Enjoy! Revisions: 0.1: First version 0.2: Fixed bug: -d mode would constantly report receiving query packets, because I was using non-blocking reads and forgot to stop printing packets if I didn't get anything. The code no longer uses non-blocking calls anyway, though. Attempted to reduce CPU-hogging by using blocking reads instead of polling. Unfortunately, blocking reads hog up system CPU time, too. Probably something in the kernel IPX code, but I'm not sure. I may consider putting in a sleep or something, but that would mess up my alarm timing as it stands. So..for now, just nice it if you're planning on running it for long. Cleaned up other miscellany, such as somewhat more consistent error reporting. 0.3: Fixed bug: turns out that one of the bytes in the server's answer packet header varies, so a lot of packets were not being recognized. This should be fixed now, although I'm not really sure what that byte meant.