Category: Uncategorized

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.

With my 7th Raspberry Pi I finally ventured into mobile space so to speak. While all my other applications so far were of stationary nature and power sockets were always close by, I had to use a mobile power source, i.e. a battery this time to keep the Pi running while it was in my backpack. Powering a Raspi from a battery that I normally use for recharging phones while on the move is straight forward as Raspberries use the same USB connector for power as most smartphones. No extras required, I just connected the 3000 mAh battery into the Raspi and it kept it running for around 4 hours. I've put a picture of the setup on the left of this post so you can get an idea of the battery size required to keep the Pi running for a couple of hours.

So far I assumed that the SPDY protocol, a more efficient version of HTTP, is still in some sort of experimental state but not widely used. Therefore I was very surprised when I recently saw it being used in a Google search request. For those of you wondering how I found out, take a look at the screenshot at the left. During TLS authentication, the servers sends the optional 'Next Protocol Negotiation' information element in the TLS 'Server Hello' message. As Firefox also supports SPDY, the communication then continues using this protocol. I couldn't observe this directly as everything is done inside the TLS encrypted traffic flow. However, there's only a single TCP connection to the server which is a pretty good indication that SPDY is used. Also, the Wikipedia entry on SPDY notes that there are quite a number of popular services in addition to Google that have also activated support for the protocol. How interesting!

This is perhaps a bit of an odd title for a blog post but it pretty much describes an interesting phenomenon I recently discovered. Believe it or not, but I've been using an old WRT54 802.11g based Wi-Fi router at home simply because of the fact that it was stable compared to my DSL router's built in Wi-Fi and from a performance point of view it was not much slower. In practice I got around 20 Mbit/s out of that setup which was still o.k. for most uses but slower than my VDSL line at 25 Mbit/s in downlink and 5 Mbit/s in uplink. I therefore decided recently that it was time to get a well performing 802.11n router to be at last able to transfer things at line speed.

So I said bye bye to my Linksys WRT54 and hello to a Netgear WRT-3700 that I still had as a backup for the connectivity solution with bandwidth shaping for larger scale meetings. I was also thinking about buying a 802.11ac access point but my notebook only has an 802.11n Wi-Fi card so it wouldn't be worth the while for the moment. My first attempts to get to the full 25 Mbit/s my VDSL line offers over Wi-Fi were quite disappointing. Even thought the Wi-Fi access point has an 802.11n interface, I still couldn't get far beyond 20 Mbit/s I also got with the old 802.11g equipment. So I started experimenting with the orientation of the router and used the optional stand to turn the router 90 degrees around as shown in the image on the left. And suddenly I could reach a sustained throughput of 80 Mbit/s. By just turning the router by 90 degrees. So much for directional antenna output…

One of the podcasts I listen to every week recently crossed the 100.000 regular listener mark. Quite a number and it made me think how much it costs to deliver that podcast four times a month to 100.000 recipients!?

Let's do the maths: Let's say the podcast audio file has a size of 50 MB. Four times a month makes that 0.2 GB x 100.000 listeners, so the total volume to deliver is 20.000 GB or 20 TB. Now how much does it cost to deliver 20 TB of data? Large cloud providers have special services for content delivery and Amazon's CloudFront service, to make a practical example, charges 0.10 cents per GB on average for that kind of data volume. In other words, delivering 20.000 GB per month costs $2000 a month plus the cost of the virtual or physical web server behind the CloudFront service. When you look at it from a listener's point of view, it costs half a cent to deliver a single episode or two cents a month per listener.

Interesting numbers! One thing I didn't factor in is that the podcast is also available as videocast in HD as I have no idea what their ratio is between those who listen vs. those who watch the video stream.

Update: A reader sent me an email today with a link to an alternative hosting provider with quite different prices. They are asking for €2 per TB, i.e. €40 = $53 instead of the $2000 calculated above when using Amazon's CloudFront service. I'm a bit baffled, that's quite a difference.