So maybe your printer already advertises mDNS on the LAN, as mine does, but doesn’t pass out all the parameters AirPrint devices expect to see.  From what I’ve been able to determine from a variety of sources, here’s what I know:

• IPP is used for the actual printing
• Either mDNS or DNS-SD for advertising the service availability
  • mDNS for local LAN
  • DNS-SD for wide-area support
  • DNS-SD announcement is in _universal._sub._ipp._tcp
• AirPrint requires a TXT record called URF
  • All current AirPrint apps seem to print as PDF, but field opens the door for additional formats – PDF support will be key further down in the process

So, what do you need to make this work?

1. A printer that supports printing via IPP
2. A server that can run cups & avahi
3. A suitable printer driver for cups that supports your printer and can handle PDF documents (foomatic, gutenprint, etc. are fine choices)

I opted to create a VM on my existing VMware ESXi server at home.  I used the FreeBSd 8.2 x86 (i.e. 32-bit) version.  I just did a basic install, then added packages from the CLI later.  I installed the packages I needed:

pkg_add -r avahi cups gutenprint-cups py26-cups

This will pull the packages for avahi (mDNS server), cups, the Gutenprint cups drivers and the python interface to cups.

First, you’ll want to configure cups so that everything on your local LAN can print to the cups server.  This is covered quite well in the cups docs, so I’ll omit those directions.  Next, add your printer to the cups server.  Again, this is a very simple process, so I’ll omit that as well.  After you get the printer setup on the cups side, print a test page to be sure the communication between your cups instance and the printer is functioning.  Got it working?  Good.

Next, you’ll run a script from a guy named TJ Fontaine that generates the Avahi service file.  So, the script talks to your cups server and pulls the list of available printers, and spits out service files for them.  I wasn’t thrilled with the quality of the XML that got shot out by the program – it was almost all on a single line.  I took the time to break the lines and indent properly, and for my HP LaserJet 2420dn, I wound up with:

[airprint:root](04:47 PM)
/root# cat /usr/local/etc/avahi/services/AirPrint-OfficeLaser.service
<?xml version="1.0" standalone='no' ?>
<!DOCTYPE service-group  SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">AirPrint OfficeLaser @ %h</name>
<service>
        <type>_ipp._tcp</type>
        <subtype>_universal._sub._ipp._tcp</subtype>
        <port>631</port>
        <txt-record>txtvers=1</txt-record>
        <txt-record>qtotal=1</txt-record>
        <txt-record>Transparent=T</txt-record>
        <txt-record>URF=none</txt-record>
        <txt-record>rp=printers/OfficeLaser</txt-record>
        <txt-record>note=hp LaserJet 2420</txt-record>
        <txt-record>product=(GPL Ghostscript)</txt-record>
        <txt-record>printer-state=3</txt-record>
        <txt-record>printer-type=0x21014</txt-record>
        <txt-record>pdl=application/octet-stream,application/pdf,application/postscript,application/vnd.cups-raster,image/gif,image/jpeg,image/png,image/tiff,text/html,text/plain,application/vnd.cups-banner,application/vnd.cups-postscript,application/vnd.cups-raw</txt-record>
</service>
</service-group>

Drop this in /usr/local/etc/avahi/services, and Avahi will start advertising the service.  You’re going to need to generate your own service file, but with the script linked above, this is pretty simple.

Now, go grab an iPod Touch, iPhone or iPad running iOS 4.2 or later.  Launch Safari, print something.  Your newly created printer should show up as available.  Print there, and whammo, you’re done.

For those who don’t know, I was a hardcore Symbian user for years, mostly S60 devices, though I had a fleeting stint using a Nokia 9300 (my only S80 device ever).  That’s what you get when you spend the better part of 10 years working at Nokia.  Nokia has historically done a very good job of producing smartphones – it’s been their bread & butter for years.  I had a brief stint using an N97, followed by a loaner of an N97 Mini from the Womworld guys, and I was never wowed, heck, never even liked S60 v5.  For me, the last great S60 was v3.  FP1 or FP2 were both good to me.  Heck, I still have an N85 that I use for my home line.

These days, it seems like everyone’s in iLove, going absolutely gaga over the iPhone, including the latest incarnation – the iPhone 4.  Deathgrip aside, I was never a huge fan of the iPhone.  I had a 3G for a day, and returned it.  Bad battery life (like in the 3-4 hour range), and the walled garden – don’t get me started about locking out developers – I maintain that it’s bad for business in the long run.

I got my Nexus One in the AT&T variant, so it’s got quad-band GSM/EDGE and tri-band (850/1900/2100) UMTS/HSDPA support, as well as the 802.11g WLAN, Bluetooth and GPS radios.  That’s a lot of RF in a small case.  Physically speaking, the Nexus One feels great in your hand.  There’s some sort of coating on the metal parts that’s just slightly tacky, not metallic at all.  It just feels great in your hands.  The RF performance on the Nexus One is very good in my experience.  I don’t notice any lower coverage than I saw with my prior Nokia E72.  All in all, very good.

Connectivity is where Android 2.2 really shines.  On my Nexus One, I’ve got my home Google Apps account sync’d, as well as my corporate Exchange ActiveSync.  The phone keeps track of where the different bits of data came from and only tries to sync the appropriate data to the various accounts.  It’s very well thought out and I didn’t wind up with lots of data duplication.  Further, Android 2.2 implements the much sought-after mobile hotspot feature.  If you’re unfamiliar, you use your WLAN radio to setup an Access Point, then connect WLAN devices to that AP, which shares your phone’s 3G (or even EDGE) wireless data connection.  Pretty slick.

On the ActiveSync front, the client is very good, and fairly complete, though a couple of what I consider to be key features aren’t there yet.

Rather than the App Store, Android uses the Android Market.  Same idea, essentially, though it seems that you need to do substantially less hoop-jumping to get your app in the Market.  While yes, Apple definitely has a wide margin of available apps, I’ve yet to be disappointed when I got searching for an Android app for a specific task.  This review focuses on the device itself, not the apps, so I’m not going to go too deep there, but suffice it to say that I’m happy with the app selection.

Overall, it’s a great device, and the future for Android is indeed bright.  Go make the jump, you won’t be disappointed.

1. No RAID
2. Onboard NIC required significant fiddling to get working under ESXi 3.5u4
3. No onboard video, so I needed a video card, plus a network card to get going (the real root cause of #1 above).
4. A bit loud.  The system wasn’t terribly loud, but for something that’s on full-time in the background in my office, it could be distracting at times.

So here we are, it’s a brand-new year, so the big project was an upgrade, inspired by some requirements I found with a project at work.  In the end, the old server was converted into a workstation and now has a happy home.  So what’s the current system?  Another Shuttle XPC.  This time, it’s the SG45H7.  This is a slightly smaller chassis than the already small SP35P2 Pro.  The SP line has space for 2 hard drives up top, above the optical drive that the SG line lacks, resulting in a shorter case.  The SG45H7 is targeted as an HTPC, and includes onboard video with both SVGA and HDMI outputs.  Further, it includes 2 expansion slots, one PCIe x16 and one PCI.

Shuttle SG45H7 Case

System preparation was pretty straight forward.  I followed the basic Shuttle directions for installing the Intel Core 2 Quad 9550  CPU, and the 8GB of DDR2-800 RAM (the ram shifted over from the SP35P2 Pro).  With the latest BIOS upgrade, (which I applied first) the SG45H7 can handle 4x 4GB DIMMs, for a total of 16GB of RAM.  Not too shabby!

The system came with 3 internal SATA-II ports, only 2 of which were pre-cabled (1 extra cable in the box though), and an IDE cable for use with an IDE optical drive.  I removed the IDE cable and one of the 2 SATA cables, which gave me room to run a SAS SFF-8087 to 4x SATA break-out cable through the wiring channel along with the remaining system SATA cable.  The SATA cable was used for a DVD-RW drive (I picked the cheapest Lite-On DVD-RW drive that Newegg was selling at the time), and 2 of the 4 SATA connectors on the break-out cable were for the 2x 1TB Samsung HDDs I installed.  Starring as the RAID controller was an LSI 8344ELP PCIe x4 card.  I got a new card that was actually an HP OEM version.  It’s really HP only as far as the sticker goes.  It still runs the LSI firmware, and happily accepted the latest firmware from the LSI website.  I’ve used this card a number of times now in other system builds, and it works very well, in addition to the low cost (around $150).  That’s right, $150 for a PCIe x4 RAID card that’s real, honest-to-goodness hardware RAID with 8 ports, supports use of SAS expanders to accommodate up to 32 total drives and supports RAID 0 / 1 / 5 / 10 / 50.  Yes, I see the word “obselete” in the URL on LSI’s website, but I’m not terribly bothered by that, since there is excellent support for the card.  Driver support is excellent, and there was a firmware update in November, 2009.  Doesn’t seem all that obselete to me.

Since the onboard NIC was also not supported by ESXi 4.0 update 1, I opted for an Intel Pro 1000 GT PCI NIC.  This was my only quibble with the build.  If this system had both onboard video, and 2 PCIe slots, I could have used a multi-port NIC from Intel.  Now that this build is complete, Shuttle will probably truck out a new version of this model that includes 2 PCIe x16 slots, keeping the onboard video.  I’ll save that for the 3.0 version of the project, maybe in 12-18 months.

After I completed the hardware build, I formatted a USB stick to be bootable, using Method 2, as shown on bootdisk.com.  On that bootable USB stick, I dropped the Shuttle BIOS upgrade files, as well as the RAID controller firmware update.  Then, I booted from the stick and did the upgrades needed.  That took a couple of reboots and probably 10 minutes to complete.  After that, I built the RAID, from the LSI card BIOS, which only took a few minutes, since I was just simply creating a blank RAID-1 volume from a couple of empty drives.

Lastly, I installed VMware ESXi 4.0 update 1, and frankly, it was the most uneventful part of the process.  Why?  It took a good 5 minutes and almost no interaction to complete.  The final migration step was to move VMs over, update the VMware Tools and upgrade Virtual Hardware.

I was tired of performance that VMware Server offered, along with its baggage.  For instance, the Web UI suffered from frequent crashes, and it was also fairly slow.  Having had great success in the lab at the office with VMware ESXi, I decided that was the way to go.  ESXi 4.0 is still fairly new, and I’ve had some trouble with my SSL VM on it, so I decided to sit that one out for a bit, leaving me with 3.5u4.

Next hurdle – my hardware.  I use a Shuttle XPC for my server.  It’s small, and doesn’t inhale too much power, so I found it to be a good choice as a Linux server, what it’s spent most of its time as.  Unfortunately, as it uses a Marvell Ethernet chipset (the sky2 driver), and that’s not on the VMware HCL, there wasn’t a driver for it.  But then, KernelCrash to the rescue.  The author gives very nice build instructions to get a mod_sky2.0 driver that works on ESXi 3.5u4.  It’s been good enough that I haven’t noticed any problems with performance or functionality.

I did have to give up my Linux software raid, so at the moment, I’m sort of running without a net.  My plan is to add an external RAID box, either connected via eSATA or 1GbE NAS.  Obviously eSATA will perform better, but I’m not yet convinced I’ll see much of a practical performance difference.  I’ll add a new Intel e1000 NIC to the system dedicated to storage if I do that.  Anyone have thoughts on VMware iSCSI vs NFS performance?

Now I’ve got VMs for my SSL VPN, my File/Pri DNS/DHCP/kitchen sink server, a secondary DNS, and a FreeNAS, as well as some assorted client systems to test various things.  All in all, it’s worked very well.

If you want to go straight to ESXi 4.0, KernelCrash has you covered there as well.

IDS Install with Tap

I wanted to install a small network ids on my home network using Snort.  I wanted to stick the nids outside of my firewall, so it would be able to examine all Internet traffic coming in & out of the network.  Of course, putting a device online outside my firewall without any protection isn’t terribly attractive, so I decided to install using a tap.  Ignoring the fact that this is really the only possible configuration, given my home ISP (FiOS), it allows me to do a completely stealthed deployment of a nids.  Unfortunately, this type of deployment also precludes the ability to interact with any traffic seen on the wire, so flexresp is out of the question.

Construction of a passive tap

The other bad part about using a tap is that simply by the nature of the tap, you need to have 2 Ethernet ports to sniff on.  Why?  Check out the Snort docs on the subject.  When you setup a tap, you can only push one direction’s worth of traffic onto a single port.  This means you have to combine the traffic on the sniffing device.  Since you can only receive traffic and can’t send on these ports, you must have a third Ethernet port to connect to your internal network, or if you’ve got a larger network, a management LAN.

So, building your tap is pretty simple, when you’ve got the picture here on the right to work from.  Need the parts?  Head over to Home Depot and grab yourself the following parts:

1. A plastic electric box (get one marked for “Old Work”).  An 8 cubic inch box will probably not be deep enough, so go for the one of the 14 cubic inch ones.  Unscrew the little anchor flaps and toss them in the trash.
2. A 4-jack faceplate.  Whatever color you like.  I used white.
3. 4 Cat 5e Ethernet jacks.  I got 2 white and 2 blue.  The white jacks are the Host jacks, and the blue ones are Tap A & B, as shown in the figure at the right.
4. About 6 inches of Ethernet cable.

Strip off the jacket and remove the 8 wires.  Wire up the jacks as shown in the figure.  I found it easiest to wire up one of the host jacks, then run the wires through the tap jacks and finally up to the other host jack.  Try to keep the twists in the wire as much as possible, to prevent NEXT (Near End Crosstalk).  Cap off the jacks and screw the thing into the electric box.

I made two, one to use for the NIDS, and another to carry around for work if I need a tap.

I’m not going to go into how to install Snort, ACID, or any of that stuff.  There are already enough guides out there on that topic.  I will, however, address the need to join the two sniffing interfaces into a single full-duplex interface for Snort to sniff on.  You’ll be using the Linux kernel’s bonding module for this.  I’m going to assume Debian or Ubuntu here.  Add the bonding module to your /etc/modules file, then execute the command modprobe bonding.  In the /etc/network/interfaces file, you’ll need something like this:

auto bond0
iface bond0 inet manual
  up ifconfig $IFACE 0.0.0.0 up
  down ifconfig $IFACE down
  post-up ifenslave bond0 eth0 eth1
  pre-down ifenslave -d bond0 eth0 eth1

Obviously, you’ll need to configure Snort to sniff on the bond0 interface.  Don’t forget to install the ifenslave package.  It’s not installed by default on Ubuntu.

The biggest concern lots of tap novices have is accidentally introducing traffic onto the wire via the tap.  Let’s be clear.  This is simply impossible.  Can’t happen.  At all.  Why?  The only pins that are live on the tap ports are 3 and 6.  Guess what happens on those pins?  It’s only RX, not TX, so you can’t transmit on the tap ports.

Bookmarklets

Bookmarklets rock.  They’re great timesavers, and a worthy addition to your browser’s bookmark bar.

So, what’s a bookmarklet?  In short, a bookmark, typically constructed with JavaScript that does a specific task.  For example, emailing some data via your favorite webmail provider, or checking Bugmenot for a login to a site you don’t really want to register for, or generating a shorter URL for a site.  Here are the ones I keep around.  Hopefully you’ll use some of them.  To grab them, mouse over the link and drag to your browser’s bookmark bar.  I recommend you make a folder on your bookmark bar and toss your bookmarklets in that folder (that’s what I do).

Here’s the breakdown of my favorite bookmarklets…

Google Services

Google This: Select some text on a page, click the bookmarlet, blammo – you’ve got a Google search for the selected text.

Google Images: Select some text on a page, click the bookmarlet and you’ve got a Google Image search for the selected text.

GAppMail This: Send the selected text via Google Apps for Your Domain Mail. You’ll need to edit this one to change out yourdomain.com for what your domain name actually is.

Gmail This: Send the selected text via Gmail.

Google Cache: Pull up the Google Cache version of the currently loaded page.

Google Map This: Select an address, get a Google map of it.

Geocode: Get the Latitude & Longitude for the center of a Google map.

Google Translate: Translate the currently loaded page into English

Web Development

Show Divs: Show the <div> areas on the currently loaded page.

ReCSS: Reload CSS for the currently loaded page.

W3C HTML Validator: Run the currently loaded page through the W3C’s HTML Validator.

W3C CSS Validator: Run the currently loaded page’s CSS through the W3C’s CSS Validator.

References

Acronym Lookup: Lookup an acronym in the Internet Acronym Database

Urban Dictionary Lookup: Lookup a selected word in the Urban Dictionary.

Social Networking

Del.icio.us Linkbacks: Show del.icio.us links to the current page.

Compulsory Login Bypass

BugMeNot: Lookup usernames & passwords for various sites.

URL Shorteners

DiggBar: Uses the new DiggBar for URL shortening.

Cli.gs: Uses the Cli.gs shortening service.

Yup, it was a dead battery.  Fortunately, as it was only a mile, I walked home, ate my lunch, then as Heather & the kids had arrived back at home, we hopped in the van to go back over.  I could have avoided this if I’d simply left the jumper cables in my trunk.  For some unknown reason, I took them out and left them in the garage after I’d last used them.

One jump start later, I was able to drive the car back home.  I grabbed the van keys, ran to Pep Boys and grabbed a new battery, as the old one was the original, now nearly 4 years old, and had a dark eye – i.e. It’s Dead Jim.  Swapping out the battery was easy enough, and then I found a new problem.  My radio has the anti-theft feature that requires a 5-digit code to unlock it.  Fortunately, after a bit of googling, I found that if you sit in the driver’s seat, open the glove box and look at the little sticker on the left side of the outer shell of the glove box, you’ll find two numbers.  The one on top is 5 digits.  Guess what?  It’s your radio code.

Wildly convenient for situations like this, but what if my radio were stolen?  Someone smart enough to steal a radio is probably also smart enough to look at a sticker that’s less than a foot away from the radio, right?

Conventional wisdom calls for (as many others have done previously) an Intel 4965 MiniPCIe card. The 5300 seems to be the successor to the 4965, boasting up to 450 Mbps of 802.11n performance.  Not having any 802.11n APs, I wouldn’t know about that just yet.  We’ll see.  Unfortunately, this card doesn’t have drivers in the mainline Linux kernel until version 2.6.27.  As I’m running Ubuntu Hardy (until Intrepid Ibex rolls out), and on kernel 2.6.24, no drivers exist, outside of the backported ones from compat-wireless guys.  Well, since the drivers exist, I decided to give it a go.

First up, grab the firmware and the drivers package.  Unpack the firmware and drop it in /lib/firmware.  Next, you’ll need to install the “build-essential” package, as well as the linux-headers packages appropriate for your kernel.  Unpack the drivers, check the config.mk file.  You should probably (as I did) uncomment the lines that enable support for the RFKILL code.  This is what gives you the ability to toggle the wifi on & off.  Do a make & make install (as root) to load the drivers up.  It will not overwrite existing mac80211 modules, and that’s a good thing.  Halt your machine and do the card swap.

Installing the card was pretty easy.  Pull the battery and unplug first.  After all, you don’t want to short things out, right? Ok, now remove the two screws that hold down the existing Ralink wifi card and pop the two antenna leads off.  Now install the Intel card and put the screws back.  Connect the white wire to terminal 1, and the black to terminal 2.  Terminal 3 is where you’ll need to connect the extra antenna.  I opted for a small antenna, typically used for a bluetooth radio, but since it’s a 2.4 Ghz antenna, it also works fine here. I snaked the wire through one of the small gaps in the plastic housing adjacent to the wifi card, and used the adhesive backing on the antenna to stick it in the hole where the hard drive goes on a 1000h.  Not sure where you’d want to put the antenna on a 1000h, but then again, that’s not my chief concern, as I’m working on a 1000.  Put back all the screws and you’re done.

Boot the system, and you should be all done.  The card should be automagically detected and have the iwlagn module loaded.  You’ll likely want to gently massage your /etc/acpi/eeepc-wifi-toggle.sh script to work with the proper modules.  Removing the module and echoing a 0 into /proc/acpi/asus/wlan (to power down the card) results in the card going into “deep sleep”.  My last bit is to figure out how to wake it from deep sleep, other than a reboot.