Archive for January, 2010
My son has a number of game consoles and has really been into his XBOX 360 of late. He recently acquired a new title that was complaining about our network configuration and refused to let him play.
After hearing his description of the message, I figured the issue had something to do with my very tight firewall configuration. I went up and had a look at the error and sure enough, the complaint was regarding my NAT (Network Address Translation) configuration which it wanted me to resolve by enabling UPnP (Universal Plug and Play). I’m not a gamer but I know that many of the gaming platforms make extensive use of UPnP to ease firewall configuration by automatically port forwarding the ports needed for their particular platform. Since I have so much of my home “wired” to the internet, I’m pretty particular about my configuration and refuse to allow automatic rule insertions on my firewall regardless of how benign they might be. That meant Microsoft’s suggestion to enable UPnP was not an option.
If you read this blog with any regularity, you know that I am fond of the DIY approach to meeting my family’s technology needs. That means I tend to build many of the solutions that we use every day, including my router, which I built using a small form factor Shuttle case and then installing pfSense which is a BSD based router distribution. If you use a Linksys or Netgear router, you may find options in the configuration menu specifically for gaming, however no such options exist in pfSense.
My first thought was to figure out what ports the XBOX was wanting to use then login to my router and set up NAT rules for those ports. One way to figure out what ports I would need to focus on would be to fire up an instance of Wireshark and analyze the traffic from the XBOX, but since the XBOX 360 is such a mainstream device I figured this would be a pretty common problem and a quick Google search would turn up the needed information. Just as I suspected, the port information was readily available, but there was plenty of conflicting data that, in this case, centered around single ports versus port ranges. To test whether or not a few simple port forwarding rules would work, I did the following:
- Set up a static DHCP lease for the XBOX so I could ensure that the device always had the same IP address
- Set up a rule to port forward ports 87-89 UDP and port 3073-3075 TCP/UDP from the WAN interface to the XBOX
After a quick test, we found that the problem persisted. At this point I started to focus on the text of the error message that mentioned “Open NAT” … what the heck is that!? I’m not a networking expert, but I certainly know my way around a router and know my networking terms but I had never heard of “Open NAT” so I started to poke around and couldn’t find anything that really explained that term. Finally I ran across a site that explained that they were Microsoft terms that were slight variations of already existing open standards; no wonder I couldn’t find any explanatory information … makes you wonder why Microsoft didn’t just use the existing terms :)
|Microsoft Term||Standard Term|
|Moderate||Cone shaped NAT with port filtering or with UPnP turned off|
|Open||Cone shaped NAT with no port filtering or with UPnP turned on|
Now that I knew that the I needed a Full-Cone NAT setup, I had to figure out how to change these settings on my router.
By default pfSense is configured for what it calls “Automatic outbound NAT rule generation (IPsec passthrough)”. This setting causes the ports the be “scrambled” which, in turn, causes many games for the XBOX 360 and other platforms to fail. The other option is to tell the router to use “Manual Outbound NAT rule generation (Advanced Outbound NAT (AON))” which will allow port information to flow in and out of the router without needing any kind of translation.
After making this change we performed another test and voilà – it worked!
Remember the conflicting information that I mentioned earlier regarding ports? I didn’t want to just let that go, so I then went back and performed a number of tests and found that we were able to get by with only forwarding ports 88 and 3074.
Note that this configuration may not work on networks with multiple XBOXs but if you have a single XBOX and have been struggling with NAT errors, this solution works like a charm.
Back in October 2009, I wrote an article about Home Automation and mentioned that one of my next tasks was to figure out a way to “sense” my garage door status so I would always know if it were open or closed.
Initially it may not seem particularly valuable to know the status of one’s garage door, but if you think it through, having this data can be very helpful. In my case, I wanted the information for two primary reasons:
- When I go to bed at night, I go through a routine that involves ensuring that the garage door is closed before setting the alarm. Being able to electronically sense whether the door is open or not allows me to display the status on a Keypad Linc right next to my alarm pad which is way more convenient than having to walk to the other side of the house and physically open the door and check myself.
- I’ve always thought it would be nice to detect when a member of the household drives up to an empty house and have it automatically turn lights on so that it is more inviting than arriving in total darkness. If I’m able to detect when the garage door opens and then combine that with some simple scripting to detect the time of day, etc, I can then achieve my goal of walking into a fully lit home even if the house is completely empty.
Before I delve into the details of how I set this up, I thought I would mention that since October last year I have gone through a number of controllers and am currently using a UDI ISY-99i. All of the previous controllers were very good but I continued to need more and more functionality and thus finally settled on the ISY which is really the Grand Poobah of controllers. Having this particular box makes extending your smart home’s capabilities much easier by using a scripting engine that is built-in to the controller itself.
So how does one go about determining the open/close status of a door? The best method is to use some kind of dry contact device. I decided to use Seco-Larm’s Overhead Door Contact (SM-226L-3) which will allow me to capture the status as either open or closed. Installation of the contact is really quite easy. I decided to mount mine to the top of the door thus ensuring that it stayed dry and giving me an easy path for running my cables.
The only real cautionary point to consider when mounting your contact is around magnet spacing. It’s very important to follow the manufacture specifications for installation to ensure that the contacts work reliably. It’s also important to test, test and test again to make sure that there is proper clearances in order to prevent jams from being created by the newly installed components.
The next step was to connect the contact to something that could send a signal across my Insteon network to report status thus allowing me to perform “smart home” actions based on the information provided. I have a spare EZIO6I Controller from Simplehomenet that should have worked but there are bugs that prevented the controller from working reliably with the ISY-99i box, so I opted to buy an I/O Linc from Smarthome as my interface.
Since my initial goal for the I/O Linc was for detecting my door status, that meant that I was only going to use the sensor input on the device and not use any of the built-in relays. The process of connecting the door contact to the sensor input on the controller was as simple as determining the input contacts (translation — I had to read the directions ;), routing the wire and making the connection. Once connected, I went ahead and interfaced the I/O Linc with my Insteon network by plugging it into a wall outlet and adding/pairing it with my ISY-99i.
After putting this in place, I performed numerous experiments and my results show that this is a rock-solid solution that has, so far, captured and transmitted my door status across my Insteon network. I have been successfully using this information to display the door status on my Keypad Linc and on a private Twitter feed for a number of weeks now.
Next I will extend the functionality by connecting one of the I/O Linc’s built-in relays to my garage door opener thus giving me the ability to open/close the garage from anywhere or taking automatic action based on conditions in the house. An example might be to automatically close the garage door if there are no cars parked in the garage, if there has been no movement in the garage for a certain period of time and if the house alarm has been engaged. This would deal with those occasions where one drives off and forgets to close the garage door.
There you have it, a house that’s just a little bit smarter than it was before I started.
Geek out and ENJOY!