WirelessMoves

When what is called 'tethering' today first became fashionable to a few geeks at the end of the 1990's, Bluetooth was the technology of choice and it was well suited for the data rates in 2G mobile networks of a few tens of kilobits per second. But over time, mobile networks outgrew Bluetooth's capabilities when the technology could not evolve beyond around 2 Mbit/s. Here's an interesting post I published back in 2007 if you care for the historical perspective. Fortunately, Android pushed Wi-Fi tethering to the masses in around 2010 and for some time it looked like it could keep pace with theoretical peak data rates in mobile networks. At some point I had my doubts it could in such small devices when LTE data rates reached 100 Mbit/s and beyond. But it looks Wi-Fi chipset manufacturers were not sleeping as Anandtech reports in this post that they have measured a maximum throughput of over 400 Mbit/s in the Samsung Galaxy S5. And it's by far not the only device anymore going well beyond the 200 Mbit/s line with 802.11ac. Such speeds are likely to be only reached at close range but that's how tethering is mostly used anyway.

Just about a year ago I bought my first Raspberry Pi out of curiosity and to get my Owncloud server project started. At the time it was an experiment but it turned out to be the most liberating computing experience I had in many years. A large part of this is due to Owncloud that finally let me use cloud services such as calendar, address book synchronization and many other things from home. But it did not stop there, I've since put more Raspberry Pis into service as a water alarm system, to run Selfoss as my RSS server after Google has shut down its service, for daily checks of call by call prices with automatic email reports, for hardware projects to better understand how a CPU works, I'm using one as an OpenVPN gateway at home and another one as a secure VNC remote desktop bridge, another one to stream music to my Hi-Fi equipment, one went to my brother as as a learning kit for his kids and to be used as XBMC media server for his TV, and another one has been put to work as an automatic Wi-Fi and baseband long duration stress tester. The list of things I'd like to do next with it but haven't had the time yet is at least as long. And it's so easy to get started with a new project as the hardware is always the same and the operating system works almost identical to Ubuntu (that I use on my desktops) and most other Linux OS flavours out there. In addition, most of the software available for Linux runs on the Pi as well. So if you are also toying with the thought of getting a Raspi for one project or another I can more than recommend it. But be warned, once you get started there it's difficult to stop. At this point I'd like to say a BIG THANK YOU to all the people at the Raspberry Pi foundation, you've done something really big here!

This is a follow up to a previous post in which I described a new 5€ a month roaming offer I've subscribed to which allows me to use my included voice minutes, SMS and my 1 GB mobile data bucket not only in my home country (Germany) but also in other EU countries.

Previously the all inclusive bundle + 1 GB of data traffic I've subscribed to was only valid in Germany, all traffic and phone calls abroad were charged separately. That means that when I had been abroad for two weeks I had to pay for my full subscription even though I was not in the country. In other words, I had to pay for two weeks of service without being able to use it.

What the new roaming offer now effectively does from a psychological point of view is to give the two weeks worth of my subscription to the network operator abroad who delivers the service (i.e. Internet access, voice calls, etc) to me instead.Think about this idea for a minute!

From a technical point of view this works out as I am not using the radio network at home, which is the most expensive part in the transmission chain. Instead I'm using the radio network of a network operator in another country. On average, that is neither more nor less expensive than using the radio access network at home. Note that I'm looking at this from a technical point of view, what network operators charge each other for roaming is another matter entirely.

From a technical point of view, the cost of using the mobile network at home or abroad is almost the same. The only difference is that my data still flows through a gateway located in the network of the home operator which then connects to the Internet. But data traffic on the backbone is cheap and the 5 euros extra a month easily cover that.

It's clear that mobile network operators don't especially like this because now they forward money they could previously keep to themselves. But this change is very much in line with the desire to have a single EU economy which has also triggered changes in other areas as well. An example is the banking sector, where already many years ago, extra charges for money transfers between EU countries were abolished. Another example is extra charges for use of credit cards in other EU countries, which also no longer exist.

Let me set this into a historical context by looking back only 30 years: In the 1980's there was no interoperability between mobile networks of different countries in Europe and it was in many cases even forbidden to take 'mobile' phones (i.e. big equipment in trunks of cars) accross a border! Unbelievable from today's point of view.

GSM changed this mindset of "our [nation's] frequencies, our [nation's] network" to "we all build networks based on the same standard and enable our subscribers to use their devices in other networks abroad". A radical shift to something we take for granted that didn't come easy and lots of battles of words had to be fought over it. Compared to this, the change of the current mindset from "subscribers pay for national service" to "subscribers pay for EU service" seems much less dramatic and it might even seem strange 30 years from now why it was so difficult to achieve this.

But as strange as it might seem 30 years from now I'm sure there will still be many battles of words to be fought before we arrive at this point. But we are getting there one step at a time!

As I often stay in hotels and try to make the best of the available hotel Wi-Fi, I've bought a Wi-Fi distribution dongle that connects to the Internet over the hotel Wi-Fi on the one side and spans up a private Wi-Fi network on the other side for all my devices to connect to. The advantage is that I only need to configure the Wi-Fi distribution dongle and that I only need to pay for one connection. The disadvantage of the approach is that while I can use a VPN tunnel on the PC to protect my data traffic, a lot of data that I exchange with services on the Internet with my other devices is unprotected. Needless to say that at some point it was time to change this.

The platform of choice for this project is of course a Raspberry Pi with two Wi-Fi interfaces. I did a lot of research on the net but could not find a single project that combined the Wi-Fi Access Point functionality I needed with a second Wi-Fi USB stick for the client connection that acts as a backhaul and an OpenVPN client configuration that uses the backhaul to tunnel all traffic of my private Wi-Fi network. But each of these things are described separately and after experimenting a bit with all bits of the puzzle I was able to put the project together. In addition to using a Wi-Fi network as a backhaul link it's also possible to use the Ethernet port in case the hotel has cabled Internet access.

At first I thought I'd describe the solution in a blog entry but I soon realized that describing how to install a dozen packages and to modify 15+ configuration files is a bit too much in a single blog entry. So I put together an installation script, sample configuration files plus installation and usage information and put the result on GitHub. I spent two weekends to get the script and configuration files in a form and shape that their usage is straight forward on a newly installed Raspian with little manual work required. A lot of comments have gone into the script file so for those who'd like to know the details, have a look there and also at the configuration files used for the different components that are installed.

I've been using the solution in quite a number of environments over the past few weeks now and I'm pretty happy with the result and hope that this will be useful for others as well. Have fun!

Power doesn't fail often in Germany but just as luck had it, I experienced two failures in a row in the past year that rendered my cloud services at home out of service for a couple of hours. Needless to say that both incidents occurred at the least convenient time, i.e. while I was traveling.

So far, I've stayed away from uninterruptible power supplies (UPSes) as the last one's I've seen were bulky and had a noisy fan. But recently, I discovered the APC ES-700, a small UPS the size of a shoe box without active cooling that perfectly fitted my needs.

Despite it's size it can drive equipment that requires around 40 watts for around 70 minutes before it shuts down. Just like its big brothers it has a USB port for status messages and control input and the interface is compatible to Linux's APCUPS daemon that is easily installed. Apart from letting me query the status of the UPS from the server, the softare also logs power failures and automatically shuts down my Owncloud server before the battery is empty. No noise, open source software on Linux that is easy to use, it couldn't be any better. Two thumbs up!

The screenshot on the left shows log entries generated after the software installation while the UPS was not yet connected and some real messages once the setup was in place.

When describing the hardware of current smartphones, particular emphasis is usually put on the fact that there are there are two main processor blocks in the device. On the one hand there is the application processor, usually with several CPU cores today, that runs Android or another operating system. On the other hand, there's the baseband processor, sometimes also referred to as 'the modem' that handles communication with cellular networks such as GSM, UMTS and LTE. In many phones, both functionalities are integrated in the same chip. The modem, however requires a couple of functionalities between itself and the antennas such as transcievers that are separating the uplink and the downlink, frequency filters, power amplifiers, band switches, etc, commonly referred to as 'the front-end'. Quite some time ago, I saw this post on AnandTech that describes the latest state of the art and challenges in that area. Well worth a read!

It's good to see that the continuing pressure of the EU on European mobile network operators for affordable roaming charges has resulted in a further improvement of roaming tariffs. My preferred German network operator, for example, now offers to lift roaming charges in the EU for 5 Euros extra per month.

This means that I can use my (previously national) flatrate for voice minutes for calls in the visited country and back to Germany, for SMS messages and, most importantly, I can use my 1 GB data bucket for mobile Internet access in any EU member state and some other places such as Switzerland, Lichtenstein, Norway, Iceland and, believe it or not, French Guayana (in South America), Reunion and a couple of other French territories. This offer was an absolute no-brainer and I activated it immediately when it became available earlier this month.

I expected to see similar offers from network operators in other countries so I had a look on the websites of operators in Austria and France but came up pretty much empty handed. Incredible, should Germany for once become the leader in roaming pricing!?

I'd be quite interested to hear from you what kind of roaming tariffs you use at the moment and what mobile network operators offer in your country at the moment. So if you have a minute, please consider leaving a comment below. Thanks!

Three years ago I published a post on how to stop Android frequently calling home to Google. I was hoping that three years and a couple of devices later the situation would have improved somewhat with all the options one can disable in Android today and by replacing Google services with OwnCloud. But unfortunately this is still not the case. I can disable whatever I want in the settings but my Android phone still connects to Google via mtalk.google.com every time I unlock the screen. I also have the Amazon kindle app installed which contacts Amazon every 20 minutes even after rebooting the phone and not having opened the app before. Sorry guys, that is intolerable. So I had to again resort to the method of blacklisting all domain names that are used for these purposes in the hosts file on my device (see my original post from back in 2011). Unfortunately the method is not practicable for the ordinary user so it will remain a niche solution for the willy hacker.

While the main purpose of my tiny data center at home with a NUC and a couple of Raspberry Pis is of course to host my own cloud services (such as Owncloud, Selfoss, VPN server, VNC bridge, etc. etc.), it's also a great platform to try out new things. I like redundancy, especially when I am not at home for a while and have two backhaul connections, my main one over VDSL and a backup over LTE. While I could use a single router for both options I've decided to use two separate devices for redundancy. While this covers the most likely failure scenario of the VDSL line going down for extended periods of time (which it has done several times already when I was not at home) the solution's weak point is that my servers are connected to the Ethernet ports of the VDSL routers. In case the VDSL router hardware fails, this means that I would not be able to access my devices over the fallback router anymore. I could of course also use an Ethernet switch to interconnect all my devices but that would just move the hardware failure scenario from the router to the switch.

A solution to such a failure scenario is to have two Ethernet interfaces on the devices I run services on I rely on when I'm not at home and use them to connect the devices to both routers simultaneously. Redundancy is then achieved by bonding the two Ethernet ports together and only use one at a time with automatic failover. This is called Ethernet channel bonding and Debian Linux on which both Ubuntu and Raspbian are built on comes with an easy to use channel bonding kernel module. Here's how I set it up:

The first step is to install the kernel module for the bonding drive which is done as follows on both Ubuntu and Raspbian:

sudo apt-get install ifenslave-2.6

Once done the OS has to be instructed to load the kernel module during system startup. This is done by adding a new line in the /etc/modules configuration file that says "bonding". Make sure to back up the configuration file before making the change.

sudo nano /etc/modules
insert a new line which sys "bonding"

And finally, the network interfaces have to be configured for bonding. This is done in /etc/network/interfaces and my configuration looks as follows (again, backing up the configuration file first is a good idea!):

#eth0 is manually configured, and slave to the "bond0" bonded NIC
auto eth0
iface eth0 inet manual
bond-master bond0
bond-primary eth0
bond-mode active-backup

#eth1 ditto, thus creating a 2-link bond.
auto eth1
iface eth1 inet manual
bond-master bond0
bond-primary eth0
bond-mode active-backup

# bond0 is the bonding NIC and can be used like any other normal NIC.
# bond0 is configured using static network information.
auto bond0
iface bond0 inet static
address 192.168.77.33
gateway 192.168.77.1
netmask 255.255.255.0
dns-nameservers 192.168.77.1
bond-master bond0
bond-primary eth0
bond-mode active-backup
bond-miimon 100
bond-slaves none

While the bonding driver can also combine several Ethernet interfaces for load sharing I decided to use the active-backup mode and to declare the first Ethernet interface (eth0) as primary interface. This means that the system will always choose to use eth0 as the active interface and only use eth1 when this interface goes down. As soon as eth0 comes up again the bonding driver will immediately switch back to eth0. This perfectly fits my needs as eth0 is a gigabit Ethernet interface while eth1 is only a 100 Mbit/s interface connected to the server via USB. Also, eth0 connects to my VDSL router while eth1 connects to the backup LTE router. You might have noticed that the same options are spelled out three times above which seems superfluous. However, it wouldn't work when only using them once in the configuration.

Once the interfaces have been configured it's time to do a reboot of the system and then to check if the configuration works:

Status of the bonding driver: cat /proc/net/bonding/bond0
Status of the network interfaces: ifconfig

When the bonding interface is up and reports both Ethernet ports to be up and running, each can now be unplugged without the system loosing connectivity. Status changes are reported to the system log in /var/log/syslog which is a nice way to monitor changes. Another interesting exercise is to use tcpdump on eth0 and eth1 to record network traffic into separate Wireshark pcap trace files.

For more information have a look at the following resources:

General description of how to configure channel bonding on Ubuntu.com

The bonding driver manual

And two interesting descriptions on how bonding is done on RedHat and Fedora Linux. Note that different configuration files are used on those systems.

Happy bonding!

What's the best way to attract people to your network and pay money for it's use: Make sure it is available and works where it is needed (and where networks of other operators don't perform as well). This is especially true and challenging in stadiums and other places where tens or even hundreds of thousands of people meet. A couple of days ago I came across this report on Teltarif (Google Translator version here) that describes how a German network operator has built out his network to weather the extreme usage there during events. A follow up article then describes the result.

At first I was a bit surprised that instead of LTE, the network operator chose to build a small cell 3G network in the area. But the reason is probably very simple: While LTE is limited to Internet access, UMTS enables voice calls as well. Another thing I found quite interesting in the second report was that the LTE macro networks of other operators without dedicated coverage of the area were able to cope with the data traffic during the event while 3G macro networks failed to handle the load. It looks like the industry has learned a lot about how to handle data traffic in 3G and has improved on it significantly when LTE was standardized.