I was introduced to the bash builtin /dev/tcp by warg the other day on x-tab#chat. He explained a basic use of this device by demonstrating how to download wget’s compressed tarball. The download process itself can be done with pure bash, but some post-processing of the downloaded file must be done to remove HTTP headers. I document warg’s application of /dev/tcp here because I found the idea fascinating and want this documentation for myself .

Connecting and Downloading

To read about the /dev/tcp builtin for yourself, check out the following:

$ info '(bash) Redirections'

With the exec line we initiate the connection, allocating a file descriptor and storing the numeic file descriptor into the HTTP_FD variable. Then, with the echo line, we send an HTTP request through the descriptor to the server. After sending the request, we process the server’s response with the sed line which skips over the HTTP headers sent by the server and stows the results into wget-latest.tar.gz. Note that this last command will sit around for a while. It is with this command that the builk of the data transfer is performed. And, since you’re using shell redirections to download the file, you cannot see the download progress. Instead, wait for the command to complete. This also involves waiting for the server to time out your connection since it supports pipelining. After this process is completed, the wget-latest.tar.gz file is as your disposal.

$ WGET_HOSTNAME='ftp.gnu.org'
$ exec {HTTP_FD}<>/dev/tcp/${WGET_HOSTNAME}/80
$ echo -ne 'GET /gnu/wget/wget-latest.tar.gz HTTP/1.1\r\nHost: '\
    ${WGET_HOSTNAME}'\r\nUser-Agent: '\
    'bash/'${BASH_VERSION}'\r\n\r\n'  >&${HTTP_FD}
$ sed -e '1,/^.$/d' <&${HTTP_FD} >wget-latest.tar.gz

Now you have a wget source tarball on your machine. As long as you have tar and a compiler on the machine, you are well on your way to downloading stuff using a self-compiled wget. In the commands above, you may replace “gz” with “bz2″ or “lzma” for smaller downloads if the machine you’re using has bzip2 or xz-utils installed. And, of course, it should not be too hard to repurpose the above code to download a particular version of wget or even a completely unrelated software package.

Please feel free to point out problems with this approach or give pointers on porting this to other environments .

The problem: you have a computer sitting behind a firewall. You want to access it from a different location, but you don’t have the ability to forward any ports to it. The answer: SSH tunneling.

The Solution

Using an SSH tunnel, you can reverse-forward ports from one computer to another. To do this, you will need a computer running linux and sshd to reverse-forward the ports to. It is very convenient if this is the computer you will be using to access the remote machine. Otherwise, additional steps must be taken.

The Setup

The easiest way to set up and maintain a reverse port-forwarding tunnel is with ohnobinki’s insurgent script. The script allows you to specify a remote host and the ports you want to reverse-forward. To start off, create a new user on your system, such as insurgent. Log in or start a shell as this user. Assuming you have mercurial installed, run:

hg clone https://ohnopublishing.net/hg/insurgent

Now cd to the newly created insurgent/bin directory. Finally, place the contents of insurgent/share/contab.txt into your crontab (use crontab -e to edit your crontab).

Now you simply need to configure the script. To do so, open insurgent.sh in your favorite editor, and update the REMOTE_HOST and other variables. The format for ports is [remoteport]:hostname:[localport] (ssh(1) ). I recommend starting with reverse-fowarding SSH (port 22), a vnc session (590x where x is the VNC display number), and nfs.

If you have not done so already, you need to set up passwordless public key authentication for the new insurgent user.

You’re Done!

If you’ve gotten this far, you may be ready to go. You should be able to access any port on your insurgent box via the corresponding port on your local box. Have any problems? Drop some comments below or pop into irc.ohnopub.net#protofusion and speak to ohnobinki or normaldotcom.

Image credit: star6. Used under Creative Commons CC BY-SA 2.0

With the advent of powerline LAN from various manufacturers for a steadily decreasing price, designing network-connected products becomes much easier. Once the price of hardware for powerline networking drops due to wide acceptance, some standard “dumb” appliances and pieces of hardware could be easily and cheaply networked, allowing for a “home automation” of sorts, such as lightswitches and power outlets.

We already have twittering “tweet-a-watts,” but powerline networking could extend this functionality and add control to every switch and outlet in one’s house. Just think–a house having all of its outlets and switches networked would be fully customizable, controllable, and monitorable. A homeowner could see power usage on a per-outlet (or even per-plug!) basis, which could make saving electricity much easier. In addition, power outlets and switches could be actively controlled over the network, allowing a computer to regulate power savings by, let’s say turning off or dimming a light, completely autonomously.

Despite many utility providers beginning to deploy “smart meters” (meters that let report, and often let you see, your power usage), monitoring power on a per-outlet basis still has great advantages. The “smart meter” can only report the energy usage of an entire household, and homeowners must unplug devices and check their energy usage monitor to determine how much power a device is using. With networked outlets and switches, users could see power usage on a per-outlet basis on a single screen, live. Networked outlets and switches could provide crucial energy-saving information to homeowners, saving them money and saving the earth from pollution.

Image Credit: http://www.flickr.com/photos/kk/ / CC BY-NC-SA 2.0