Either you're a programmer, monitoring the world of packets as they streak across your network cable in an attempt to track down some elusive bug, or you're just bored and thought it might be interest to see exactly what is coming and going across your network. For the most part, the existing packet sniffers are either expensive, or difficult to install. Hopefully with AnalogX PacketMon, we've managed to eliminate at least one of those problems :) So what exactly does a packet sniffer do, you ask? Simple, it sits on your network and reads all the messages that happen to cross it's path. If you would like a more detailed description of packet sniffers and the like, check out this article:

    http://www.grc.com/oo/packetsniff.htm

Operation is pretty straight forward, and on most systems it should work right out of the box - click Start and voila - it's capturing packets. It's important to note that PacketMon *REQUIRES* a system that has raw socket support, such as Windows 2000 or Windows XP (no, Windows 95, Windows 98, etc DO NOT have raw socket support).

    :::Configuration:::
Here's a brief overview of all the configuration options. 'Always on top' ensures that the dialog will always be the topmost dialog, while 'Minimize to Tray' will cause the application to become a little icon on the system tray instead of a box on they task bar like most programs. 'AutoNew on Start' tells PacketMon to reset the packet list before starting a new capture session. 'Packet Recycling' and 'Packet Limit' are both covered in more detail in the 'Managing memory' section of this document. 'Network Interface' specifies which physical interface on the computer that the packet monitor will be listening to; normally this should be whatever IP is your Internet IP. 'Stream to file' lets you specify a file to stream packet contents to, and is covered in greater detail in the 'Exporting data' section. 'Resolve IP to name' causes the program to resolve as many IP addresses as it can, once packet monitoring is stopped. All resolved IP and machine names are cached to the duration of the session, but will be resolved again once the program is run.

    :::Managing memory:::
Depending on the amount of traffic moving across your network, the memory PacketMon could require could be enormous - imagine if you monitored a 400 meg file being transferred, it would require well over 400 megs of ram to hold that whole session in memory. Due to this sort of limitation, there are really three different capture modes PacketMon can run in. The first mode is the normal mode - it will capture every packet until you stop it, and as mentioned above can use quite a bit of memory depending on what's going on. The second mode is using a packet limit (set in the configuration), with a limit turned on the sniffer will only capture that number of packets and then stop - so if you set it to 100, only the first 100 packets are captured. The final mode is recycle mode, and is basically a variation of the limit mode. When a limit is set, and recycle is turned on, the sniffer will start to re-use packets (oldest first), thus still capturing new packets while keeping a constant memory usage. This mode is more for people who are interested in monitoring a LARGE amount of information and are using it in conjunction with the stream to file option. For most people, the normal mode will be fine though.

    :::Interpreting the results:::
Once you've captured some data, you have several options to help you interpret what you've received. The main dialog contains all of the most common information, such as the source IP address, destination IP address, protocol, etc. To get a more detailed view of the specific packet, simply double-click on the line, and the detailed view will be opened. It's important to note that there is no limit to how many detailed views that can be opened, which makes it very easy to follow multiple connections, etc.

Most of the detailed views functions are pretty self explanatory; the top portion of the dialog represents the decoded IP packet header while the bottom portion contains the actual contents of the packet. These contents are normally displayed as hex with the characters mapped on the right side, but for easier reading you can choose to display the entire contents as just straight text (this is particularly handy when viewing HTTP/web traffic, etc). You may also choose to display the raw packet header, if you would like to see what additional information is stored in there.

The next and prev buttons allow you to move forward and backward to the adjacent packets. If you also have the 'Trace' option enabled, it will only step forward to packets which share the same source and destination IP's and ports, to help you view a specific connection.

    :::Rules are rules:::
One of the more powerful functions in PacketMon is its ability to apply a very flexible ruleset to any incoming packet. The rules section has one overall policy when dealing with packets - either it rejects all packets unless it matches a rule, or it accepts all packets unless it matches a rule. Make sure you understand the distinction between those before continuing - if you don't, rules are not going to do what you want. Multiple rules can exist within any number of groups, but right now groups don't have any real meaning, this does not mean that they won't in the future though, so keep that in mind. Each rule is made up of three parts, the description, the field that it tests against, and the operation it performs as the test. For example, let's say you want to create a filter which will only show packets going from you to webservers on the internet. Here's what you do:

    1. Set overall to "Capture only packets that match...". This automatically rejects everything except things we explicitly request
    2. Create a new group and change it's description to "Web traffic"
    3. Create a new rule and change it's description to "Outgoing traffic"
    4. Select the field "Protocol Header Dest Port"
    5. Select the "Numeric" test
    6. Select the operation "=="
    7. Enter in 80 in the field next to the operation.

That's it - click Ok, start up the packet monitor, refresh a webpage and you should see all the packets that you are sending to the webserver. Now, keep in mind that this does NOT include the packets the webserver is sending BACK to you... You get to figure out how to do that, but don't worry, it's easier than it sounds! :)

Data entered into any of the tests is pretty simple, numeric tests only allow numeric values, the string test only wants string values, and the binary test wants thing in hex. Oh, I guess that isn't quite as simple, but here's how the hex input works; each hex value is made up of two characters, 0-9 and A-F for a total of 16 values. So the character 'm' is ASCII value 109, which is 6D in hex - don't worry if you don't get it, this is really more for hard core network people or programmers. The hex values entered into the binary test can either be one right after the other, such as "01557DB4" or with spaces between each value, such as "01 55 7D B4", whichever appeals more to you.

    :::Rules part 2: there's always a special case:::
As with everything in life, there's a couple hidden special cases. These all apply to the binary test, and they are really meant to just make life just a tad easier. Say you would like to use an IP address in a test, you can instruct the binary test to convert it and perform the test. To do this, instead of entering hex, you would enter this (assuming the IP is 10.0.0.1):

    ip:10.0.0.1

and the binary test will do the rest. You can also specify wildcard ranges like this:

    ip:10.0.0.*

and it will match anything for the last range, so in other words 10.0.0.0 to 10.0.0.255. Now say you want to watch for a specific range of IP's, you can do that as well like this:

    ip:10.0.0.55-10.0.0.100

and it will match anything between those two.

It's also possible to have PacketMon do the work of resolving an IP address for testing by typing the following:

    dns:www.analogx.com

and it will use the IP address of www.analogx.com in it's test... Pretty cool, eh?

    :::Exporting data:::
There are two ways in which you can export information from PacketMon once its been captured. The first and probably the most common is just the 'Save As' function from the File menu. Just select the output file, and all of the active packets will be stored in a comma-delimited file which can easily be imported into a variety of programs (such as access, SQL, whatever). The other option is selected from the configuration menu and is called 'Stream to file'. With stream to file, all packets that are displayed will be stored to the file specified. It is particularly useful if you wish to monitor a particular connection or would like more historical information. It's important to note that each packet is not written to the file when it's received, but rather it's stored into an internal buffer first, and then once that is full it's flushed to the file.