Recently in notes Category

Two days of work and a lot of stupid mistakes later, I finally set up a functioning "transparent" VPN between two facilities.  By transparent, I am referring to the fact that the VPN will start on-demand and is transparent to the end users on each network being connected by the VPNs (no one has to manually initiate the VPN).  Usually, my preference would be to simply use gear from the same manufacturer (i.e. SonicWall/SonicWall or Netgear/Netgear), but it made no sense to decommission two fully functioning routers because I was too blockheaded to get them to play nice with one another.

So, here is the setup:  On end A, we have a SonicWall running SonicOS 4.2.x (advanced) with SonicROM 3.1.x.  On end B, we have a Netgear FVS124G running  the latest firmware, 1.1.48.  Netgear has a great howto at VPN Between NETGEAR ProSafe VPN Firewalls and SonicWALL, but there are a few tiny gotchas that got me.  The two primary issues were related to the Local and Peer IKE IDs and the destination networks.  The screens on our SonicWall looked different.  Instead of:

Our VPN Policy screen looks like:

Make sure that your Local and Remote IKE IPs are swapped on the Netgear (or other box) you are trying to connect to.  (If your local IKE ID on the Netgear is 1.2.3.4, then the Remote (or Peer) ID on the SonicWall should be that number.  (In many VPN examples out there (especially with Netgear), the local and remote IKE IDs are in the form of a FDQN, fully qualified domain name, which actually doesn't have to be a real FDQN.  For example, thisismynetgearfdqn.com and thisismysonciwallfdqn.com will work respectively.

Then, the issue of how you define the local and remote networks on the SonicWall created a ton of problems.  To make issues worse, the error logs gave no real indication that the problem was the definition of those networks.  In my example, I wanted the SonicWall network of 10.1.1.0/24 (or 10.1.1.0/255.255.255.0) to be accessible by the people behind the Netgear network and vice versa.

At first, I defined the local network as Any Address.  This meant that any addresses on the local network would have access to this VPN.  Both of the Routers are dual-homed and in the case of the SonicWall, it is not only dual-homed, but it also manages two subnets.  One subnet is for an internal, administrative network and the other is for guests of the company (aka the open network) to surf at their leisure.  We don't want the open network clients to have access to anything but the internet.  So, besides this potentially causing errors with the remote network definitions on the Netgear:

It also would (potentially) give guests access to the remote subnet.  This is definitely not something we wanted.  So, suffice it to say, one needs to be very, very careful as to how the local and remote networks are defined on the SonicWall.  I defined a range of IP addresses for the remote network on the SonicWall, whereas on the Netgear, I had defined an entire subnet.  Even though they technically matched (i.e. 10.0.0.1-10.0.0.255), this is not the same as defining a subnet in the Phase 2 portion of the handshake.  So, if you define a subnet on the Netgear, then you must define the address range you wish to reach on the SonicWall as a subnet also.

The last gotcha came in the form of which interface the VPN was bound to.  Because both routers were dual-homed, I had to make sure that the traffic for the VPN went through the fastest interface.  On the Netgear, this was WAN2 and on the SonicWall this was interface X1.  Here is a screenshot of the SonicWall:

This is where things get complicated and this HowTo/notes page really won't do justice to your setup.  None of this matters if your routers are single-homed.  In my case, not only was the dual-homing a complication, but, in the case of the SonicWall, I thought I had to bind the VPN policy to the internal subnet with which we were playing.  That is wrong, you need to bind it to the external interface that is the endpoint of the VPN for the remote (in this case, the Netgear).

The last bit is just like in the Netgear KB article.  The SonicWall Proposals tab looks like:

There are a few things we should recap.  First, as the Netgear KB article implies, you really want to print this out and write in your own values.  Here is the IKE Policy page from the Netgear:

It is very easy to mistake one IP for another and make the subnet versus IP range mistake I made on the SonicWall.  The three gotchas are Local and Remote/Peer IKE IDs, defining the local and remote networks and, in the case of the SonicWall (and the complication of dual-homed devices), binding the VPN policy to the correct interface.

Hopefully some of my experiences have helped you with configuring something similar.

updated: 2010/07/14

I continually forget how to do this (because I usually set it up once and never again), so I'm making a quick note of how to show the shortened hostname, username and current directory at the prompt under ksh (the default shell for OpenBSD). In the standard .profile file, enter:

HOST=`hostname`
export PS1='${USER}@${HOST%%.*} ${PWD##*/} $ '

There are ways to add color, etc. to this, but I like the plain, vanilla look it produces. Finally, I won't be likely to run commands on a machine where I shouldn't be.

I happened across this device on some tech related weblog (whose name and url I can't remember) and had to give my opinion. I've been using WiebeTech usb/firewire "raw" drive connectors for a few years, but the solution was always a little cumbersome; unless using it in situations where portability is key. Most of the time, I'm not in one of those situations and I have popped a drive out of a machine whose power supply has gone (or some other relatively minor problem has occurred). Now that most of the machines I deal with are SATA, I was looking for a device that made quick, raw hard drive backups (or reads) easy, yet don't clutter my desk like the WiebeTech solutions do. Like I said, I happened across mention of this device and ordered two. The shipping is ridiculous; $50 because it is being shipped from Japan, but I because the cradle is $50, I figured $75 for each cradle wasn't half bad, as long as they worked as promised. (I've found that some caddies/adapters do not perform even close to USB 2.0 specs. One transfered data from a good drive at about 4mbps. Definitely not 480mbps or close to the expected rates of around 350mbps.)
Today is the umpteenth time I've used the cradle, but the first time for an "emergency." I arrived at work this morning with my Mac Pro turned off (I leave it on 24/7 because I access it remotely quite often). I figured the power went out last evening and I went to restart it. Nothing. I fiddled with the power button, unplugged the machine, plugged it into a different electrical outlet, used a different power cord, and ran through a few procedures you use for getting Mac Pros to start if it is a simple memory board problem. Nada. I do regular backups of my two main machines now (a MacBook Pro and the Mac Pro), so I wasn't all that worried... except I had written two letters last night that I needed for work today. I spent quite a bit of time composing them, so I didn't want to go through the trouble all over. After AppleCare Phone support provided more aggravation than help (buy the AppleCare plan and find out you still have to hand deliver a Mac Pro for service and deal with an agent who obviously hasn't listened to any of the attempts I made before calling to revive the machine), I popped open the case, pulled the main drive and plopped it in the cradle. I navigated to my home directory and mounted my FileVault image ('hdid ./.snfettig.sparseimage'; enter password; access files through finder...) and grabbed the two files I needed. Done.
I can say that from the numerous backups I've pulled off drives with this cradle, I'm extremely happy with the performance and size. The fact that it will accept both 3.5" and 2.5" drives makes it all the more convenient. If you're a tech who uses drive caddies for any reason - and find that you have a lot of SATA drives you connect to - I highly recommend the cradle. Despite the relatively high price, the cradle is solid and makes life oh' so easy on days like today.

This is simply a note for the internet archives. I spent the better part of 45 minutes following very, very simple instructions as to how to get Patchstick to boot on one of my Apple TVs. I had two 2GB USB thumbdrives and neither worked. I was able to get two Apple TVs to reboot, but never read from either USB drive. Finally, I dug through an old backpack and found a 1GB USB drive that I immediately tested my luck with. It worked. No problems. There was obscure mention of this problem in a 123macmini.com forum note. Later in the thread from the link above, there is mention of a fix by changing a line in the "createPatchstick" script. If you make the appropriate changes, the 2GB drives will work, too. I have some other build notes relating to nitoTV that I'll post later.

I guess I'll update this as I go along, instead of posting a single long essay once I have things figured out to my satisfaction. So, last night I wrote about the fact that transcoding HD content with EyeTV 2 to h.264 at 24fps left much to be desired. (Later today, I'll provide specific screen shots of what I was doing, what I did and what I'll try.) I started transcoding another CSI episode, this time no specific fps, rather, I left the settings at automatic (which means ~30 fps). I set the bit-rate at 3500 kbps (usually, more than adequate to get the color and picture content), but didn't transcode using multi-pass. Well, this morning, I fired up the Apple TV and played the clip and... it still sucks. The choppy frame-rate is gone. So, that means that the device is capable of handling over 24 fps encoded material. The picture, however, exhibited jagged edges around all of the characters on screen. The more movement, the more jagged the edges got. I remember this being an issue when I first was testing without Apple TV, but in this case, I wanted to make sure that it could handle a 24 fps+ encoded file. It obviously does. So, back to the workshop. I'm taking the same clip now and transcoding with the same settings, but this time with multi-pass set. We'll see what happens later...

Technorati Tags: apple, apple tv, technology, transcoding, video

I ordered an Apple TV when Apple announced that they were for sale and finally received my first batch this week. For the past two years, I've been using Mac Mini's as a type of custom home theater PC to access content I store on a central server. While this works quite well for me, guests and my wife find the process of getting to the content overly complicated (and I find the same thing when problems arise). So, it appears that the Apple TV will fit in well and bridge the gap between what we are already using and what we are missing.
I started transcoding a bunch of HD programs I had recorded into h.264 files. I set the resolution at 1280x720 and tried different bit-rates. I ended up finding that 2500 kbps and above worked pretty well. While 1500 kbps worked, it lacked the color composition that seemed to come out of a higher bit-rate. In reading the Apple TV documentation, I found that the Apple TV is capable of reading 1280x720 h.264 content at 24 fps. Now I'm wondering if that last piece means that I had to transcode at 24 fps or that it was simply capable of reading 24 fps regardless of the encoded framerate. Tonight I was able to finally test a number of recordings and was thoroughly disappointed. At 24 fps, the picture is choppy, especially if the scene has any movement or detail with movement. My tests in transcoding are far from scientific and I realize that I may have made a mistake in other settings choices, but I see the same issue when playing the content back on the Mac Minis, PowerMacs or MacBooks. In those cases, though, I usually don't bother in transcoding because they are capable of handling the raw HD content.
So, tonight, I am re-transcoding a bunch of episodes of CSI to compare to what I saw this evening. This time, I'm leaving the frame-rate at automatic and am going to see if the Apple TV can at least read the file. Even on a PowerMac (dual G5), transcoding to h.264 is very slow going - about 3 hrs per 1 hr of HD content, without multi-pass enabled (which further degrades the quality of the output video - usually I use multi-pass). We'll see... For now, though, I do not recommend the 24 fps setting on EyeTV 2, it is unlikely you will be satisfied with the picture.

Technorati Tags: apple, apple tv, transcoding, video

Sorry - I have a css mess on my hands ;) I'll be back asap...

Update 24 March 2007: Well, the beginnings are done. I'm still working on better navigation and a background image for the header, but I like the plain, clean look. Comment if you don't (now having integrated all three blogs, commenting should finally work and be under a bit of control) or if you have any advice. (By the way, IMing me would be easier.)

When Apple introduced their new AirPort Extreme and I started digging around at the specs, I got quite excited: it could act as a mini file server. I was less excited about the speed specifications of the 802.11n draft because the fact is that it still doesn't come close to performing like gigabit ethernet, and because I'm usually pushing around video content in the gigabytes range, I rely on wires. (Plus, I know that reality never coincides with the test environments where wireless specifications are proven. And, I have so much wireless equipment littering the airwaves in my house that I expect diminished performance in whatever I have bought.)
But, as a mini file server vis a vis a USB Hard Drive, I thought, "wow, my prayers are answered. Apple usually does things the easy way and this has got to be one of those products."
I have seen a number of published reports from MacWorld, MacNN and a few other tech weblogs that have either dissected the device and/or tested primarily wireless performance. Wireless speeds are all across the board. MacWorld has a review that best explains why you will see better speeds using the 5GHz settings instead of 2.4GHz:

When a network was using 2.4GHz channels (or ranges of frequencies) shared by other nearby networks—as many as five networks showed up in testing on one channel—we still saw typical speeds of 50 Mbps. On unused channels, a rarity in cities, we saw rates of 70 to 80 Mbps. (via Macworld Review: AirPort Extreme Base Station)

The fact is that with all of the devices out there that can potentially interfere with products like the AEBS, people should be happy to see performance of half of what it is advertised to do - especially if they are not knowledgeable of what equipment may or may not interfere with the device.
My own opinion has very little to do with the wireless side of the equation (other than, I have my base station set at 802.11n 5GHz only - and it works great that way, except range is very limited in my house), I am more interested in performance as a file server. Simply put: it sucks. If you want to backup, store or share small files - or even tens of thousands of small files - the performance is certainly not that of a file server (or a bastardized Mac being used as a file server), but it is adequate. If you want to serve huge media files, forget it.
I should have known, though. My experience with using small, low power devices as file servers has been telling. An old P5 100MHz was one of the first machines I tried to use as a power file server. It was the first big tower computer I purchased with my own money when I went to college and had done its job for years, but about two years ago, after collecting dust for a year in our basement, I decided to throw OpenBSD on it and set it up as a file server. It performed, but not well. There simply wasn't enough horsepower from the processor or the motherboard to push a lot of large files (large being multi-gigabyte) through my home network. It sufficed for storage, but not a lot of reads and writes from multiple devices. My next attempt was to use a Soekris board an HD connector. Same exact problem: not enough horsepower. So, I ended up biting the bullet and taking a PowerMac G5 that sat idle most of the time and turned it into a file serving power house (to make up for going overboard on the processor of said file server, I used a lot of its idle time to transcode video). With that in place, I was able to transfer 10GB DV files and transcode to my heart's content.
What I had hoped for in the AEBS was something low power to simply copy content to and server content from. I realized that with a 10/100 ethernet connection that transfer speed expectations shouldn't be overly enthusiastic, but they should suffice.
Well, transfer speeds are sufficient. The problem is that the AEBS locks up all the time when transferring large files to and from the attached storage. To simplify my testing, I removed the three 500GB drives from the USB hub and attached one, 500GB LaCie USB drive. I decided that whatever content was to be moved to the drive ought to be moved to it from a wired device. On five different occasions - and the only five I tested with the single drive - the AEBS locked up and I had to unplug it to get it working again. I tested by sending 20GB of 1-2GB video files to the drive. I didn't ever get to the process of reading from the drive... Half of the time, the base station itself would still act as an access point, but clients could no longer access the shared drive.
Sorry, but that just doesn't cut it. I have some thoughts on why this is happening (i.e. memory buffers on the AEBS are filling up, etc.), but Apple should know better. They should know that because their market is somewhat driven by video and music content, they should expect people like me wanting to use the AEBS as a mini file server for said content. If I can't copy large files to it, how shall I ever read from it?
None of what I have written has been proven through scientific method and may be a result of a problem with my specific AEBS (which is why I ordered another one), but it is somewhat telling: don't expect much, if anything out of this file server's capabilities. Hopefully these are issues Apple will fix. This is yet another reason why I hate rev0 Apple products...

Technorati Tags: airport, apple, hardware, wireless

With the redesign (thanks Aaron) of my "start" page, I wanted to slowly move changes into the different weblogs I write. Those changes include:
• Coming up with a unified search for any and all of the sites. (Done through the use of Google's customized search tools - not yet added to the sidebar, though.)

• Coming up with a unified rss feed for any and all sites. (I have some leads, but I'm not even close to understanding how rss is actually produced by MovableType and WordPress.)
• Coming up with a new color scheme for stevenfettig.com/mythoughts/. (This is getting really old.)
• Coming up with some way of dealing with comment spam. I've been desperately avoiding this issue for a long time now and simply need to find a way to deal with it. I miss the comments I received for some of the howto postings I've put up over the years. The comments have not only been helpful, but have led me to meet new people. Comment spam is such a waste of time and right now, I receive well over 200 a day on the two weblogs that have been around the longest (stevenfettig.com/mythoughts/ and rescogitans.net/blog/). So, what I've decided to do is remove mt-comments.cgi all together. Once I have learned a way to deal with the crap, I'll put it back in service and hopefully reconvene commenting.
One of the reasons I still even pursue weblogs is that, 1) I'm an avid reader of around 10 and skim through over 60 different ones in a a week's period of time and 2) I like the outlet. We have had a number of things occur at work and with a business venture I ended and whose remains I used to start a new one. Both of those activities have produced a lot of experience and a lot of thought on various topics. In a way, I really do this all for myself. For the two people out there who actually look at any of my writing regularly (thanks dadLaw and naked guy in a lawn chair who is really freaking me out), I really do appreciate the readership and someday, I'll maybe be consistent enough to generate content on a regular basis. So, I want to keep doing it and while putting some energy into it, I'd like to make the experience "nice" for the readers out there.
Step one was the new entry page. Step two... well, that's a conglomeration of things.

OpenSSH is the reason I started to use BSD *nix - particularly FreeBSD (and now OpenBSD) - back in the days of my first experimentation with qmail. But, I never knew that using ssh with the -D switch allowed you to use the port forwarding mechanism as a SOCKS proxy... This is an example of link stumbling: I was on the road at the end of last week and I'm forcing myself to be more secure about my surfing habits and transmit most anything I do (i.e. email and web browsing) through my own servers. In order to do this, I had to set up a minimum of four tunnels for the traffic, one to my squid server, one to my smtp server and two to the two different mail servers I access. So, I remember seeing a program for OS X for which you could set up profiles to automatically start up x number of ssh tunnels (because I'm too lazy to write the script to do so myself) and I googled "os x set up ssh tunnels" and happened across Marc's Combining ipfw/natd and SSH Tunnels which then pointed me to SSH as a SOCKS Proxy. Sometimes it is truly amazing what one can stumble across. I was so excited to write about this (kind of a note to myself), that I still haven't found the program for which I started looking in the first place. OpenSSH really does rock... and by the way, next time read the friggin' man page! (note to self)