Teutoburg Autumn, again
The Teutoburg Forest In Autumn
I went for a walk through a small bit of the Teutoburg Forest today and took a few photos while I was there. If you'd like some or all of the photos in their original resolution, feel free to send me an email.
Watching anime on a VT420
Someone on IRC was curious about my vintage terminal and asked:
<+halpychan> can you watch anime on the VT420?
I tried to watch the first episode of Samurai Champloo on it. Here's the result.
The audio stutters a bit since mplayer spends a lot of time waiting for the terminal to finish drawing the screen, but overall I'd say the VT420 is the current gold standard for viewing your 10-bit chinese cartoons and beats contemporary LCD screens by a landslide.
If you want to try this on your own VT420 or on your >boring software-emulated terminal, here's the mplayer incantation to play a video using the ncurses text output:
$ mplayer -vo caca your_filename_here.mkv
I got my VT420 working
Many thanks to Steve Davidson. His blog post “Vintage Digital VT420 Terminal on Raspberry Pi” was very helpful in figuring this all out.
A little over a year ago, a strange bug bit me and suddenly I really wanted an amber VT420 terminal for that 80's UNIX mainframe feeling. I went on eBay, found an amber VT420 for $89 and pulled the trigger. I was assuming the terminal would come with a DB9 port, which would be easy to hook up. This turned out to be naive. The VT420 was produced in several variants for different regions, and the one I ordered was the North American version which comes without DB9 ports. It instead has two MMJ (Modified Modular Jack, sometimes referred to as DEC-423) ports—a proprietary cable/plug manufactured and sold by the now defunct Digital Equipment Corporation. These days it's only available at specialized cable companies. The few ones I found were US-based and quoted ludicrous amounts for cable and shipping.
The nice thing about MMJ is that it's essentially an RJ11 plug with a displaced locking pin to distinguish it from other RJ11-like ports. Another conveniently ubiquitous type of cable that uses RJ11-based plugs is LEGO Mindstorms cable, and I happened to still have one taking up (very little) space in my electronics drawer. After filing off the locking pin the plug fit into the MMJ port perfectly—if you ignore how easily it slips out. My “solution” to this problem is touching the setup as little as possible.
I then cut the other plug off the cable, removed the insulation and stuffed the wires into female-to-female jumper wires. I did this because the USB-to-serial adapter I ordered for this project had a male RS-232 connector on it. Putting wires on the pins was not feasible, but I also didn't want to order a female-to-female RS-232 adapter and wait another few days when I was so very close to success. I tried putting the jumper wires on the male DB9 plugs pins directly. The wires ended up holding surprisingly well.
Since the Mindstorms cable isn't configured as a null-modem cable, I essentially had to mirror the pins. Here's a table detailing the wiring:
|MMJ Pin||RJ11 Wire Color||Male DB9 Pin|
|1 DTR||White||6 DSR|
|2 TXD+||Black||2 RXD|
|3 TXD-||Red||5 GND|
|4 RXD-||Green||5 GND|
|5 RXD+||Yellow||3 TXD|
|6 DSR||Blue||4 DTR|
You can find some interesting diagrams for wiring MMJ adapters on this page. The diagram for the BC16E MMJ crossover cable was especially useful to me.
Soon after connecting the cables and starting a Getty instance for /dev/ttyUSB0 on my Raspberry Pi, beautiful results ensued.
TCP forwarding in OpenSSH
If you've ever used the
ssh program in your terminal, there's a very good
chance the implementation you were using was
OpenSSH. It would of course be kind of lame if all
OpenSSH could do was remote shell access. In this post I'd like to show you one
of its lesser-known features.
Using ssh with the
-L flag you can use an SSH server as a TCP proxy and
forward your traffic to a remote host. This will only work if
AllowTcpForwarding is set to
yes in the server's
sshd_config. This might
not always be the case since it's generally considered good security practice
to disable this feature.
Now for a use case. Consider the following:
You're on a school network with an evil, fascist sysadmin who blocks ports 6667 and 6697 (the standard ports for IRC). Of course you should be paying attention to the class, but if there was an emergency that required you to be on IRC right away, you could do this:
$ ssh -L 1234:freenode.net:6667 example.com │ │ │ │ │ └─ Server to route your traffic through. │ │ │ └─ Destination you want to reach. │ └─ Local port for SSH to listen to and forward from.
You can then let your IRC client connect to localhost:1234. The traffic will be tunneled (and thus encrypted) via the SSH connection. Keep in mind that the tunnel only protects the traffic between your machine and the remote SSH server. If you don't trust the owner/admin of the SSH server, you should take additional steps to protect your traffic, otherwise the owner of the server will be able to eavesdrop your connection very easily.
OpenSSH is also capable of reverse forwarding TCP packets. Let's assume you're running a web server on your local machine and that you'd like to make that server publicly available, but you don't control the network you're connected to and thus can't open up ports in the firewall. By running SSH like this:
$ ssh -R 8090:localhost:8080 example.com
... your web server running on localhost:8080 will now be reachable on example.com:8090. I used this feature on a shared server at Uberspace to get around my ISP's use of Dual-Stack Lite (which leaves you unable to use IPv4 port forwardings) and hosted my ownCloud and two Minecraft servers over SSH tunnels. As a temporary "duct tape" solution it works pretty well, especially when you don't have root on the remote server and can't set up a VPN.
Both of these features have a few more options that make them more useful. Run
man ssh and have a peek at the options