Bad Internet Connectivity Makes Me Leave The Turkish Airlines Lounge

The Turkish Airlines Lounge in Istanbul is by all means one of the coolest places to stay at any airport around the globe. Well at least it was so far.  Apart from a nice interior one thing that is obviously absolutely crucial to me and many other business travelers is good Internet connectivity. And this is more and more difficult to get in that lounge.

While there is Wi-Fi in the lounge, OpenVPN and IPSec connectivity is blocked. No idea why but I’m probably not the only business traveler who is more than unhappy about this. At least I can use an SSH tunnel VPN that they (forgot?) to block to get my data safely through the network. Another option that has worked so far in the lounge is to tether my PC via a mobile device and one of the cellular networks there to the Internet. Unfortunately both times I’ve been there recently, Turkcell and Vodafone Turkey failed miserably.

Outside the lounge at the gates, both networks worked well so I decided to leave. Perhaps one of the companies involved in this cares and does something about the situation next time. Would be nice…

In-Flight Internet Reloaded On A Flight To Asia

china-flight-smBack in 2011 I had my first in-flight Internet experience over the Atlantic with a satellite based system. Since then I’ve been online a couple of times during national flights in the US where a ground based system is used. In Europe most carriers don’t offer in-flight Internet access so far but an LTE based ground system is in the making which will hopefully have enough bandwidth so support the demand in the years to come. When I was recently flying to Asia I was positively surprised that Turkish Airlines offered Internet access on my outbound and inbound trips. Free in business class and available for $15 for the duration of the trip in economy class I was of course interested of how well it would work despite both flights being night flights and a strong urge to sleep

While most people where still awake in the plane, speeds were quite slow. Things got a bit better once people started to doze off and I could observe data rates in the downlink direction between 1 and 2 Mbit/s. Still, web browsing felt quite slow due to the 1000 ms round trip delay times over a geostationary satellite. But it worked and I could even do some system administration over ssh connections although at such round trip times command line interaction was far from snappy.

In the uplink I could get data rates of around 50 to 100 kbit/s during my outbound leg which made it pretty much impossible to send anything larger than a few kilobytes. On the return trip I could get around 300 kbit/s in the uplink direction when I tried. Still not fast but much more usable.

Apart from web browsing and some system administration over ssh, I mostly used the available connectivity to chat and exchange pictures with others at home using Conversations. While being mostly available, I noticed a number of outages in the link ranging from a few tens of seconds to several minutes. I’m not sure by what they were cause surely not due to clouds or bad weather above the plane… 🙂

While overall I was happy to be connected I have to say that like in the US, this system is not offering enough capacity anymore and it will become more and more difficult to offer a good customer experience without bumping up speeds significantly.

Wi-Fi Hotspots With Real Encryption Without User Interaction

One of the major issues of public Wi-Fi hotspots is that they are usually unencrypted which makes users an easy target for eavesdropping. Some Wi-Fi hotspots use encryption but the PSK password is the same for all users. As a consequence an attacker that intercepts the authentication procedure can decrypt the traffic easily. This means that the only thing that can be achieved by using WPA2-PSK encryption in public hotspots is a weak form of access control by trying to keep the password within the group of authorized users. Good luck with that. Thanks to this post over at Heise (in German) I got aware that Dan Harkins of Aruba (now owned by HP) is trying to change this in the IEEE:

What Dan proposes in his “Opportunistic Wireless Encryption (OWE)” document presented back in September 2015 is to use a Diffie-Hellman Key exchange instead of WPA2-PSK when establishing a connection to the Wi-Fi Access Point. The difference between DH-Key exchange and WPA2-PSK is that the user does not have to supply a password and that an encrypted tunnel for which no shared secret is required is used to exchange a per-device encryption key. In other words, the proposed solution works in the same way as the key exchange used by https to secure web traffic today. No password needs to be given and the individual key that is exchanged through the encrypted tunnel ensures that an attacker can’t decode the traffic even if he intercepted the exchange (which is possible with WPA2-PSK). Two problems solved (no password, real encryption) at the same time.

Unfortunately it seems that there is no wide spread support for the idea yet. This document suggests there weren’t enough supporters in a meeting in January 2016 to include the idea in the next update of the 802.11 Wi-Fi standards. Let’s hope that this will still change as the current state of public Wi-Fi security is simply unacceptable.

Book Review – Where Wizzards Stay Up Late

wizzardsOn I go in my quest to learn more about the history of computing. After visiting the 1940s and 50s in Pioneer Programmer, I jumped forward a decade and a half to learn a bit more about the origins of the Internet.

While I knew that the Internet grew out of the ARPANET I had but a fuzzy idea so far. After reading Katie Hafner and Matthew Lyon’s account “Where Wizzards Stay Up Late” about how engineers at Bolt, Beranek and Newman (BBN) turned the ideas and visions of J.C.R. Licklider and others into reality and how people who’s names are well known in the industry today such as Vint Cerf and Bob Kahn got hooked and designed TCP/IP, a lot of things have become much clearer.

An interesting side note: The book was published long long ago in 1998 but since only events up until the mid-1980’s are described the book has aged well and is as readable and interesting today as it was over 15 years ago.

Coming back to the content, I found the book is very well researched and written and it’s fun to follow the story line. One thing I got a bit frustrated about at times was that it addresses a non-technical audience and hence doesn’t really go into the technical details. Instead it often tries to describe its way around the geeky stuff. Fortunately there’s the Internet and Wikipedia so it’s easy to get the details on specific parts of the story including easy access to original documents.

In other words a perfect symbiosis of story telling and online background research. Actually, it’s an interesting recursion as I used the Internet to download the book and also for doing background research, which means that the Internet practically tells it’s own story.

A highly recommended read!

How To Move From Typepad To WordPress

In a free and open web one would expect to be able to move one’s website from one service to another without too much hassle. But unfortunately many parts of the web are neither free nor open and making an escape with a blog from Typepad to a WordPress installation requires a bit of tinkering. While there are quite a number of reports by others of how to move away from Typepad exist on the web I thought I’d add my story as well because in the end it was less complicated than I thought. Overall, it took me about one and a half days to get things done. It could have gone faster but I wanted to experiment a bit to get exactly what I wanted. Read on for the full story.

Continue reading How To Move From Typepad To WordPress

Linux And A Good Backup Strategy Save The Day

When you travel a lot, chances are good that at some point your computing hardware fails without prior notice or gets stolen. It will happen, it’s just a question when and one is better prepared for it. In fact I was prepared and it paid back handsomely when a notebook under my care was stolen last week in Paris out of a backpack in a restaurant. First question of the owner: What will they be doing to my data? Second question: What shall I do now, I can’t work without the notebook?

Answer to the first question: They won’t do anything with your data, your notebook ran Ubuntu, it was encrypted to counter exactly this scenario and your password was long and diverse enough to withstand casual and less casual brute force attacks. And besides, those people were probably just interested in the hardware anyway… So rejoice you didn’t have Windows that doesn’t encrypt anything unless you have the Pro version… Yeah!

Answer to the second question (what shall I do now): 1.: Don’t panic (I’m sure you have a towel with you) and 2.: Don’t worry, the last backup of the system partition and the data partition are only 3 days old. That’s the amount of data loss you have. And 3.: Clonezilla restores your system on a new SSD in 15 minutes. Restoring your 600 GB of data to the user partition takes a little while longer but it will be done in time for me to catch that 6 am train to Paris to deliver the 1:1 replacement (minus 3 days worth of data).

So as sad as the story is, it’s great to have a working backup strategy that gets you back up and running in 15 minutes on totally different hardware with everything (still) installed and configured like on the “old” one. Thanks Clonezilla!

No Love In Ubuntu 14.04 for OpenVPN and IPv6/UDP for Transport

On my way into IPv6 land the next stop was in OpenVPN land and to see if I could establish an OpenVPN tunnel over an IPv6 UDP connection. Note that in this scenario I only want to have IPv4 inside the tunnel as before but the tunnel itself should make use of a UDPv6 instead of a UDPv4 connection. Turns out that OpenVPN does support this in principle but one has to decide whether to start the OpenVPN server in IPv4 or IPv6 mode. Dual-stack operation is not yet included. Not ideal, but for testing purposes I would have switched to IPv6 on the server side. Unfortunately it never came to that because the OpenVPN client in Ubuntu’s network manager does not have an option in the GUI and also not in the NetworkManager configuration files to specify UDPv6 as a transport protocol. Quite a pity as it excludes everyone with a Dual-Stack Lite cable modem from installing an OpenVPN server at home and using it together with Ubuntu’s NetworkManager. Perhaps the OpenVPN client can be launched from a shell but where’s the fun in that?

Now We Can Almost Switch-Off UMTS

Now that all German network operators have switched-on VoLTE for voice services on LTE and are transitioning their subscribers to VoLTE step by step I can visualize a UMTS switch off in the mid-term quite well. Agreed, were aren’t quite there yet but the list of reasons to keep 3G running has become significantly smaller:

One major aspect will be how quickly VoLTE actually takes off and thus reduces the need to fall back to 3G during voice calls. For the moment, network operators seem to move their subscribers to VoLTE step by step, some slower, some faster. In other words, even though VoLTE is now up and running, not everyone automatically uses it.

Also, to be able to use VoLTE, one needs an LTE smartphone with an embedded VoLTE client. For the moment, only network operator device variants, at least in Germany and I suppose in the rest of Europe as well, come equipped with VoLTE capabilities. Buy the same device outside of an operator store and it won’t come with VoLTE. That will change in the future once the dust has settled a bit and device manufacturers, operating system and chipset vendors start treating VoLTE as a black box but I think that it is still some time away. Two to three years seems a realistic time frame for me until VoLTE comes out of the box in every new VoLTE device outside operator stores but that’s just gut feeling.

And once that is in place, network operators have to wait a while until the “installed based” of non-LTE and non-VoLTE devices has thinned out considerably. Telenor in Norway says it expects all of this to happen until 2020 by which they want to switch-off their 3G network. And in 2025 they want to ax their GSM network as well. The timing is a bit tight but if a network operator accepts that voice fallback of non-VoLTE devices will be to 2G without data capabilities during the call than they can certainly meet these deadlines.

How To Get That Dynamic IPv6 Address To The DNS Server

In a previous post on my first “IPv6 call” to a service at home I reported about the pains of finding a Dynamic DNS provider that supports IPv6 and supports it with a Time To Live (TTL) value of 60 seconds. The later part is important as this is the time the domain is not reachable in the worst case when the IPv6 address changes. For the moment my solution is to use a CNAME entry in my domain name I host at noip.com to another domain name at dynv6.com. For details see the previous post. The next challenge now was to find out how to automatically update the IPv6 address at the DNS server once it changes as this does not work the same way as for IPv4 addresses.

Updating the dynamic IPv4 address at a DNS server is straight forward. Either the Network Address Translation (NAT) router already has the functionality to send an update message to the dynamic DNS server or a simple http(s) request from any machine behind the NAT with some authentication information in the URL does the trick. No IP address is required in the request as the DNS server gets the request from the backhaul facing public IP address and just takes the value from layer 3. With IPv6 this doesn’t work for two reasons:

There is no NAT anymore so each server behind the router has its own public IPv6 address and thus has to send the request by itself. O.k., so far, no big deal. The next problem is that the server can have more than one public IPv6 address. While the public prefix for these IPv6 addresses are the same, there can be different interface IDs in case IPv6 privacy extensions are enabled. On a server, privacy extensions are not necessary but Ubuntu server seems to have it switched on by default. Also, for a little while there can be deprecated IPv6 addresses in the address list with a prefix that is no longer valid. To get the IPv6 address across to the dynamic DNS server one could do as before and just send an http(s) request with a token if the URL is only reachable via IPv6. The problem with this approach is that the update domains for the service I tried to not support that, they are both IPv4 and IPv6 reachable.

Another problem occurs in case privacy extensions are used on the server as described before. In this case the interface ID will be randomly assigned for one of the IPv6 addresses bound to the interface. While the dynamic DNS server won’t mind, the router at home will because, at least my model blocks incoming IPv6 requests to all interface IDs by default and exceptions have to be statically configured. That’s a good thing but this requires that the interface ID of the server remains static. One of the two IPv6 addresses on my server fulfills this requirement as the interface ID is based on the Ethernet adapter’s MAC address so I can use this interface ID to configure the IPv6 firewall in the router. However, the request to the dynamic DNS server to update the IPv6 address does not originate from this IPv6 address but from the one with the randomly assigned interface id. Twice out of luck.

The solution to the problem is to find out which global dynamic IPv6 addresses are currently auto-configured on the server and to select the IPv6 address form the list that uses the MAC address as interface ID in the IPv6 address. The easiest way to do this I have found so far is a great shell script dynv6.com offers for the purpose that can be found here. For my purposes I’ve made two changes:

First, I adapted the command that finds the current IPv6 address. The original script does not take IPv6 privacy extensions into account which can be fixed by modifying the line as follows:

address=$(ip -6 addr list scope global $device | grep -v ” fd” | grep “global dynamic” | sed -n ‘s/.*inet6 ([0-9a-f:]+).*/1/p’ | head -n 1)

And the second change I’ve done in the script is to use https instead of http to actually run the queries as dynv6 supports https for the updates as well. No need to spread the word about my id token in plain http requests. The beauty of the script is that it checks if the IPv6 address has changed and only sends an update if it has. This way I can call the script with a cron job once a minute without sending and update to dynv6.com every time.

There we go, this problem is now solved as well!

 

Why I Left Typepad For A Self-Administrated WordPress Blog

Welcome, this is the first ‘original’ post on WirelessMoves’ new platform. I’ve been a loyal Typepad customer for 10 years but there were a number of reasons that accumulated over time that finally made me finally switch to a self-installed and administrated WordPress instance in the cloud. In case you are interested in the details of why I switched, read on.

One thing that has bugged me for many years is that my $50 per year account at Typepad would not allow me to use my own domain name. I could have had my own domain linked to Typepad, of course, but after a few years without it it wasn’t appealing anymore to retrofit this later. Also, pricing for my own domain wasn’t that appealing either.

Next, there’s no way around the fact that my blog in 2015 still looked almost identical to how it looked like a decade ago. What was slick and modern at the time looks a bit rusty today, the world wide web and design has significantly moved on over time. Also, a mobile friendly design is a must have today and Typepad didn’t offer an answer for me here, either. In other words, Typepad seems to be pretty much in a maintenance only mode rather than trying to continue offering an appealing platform for content creators. Over the years the platform seems to have changed hands a couple of times and the current owner seems to have no intention of changing this sad fact.

On the technical side a number of gripes have accumulated as well. There’s no  IPv6 and, even worse, there is no secure http, not even in the writer’s user interface. While the log-in procedure is protected by https, the platform immediately falls back to http. Especially when using public Wi-Fi hotspots and other non-secure places this is a significant problems as the browser cookie giving me editing rights can be easily intercepted. Obviously I’m always using a VPN whenever I’m not at home but it should be in Typepad’s own interest to keep their customers safe.

Next in the list of things I really would have liked to have had is internal statistics about what is read on my blog beyond Typepad’s meager info of how many pages have been accessed per day. I did use an external service for this purpose for many years but it shouldn’t really have been necessary. Also, Typepad embedded Google Analytics in my blog without my consent for their own tracking purposes. And finally Typepad never offered a public search functionality for my blog. Sure, you can use Google or another search engine for the purpose but, again, it should be part of the platform.

So here we go, that’s the list and it makes me wonder why it took me so long to make the switch!? A self-administered WordPress installation fortunately offered a solution to each and every one of these issues when coupled with the right hosting platform, especially when it comes to IPv6 and https. In a previous post, I wrote about the cool features of Uberspace’s hosting platform and this is where I migrated my blog to. The domain name is in my hands, WordPress is open source and should I decide in the future that I don’t like it there anymore I’m free to go instantly.

Unfortunately, Typepad doesn’t make transferring a blog to another service exactly easy but I got it done in a day and a half. More about that in a follow up post.