Just a quick note - if you ever need to backup your SmoothWall 3.0 configuration from a script / etc, try the following:

wget http://<ipaddress>:81/cgi-bin/backup.img --http-user=admin --http-password=<password> --post-data="ACTION=Create backup floppy image file" -O fwbackup-`date -I`.img

where ipaddress is the internal IP of your fw and password is your admin/root password. This will create a file called fwbackup-timestamp.img in the local directory. Stick this in a crontab and you're ready to go.

My wife and I are pretty avid car buffs and can usually have conversations about most Japanese cars. Our current baby is an 05 RX-8 that really needs a partner in the garage and about town. We've got a couple of daily drivers but really enjoy driving a stick shift and actually feeling connected to the cars we're driving (which really is the opposite of what most people want these days.)

We've been looking at various cars for several months now, and as one useful aspect of the current state of the economy, dealers are foaming at the bit for anyone that might buy a new vehicle. As such, we've been able to drive almost anything we've wanted and have significantly narrowed down the list. For pure fun, I thought I'd record some of my opinions here.

First, a bit about the requirements:

• Mainly a car for my wife, but something I would enjoy driving as well
• Unless absolutely amazing, it has to be a stick shift. Yes I know they make cars where the computer shifts faster than a human, blah blah blah. Yes, I know that they have "paddle shifters like a Ferarri." Yes, I know you can go into sequential shift mode on most automatics. Doesn't matter - we want a stick shift - which has made this task significantly more difficult.
• Rear wheel drive - possibly AWD but probably not.
• Handling - I grew up thinking horsepower & torque were the most important things - I was wrong. One of the best things about the RX-8 is even though it's about 230HP, it can turn on a dime and not feel like it's going to lose a wheel doing it.
• Reasonable power to weight ratio - Not just a pure hp number, but something that feels like it's moving.
• Proper mix of technology & reliability - We hate built in Nav, movie watching, etc. We like iPod / Aux connectivity, a measure of comfort, etc.
• Appealing look - This is obvious, but the standards change based on the car.

There are other aspects, but it all basically rolls down to a feel for the car and how much fun is it to drive. So, here's the list...(in no particular order - and these are all things we drove - there were others we considered)

• Infiniti G37S Coupe
• Infiniti G35 Coupe (Used)
• Mini Cooper S
• Pontiac Solstice
• Volkswagen GTI
• Volkswagen Jetta Wolfsburg
• Lexus IS 250
• Nissan 350z
• Mazda MX-5 Hardtop Convertible

Over the next couple posts, I'll provide a bit more review of each vehicle and what I think we'll end up choosing.

Around July last year, I purchased Charlene (The Simpsons, "Dead Putting Society"), my 17" MacBook Pro with the nice glossy high-res screen, etc. As part of this purchase I added a Sprint AirCard, in this case the SierraWireless 597E ExpressCard device that fits perfectly in the slot on the left side of the computer. It's always worked well (save for certain hotels in Las Vegas and Chicago who obviously want you to buy the overinflated hotel access) but one feature was always left out on the Mac side - GPS. It also really stunk that I could even boot up a Windows session in VMWare and the GPS data would appear perfectly. In other words, it was simply a matter of sending the right commands to the card to activate the GPS data. I did spend quite a long time fiddling around trying to find the necessary sequence to activate the GPS functionality, but to no avail. Much like other little projects I've come up with, this got moved to the back of the list for later consideration.

Today I was reading an article about running OS X on one of the new Dell Mini 9's, something I've contemplated myself several times. This was full of fairly useful information, including a note about a program called Sprint SmartView for any of their AirCards, that also enabled GPS functionality on a Mac. Unfortunately while pleased with Sprint's EVDO service, I have less than favorable things to say about their customer service (*WHY does the forgotten password web functionality not realize that you can't accept an SMS message on an aircard? And WHY does support not realize that them doing the same operation not help?....*) I chalked up the fact that I had never heard of this new release to similar behavior, but quickly put it behind me after I downloaded and installed the app (Here if you need it.) Other than an irritating reboot likely required due to a kext, the software works perfectly and even lets you access the GPS data in NMEA form - on one of the serial ports created when you use the card. Nice job Sprint!

One final note, if you do pick up an ExpressCard and then get irritated when you realize you want to use it in a non-ExpressCard equipped system, all is not lost. At the base most AirCards are actually USB devices in a PCI Express / ExpressCard form. On a Mac, the easiest way to determine if your card is like this is to open the About This Mac and click on More Information to open the stats about your computer. Under the Hardware: USB section you should see a USB Bus with the AirCard device listed. If so, you can actually use a USB to ExpressCard adapter. There are more expensive options available too if you want to buy direct from Amazon (ie, this.)

I've spent the past couple weeks learning enough Cocoa / Objective-C to be dangerous, and here's my first attempt:

EyePatch is a menubar tool to easily enable / disable the built-in iSight cameras on modern Mac computers. This tool was influenced by the AppleScript based iSightDisabler tool released by Techslaves.org. I wrote it specifically to know the state of the camera at any point, especially before using web conferencing tools.

The code is hosted on github (http://github.com/mike/eyepatch/tree/v1) for any that want to modify / update / etc. I placed the code under an MIT License for free use by anyone. A binary version is attached below for convenience - otherwise you'll need XCode 3.1 or later to compile the source version.

Some notes about the tool and how it works -

• Makes changes to the permissions of the driver files for the iSight to enable / disable access
• Applications using the iSight must be restarted to see the effects
• The tool will ask for admin privilege whenever you change the state of the drivers - this is expected and normal. It will drop privilege immediately after each use
• Basic testing on my machine works well, but I have not tested widely. As such, to reiterate the license, no warranty
• Requires Mac OS X 10.5 or Later - the source code uses methods not present in previous versions
• The first version of the code uses an arguably unsafe method for gaining privilege - this is due the relative simplicity of EyePatch and my newness with Mac development. I plan to consider how to modify this safely in the future
• This binary is a debug version - if you have problems there should be some logging information in the console log

This is definitely a first version so comments would be appreciated.

EyePatch-v1.zip (34.00 kb)

A guest post I wrote for the Voip Insider blog is now posted. If that's what brought you here, welcome!

I've been using ExpanDrive since shortly after it appeared - it works flawlessly for what I need (including editing files on remote web servers, easily copy files, etc.) I recently completed a satisfaction survey for them - in return they provided two coupons for 50% off ExpanDrive or the Windows version, SFTPDrive. If anyone could use either of these coupons, just shoot me a message in the comments - first to ask gets them.

I've been working on an amusing project for quite some time that will be better served with a wireless camera to snap photos of the action. I had been leaning toward the AIC250W due to its relative cheapness (approx $50-$100 depending on the mood at Fry's.) That and you can simply grab a copy of the current frame by making a web request to http://cameraip/IMAGE.JPG?cidx=randomtimestamp (Thanks to Scott Hanselman for that tidbit.) Unfortunately the camera has gotten a bit difficult to find, especially for a good price. Enter its successor - the Airlink SkyIPCam 500W - Wireless, smaller, supports "Night Vision", motion detection, etc, etc. More importantly, it was on sale for $70 a while back so I picked one up.

I finally got around to unboxing the thing yesterday and started fiddling with the included tools. PC only to setup, but once configured you can use a Mac / Linux to actually view the video / images / etc. The issue is that this is not what I want it for - I need to make quick snapshots. So I tried the link as described above - and of course it didn't work. Looked at the page source, but it mostly uses an ActiveX control or a Java applet so the actual HTML / Javascript is fairly useless. Tried Fiddler, but it would crash IE immediately when I accessed the video page. Time to pull out Wireshark. Captured a couple of seconds of traffic and found the clue I needed. The default view for this camera will give a live video stream (Motion JPEG format) - looking through the capture I found the initial HTTP request:

http://camip/cgi/mjpg/mjpeg.cgi

This will automatically feed you a binary stream of the current video. Now based on Scott's article above, I'm guessing there's some more processing that needs to be accomplished, but that's for another day. I still wanted an immediate snapshot of the current image. I fiddled with the URL a bit and finally found what I needed:

http://camip/cgi/jpg/image.cgi

This presented exactly what I wanted - a jpeg file of the current view. This still requires authentication (yes, I checked) so you do need to use a tool that supports user authentication (ie, wget --user username --password password http://camip/cgi/jpg/image.cgi) or code it appropriately into whatever tool you're using.

I do have a feeling there's also a way to get an MPEG4 version of the video based on a hint in the Users Guide, but initial tests haven't worked yet. My bigger pressing issue is getting the wireless networking working properly with the security settings I have in place... Anyway, I hope this helps someone - I'll reveal more of my project soon enough.

  While working on a contract, one of the requirements is to run an external process to generate a license.  The license information itself is then printed to standard output.  Being a C# / ASP.NET project, I need to do this in a fairly simple way - run the process, capture the output, and store in a database until the actual license file is needed.  

This of course leads me to the typical way of handling this - create a System.Diagnostics.Process object, feed in the path and argument info, and capture the output  from a redirected standard out stream.  All is good right?  Well - I hopefully would not be writing this post if it were.  Turns out another little detail of this project is that the license file is actually going to be used on a Linux machine.  

Let's start with some sample code:

string GenerateLicense(string details) { Process p = new Process(); string exe = @"C:\License\LicenseGen.exe"; ProcessStartInfo psi = new ProcessStartInfo(exe, details); psi.RedirectStandardOutput = true; psi.UseShellExecute = false; psi.CreateNoWindow = true; p.StartInfo = psi; p.Start(); p.WaitForExit(); string license = p.StandardOutput.ReadToEnd(); return license; }

This all looks good - until I write the output to the binary response stream in ASP.NET.  The code itself works fine and the file is written - the problem is the license won't work when read by the app on the Linux system.   A little investigation, and basically the string exists as a certain number of bytes (say 120) directly off the standard output, but the written file size was considerably larger (180 or so.)  Banged my head against the wall a little and it hit me - it was the encoding. (Note - this really only applies to binary files - text files are usually better handled cross platform.) 

A little more code:

Encoding enc = System.Text.Encoding.ASCII(); byte[] bytes = enc.GetBytes(license_details); Response.AddHeader("content-disposition", "attachment;filename=license.lic"); Response.Charset = ""; Response.Cache.SetCacheability(HttpCacheability.NoCache); Response.ContentType = "application/binary"; Response.BinaryWrite(bytes); Response.End();

My first guess was to read the bytes as ASCII into a buffer stream.  This still didn't work - came up with around 150-160 bytes or so.  UTF8, UTF7, etc, etc, etc, all came up short.  I was pretty sure I was on the right track but just going about things the wrong way.  Time for a little reading and some experimentation.  

First stop was simply to read about strings in .NET - everything is stored as Unicode - aka multi-byte characters.  I looked at a unicode map and it looked like for most of the character set I was using, everything would map to the first byte being the character I wanted.  I wrote a quick little loop to give me every other byte and tried writing that out to the byte stream.  Yeah, that didn't work either.  

Finally, I started searching around a little more, and from a few forums I found the magic of the "Code Page" (Wikipedia Link.)  For the unfamiliar, a code page is basically a character set - the map of characters to bytes.  Changing the code above, we simply need to use:

Encoding enc = System.Text.Encoding.GetEncoding(codepage);

Where "codepage" is the integer value of the given code page.  I tried the two mentioned in several posts (437 and 850) but neither worked properly.  Finally, I found the right one - 1252, and all worked exactly as expected.  Of course, this was one of the situations of fixing the problem but not necessarily understanding how to avoid it in the future.  

It's been a couple weeks since I worked out the above so I decided to dig into exactly what was happening with the code pages.  I found / remembered about the old program, chcp.com, which lets you view / change the code page of a given command prompt.  Running this provided that the default code page was 437.  Huh?  If that's the case, why didn't setting my Encoding to code page 437 work?  There must be a difference between what cmd.exe defaults to and what the code page is for a System.Diagnostics.Process.  After some experimentation, I found the following:

Process p = new Process(); string exe = @"C:\License\LicenseGen.exe"; ProcessStartInfo psi = new ProcessStartInfo(exe, details); psi.RedirectStandardOutput = true; psi.UseShellExecute = false; psi.CreateNoWindow = true; p.StartInfo = psi; p.Start(); p.WaitForExit(); int currentCodePage = p.StandardOutput.CurrentEncoding.CodePage; Encoding enc = System.Text.Encoding.GetEncoding(currentCodePage); byte[] b = enc.GetBytes(data); ...

The variable now contains the running code page for a given Process - of course this is 1252.  In other words, the best option for working across systems is to always get the Code Page / Encoding for your system in code and get the bytes accordingly.  

Well - after spending way too much time dealing with the details of writing my own blog engine, I decided to go with a known quantity.  ASP.NET MVC is pretty cool, as is LINQ, but dealing with updating the DataContexts is pretty terrible.  Anyway, I've got to get the first post out of the way and go from there.  Eventually there will be content of interest here and eventually even some readers.