I even bought another modem at a yard sale, thinking that maybe ours was on the fritz – but no… same M.O.: laggy/lossy connection, then no connection, go downstairs and the modem’s really hot to the touch. It probably doesn’t help that it’s in a small closet under our stairs with the router and everything else, but even if we keep the door open with a box fan blowing in there it still does it.

As I was throwing away a bunch of old stuff, I happened upon an old add-on DVR I’d bought to steal the drive out of. I opened the lid just to see if there was anything else in there I may want, and there it is – a small square heatsink just the perfect size for the little ARM (I think? Could be MIPS though) CPU in our SpeedStream 4100. I pulled it off, then used a razor to scrape all the old thermal pad off. I mixed up some thermal expoxy, applied a really thin layer and glued it to the top of the CPU in the modem, as you can see on the left.

We since went about 4 nights with no disconnects, despite the fact the top of the heatsink still got a bit warm to the touch. I was not taking any chances though, I wanted to attach a fan to it as well.

It’s been a while since I’ve had an excuse to get this uhh…. AfroTech on any project. I’m terminally lazy and still obsessed with genuinely attempting to do things The Right Way, so this site hasn’t seen much action as of late. Anyway, I grabbed an old squirrelcage fan I’ve had laying around a while – I don’t know how many CFM this thing is rated for, but let me tell you on 12v it is like a hair dryer. I scrounged up an old 5vDC PSU to power it because I didn’t quite need it to roar that bad.

I cut a hole in the top of the DSL modem for the heatsink to poke through into the front of the fan. I thought about having the exhaust blow inwards, but frankly it looked stupid – not to mention flimsy. In the end I decided to go negative pressure, with the exhaust blowing off the side.

The top of the modem is quite curved, so it really didn’t fit all that well when I affixed the fan to it. So I broke out some latex based sealent and caked it around the gaps. The air is sucked in via the vents under the board, makes its way around the board and over the heatsink and out the exhaust.

So I took a break from authoring this post, and it’s now about a week short of 2 months since I started working on it. The uptime on the modem speaks for itself:

Time Since Last Sync 031 days 20:56:49

I actually rebooted the modem at that time on purpose, it turned out it was a problem at AT&T’s end. For all intents and purposes, the modem’s been up and synced since I plugged it in. Considering we’ve had some really really hot days here, that’s a huge improvement.

So while we were doing our after-christmas-toy-shopping, I decided there needed to be room in the budget for a new headset. I ended up going with the Logitech g330, and here’s what I think after using them a few months with Mumble.

The good…

These things are comfortable. You’ll read that in almost every review, so allow me to elaborate a little bit. My old headphones (sans microphone) were also the behind-the-ear type, but that little over-ear strap to keep them from sliding down around your neck would start to make my ears ache after a while. I can literally wear these things for hours, and sometimes after everyone gets off Mumble I still have them on my head and I don’t notice.

They don’t echo. My old headset had it’s microphone boom made out of hard plastic – it was the bit that snapped and is held together with duct tape. I never really noticed it until I started using Mumble, but that hard plastic transmits vibrations from the headphone speaker, up the boom and back into the mic. The g330′s boom is made from the same shit as Gumby, and do you ever hear of people complaining about Gumby echoing? I didn’t think so.

They sound reasonable. Let’s be honest, they’re no Sennheisers, but they’re not awful. Apparently I sound a lot less “telephony” than I did before, but I’m not sure how much of that is because the mic is better and how much of it is due to the above-mentioned echo factor, and Mumble not trying to de-echo it.

They’re USB and 3.5mm. This was one of the selling points to me. I like to be able to use them on my PC as well as my PS3. When on my PC, I will generally use the sound card’s output because I think it sounds just a hint better than the USB, and it doesn’t disappear as a Windows device when I unplug the headset.

When I plug it into my PS3, I need a USB for the Microphone – but I probably don’t want to hear just the voice comms, I want to hear everything. Having headphones on and still using my TV’s speakers would put me at a huge disadvantage in an FPS. So I plug only the mic into the USB adapter, and the headphone plug into the TV. Bingo bango, best of both worlds.

The Bad…

They sound reasonable. I mean, this isn’t entirely bad, but I don’t want a reader to come away thinking these are the best sounding things ever. The fact they sit on your ear instead of around it doesn’t really help, I don’t think (and might be why I think even my cheap-ass older headphones sound marginally better on output).

The cable’s a bit short. Not a huge deal – it’s long enough that if your PC is on your desk, it’ll reach without you sitting all weird. If your PC is on the floor, you might have to do some re-arranging. Compared to the old PS2 Logitech headphones, with what seems like 10′ of cable, it’s a big difference. It’s non-trivial to use these things while sitting on a couch in front of a TV – you will likely want a USB extender or something similar – or you could upgrade to a wireless/Bluetooth headset.

The conclusion:

These were definitely a good buy, in my humble opinion. I’m not only a moderately-avid gamer, I also run a Mumble host… so naturally I use the shit out of these things, and I really have never had a situation where I wished I’d bought something better.

I bought mine at Best Buy for about $35, simply because I had to have them right then. If you check eBay, there are probably better deals – but be warned there are certainly much worse deals too ($75? Who the fuck are you kidding?).

Note: These instructions worked for me, but I can’t guarantee there’s not something I did by “muscle memory” and didn’t document. I repeated this process about 6 or 7 times, and each time found something new I’d forgotten to write down. It also stands to reason that these instructions may stop working at any point, for any reason – I can’t provide support for these instructions as by the time you read this I will likely not have a Linode any longer.

First, you’ll need a Linode, if you don’t already have one – any size will do, depending on what you actually want to do with it… but there’s no minimum Linode size for FreeBSD itself. Then next thing you’ll want to do is file a ticket with support – Linodes default to vcpus=4, which will choke FreeBSD at the moment. They won’t increase this setting of course, but they will happily lower it for you. Simply give them your Linode # and ask them to reduce vcpus to 1 and they’ll make the change. You can continue setting everything up, they’ll just tell you that the Linode needs to be powered off and restarted before the setting will take effect – which we’ll do when we go to boot FreeBSD anyway – and chances are by the time they respond you’ll be about ready to reboot into FreeBSD for the first time.

Configuring the Disks

Go into the Linode manager, and trash any existing configuration it may have generated for you, along with any disks. Create a new disk image, 64MB should be plenty, and make it ext2 – we’ll be using this disk to store our FreeBSD kernels, PV-GRUB’s configuration, that sort of thing.

Next, create a ~512MB or so raw disk, which we’ll be dd’ing a FreeBSD image over in a rather nasty fashion. Make it whatever size you need for your image, most FreeBSD “minimal” images weigh in at around 200MB or so, so 512MB should be plenty.

Finally, use up the rest of your disk space with another “raw” disk image, which is where our main FreeBSD installation will live.

Setting up Profiles

Next, create a new profile… I called mine “finnix” but you can call it “Linux Rescue” or anything you like. Set it’s kernel as “Recovery (finnix)”, set xvda to the “recovery – finnix (iso)”, xvdb to your ext2 kernel storage disk, xvdc to your temporary FreeBSD root (the littler one), and set the initrd to “finnix (initrd)”.

Create another new profile, we’ll call this one “FreeBSD”. Set kernel to pv-grub, 32-bit (might be called x86_32 or something), xvda is your kernel store, xvdb is your main FreeBSD disk, xvdc is your “rescue” FreeBSD disk.

Note: laying the disks out this way will have the unfortunate side-effect of having your main disk live on xbd1 in FreeBSD – there’s no way around this, the ext2 disk has to be disk zero for GRUB to run unattended.

Booting into finnix

Finnix is a “live CD” style Linux, which will work from a RAMdisk and not occupy or otherwise hold any disks, leaving you free to do things like dd images over them and such. Now we need a kernel – you have two options here. One, you can build one yourself on another machine, put it on a webserver, and curl it across; or two you can use the one graciously provided by Aprogas in this forum thread. If you decide to use his images (I did to bootstrap the process), I’d suggest mirroring them someplace yourself in case you screw up and need to do it multiple times.

If you’re building your own kernel, see the notes below – at the time of writing the default XEN kernel won’t work.

Now we need to put our kernel in place:

# mount /dev/xvdb /mnt
# curl http://path.to/kernel.gz | gunzip > /mnt/kernel
# umount /mnt

Now extract and write the image over your temporary root disk:

# curl http://path.to/root.img.gz | gunzip > /dev/xvdc

Sync (I’m not sure if this is necessary, but it’s a habit) and reboot:

# sync
# reboot

From the Linode manager or LISH, boot your FreeBSD profile. You should end up at the grub menu, so point it directly at your kernel (I’m led to believe chain loading the BSD loader won’t work under paravirtualization):

grubdom> kernel (hd0)/kernel
grubdom> boot

Because we bypassed the FreeBSD loader, it’s extremely probably FreeBSD won’t know where to find it’s root partition. We’ll point it at our temporary root partition:

mountroot> ufs:/dev/xbd2s1a

You should now have booted FreeBSD, and be able to login as root (you’re on the console, and if you’re using Aprogas’s image, there will be no password on root at the moment).

Installation

There’s a lot of gotchas in this portion, so try and pay attention to what you’re doing (and don’t rely on me). First thing to do is fdisk /dev/xbd1 and note the geometry, because for some reason the fdisk inside sysinstall won’t be able to tell it, and will set it to 0/0/0, which will cause sysinstall to blow up when you try to partition the drive.

Start sysinstall, and go into fdisk. Set your geometry as noted before (mine was: cylinders=2015 heads=255  sectors/track=63), and then use the entire disk for a Freebsd slice. Write your changes, then back out to the label editor. Create your partitions how you’d like them… for testing I just made a 512MB swap (not sure if I’d need it or not), and then used the rest of the disk for one giant partition. Set the mountpoints for your partitions with root as /mnt, because / is already in use at the moment. Write your changes out, no boot loader (I’m pretty sure it doesn’t work anyway) then bail out of sysinstall.

When you’re out of sysinstall, mount all your partitions under /mnt, because for me they wouldn’t stay mounted inside sysinstall. You might need to newfs them, I did sometimes and didn’t others.

Back into sysinstall, go into options and pick your OS version (any kernel you’re likely to build is going to have -pX on the end of it, which will not be a valid FTP path for installation), and then make sure you set the install root to /mnt.

Back out, and do a standard install, without clobbering any of your partitions. I can’t recall if you need to set the geometry again if you’re not actually writing anything out. Select your distributions and install them, if you’re using Aprogas’s images the network is already configured (DHCP). Let it fly.

Once you’re out of sysinstall, make sure all your partitions are mounted, then configure /mnt/etc/fstab the way it should be… it’s very likely sysinstall didn’t wind up making one, but if it did, it may not be sane – it may have /mnt as the mount points for everything, and you’ll want to set them back to /.

Also ensure that /mnt/etc/rc.conf is correct – it may not even exist. You probably want at least sshd_enable=”YES” in it. Finally, chroot /mnt, set a root password, and create at least one non-root account. Make sure it’s in wheel.

Exit chroot, unmount everything and reboot. At the grub profile again:

grubdom> kernel (hd0)/kernel
grubdom> boot

Then this time at the kernel’s “where the hell is my root partition” prompt (actual location of your root partition may vary):

mountroot> ufs:/dev/xbd1s1d

If everything went according to plan, you should be inside of a working FreeBSD installation at this point… but it won’t boot unattended. If your kernel has ext2fs compatibility, you can fix that from inside FreeBSD (otherwise it’s back to finnix). Either way, mount your kernel store partition under say, /mnt, then:

# mkdir -p /mnt/boot/grub
# cat > /mnt/boot/grub/menu.lst
default 0
timeout 5
title FreeBSD
kernel (hd0)/kernel
^D
# umount /mnt

Now PV-GRUB should boot unattended (sidenote, i have “timeout 5″, but for some reason grub instantly boots freebsd). I haven’t figured out how to pass the root partition to the kernel yet, so see the notes below about compiling that into the kernel.

Compiling a new Kernel

8.0-RELEASE kernels will boot and apparently function fine in Linode if they’re built with the XEN configuration. Anything newer will panic on boot because of the new x86bios stuff, which is called from atkbd, but Linodes don’t actually use the atkbd device (console functions fine without it)…

… so copy the XEN config to something (I called mine “LINODE”) and edit it. I commented out the lines for atkbd, aktbdc, kbdmux, and psm – though I’m not sure all that is necessary.

If you haven’t already got it, you’ll likely want “options EXT2FS” so you can install new kernels without shipping them off to another machine and rebooting into finnix. Finally, you’ll need to tell FreeBSD kernel where to find it’s root partition so I used:

options ROOTDEVNAME=\"ufs:xbd1s1d\"

Build and install your new kernel, noting that it’ll land in /boot/kernel. You need to get it over to the kernel store where GRUB can find it – if you have EXT2FS compatability, that’s as simple as mounting the ext2 partition in /mnt, and cp /boot/kernel/kernel /mnt/kernel. Unmount all partitions and reboot.

At first I didn’t have EXT2FS compatibility, so I had to gzip the kernel, scp it to another webserver, boot into finnix and curl it back the same way we initially got the kernel up.

Finally, at the time of writing you’ll be spammed with messages (approximately one every 10 seconds) about the “hypervisor wallclock nudging TOD”. It doesn’t appear to effect anything, so I commented this message out in the kernel sources (sys/i386/xen/clock.c:344 at the time of writing)… that’s probably bad, but that’s up to you.

One more boot, and the Linode should boot completely unattended, including when it falls and can’t get up and lassie needs to restart it. Which will happen. A lot.

I decided to take it apart and try and clean the “pot” – it’s not really a potentiometer, but that’s what many people would call it anyway and cleaning it is basically the same principle. It took me a few minutes to get into the machine and access to the front of the volume control – it involved removing the top cover, then the entire face (after disconnecting a couple of ribbon cables), and then removing the PCB from the plastic face.

Once I got access to the front of the “pot”, I pried open the four tabs holding it together. I grabbed a can of my trusty CRC 2-26*, and sprayed a bit in there before putting it back together and twisted it a bit. After pressing the tabs back together, I carefully put the ribbon cables back on, plugged everything in and gave it a shot. There was still some obvious scratchiness and/or errors, but it was markedly better.

I made sure the tabs were down tight, and reassembled the entire unit. Now that I’ve got a working volume control again (and I don’t have to find what the hell the kids did with the remote), my receiver works perfectly for my PS3 and my PC’s digital output.

* A word about 2-26 and spray “lubricants”. 2-26 is, according to the manufacturer, a plastic-safe precision lubricant that displaces water and can improve the electrical contact properties of things like switches, relays and stuff. WD-40, on the other hand, is advertised as a lubricant, but I’ve had terrible luck using at as such. While it doesn’t seem like it’s billed as such, in most situations I’ve used it it acts as a degreaser. Based on my experience cleaning volume controls and such, I wholeheartedly recommend you make the trip to Lowes or wherever and pick up some 2-26 instead.

Anyone that knows me knows I’m basically a hop skip and a jump from a clinical hoarding dysfunction – okay it’s probably not that bad, I really only tend to hang onto things I feel might be useful some day. It’s worked out pretty good, because that’s how most of this site came to be.

For some reason, I held onto an office chair that had the wheel broken off of it somehow. Don’t ask why, I probably won’t tell. Anyway, while reaching behind her, probably to do something with our new baby, my wife managed to snap the arm on her cheap Target office chair – unfortunately the arms on most office chairs are an integral part of the structure of the chair, rendering it pretty much useless.

It struck me to make one out of two, and my original plan of attack was simply to unscrew the screws that went into the bottom of the butt-cushion, and swap bases over. That didn’t work because my old chair, being an “executive” model chair had a high back and that obviously meant needed the screws approximately an eighth of an inch further apart.

What I found next was a small “retaining clip” on a shaft at the bottom that appeared to match on both chairs. After gingerly removing it and carefully dismantling the chair, I discovered that they indeed were a match.

I picked the better looking set of bearings (trivial really, considering the ones in mind were destroyed, see photo), put some good old axle grease in there and reassembled my chair on Sabriena’s wheels/base.

The end result, while rough and obviously worn, is a chair that’ll probably last us until we get enough money to buy another one… like any sane person would have by this point.

But even so, this mouse has served me well. It’s now called the “Microsoft Optical Mouse Basic“, but back when I got it I think it was just called the “Optical Wheel Mouse”. Regardless, it’s out-lived virtually all my wife’s mousing devices, most of which have been the wireless variety. I’m now used to the cord on it, we have quite the rapport and it never seems to get in the way… and it’s nice not having to change out batteries every freakin’ month.

Unfortunately though I have this rather nasty habit of highlighting and un-highlighting text while I read it. It annoys my wife no-end, the constant click-click-clicking while I’m engrossed in something particularly interesting, but I figure at least it’s better than me mutilating my fingers which is my other annoying concentration-habit.

The end result is that the micro-switch for my left mouse button has reached the end of it’s operating life. It bounces now, and dragging anything with it is a nightmare. I have a new mouse on the way (I actually bought one already, but it’s defective so it went back, and now I’m waiting again), but I can’t keep using my computer like this.

So I took my mouse apart with a view to switch out the left mouse button switch from another mouse – unfortunately they’re different switches and it won’t physically fit in my mouse… so I came up with a hackish solution in the mean time. I simply de-soldered the left mouse-button switch, and the switch under the middle mouse button, and swapped them.

I reasoned that the occasional, unintentional double-click on the middle mouse button probably wouldn’t anger me as much as the much more likely double-left-click… and how often do you ever drag with the middle mouse button on Windows systems?

Never.

So it should live until my new mouse gets here, at which point it’ll serve me well as a backup or for when I’m roped into fixing some asshole’s computer. Also, I apologize for the lack of technical content in this article.

So here’s how to do it yourself in a few easy steps… first, right-click My Computer and choose properties. Then, go to the Hardware tab, and pick Device Manager.

Navigate to your unknown device, double-click it and then pick the Details tab. Find the Hardware Ids entry, and look for the most detailed entry. My shitty SiS network adaptor’s is “PCI\VEN_1039&DEV_0900“.

Navigate to the PCI Devices database in a browser on an internet-connected computer. In my case, I’m looking for vendor ID 1039, so I’ll click “1″ and scroll down… and I’ll find the Vendor “Silicon Integrated Systems [SiS]“, which is to be expected. Click into the Vendor entry and look for the Device ID.

That should hopefully give you the correct Google-snacks to track down a driver for the hardware.

However, we have another site that my wife’s internet services company hosts that needed to be optimized for Digg/Slashdot-style surges, and it does use TimThumb – extensively in fact.

The Problem

TimThumb does have a caching engine built in which will, if your permissions are set up correctly, prevent the thumbnail from having to be re-generated each request. However, it does require the PHP script to run each time to return the cached file (in fact, the PHP script simply takes all the arguments, concatenates them together, generates an MD5 hash, then looks for that file).

If you’re using mod_php, this probably isn’t a huge deal… it’s not going to be the bottleneck for surges of traffic – mod_php and your heavy-weight Apache processes will be. If you’re using php-cgi or php-fcgi, however, having quite a few thumbnails on the page (such as themes like Arthemia) is going to cause you quite a headache. You could have at least 10 or 15 extra php processes per page load… even required to just answer an If-Modified-Since request!

Proposed Solution: Hack TimThumb

I don’t know if this is the greatest idea, but it seems to work. Our idea was simply to make TimThumb cache files in the same manner that Donncha’s WP-Super-Cache plugin does, and then the web server can simply fling out pre-thumbnailed images all day long without invoking php at all.

The first thing we had to do was modify TimThumb to save cached thumbnails in this manner, for which you can find a rough patch here:

• Patch for TimThumb to enable path-based caching

It’s not perfect, because it requires you to edit the script and point it at your thumbnails directory. We made ours /thumbs in the website’s root directory, and you have to point it at the operating system’s fully-qualified path to that directory. We then saved the modified version of the script into our /thumbs/ directory so we could access it easily.

The format is then /thumbs/<width>/<height>/<path/to/image>. A quick check of the file system shows it’s caching the files properly and finding the cached versions okay. Now to remove PHP from the equation.

Rewrite Rules

%cat .htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([0-9]+)/([0-9]+)/(.+)$ /thumbs/timthumb.php?src=$3&w=$1&h=$2&zc=1&q=100 [L]

I stole this rewrite rule from WP-Super-Cache, basically it just checks if the file isn’t a file, and it isn’t a directory, and then passes it in an argument to TimThumb. You can edit the zoom/crop and quality settings globally here – if you want them adjustable on a per-image basis you’ll need to hack the script to include those in the cache path instead.

If the file exists (which it will, if it’s been cached) Apache can simply pass that file out as a static file, PHP is never invoked for that image. When combined with nginx as a reverse proxy, we’ve found this resulted in a dramatic increase in performance for just one page-view alone. Because of our WP-Super-Cache rules for nginx will also work for these cached images, nginx can hand out upwards of around 7,000 thumbnails a second – more than enough to saturate a gigabit pipe on reasonable hardware.

Editing the Theme

Next up is editing the theme to call our new thumbnail URL – unfortunately, there’s no way around this process… it’s tedious. Replace:

<p><img src="<?php echo bloginfo('template_url'); ?>/scripts/timthumb.php?src=<?php echo get_option('home'); ?>/<?php
$values = get_post_custom_values("Image"); echo $values[0]; ?>&amp;w=<?php echo $width; ?>&amp;h=<?php echo $height; ?>&amp;zc=1&amp;q=100"
alt="<?php the_title(); ?>" width="<?php echo $width; ?>px" height="<?php echo $height; ?>px"  /></p>

with:

<p><img src="/thumbs/<?php echo $width; ?>/<?php echo $height; ?>/<?php
$values = get_post_custom_values("Image"); echo $values[0]; ?>"
alt="<?php the_title(); ?>" width="<?php echo $width; ?>px" height="<?php echo $height; ?>px"  /></p>

Caveats

There are a couple of downsides to this… first of all, there’s no automatic garbage collection. I don’t suppose it’s that big of a deal, because realistically you’re probably going to want to keep the thumbnailed images around anyway.

As mentioned above, unless you want to hack your URL scheme to include those arguments – you lose the ability to control the quality and the zoom/crop arguments on a per-image basis.

Related Links

• Patch for TimThumb to enable path-based caching

Removing the shim couldn’t be easier – shown in the picture to the left is my regulator, taken apart because my O-rings were bad. It’s not necessary to disassemble the bottom “swivel feed” of the regulator like I have, just remove it from your marker’s ASA, then grab the two sections shown in the photo and unscrew them apart. Note that the bottom potion “swivels” and if you’re trying to turn the regulator body in relation to the inlet tube you’ll get a whole lotta nowhere.

Once you have it in two pieces (there’s a spring in there but it shouldn’t shoot apart like a blow-back marker does when you take out the field-strip pin) remove the short, fat main spring. Underneath it, probably stuck to the piston is the shim. If it’s stuck, take something soft-ish like a pencil and push the piston out gently, then use something like an exacto-knife to separate the shim from the piston.

To the left, you can see the mainspring and the shim out of the regulator, and stuck together. You should be able to separate them with your fingers, the only thing that was holding them together on mine was the surface tension of the lubricant from inside the regulator. By the way, unless you’re planning on lubricating the regulator, try not to wipe off too much of the lubricant.

It should then just be a simple matter of putting everything but the shim back in the regulator the way you found it, and re-assembling your marker. You’ll have to play with the adjuster to get the pressure where you want it, I’m going to wait until my gauge and new springs get here before playing with it further, so expect another post in the near future.

Our most recent setup has been a Linksys WRT54G, which has been rather crap in it’s duties really. For some reason it’s consistently dropping packets and possibly rebooting (but with the garbage default firmware, there’s absolutely no way to tell if it’s rebooted or not) so I decided to replace it with a FreeBSD machine again – at least temporarily.

Networking in fwaggle-land these days is not without it’s new challenges, bumped well up from “lolsecurityissue” to “must have, design requirement” is Universal Plug and Play, or UPNP for short.

The Lowdown on UPNP

UPNP-IGD is both a terrible idea and an awesome idea at the same time – or more accurately: it’s an awesome idea, but a terrible implementation. Basically in it’s “Internet Gateway Device” form, it allows devices behind a firewall to arbitrarily set up port forwarding and open those ports temporarily, completely transparently to the user. For computing, this is probably unwanted – malware can easily make use of it and your firewall’s essentially useless.

But for gaming on consoles, it’s a godsend. It’s the difference between an awful experience on a Playstation 3, and an event-free, enjoyable gaming experience.

Setting up Routing

For the purposes of this article (which is already long enough, thanks to my story-telling) I’ll assume you’re familiar with setting up NAT under FreeBSD. We’re also going to assume you’re using the PF packet filter from OpenBSD – if you’re not and you’re clever enough to work out setting up NAT with one of the others, figuring out PF can be done in an afternoon.

We’ll assume at this point that your machine is up, routing and translating traffic correctly and is protected by some form of firewall ruleset in PF. We’re also going to assume you have a working DHCP server and all your machines are able to connect to the internet in some form. Now we make the top of your PF ruleset look like this:

scrub on dsl0 no-df
nat on dsl0 from lan0:network to any -> (dsl0) static-port
rdr-anchor miniupnpd

Obviously interface names need changing (or you can rename your interfaces, like I did – which requires only a one-line change in /etc/rc.conf if you happen to swap cards out for a different card/driver later on, instead of grepping for fxp0 in /usr/local/etc/. Reload the ruleset in PF if you haven’t already:

pfctl -f /etc/pf.conf

Let’s explain what’s going on here. First of all, it appears as though PF might scrub at least partially by default these days – I’m not sure about this, I haven’t confirmed it, but my Playstation was complaining about fragmented packets not going through and some Google searching appeared to indicate the PS3 likes to do dumb shit like sending fragmented packets with the DF bit set. This rule helped immensely and removed all complaints from my PS3 once miniupnpd was enabled.

Adding static-port prevents PF from re-arranging port numbers on the WAN side as it makes sense, which might break stuff occasionally, but for our purposes it’ll break far more if PF re-arranges port numbers on UDP traffic – internet games on consoles are stupid. If Modern Warfare 2 sends game data from port 3658, to another host on port 3658, and the packet doesn’t arrive with source port 3658, the host appears to drop it.

Configuring MiniUPNPd

Now that you have an anchor set up for MiniUPNPd to add rules to, it’s time to configure the daemon itself. Copy the miniupnpd.conf.sample to miniupnpd.conf in /usr/local/etc, and then start editing it with your favourite editor. The important bits I changed are:

ext_ifname=dsl0 # the interface name of your WAN device
listening_ip=10.0.0.1 # the LAN IP of your router
secure_mode=yes # this is default, but I wanted to point out what a great idea it is
allow 1024-65535 0.0.0.0/0 1024-65535 # access control, but you can do it via PF anyway

secure_mode is important – UPNP-IGD specs allow devices to set up firewall rules for other devices, which is where the broken-by-design issues with regards the UPNP spec come into play. You almost certainly do not want to allow this, and I can’t for the life of me figure out any reason you would need such functionality.

Access control can be configured based on IPs, you can also firewall the UPNP service (UDP port 5555) so that your network doesn’t appear to even support UPNP for hosts that you’d rather not have it. Our network is configured to assign all consoles into a /24 of their own, and to only allow those IPs to use the UPNP service. You can be as draconian as you like with UPNP access control, either via MiniUPNPd’s configuration or just by firewalling the UPNP service.

Testing it out

The first step was testing the internet configuration in the network settings menu. After correctly allowing UPNP, I successfully reached “NAT Type 2″ as far as the Playstation 3 is concerned. Next it was time to test if a game would actually work, so I loaded up Modern Warfare 2 and tried it out. At first I had “NAT Type: Strict” which basically meant that I was boned, until I found the above gotcha about source ports. Adding a static-port keyword to my ruleset in PF and reloading gave me “NAT Type: Open”, and I was all set.

With our PS3s in their own subnet, I’m able to enjoy hassle-free internet gaming without sacrificing the security of the rest of our network.