I’ve always thought it was pointless for game companies to hide their server addresses. Surely there are better ways to protect their servers…? I can understand the need to secure certain parts of your operation, for example, how it all works. However, IP addresses are easy to find for anyone with patience and it is sometimes necessary for customers to have them to troubleshoot connectivity or latency issues.

The other day I wanted to see how my password for my World of Warcraft account is sent over the wire. It turned out to be hashed, which is good. While investigating the traffic, I noticed that the client receives a full list of the servers with names, addresses, and other information. An example:

It is easy to see the server names, addresses, and the common port (3724)...but what is all the other information? When you view the entire stream, patterns definitely stand out. The 5th byte following the port of the server is commonly a (ASCII-translated) C, D, ?, or @. This byte appears to indicate the population level of the server. Servers with a value of “C” are “Full”, “D” is “High”, “?” is “Low” and “@” is “Medium”. If the 4th byte is “H” and the 5th is “C”, the server is “New”. Some of the dots seen in the screenshot are null, but others have values and I’m not sure what they mean. I would imagine: location, type (PvP, RP, Normal), Up or Down, etc.

I decided to go ahead and extract all of the server names and IP addresses from the stream. I saved the stream shown in the picture above to a file. I extracted the addresses manually the first time while I looked at the different patterns, but it took a while, and I wanted to be able to do it again quickly.

#!/usr/bin/perl

my @list = split(/:3724/, <STDIN>);

foreach (@list) {
    if (/([A-Z]{1}[a-zA-Z0-9\'\-\s]+)\.(\d+\.\d+\.\d+\.\d+).*/) {
        printf("%-25s %s %s", $1, $2, "\n");
    }
}


$ cat serverlist.asc | tr -d '\n' | perl extract.pl


And you end up with a list: World of Warcraft Servers. The script could easily be modified to generate a CMD file for the PacketShaper to create a host list containing all of those addresses.

I created a script to create the list, rules, and apply policies: wowrules.cmd

It doesn’t happen very often that I become completely fed up with a product. I try to be fairly reasonable and I understand that people aren’t perfect and nothing they create is either. However, I don’t think that was ever an excuse to make a terrible product and charge $30k+ for it, which is exactly what Packeteer seems to do.

We own one of their products, the PacketShaper 9500/ISP model. It is useful in our situation because we don’t have very much money for bandwidth (or anything, for that matter) but we have several thousand students with similar habits. If we don’t divide up bandwidth at all, one student could easily make the connection unbearably slow for everyone else without even knowing it. Packeteer PacketShaper allows us to prioritize certain types of traffic such as web browsing above filesharing. Usually it is pretty good about this.

So what makes the product terrible? The fact that it works just enough to hold a (rather large) piece of the market but fails miserably at the same time, and there is very little you can do about it.

When we wanted to upgrade our bandwidth from 40Mbps to 50Mbps, we learned that the operating system on PacketShapers (known as PacketWise) limits the amount of traffic it will shape to 45Mbps, unless you want to pay for a “linksize key.” This key is not cheap, either, but we ended up shelling out the money for it. When I went to install it (two commands) and reset the unit as you must, the box simply failed to come back up. This means we had no access to the box except local access, and this was in the middle of the night and I was an hour away from the datacenter. In the morning, a power cycle fixed the issue and I discovered that the PacketShaper had (as it usually does) reverted to a previous version of PacketWise after failing to load the current one.

Now, this afternoon, somebody went to add an address to a host list to prioritize somebody’s game traffic. Apparently PacketShaper didn’t like that either, and decided to reset and not come back up again. This time, however, the unit didn’t come back up after we reset the power. Nope, why should it? We only paid about $30k for it. But it is easy to get help when you have a support contract, right? Of course not.

This isn’t the first time such a bug has shown itself in PacketWise software. In fact, there are many. I’ve stumbled upon bugs involving oddities such as certain filenames crashing their FTP daemon. Even better, the programmers at Packeteer apparently haven’t learned about buffer overflows because a long string of characters in your command will—that’s right—overflow the buffer and cause the unit to reset (watchdog function). I have reported this issue to Packeteer twice, and received no response.

In the words of the infamous Tbone, my love for Packeteer has turned to hate.