The many Houses of the Seven Kingdoms of Westeros have a problem. They need to send messages to each other, and in a way that’s both fast and secure.
How do they accomplish such a task? Well, they use these guys:
The way that the houses use these messenger ravens isn’t all that different from how IPsec is used on the Internet today to secure messages between two private networks. Both the ravens and IPsec use a public medium to deliver their message. They’re both susceptible to interception and tampering. They’re both at the whim of the environment – a forest fire is just as likely to be hard on the messenger ravens as packet loss is to an IPsec packet. In fact, both methods deliver their messages in “packets”: the ravens are just more efficient at it.
But the most important way that these two mediums are alike is that it all starts with an agreement. Two parties must meet somewhere, at some time, and agree to terms of how future messages will be exchanged. In Westeros, this might be done by meeting in secret at some point. In IPsec, we call this the “Phase 1” negotiation.
It’s important to recognize that when an IPsec tunnel is established, it simply means that two parties have agreed to how they will exchange packets of information in the future. IPsec is not synchronous. It’s not like a traditional tunnel or most peer to peer tunnels where data is exchanged over a TCP stream. IPsec packets are marked as their own protocol (they are neither UDP or TCP), and it’s up to the sender of the packet to ensure that it’s sent in such a way that the recipient knows how to decode it.
A lot of products on the market today are a little misleading about how they present the status of IPsec tunnels. As human beings, we want to be able to look at the status of something and know whether it’s working or not right away. Take these examples from three popular firewall products:
All would lead you to believe that the tunnel is up and running (a green indicator is most popular.) But IPsec tunnels are not so simple. In fact, these are just indications that the Phase 1 negotiation has succeeded. The gateway is simply saying, “yep, we’ve negotiated an agreement!” It’s not actually giving you an indication of whether that agreement is working or not.
Firewall dashboards like these are great ways to check whether a tunnel was negotiated successfully, but they’re not a good way to check if a tunnel is operating properly.
(post phase 1 negotiation)
- Public IP Changes
- Internet Performance
- Rekey Races
Desynchronization is a problem that happens when one member of the IPsec agreement gets out of sync with the other. Maybe one member was expecting the cryptographic cipher to change on a schedule, but the other member didn’t actually change it. Once the cipher has changed, the member that changed it can’t go back to using the old one: that would open up a vulnerability (by allowing someone to send a message with the old cipher much later.)
Public IP Changes are easy to detect, by verifying the real Internet IP address on both gateways participating. Depending on the software or equipment being used, it may or may not be possible to configure the gateway to use a dynamic hostname instead.
Internet Performance ultimately determines the performance of IPsec. This can be verified by troubleshooting the performance of the underlying Internet connection (for example, by pinging the other IPsec member’s gateway address.) It’s tempting on many firewall devices to reject all ICMP packets silently, but this is discouraged since all it does is make troubleshooting issues like this much more difficult.
Rekey Races are a rare issue that happens on some equipment when both members agree that it’s time to re-negotiate the Phase 1 agreement, but also re-negotiate some Phase 2 agreements at the same time. This has caused some IPsec gateways to become “confused” about what’s happening, and re-negotiate a new Phase 1 agreement while leaving some of the tunnels in the old Phase 2, where the other gateway has put those tunnels in the new Phase 2.
- Verify Local Internet Connectivity
- Ping Remote Gateway Internet IP Address
- Check Phase 2 Associations
- Verify Traffic Over Phase 2 Tunnels
- Ping Remote Address via Phase 2 Tunnel
As you proceed through these troubleshooting steps, collect the information as you go, as you may need it to report tunnel trouble to your IPsec partner. Nobody likes to receive a “tunnel down” report with no other information, so having the information available up front will help get the problem resolved faster.
Verify Local Internet Connectivity first, including the actual public Internet IP address that the gateway is using. Many services on the Internet will verify this for you, including http://www.whatismyip.com/ and via Google:
dig o-o.myaddr.l.google.com @ns1.google.com txt +short
Ping Remote Gateway Internet IP Address, which will reveal whether the remote gateway is reachable, and, whether any packet loss is occurring. Keep the ping running continuously, since packet loss can be intermittent, it may take some time to observe it.
Check Phase 2 Associations for desynchronization. This will usually manifest itself on firewall dashboards as seeing multiple SPI associations. A healthy IPsec tunnel will have only one SPI association (and multiple only for the time it takes to rekey.) Long-term, multiple associations for the same network pairs are not normal.
Verify Traffic Over Phase 2 Tunnels by looking for byte or packet counters incrementing. IPsec will not generate traffic on its own: it needs traffic to be flowing over the tunnel for the traffic counters to increment. If you see traffic incrementing on one side but not the other (for example, a receive counter incrementing but not a transmit counter), then that’s a strong indication that one member of the IPsec association is desynchronized.
Ping Remote Address via Phase 2 Tunnel, and try multiple IP addresses. It’s possible that the issue is local to one system on the private network only. If you’re able to ping a system on the remote side, then the tunnel is functioning.
- Ping a Gateway from Gateway
- Tunnel Reset
Generally speaking, you cannot Ping a Gateway from Gateway. This is because the gateway doesn’t know what IP address to originate the traffic from (since the gateway has multiple network interfaces), and, a lot of IPsec implementations are done in ‘user space’ instead of in ‘kernel space’. This means that since the IPsec service is not part of the system’s core networking stack, it can’t originate traffic from itself. Always test traffic through the tunnel, never from the endpoints.
Doing a Tunnel Reset from one side rarely accomplishes much. For example, if one gateway is desynchronized, doing a tunnel reset on the other won’t cause the desynchronization to go away. Some IPsec implentations don’t actually clear all of the SPI associations cleanly on a tunnel reset, in which case only a reboot of the equipment will ensure the old associations are cleared. Once traffic is passing over the tunnel again, fixing the root issue is necessary, otherwise the problem will ultimately occur again.
- Perfect Forward Secrecy
- Rekey Lifetimes
- Time Synchronization
Perfect Forward Secrecy should be enabled, not only because of the security implications (it makes captured encrypted traffic more difficult to break), but because it forces a renegotiation of the Phase 2 tunnels to happen more often. The more time that passes between renegotiations, the more time you’re allowing an IPsec tunnel to become desynchronized.
Rekey Lifetimes should be as short as possible, and the Phase 2 should be set to two-thirds of the Phase 1 rekey time. This ensures that Phase 2 tunnel renegotiation doesn’t happen at the same time as the Phase 1 so often.
Time Synchronization from a reliable time source or NTP server is important since it’s used to calculate rekey times. A clock on a device that drifts (because it has no time source, or an unreliable time source) can cause desynchronization issues. Some equipment ships with hard-coded time sources, so this can’t be helped, but where it’s possible to configure it, reliable NTP servers should be used.
If all else fails, before you contact your IPsec partner, have the information you recorded during the troubleshooting steps ready. Providing as much information as possible will help the partner troubleshoot the issue. Including additional information (such as the physical location of the equipment being used and what networks are being transmitted over the tunnel) will also help.
- Both Gateways Public Internet IP Addresses
- Physical Location and Description of Equipment
- Source and Destination Inside IP’s
- Steps Taken (reboot, tunnel reset, traffic observed, duplicate SPI’s)
- Information/Screenshots from Dashboard
IPsec is a powerful and flexible service, but like the messenger ravens from Game of Thrones, taking a little care and attention will yield the best performance.
I’ve been playing Magic: The Gathering since I was introduced to it by a high school librarian in 1994. Most of my experience with Magic has been at the casual level. The goal for the most part was to find as many friends as possible, play huge multiplayer games around a dining room table, and worry more about having fun than being competitive. I have great memories of Sol Ring, Demonic Tutor, Royal Assassin, and Rocket Launcher just being huge bombs in these games.
Kobolds are unique in the fact that the smallest members of the tribe cost nothing to cast. When they were first introduced in Legends, the only synergy they had in the set was with their fellow creatures, and this made for a very weak tribe.
So the best that a kobold deck could hope for at this point was to get a few of the 0/1 kobolds on board, maybe attach a Giant Strength or play Blood Lust, and combined with a Kobold Taskmaster or two, swing in for a bunch of damage. The problem is that this plan was easily ruined by the usual suspects: a strategic Lightning Bolt on Kobold Taskmaster wipes out damage from a bunch of kobolds. From Legends specifically, Pyrotechnics could be a four-for-one in some circumstances, and Chain Lightning did a lot of work against the kobold deck as well.
It was around this time that I had learned of Duels of the Planeswalkers 2014, which I spent a considerable amount of time playing. A lot of people might slam it for not being “real Magic”, but Duels made Magic sound and feel more like an arcade game, and it let me experiment and have fun with a lot of casual decks. Really, Duels of the Planeswalkers is everything a casual or beginning player could ever dream of. The scripting language used to code cards within the game was easily modified, so I even cooked myself up the kobold deck in Duels of the Planeswalkers – here you can see me taking it for a spin against “Chant of the Mul-Daya”, a green ramp Eldrazi deck.
My prized kobolds even looked great in the new card frame:
Shortly thereafter, I decided to become more serious about the way I played Magic, and joined Magic Online. Surprisingly, aside from the massive amount of experience I gained playing competitively on Magic Online, there was also a thriving group of casual players. Having put together a kobold deck on MTGO and put in a lot of repetitions with it in the casual play area, I tweaked the deck some more and the end result looks something like this (click to see a clearer, larger version):
You’ll notice that Wheel of Fortune is gone, and in its place is Browbeat, which works great for the red aggro player either way (as opposed to Wheel of Fortune, which fueled your opponents hand as well as yours, Browbeat only draws you cards, if that’s what your opponent chooses.) Lotus Petal was shed, Mikokoro was added for some extra card draw, as well as Gamble to help you find that missing piece (best used when you have a grip full of disposable kobolds so as to minimize odds of the fetched card being thrown away.) The deck also adds Steely Resolve from the sideboard now for some protection against decks with heavy removal – you side out Alpha Status for those. I’m still torn on the role of Adaptive Automaton and Door of Destinies though, and I’m still experimenting with the best balance for these cards from the sideboard:
Playing the deck itself aside, it’s been a lot of fun to talk to people about the deck, too. It’s not meant to be a competitive deck, and I’ve had some great discussions with people in the MTGO “just for fun” room about it, even if they’re quick one-liners like “cool deck.” Then, there are the not-so-great experiences with people who take “casual Magic” a little too seriously. Take this conversation I had with a friend of mine about one particularly salty opponent:
I guess if opponents are scooping to the deck round one, turn one, I’m okay with that. As of this writing, the deck is about $60 to buy through the various bots on Magic Online, which I think is very affordable so far as casual legacy decks go.
This deck has been a lot of fun to play throughout the twenty or so years and hundreds of repetitions. Kobold creatures present a very unique Magic challenge in the sense that they’re very bad from a card advantage point of view: you’re wasting a card to be a very weak 0/1 body that does nothing on the board for the most part. The deck is ridiculously weak to removal, it’s very linear, and doesn’t really interact with the opponent. Trying to figure out a way to turn these dysfunctional creatures into something fun and powerful at the same time has been a great challenge, and one that I hope to keep up with for many years to come.
The VideoGame DataBase (VGDB, or vgdb.ca) was first inspired by the Digital Press Collector’s Guide as a way not only for collectors to keep track of which games they owned, but to track the values of video games as well. Video game pricing is an ever-changing marketplace, so the intention of VGDB was to be an amalgamate of data from across the Internet in regards to game values. Collectors would be able to track which games they owned, and their respective ‘buy’ and ‘sell’ values.
This was accomplished by scraping various websites that provided pricing data. Digital Press was the source of the base video game lists.
VGDB was also used by a major retailer for tracking store inventory and buy/sell prices for games. This data was also blended with the data scraped from the web. This has since been discontinued, but in the three year span that this was in place, VGDB recorded 15,115 transactions for this retailer from 2011 through 2014.
During this period, the top ten games that saw the most trading activity include:
2. The Legend of Zelda: Ocarina of Time (N64)
3. GoldenEye: 007 (N64)
4. Mario Kart 64 (N64)
5. The New Super Mario Bros. (DS)
6. Diddy Kong Racing (N64)
7. Super Mario All-Stars (SNES)
8. Super Mario 64 (N64)
9. Perfect Dark (N64)
10. (tied) Donkey Kong Country (SNES)
10. (tied) Super Mario Kart (SNES)
This data supports the idea of a ‘curve’ in video game collecting. The idea is that around the time people become older (their late 20’s or early 30’s), they want to re-purchase the games they remember from childhood. At the time period that this data was captured, that’s clearly the Super Nintendo on the downslope of the curve, and the Nintendo 64 rising above it.
Unfortunately, without someone to focus time and energy into improving the site, VGDB rapidly became outpaced by its competitors. In particular, Video Game Price Charts was registered a year before VGDB and became the de-facto source for video game pricing data on the Internet.
Given that there’s no point to maintain a site that is no longer in active use, and with out-of-date pricing data, the site has been retired. This blog entry remains as a memorial for the short experiment that it was – if you want current, relevant pricing data for your games, please visit Video Game Price Charts.
A company called Diskology makes a great product called the Disk Jockey (“DJ”). I personally own two of these (one attached to my server at home, and another attached to my workstation.) This is a fantastic product, albeit with a few minor quirks that you should be aware of before using the device.
In its simplest form, the DJ operates like any of your run-of-the-mill hard drive dock. Even better, it can function as a two disk dock. On the back are connectors for eSATA and USB, although I tend to prefer eSATA for performance reasons.
When the disk jockey is not plugged in to a computer, it operates as a stand-alone device that can perform a variety of functions: disk copying, wiping, and verification. For any of us who frequently need to duplicate disks, wipe disks, or verify that two disks are identical, these standalone functions are invaluable and a great time saver.
However, the greatest power of the DJ comes from its drive combining options. For example, you can connect two disks to the DJ in what it calls a ‘mirror’ or ‘combine’ volume. When you select one of these options, the DJ then presents itself to your workstation as a logical volume. In the case of a ‘mirror’, it’s a bit like RAID1, and in ‘combine’, it’s a little like RAID0. However, it’s important to realize that the DJ’s ‘mirror’ and ‘combine’ modes are different from traditional RAID.
Mirror: In a traditional RAID1 mirror, the controller has a way to verify the consistency of the volume. That is to say, if you connect two drives in a RAID1, write some data, then remove one drive and replace it with another, it will realize a drive is inconsistent and begin matching up the drives to be consistent with one another. The DJ’s ‘mirror’ mode works differently: any writes go to both drives, but any reads only come from the disk connected to the ‘source’ side of the DJ.
This is an important distinction, because if you manage to connect the wrong disk to the ‘destination’ side of the DJ, it won’t realize that there’s a mismatch and then will blindly overwrite the data there.
We can test this by connecting two disks to the DJ in ‘mirror’ mode and writing a sequence of entirely null bytes to the volume. Examining the disks individually will show that both disks are full of nothing but null bytes. Now, connect one disk of the pair and overwrite the entire disk with hex 0x01. After, reconnect the pair, but keep the disk overwritten on the ‘destination’ side. Write hex 0xFF bytes to the first 512 bytes.
Examining the disks individually will show that both drives indeed have 512 bytes worth of 0xFF at the top. But the first disk will have 0x00 for the remainder, while the second will have 0x01. There is no consistency checking on the DJ.
Combine: This mode of the DJ operates like RAID0, except again, without consistency checking. Thus, it’s easy to accidentally swap the two drives, and the DJ will happily create a stripe without checking that the drives are connected backwards. This isn’t as fatal as in the ‘mirror’ scenario, but can be if the user continues with some kind of write operation.
So long as you’re aware of these quirks, the DJ is an excellent device of superb quality. The mirrored mode is especially useful as part of a on-site/off-site backup strategy. Its standalone functions are great time savers. The eSATA connectivity ensures fast transfer speeds, too. This device is well worth the money.
Everyone knows that they should take backups of their digital media. It also seems that everyone knows that everyone else rarely does so. As human beings, we tend to get a little sloppy about things that aren’t strictly necessary or of an immediate need.
Jamie Zawinski has a pretty good article about backups here, and you should read it.
Of course, everyone’s situation is different. I have a large RAID array (24TB), which meant deploying a single external disk for a backup wasn’t possible. I also tend to be a little extra paranoid about my data, so I had the following requirements:
- Physically Redundant Storage: A copy of the backup must reside in two physical locations, so that if one burns to the ground, all of the data is safe at another.
- Intensive Integrity Checking: It’s not good enough to just let a backup disk sit spinning and then write the changes to it. There must be a way to frequently check all of the data on the backup disk to ensure that it’s still a good backup when the time comes.
- Ease of Use: An automated process that will begin backups automatically, without supervision, and then report backup success or failure after.
Problem #1: Physically Redundant Storage
A company called Diskology makes a great product called the Disk Jockey (“DJ”). The DJ allows you to connect two SATA disks to it to make quick on-the-fly disk mirrors, stripes, and also serves as a basic SATA disk dock as well. The version I picked up has USB and eSATA connectors. In the case of backups, I connect two disks of equal size to the DJ, select “mirror” mode, and then the DJ appears to the OS as a single disk. (For example, if there are two 2TB disks connected to the DJ, it shows up as one 2TB disk to the OS in “mirror” mode.)
Whatever writes you make to the DJ will be written to both disks in mirrored mode. Whatever reads you do from the DJ will be read from one. This has some interesting implications that you should be aware of, and I talk about them in greater detail here.
The result of all of this is that I keep one disk off-site at work. I bring home one side of the disk mirror from work every day, then attach it to the DJ along with the other side of the mirror I keep at home. When going to work in the morning, I do the opposite.
Problem #2: Intensive Integrity Checking
The problem with most “set and forget” backup regimes is that you might need some obscure piece of data from the disk down the road, only to find that the section of the disk where that data is has long gone bad. You don’t know that it’s gone bad because you’ve never tried to read it (in the case of data that rarely changes.) The solution to this is to always read the entirety of your backup disk during every backup cycle, and then report failures immediately.
The default behaviour of rsync is to simply check the modification time and file size, and if there’s a match, it doesn’t read the file on the backup disk at all. Many other backup solutions operate in a similar fashion.
I chose to solve this problem by using rsync’s –checksum (-c) option. This forces rsync to read each and every file on both sides of the backup to compare whether it should be replaced on the backup disk or not. The downside is that this is very slow, so in my case, a backup run will typically take 12 hours or longer.
An alternative to this would be to simply blow away the backup volume, and then do a complete backup on every backup run. There’s a big problem with this approach, though: if something happens during the backup run, you have an incomplete backup. The checksumming method ensures that the data on the backup volume is never erased ahead of time.
Problem #3: Ease of Use
So the backup procedure I have is now very simple:
- After work, I attach the drives to the DJ,
- A backup script runs automatically overnight,
- I detach the drives from the DJ, keep one at home, and bring one in to work.
The script does all of the heavy lifting. It splits my array into easily managable chunks. The backup script has a –info flag that allows me to quickly see the status of all of my backups:
Last Backup Used Free UUID
M Tue Sep 2 20:00:04 PDT 2014 1.3T 66G 18e61a61-6502-6510-8086-0065d1917f97
S Wed Sep 3 20:00:05 PDT 2014 1.4T 487G 0cfdeff4-6502-6510-8086-145408f4e658
Tb Sun Sep 7 20:00:06 PDT 2014 2.4T 374G c54d93c9-6502-6510-8086-7395b84d22d7
Z Mon Sep 8 18:00:04 PDT 2014 627G 291G 57df37aa-6502-6510-8086-a9ac378f85d5
Ta Tue Sep 9 18:00:04 PDT 2014 2.2T 519G 45ff4122-6502-6510-8086-cf0a1f0ea6d7
Y Tue Sep 16 18:00:14 PDT 2014 1.6T 295G 385afa54-6502-6510-8086-82120fc9d546
G Wed Sep 17 18:00:03 PDT 2014 1.6T 264G 44d010a8-6502-6510-8086-f1032299ef49
A Mon Sep 22 18:00:04 PDT 2014 1.5T 393G 08ece419-6502-6510-8086-59d4cb0e617c
The backup runs every day at 6:00pm (formerly 8:00pm – I had to push it back because the backup times were running too long for me to pick it up before work.) Regardless, I find that an hour between quitting time and backup start time is sufficient to connect the drives to the DJ. If I miss a backup day, it’s not such a big deal – you can see in this example, the oldest backup is about three weeks old.
Each letter to the far left represents a logical collection of files on the array. The “T” series is so large that it needs to span two 3TB disk pairs. Each disk contains a simple ext4 volume so that if the worst happens, it’s as simple as mounting it on virtually any Linux rescue boot image, and doing a single “rsync” to get the contents back.
If something goes wrong with a backup, it will be flagged in the status display.
The downside to all of this is that it’s possible for data to go for a long time without a backup (in this example, eight pairs of backup disks means it will take two weeks’ worth of working days before wheeling around to the first disk pair again.) That’s a risk I’m willing to take.
Ultimately it’s up to you how you craft your backup solution, but they should generally all fit the same mold: redundant, stable, and easy to use.
A few months ago, my grandfather passed away. He was 88 years old, and had lived a long, happy, and fulfilling life – there were no regrets or sour feelings about his passing.
While his belongings were being sorted through, they happened upon this:
I have no doubt that this kind of thing happens all the time when someone passes away. I can’t imagine the number of unknown or blank CD’s, VHS, cassette tapes, and all kinds of other media that must be discarded as garbage. Who knows what they contain? At some point, it was probably important to the person who kept it.
So, I decided to preserve this tape and listen to what was on it. The first step was to dig through my box of USB miscellanea and revive some old hardware:
This is an Ion Tape Express. It’s more or less the size of a walkman, but connects to your computer via USB. There’s a C-Media audio-to-digital chip within the enclosure which helps to minimize how far the analog signal must go before it’s converted to digital. You can pick one of these up at Radio Shack for about $60, and they’re fully Linux compatible.
I have no doubts that a better analog-to-digital conversion could be done with both a high-end tape deck and analog-to-digital converter. But for household amateurs such as myself, the Ion Tape Express is a good intersection of price and space (after all, how many tapes do you convert in a year?) I have no interest in taking up a lot of space with high end audio gear that won’t get used all that often.
The conversion is as simple as pressing “play” on the Ion, and then record in your favourite audio editing/recording software. In my case, I decided to use Audacity.
In the end, only the first 30 minutes of the first side of the tape had content. I recorded all 90 minutes of the tape and preserved it as a 41khz .wav file. Ultimately, the tape contained nothing of real value, but disk storage is so cheap and dense that it doesn’t matter: I’ve now digitally preserved something of my grandfather’s that should last for all time so long as it’s stored and backed up correctly by those who come after me.
The theme of the 1986 World Exposition in Vancouver was Transportation. Vancouver’s state of the art driverless, computer-driven SkyTrain mass transit system had just opened, showcasing the best in Canadian engineering talent. The expo grounds were filled with varying examples of transportation. Japan had its HSST high-speed rail system on display. Gondolas transported expo-goers high above from one podium to the next, giving breathtaking views of the expo grounds. Water ferries carried passengers across False Creek from one area of the expo to the next. The history of world transportation was chronicled at Expo ’86, from the steam engine to modern magnetic propulsion.
Most attractions were built as temporary features, and the Expo ’86 Monorail was no exception. Built as both an exhibit and method to transport expo-goers from one site to the other quickly, the monorail spanned the entire length of the expo grounds. Because of this, the monorail can be seen in the background of many Expo ’86 photos, and was fondly remembered by attendees. After the expo, the monorail was dismantled and sold to the Alton Towers amusement park in England.
When most people think of abandoned transit stations, they think of New York or London, with their maze of tracks and tunnels going back a hundred years. Most people attending an event or concert in the Plaza of Nations have no clue that an abandoned station is just over their shoulder, footsteps away.
A section of the monorail actually ran through several of the temporary buildings. One trio of temporary buildings, the Plaza of Nations, still stood as it did in 1986, a full twenty years after the expo was over. Few people will remember that Stadium Gate Station was a stop on the monorail route, and actually stopped within the Plaza of Nations building itself. In fact, rumours circulated the Vancouver Transit mailing list for some time about an ‘abandoned’ monorail station, so I decided to go for a walk around the Plaza of Nations to find it. In the photo to the left above, you can see the last remnants of the monorail track, held up by metalic, white pillars as it curves around.
Finding the station itself proved to be a bit of a challenge. I walked around all three buildings numerous times before spotting the telltale ‘U’ shape of a guideway where the rail would have gone. You can clearly see this, on the second floor of the building in the picture to the right. Gaining access was a simple matter of climing up a set of stairs (used as exit stairs while the station was active) that was only blocked off by a chain. As you can see from the photo, there is equipment all around, preparing for the building demolition.
Stepping into the station is like stepping back in time. It is amazingly free of graffiti and vandalism, thanks to its inconspicuous location. In fact, with a little cleanup and restoration, the station could be ready to resume full service the next day.
As you can see from the photo to the left, the station is surprisingly intact. The wooden slats along the roof are all in pristine condition, the station signs in excellent shape. The metal bars guide passengers to the individual train doors. Even the lights and speakers are still all intact. All that’s missing is the one solid rail down the middle of the guideway, and you’d have a perfectly functional station.
The exit markings are still in perfect condition, used to guide passengers out of the station. We get a good look down the center of the empty guideway. You can still see most of the intact multi-colored lights where the wooden slats end on the roof.
Unfortunately, this piece of history is now gone – it’s been demolished. The Plaza of Nations, which housed Stadium Gate Station, was originally built as a temporary structure. It was supposed to be destroyed immediately after Expo ’86, along with the rest of the temporary structures. However, the Government of BC saw new possibilities in the use of the Plaza of Nations, so it (and Stadium Gate Station along with it) stood for over twenty years after the expo. Now, the only remaining remnant of the Expo ’86 Monorail is a short section where it passed through the opposite building.
I’ve always wanted to visit a micro-state. There’s just something neat about paying a visit to a truly sovereign country that is smaller than most cities. Liechtenstein is certainly no exception; it’s been settled in one form or another since the Roman days, and has been recognized as a sovereign country for longer than my home country of Canada has.
So, Liechtenstein has always been on my list of ‘must visit’ countries, if only to say that I’ve set foot on the soil there. My original plan called for a train ride from Munich into the heart of Liechtenstein, a short two hour visit, and then back to Munich. But there was something that wasn’t glamorous enough about this plan. It needed something else.
After looking at a map of Liechtenstein, I decided that I could actually walk from one side of the country to the other. An Austrian “OEC” (express) train took me on a breathtaking trip through the Austrian alps from Innsbruck to Feldkirch. After a quick bite to eat at the Feldkirch train station (which turned out to be a very modern, clean facility,) I set off to walk the three kilometers within Feldkirch to the Liechtenstein border.
The City of Feldkirch reminded me of the towns of Banff or Jasper in Alberta. It had that nice, high ‘alpine’ feel to it. The water was that ‘national park’ shade of green or blue. The weather was perfect for a hike across a whole country; it was about twelve degrees above and mostly sunny. As I continued to march along, the old European city gave way to a breathtaking view of the Rhine Valley.
Along the way, you could see people doing all sorts of everyday things. A group of school kids playing soccer, someone walking out of a hardware store with the day’s project supplies, another person lights up a smoke and enjoys the great weather. In this photo, you can see the houses in Feldkirch, Austria in the foreground, and then houses in Schellenberg, Liechtenstein in the background. It also became increasingly clear why people would settle in this area: the Rhine Valley is completely walled in on practically all sides by the towering alps.
The Principality of Liechtenstein is not a member of the European Union, nor has it implemented the Schengen Agreement which allows free movement of European citizens between sovereign countries. Because of this, there is still a checkpoint at the Liechtenstein-Austria border manned by Swiss guards.
I approached a guard house on foot, and engaged one of the Swiss border agents there. He didn’t seem to be too happy to see me. Whether that was because he was busy doing something else or because I was on foot is still up for debate. I asked the guard if he spoke English, to which he shook his head rapidly and said, “No.” I then frowned and said, “Do I need to show my passport?” The guard sighed and pointed at the desk, motioning that I should put my passport there. I did so, and he scanned it on some sort of imaging device (I presume, to check if I’m a wanted criminal, or something.) He then asked, “Where are you going?” I answered, “Liechtenstein.” That seemed to satisfy him, since he returned the passport and let me go on my way. (The photo to the right shows a sign marking the end of Austria. The word below it, “Grenzuebergangsstelle” means, “Border Crossing Point.”
It was at that point that I crossed into the smallest doubly land-locked country in the world, a country with a population barely above the size of a large town or small city. Schaanwald was the first municipality on my trip across the country, a small border town set on a hill looking over the Rhine Valley. I noticed that gas in Liechtenstein was very expensive, almost two Swiss Francs per liter (more than $2.00 Canadian.) The license plates are a simple white on black prefixed with “FL” (Fürstentum Liechtenstein, or “Principality of Liechtenstein.”)
The Liechtenstein countryside is simply a pleasure to hike through. There are multitudes of hiking and biking trails everywhere. The country capitalizes on its natural beauty extensively, promoting all kinds of outdoor activities. It’s almost a shame that I only had five hours to spend in Liechtenstein before I had to catch a train in Switzerland.
I hiked through the small town of Schaanwald, and then the even smaller town of Nendeln. The houses and side streets gave way to a highway that wound its way down around the side of a mountain, into the Rhine Valley. Thanks to the great weather, there were a large number of bikes and motorcycles in attendance. The majority of vehicles on the road were from Liechtenstein, with a healthy minority from Austria, Switzerland, and Germany.
The Principality also has a fantastic transit system. It was great that I was walking from one end of the country to the other, but it would be very easy to catch a bus along the same route. In this photo, you can see the distinctive neon green ‘Liechtenstein Bus’ picking up a passenger across the street from one of the Hilti offices. (Hilti is the largest employer in all of Liechtenstein.) The bus starts in Feldkirch, Austria, goes across Liechtenstein, and ends in Buchs, Switzerland. Thus, this ordinary transit bus crosses two international borders many times in the course of a day.
It would have been a great honour to take the bus or train across Liechtenstein, but walking across made the whole journey more interesting. I eventually made it to the city of Schaan, just north of the capital of Vaduz. It was here where I originally intended to take a train. In this photo, you can see an Austrian train pulling in, stopping on its way to Feldkirch. The railway line that cuts across Liechtenstein (more or less following the same route I was hiking,) is owned by the Austrian railway company. Like the Liechtenstein Bus, several trains travel from Switzerland to Austria (and vice-versa) via Liechtenstein every day.
The city of Schaan gave away to the countryside as I continued on, this time looking more like the Fraser Valley than anything else. It wasn’t much more of a walk before I came upon the bridge that crossed the Rhine, marking the western border of the Principality of Liechtenstein. In this photo, the land to the right is Liechtenstein, and to the left is Switzerland. I had crossed the whole width of the country in about two hours.
I also have to apologize for the poor quality of this photo, the sign demarcating the beginning of Switzerland. As you can see, the sun was already relatively low on the horizon, making it difficult for me to get a good shot of the demarcation sign and Swiss flag. There are no border controls on the Swiss-Liechtenstein border, since the Swiss guards check everything on the Austrian-Liechtenstein side.
From the bridge it was only a short walk over to Buchs, a town on the eastern border of Switzerland. At the point that I crossed into Switzerland, I had set foot on four separate countries in one day (Germany, Austria, Liechtenstein, and Switzerland.) The picture to the right looks back at the border from Switzerland (the little circular sign on the bridge marks the border,) with a Liechtenstein bus straddling the border in transit to Buchs, Switzerland. I looked back on the Principality one last time before continuing my journey to the Buchs Hauptbahnhof (Central Station,) to endure four more hours on the train back to Munich.
A TinyTrak is a small APRS tracker available for puchase from Byonics. It interfaces with a GPS unit and is tiny enough to fit into a vehicle or carry with you while on a hike. These diverse little units are able to decode incoming serial data (be it from a computer or GPS device,) and then re-encode it into 1200 baud AFSK for broadcast on a radio. The power consumption is very low, making it ideal for environments where power may be limited.
I chose to have the TinyTrak sent to me unassembled. This saves $10 off of the base price and makes for a fun hour of assembly.
The assembly is not difficult, and in fact serves as a great project for those wishing to learn basic soldering skills. Byonics ships the TinyTrak with easy to follow assembly instructions.
The next step is to assemble a cable for your brand of radio. I decided to use it alongside my Kenwood TM-V7, since it normally does not have APRS capability. Later, I will interface it with a more rugged Motorola Maxtrac radio, which will be used soley for APRS. The TM-V7 utilizes a 6-pin Mini-DIN socket, exactly the same as a computer PS2 plug, to send and receive digital data. This makes it easy to sacrifice an old computer PS2 cable. You can see the cable plugged in to its socket on the left-hand side of the radio in the picture below.
The Maxtrac makes use of a 16-pin connector, similar to old floppy and IDE cables, but with fewer pins. Again, sacrificing an old floppy cable to create an interface for the TinyTrak is easy.
Surprisingly, the toughest part of this project was assembling the cable. I spent hours scouring the Internet for accurate interface diagrams before I realized that Byonics had great radio interface diagrams on their website. I wholeheartedly suggest that you look there for a diagram, first. You can click here to see what the diagram for the TM-V7 cable looks like.
After that, it’s a matter of plugging the TinyTrak into a computer to program it via the serial port. The software used to program the device runs on Win32, but fortunately there are lots of old Win32 machines lying around doing nothing. I configured the TinyTrak to beacon every 30 minutes while stationary, and every 60 seconds while on the move.