Ed's Big Plans

I’ve found that the implementation of NAT (network address translation, also called internet connection sharing [ICS] (OSX) and network bridging (Windows)) on Tin is pretty decent. The most common use of NAT from a laptop is to convert the laptop into a software wireless router: the laptop is connected to an actual router via wire, and transmits the network wirelessly. I needed to do the reverse: to receive a wireless signal and then share the address with a desktop that doesn’t have a wireless interface.

This succeeded until the wireless connection was inexplicably irresolvable in that dialing to any IP address from either the desktop or Tin resulted in server timeouts. This happened over and over and usually required about ten minutes after each failure and reconnection to the wireless router.

I’ve read a bit more, and I’m really no closer to figuring out why this happened but have a few hypotheses. First, it could be that the NAT implementation isn’t as bullet proof as I had hoped; second, it could be that the router some how doesn’t like what I’m doing; and third, my ISP may see the set up as somehow disruptive to other clients and thus had disconnected me.

With the present setup, my D-Link forwards TCP/80 request to Tin on 8080 which is where Apache lives. It made sense to set up SSH and FTP as well (SFTP uses the same port as SSH AFAIK). This turned out to be remarkably easy, allowing FTP to pass through TCP/21 and SSH to pass through FTP/22 each to Tin. VNC generally uses UDP 5900 and TCP 5900~5902, but opening just UDP+TCP/5900 did the trick.

Of course, as there are _many_ sensitive items on Tin, I can’t afford to just blast everything online so I’ve deactivated the port forwarding for those services after the test was done.

Whenever it is that I get the new web serving hardware, I’ll have to create a lower privilege account to host everything. The plan is to have a box that doesn’t have any kind of interface except for its network connection so that everything is controlled over SSH/SFTP/VNC etc. wherever I am physically in the world.

Edit: Oh! I’ve just learned this is called running a machine headless. — I’ve heard that term before, I just didn’t put it together.

According to some documents I’ve scoured up online, DNS updating can be instantaneous, or take up to either 48 hours or 72 hours depending on who you ask. In my limited experience so far, it seems to take anywhere from a minute to 12 hours, so I’m not doing so poorly.

I’ve always wanted a place to drop notes and solutions to problems I’ve encountered.

I think the SnOwy is an effective way to do this. — Note that this name is chosen because the name “tinWiki” was already taken by a different group. Oh well.

SnOwy the name is a transformation of the name “SnO2wiki” which is terrible to pronounce.

Final update: No, everything is normal. The DNS updating on the client side ISPs is just slower than is needed for the 60 second updates requested by the DynDNS update client. This appears true for both Rogers and Distributel, and likely many other client side ISPs as well. For instance, with Distributel there are two DNS servers listed. One appears to update instantaneously when my host updates DynDNS while the other appears to take longer and preserve the previous IP for untold amounts of time; the result is the need to flush locally cached DNS information from the Pewter (client testbed laptop) and hope that it talks to the faster updating server the next time it asks for “tin.blogdns.com”. This is consistent with the observations made thus far.

Thus, it makes sense to increase the period of host IP updating to four hours instead of sixty seconds. This has been remarked to enable client-side ISPs to cache the address (DynDNS TTL settings panel, it’s made pretty clear). The final robustness of this setup remains to be seen, but this entry is closed for now.

Update: As it turns out, DynDNS Mac OS X update client is misbehaving on Tin– before I condemn it forever and
shun it from my system, I should probably figure out what I can do about it.

Update: Things still aren’t solved — there are intermittent routing problems that I can’t seem to quell yet. I’ll just have to watch the network for clues.

Update: This is due to a combination of two items. First, the lookupd service running client side on Mac OS X is bad at forgetting former IP addresses even when dynamic DNS services are in play– a manual “lookupd -flushcache” followed by either a reboot or network reconnect is needed before this works again. Second, my router was incorrectly set to only “connect manually” rather than to “connect always”. Both items have been fixed but I’ll have to keep an eye on things.

New problem– something is making it difficult or impossible for Tin to serve up pages some of the time, and I’m not sure what that is. I would do a more comprehensive decomposition of this problem if I had the time, but I don’t– so it looks like I’ll just have to fiddle around with the port forwarding setting.

I need to have my router enable forwarding for port 21 for ftp and port 22 for sftp/ssh to Tin. I forgot to do so earlier.

I really want to have a new small economy-class computer on the network to host the website instead of the laptop Tin– I’ll probably want to set up port forwarding for a VNC service too for maximum remote control of the thing especially since it generally won’t have any local interfaces. There’s a nice free Java based VNC client / server I got a while ago which should run nicely, I’ll have to look up the name of the software.

Finally, I should probably let this future machine host an SVN potentially on an external HD.

Brief: Port forwarding has been fixed! Back online! Yes!