EXPERIMENTAL I & II

It's been a long time since my last post.

January, huh? Wow.

A lot has happened. Sometime in late January I put up EXPERIMENTAL I on an Ubuntu 6.04 VM I had on my desktop system. It ran surprisingly well. I had a couple of goals in mind:

• Re-write Robo-Hinky to use a common code base across all running games

• Implement a snort-based anti-cheat of my own design

• Make a wireless UT server that I could toss into the garage, basement, attic, whatever, if and when I wanted.
  

This worked so well on the VM that I bought an ancient (circa 1998) IBM NetVista at a computer junk store (for about fifty bucks), installed Slackware 11.0 on it and moved EXPERIMENTAL I to its new home.

There were a few bumps in the Robo-Hinky transition but it went well, so I bought a Hiro H50069 802.11g Wireless Adapter from TigerDirect for the wireless part of the project.

After that, everything started to go to Hell.

I never really had any complaints about TigerDirect until I bought that card. Real tech specs are hard to come by, and many manufacturers will ship a variety of hardware products under a single model number. You never know what's under the hood until you rip it off and look.

BUT, at the time (they're out of stock now) TigerDirect had a "photo gallery" on this... thing... and the photographs clearly showed it was based on a RaLink chipset, which is A Good Thing™ for Linux tards such as myself. Native RaLink drivers exist, work well, and are under active development. I was looking for a RaLink card. And I thought I had found one. After all, there was a picture! And it showed the right chip!

caveat emptor

What I got was a card, same make and model number as the one advertised, but with a Marvell Libertas 88w8335 chipset.

WTF? Those bastards!

Don't get me wrong. It turns out Marvell makes marvelous (heh) wireless chips. Absolutely the lowest power consumption on the planet. In fact, a Marvell chipset has been chosen for use in the One Laptop Per Child (OLPC) project.

But there weren't any Linux drivers (not exactly true, but the drivers were only available to the OLPC development team - something to do with the proprietary ARM OS burned onto the chips).

So after a lot of bad feeling, negative reviews, support calls, RMAs, etc., etc., I said my final farewells to TigerDirect (sorry, fellas but someone else is getting my money from here on out) and bit the bullet.

I decided to keep the card because I couldn't find a RaLink card. I chalked the TigerDirect fiasco up to experience.

I used the NDISwrapper driver, which is a Linux user's driver of last resort. Through a bit of serious programming wizardry NDISwrapper allows you to use any network card you can find an... ugh... Windows driver for.

And it "sort of" worked for about six weeks. But I got tired of the hanging and the core dumps so I put it back on the wired network.

And the problems didn't go away.

As it turns out, Slackware 11.0 itself is a pile of crap. And I hate to say that because:

• Slackware was my first experience with Linux (way back in 1994)
  

• Slackware is blessed by (PRAISE HIS SWEET NAME!) Bob

In time it was also evident that using a wireless router as an access point is not a good idea. It "appears to work, but is not a good solution" (as they used to say in the Microsoft certification tests). My wireless router, a NetGear WGR614 sucked ass as an access point. It probably sucks as a router as well, but I use Linux and iptables for that anyway. It has since been retired (that is, trashed) in favor of a real access point, in my case a TrendNet TEW 430-APB.

In the middle of this entire driver/access point/OS fiasco I made a fatal error with fdisk (long story) and wiped out the BOT House server in the process. Since I had backups I put the whole shebang on the NetVista until I could rebuild the BOT House server. Performance was painful.

I thought I was going to rebuild with Ubuntu because it is a very, very slick Linux distro, but I have some serious problems with their basic philosophy (otherwise, if you can buy that drivel, I highly recommend it... not the drivel, the OS... Mrs.HinkyDink runs Ubuntu 6.04 and loves it). But Debian 4.0r0 came out in April, so I figured I'd give it a shot (BOT House was on an aging Debian Sarge distro before I trashed it).

And, as luck would have it, I found a GigaBit RaLink-based wireless NIC (VERIFIED!) at NewEgg.

Once BOT House was back on Debian I threw EXPERIMENTAL I on it as well, gutted the NetVista, wiped it, and replaced Slackware with Debian 4.0r0. The RaLink driver worked as expected (I never had any doubts about that) and the TrendNet access point proved to be rock solid (oddly, it too is powered by a Marvell Libertas chipset on an embedded Linux OS - go figure). I retired EXPERIMENTAL I and put EXPERIMENTAL II on the NetVista. I moved the NetVista to its new resting place where it is now doing double duty as a wireless print server. And a damned good wireless print server as well!

Everything works great now. It took six months and a lot of pain, but it works great. But what the Hell, I have too much free time as it is.

Turbo

Earlier this week I jacked up BOT House game speed to Turbo (from Hardcore).

From the comments I've seen it appears most players approve of the change, but sometimes it's a little flaky.

Anyway, I like it.

Los Misogynistas has also been kicked up to Turbo and I added Relics as well. I never played much with Relics enabled but it does seem to add another level of fun to the game.

Your comments are welcome.

The Tyranny of NAT

Anyone who has ever tried to set up a UT server on a spare box on their home network has usually given up in frustration. It always works fine locally, but you never see it in the UT game browser. Feeling it's kind of useless running a server the world can't see, you shut it down in frustration.

Well, relax. The world can see it, even if you can't.

The problem is Network Address Translation (NAT), a worthless hack imposed upon the world in 1994 to save Internet Protocol version 4 (IPv4) from itself.

Your ISP has granted you one and only one globally unique IP address. If you have one and only one computer attached to the Internet, this arrangement works out just fine and your UT server will work the way you expect it to.

As soon as you start adding computers and other devices to your home network (a practice formerly frowned upon by many ISPs) you need to start leveraging NAT to share that single IP address. You have no other choice.

The first step is buying some sort of router and assigning the computers in your home (internal) network an RFC 1918 address space. Sometimes that address space (usually 192.168.0.0) is imposed upon you by the router manufacturer by default. The router assigns internal addresses to computers on your internal network and then performs Network Address Translation on the traffic to and from the Internet.

Basically, the router removes your internal address and replaces it with the "real" IP address alloted to you by your ISP for outbound connections. For inbound traffic it does exactly the reverse: it changes your "real" IP into the internal IP of the requesting computer.

This works extremely well for 99% of things people do on the Internet, and it also scales well, but it essentially breaks the way the Internet was originally designed to work, back in the day when 4 billion IP addresses seemed like an infinite resource.

When you publish a UT server through your router, it should work fine.

The reason you don't see it in the UT browser is that the IP address published to the world is seen as an external address to your home network. The only way to access that external address from your internal network is through the IP address your ISP assigned you.

UnfortuNATely, these two addresses are the same address.

You end up with a packet with the same source and destination addresses. This is judged to be an invalid packet by your router and it is silently dropped.

It's like calling your own phone number. You're simply not going to get through.

If you leave the server running, people will eventually start playing. You can play as well, but you must play through the address of the UT server on your internal network.

I work with intelligent, highly paid Cisco and Microsoft network engineers who can't, for the life of them, understand this problem, so don't let it bother you. Publish that server and give it some time.

If you build it, they will come.