Category: Uncategorized

Quite amazing how many web servers have accumulated at my home over time. At the moment I count 9:

• An ownCloud server on a Raspberry Pi
• A webradio streaming server / client from my Hi-Fi set on a Raspberry Pi (Squeezeplug)
• The web server in my Laser printer for status information
• The web server in my Inkjet printer for status information 
• A web server in my DSL gateway for administration
• The wiki I use on my PC for personal notes uses a web server
• Another Raspberry Pi I use for experimenting with new stuff usually runs a web server
• My XBMC based media center for streaming videos is controlled over a web server
• My VPN server based on OpenVPN and DD-WRT is administered over a web server

When looking at this list I am really glad for the security provided by the IPv4 network address translation (NAT) of my DSL router and my OpenVPN external access because some of those web servers should never be exposed to the outside world.

So how many web servers do you have at home?

In most countries in Europe, fixed and mobile voice communication is a highly competitive market and prices have come down to acceptable levels for national calls. As soon as you want to make calls from a mobile phone abroad, especially to international mobile phone numbers, things get very expensive. But now I've found an interesting solution to this problem, both for me as a caller and also for those people who want to call me from abroad:

In the UK Lycamobile, a Mobile Virtual Network Operator (MVNO) operates a brand called "Toggle Mobile".  Their SIM cards are quite special as they can be assigned up to 5 numbers from different countries. This ensures cheap prices when roaming and also gives me national mobile phone numbers in up to 5 countries that people can call cheaply or for free if part of their monthly bundle. Here are three daily scenarios I have:

Scenario 1 – Making international phone calls with my mobile: Even only calling EU countries with my "normal" SIM card costs more than a euro a minute. In other words, I try to avoid making international calls from my mobile phone and rather use my fixed line phone at home where I can make the same call for a couple of cents a minute. With the Toggle Mobile SIM on the other hand, calls to fixed lines in many countries cost 3 cents a minute and mobiles can be called for 9 cents a minute. As I'm living in Germany and not in the UK, I've assigned a German mobile number in addition to the UK number to the SIM card to get these rates. The German mobile number is free if only needed for 30 days or 5 pounds sterling for a year if I want it to be assigned permanently.

Scenario 2 – Get local numbers in other countries so people can call a local number: Many people including myself (see scenario above) are quite reluctant to call international numbers from their mobile phones. The solution to this problem is to activate a French mobile number on the SIM in addition to my UK and German mobile numbers. This way I can give my friends in France a French mobile number they can call me as part of their monthly package. The twist is that I don't have to be in France to receive the call. I can be in any of the countries I have registered for a local number and receive the call for free.

Here's a practical scenario: The person that wants to call me is in France while I am in Germany. He dials the French number, pays for a local mobile call and Toggle routes the call to me in Germany. I receive the call for free because I currently use the German number I have registered.

Too good to be true I thought at first, but I've given this a try over the course of two weeks and found it to work flawlessly. Excellent! The only slight disadvantage: I have to carry a second phone again, a very small one, however, just for voice calls. A dual-sim phone might be an alternative in the future.

Scenario 3 – Receiving calls for free in non-EU countries

In countries such as the US, India, Hong Kong and Australia incoming calls are also free. Perfect as I tend to be in some of those countries for time to time.

On the technical side the Toggle SIM contains a SIM Application Toolkit (SAT) App that detects in which country the mobile is switched on. It then compares the country to the national numbers (IMSIs) stored on the SIM and copies the corresponding id to the IMSI field on the SIM. It then asks the mobile to perform a SIM reset to make the mobile register to one of the national networks with the local IMSI. That sounds easier than it probably is to pull it off in practice so kudos to Toggle for operating such as service.

A couple of days ago I published a post that gave an overview of what I have recently found out about WebRTC. In the post I mentioned that WebRTC includes a SIP stack. Thanks to a reader, I have found out in the meantime that this is actually not the case. As this is quite a significant difference I have updated the post accordingly. Thanks for the correction, I've learned a lot and sorry for not getting it right the first time.

Lately I noticed due to all the different things I do with the Raspberry Pi how easy the Linux ecosystem jumps between different CPU architectures. I would say it is almost seamless. Here are a couple of examples:

Starting with the Linux Operating System itself in a wider concept, system administration is the same on the x86 PC and on an embedded ARM machine such as a Raspbery Pi. The learning curve when jumping from an x86 Linux to an ARM Linux platform is zero.

On the application software side things look equally bright. LibreOffice works on both my x86 notebook and on the ARM based Raspberry Pi. It looks the same and it feels the same, no difference. Just the speed is not quite the same. VLC, my audio and video player of choice due to its universal capabilities also works on both platforms. Children games and learning apps collection such as Scratch and GCompris work just the same.

In the somewhat more advanced category, there are cloud services and remote support. The Apache web server and lots of additions such as PHP, perl, python, etc. work identically in the x86 and ARM world. Again a learn once – use across platforms experience. Lots of web based applications such as ownCloud, Wikis and even more exotic stuff such as the Logitech Media Server don't care about the CPU platform as the interpreter languages they rely on work the same on x86 and ARM. There's also no difference when it comes to a setup for supporting a device remotely. VNC exists cross-platform so there's no
difference configuring an x86 or ARM Linux for remote administration.

And finally, hardware support on ARM is excellent as well. USB keyboards, mice, sound cards, memory sticks, SD cards etc. just work fine on the ARM based Raspi without installing any drivers.

All of this would be much harder to accomplish if it weren't for a number of major innovations that have been made over the years and bear their full fruits now:

The first one that comes to mind is the centralized application repository and update tool that is at the core of every Linux distribution and has existed long before app stores became popular in the mobile world.

It's also important to realize that Linux repositories go one step further than mobile app stores: As the software contained in them is usually open source, the Linux distribution itself can can compile all software for different CPU platforms.

Finally, third party USB hardware support is fabulous because drivers are already part of the Linux kernel and due to the abstraction via USB don't care about the processor architecture either. Again, everything is compiled by a central instance and hence does not require third parties to compile their drivers for different hardware platforms and give them to the central repository. That dramatically simplifies software updates. 

Microsoft must look enviously to the Linux camp in that regard. Their jump over to the ARM world looks much more difficult. There's Windows RT running on ARM based tablets of course but except for Office that was specifically ported to ARM there are few programs known from the x86 Windows world that run on it as well. After all, it's the software companies themselves that would have to support it by compiling their applications for another architecture that lacks support for many of the legacy libraries they use today. And on top of that they have to enter the "tile interface" world. It seems few are willing to do that so it's unlikely Linux will loose its cross CPU platform advantage anytime soon.

Recently, I've been musing in this post about a self hosted alternative to Skype for communication between family members using Asterisk on a Raspbery Pi and the Ekiga SIP client. With the recent discovery that Microsoft is actually listening into Skype text conversations that need has grown even stronger. Then I've read that the upcoming Firefox 22 will have the full WebRTC API implemented and activated. So far my knowledge about WebRTC has been rather limited, I just knew it had something to do with web browser based peer to peer communication but not much else. Time to fill the gaps:

The Wikipedia entry on WebRTC is actually quite brief and pretty much reflected what I already know: There's almost nothing about how it works. The FAQ over at webrtc.org is quite enlightening however. Here are some key facts that will help you to better understand WebRTC if you know about how VoIP works with SIP:

According to the FAQ, WebRTC can be thought of as a web browser based JavaScript API to SIP (Session Initiation Protocol) functionality. In other words, WebRTC contains a full implementation of a SIP stack that JavaScript programs in the browser can use to establish a communication session. While the communication session is peer-to-peer a centralized SIP server is still needed to initially connect the two endpoints. So instead of a native SIP client that has to be installed once, the JavaScript program in the web browser that is loaded from a (web) server that also hosts a SIP server becomes the client. WebRTC can do more than just abstract the SIP API. However, if you're familiar with SIP then this is the way to start thinking about WebRTC.

According to the FAQ and this blog post, WebRTC can be thought of as a web browser based
JavaScript API for two things:

• To access camera and microphone
• To connect to another peer (i.e. to the destination user)

What is not defined is how the other peer is discrovered initially and how audio and video codecs are negotiated. Traditionally this is done with a number of different protocols, SIP being one of them. In other words, the SIP protocol and communication with a SIP server is not part of WebRTC and has to be implemented by the web app on its own (for details see the blog post linked above). What is defined however is the use of the Session Description Protocol (SDP) to describe the audio and video codecs available on each end.

What I am wondering at this point is how two JavaScript applications running on different devices can communicate with each other directly, as I always thought JavaScript enforces the rule that the program is only allowed to establish connections back to the site from which the script was loaded. Obviously that can't be the case here anymore.

The FAQ also mentions a number of other interesting facts: WebRTC implements STUN (Session Traversal Utilities for NAT) to establish a peer-to peer session through Network Address Translation gateways, a must in today's IPv4 environment. Also, echo cancellation techniques are mentioned as well as the codecs used that look pretty neat, bandwidth efficient and wideband and HD video enabled. As all functionality is part of the web browser there's hope that performance will not suffer as much as if all code was written in JavaScript.

So one the simplest use case would be to replace native SIP clients with a browser based WebRTC client that implements its own SIP stack. WebRTC clients can even communicate with native SIP clients over a proxy server if both support a common audio and video subset. This seems to be the case with WebRTC supporting the G.711 and G.722 audio codecs that are widely used in the SIP world today.

This obviously fits into Google's overall (Chrome) strategy to have everything running via a centralized server in the network and in the web browser on user devices. While this is not exactly what I have in mind due to my preference of hosting my own web services at home the architecture is open so nothing would prevent me from running my own SIP server at home with an open sourced WebRTC client and proxy. Having the client run in the browser also means that the client software can be deployed without any hassles. The use case implemented by Ericsson over here gives an insight of what's possible with "just in time" deployed communication clients. At this point, WebRTC breaks with today's technology to offer new and interesting possibilities to explore.

For further insight, have a look here on SIP servlets and here for a HTML5 SIP client (+proxy) implementation with WebRTC.

When I am at home I'd sometimes really like to use the 25 Mbit/s of my VDSL line to its full extent. That's easier said than done as my VDSL router is in the hallway while my PC is in another room. Laying a cable is not an option so I am relying on Wi-Fi. As my notebook does not reliably work with the VDSL router's built in 802.11n Wi-Fi since I upgraded the router's software I use the 802.1g Wi-Fi built into my somewhat old WRT54-GS Wi-Fi router I use a VPN gateway. That limits my transmission speeds to about 18-20 Mbit/s in practice. In other words I am falling around 5-7 Mbit/s short of what's possible with my VDSL line. Not ideal.

So I decided to do something about it and bought two 500 Mbit/s Powerline adapters. I had high hopes for the solution as the linear distance between the VDSL router and the PC is 10 meters at most. Also, most reviews on a number of web sites were very positive. Unfortunately, it seems that the the power socket in the hallway and the power socket close to my desk might be on different phases or there's something else in the way as my throughput was a meager 2 Mbit/s. Not quite the hundreds of Mbit/s I was hoping for…

I then connected the power line adapter in the bedroom and the kitchen and again I only got 2 Mbit/s each time. In the bathroom I got 7 Mbit/s. Only when I connected the the two Powerline adapters to sockets in the same room did I get the full 25 Mbit/s bandwidth of my VDSL line. The diagnosis program shipped on a CD with the adapters indicated that the line speed was 300 Mbit/s but I didn't give it a try as having the adapters in the same room is a nice exercise but worthless in practice.

I live in an apartment building in Cologne that was built in the 1980's so I don't think my power cabling is out of the ordinary. Quite a disappointing result. Looks like I have to think again about a better Wi-Fi option, Powerline's definitely not the answer for me despite seeming to be a good solution for many others.

So far I've been using my RasPi for virtual applications such as hosting my own cloud services. But the Pi can do much more and I've been thinking about using one to control something in the real world beyond my music streaming setup with Squeezeplug. Interfacing with the real world requires inputs and outputs, of which the Pi has plenty. Driving motors and reading sensor input requires some special hardware though and there are a couple of add-on boards available for the purpose. Thanks to a tip of a friend I just found the add-on I really want to have for that purpose:

The BrickPi: LEGO® Bricks with a Raspberry Pi Brain

The BrickPi is a board and a casing for the Pi to integrate into Lego Mindstorms. I can already imagine building a couple of robots to do some fun stuff, like a robot on wheels with a web cam on top that I can send through my house to see what's going on when I am not at home. No problem with a Wi-Fi enabled Raspi on the robot that controls the wheels. Incidentally, the Raspberry foundation has just announced the availability of a small camera add-on module. Ultimately, though, what I have in mind with it is to give it to my nephews and nice as a computing and construction learning tool.

Note that the BrickPi is not a finished product yet, it's a kickstarter project and in case the people behind the project don't deliver your money's gone. Well, they have my 55 dollars now.  With 648 backers at the time of writing, $37.600 in funding and a company behind the project that has been working on similar products before I think chances are quite high that they deliver on their promise.

The delivery date is foreseen for August. Time enough to dream of further things to do with it for myself and how to pitch it to my nephews and nice as a Christmas present.

Since I discovered how I could use cloud services such as file sharing as well as calendar and address book synchronization with ownCloud and a Raspberry Pi from my own home without having my data stored I keep having revolutionary experiences with this low cost, low power hardware that runs Linux. My latest own-use discovery is SqueezePlug.

I've been looking for a web radio solution for quite a while now. While I have an off the shelf web radio with a display in the kitchen I wanted to have a somewhat more embedded and hackable version for the living room that connects to my Hi-Fi set and can be controlled from my PC and mobile phone. There are quite a number of proprietary solutions out there but they come at a relatively high price and remote controlling the devices always seems to go via a cloud service outside my home. Particularly the later part is not my cup of tea.

Then I stumbled over SqueezePlug which is Logitech's Media Server (LMS) and a Streaming Client both running on a Raspberry Pi. With a nice looking and easy to use web interface, I can now remotely control my stereo set over Wi-Fi without the need of an external web service. For additional sofa comfort, there's 'Squeezer', an Android App to switch channels and to control the volume. The source can be found here and is available in the Google Play store here.

At a power cost of around 6 euros a year for the Raspi (!) I can even keep it running 24/7 to compensate for the somewhat long delay before the LMS is available after power-on. So for 40 Euros for the Pi, 10 euros for a nice casing and 10 euros for a USB sound adapter I have a full fledged and remote controllable web radio in the living room. Perfect!

P.S.: You might wonder why an external sound adapter was necessary!? For some strange reason the Raspi's analog line out that works o.k. with other software produced some strange crackling sounds when using with the SqueezePlug software. No problem over HDMI or over an external USB sound card. I tried two different ones and both were recognized by the Raspian Linux OS without the need for installing anything.

On my desktop PC I proud myself with only having to reboot perhaps once a week. While I consider this as a sign of operating system stability I recently noticed that I could not remember when I last rebooted my Android based smartphone. Even though I use a lot of apps such as the web browser, Google maps for navigation, the Kindle App and FB-Reader for ebooks, K-9 for email, the weather app, train table lookup app, etc. etc. it took over 1000 hours to finally come to a point when a reboot was necessary. That's over 40 days the OS was running non-stop. A new personal record as my previous phones usually rebooted in some sort of self-defense mechanism every now and then.

It doesn't happen often but it does happen: Just when you are on the other side of the world, your cloud services at home hangs up. The DSL router looses sync, the VPN gateway has decided to go belly up or one of the servers stops cooperating. So what can be done? If one could only perform a reset…

In the past I've used a power socket with a timer to cut power once during the night to reset everything. Crude but effective with the slight disadvantage that in the worst case I have to wait till the next morning for my services to come back. Another slight disadvantage is that late at night local time is not necessarily a convenient time in another timezone for the VPN service to go down for a couple of minutes during local daytime. So I was looking for a more sophisticated solution and have found a cool "out of band" way to reset my network at home, a GSM Power Socket.

In Germany the GSM power socket is sold under the brand name of "GSM-One", for example via Amazon for 89 euros. To switch power on or off a simple SMS with a command code inside is used. The power socket then returns a status message to confirm the command. Very cool. Even cooler is the the SMS alert message when a power outage occurs and an SMS status report once power returns. Very nice, this puts me back in the drivers seat again no matter where I am.

In other countries, the device is sold under different brand names. In the UK for example it Sells as "Lindy GSM Power socket" for a shocking 142 UK pounds. For those not familiar with currency exchange rates between pound and euro, it's around 1.1 at the moment. Quite a hefty surcharge to order it in the UK…