WirelessMoves

These days the easiest way to connect a PC or Raspberry Pi for that matter to the Internet via a smartphone is to use Wi-Fi tethering.  But there are still scenarios in which Wi-Fi is not ideal, e.g. when the air is already pretty "busy". Another way that I recently discovered is to use USB tethering that many Android phones also support in addition to the ubiquitous Wi-Fi tethering. The screenshot on the left shows CyanogenMod's Android menu to activate "USB Tethering". Luckily, Raspbian already comes with drivers for it so the new network interface is recognized immediately. The only thing that is required is an entry in /etc/network/interfaces so the USB0 interfaces gets an IP address from the phone:

auto usb0
iface usb0 inet dhcp

A month ago, the new Raspberry Pi 2 was released and needless to say I couldn't wait to get my hands on one to see by how much the new quad core processor and the 1 GB of RAM would speed up Owncloud.

Back in September 2014 I ran a similar benchmark, comparing Owncloud on a Raspberry Pi Model B, a BananaPi and an Intel Celeron based NUC. While the BananaPi wasn't as fast as the NUC it nevertheless ran Owncloud much quicker than the original Raspberry Pi. With the new Pi 2's hardware specifications now closely matching or perhaps even exceeding that of the Raspberry Pi when it comes to its 4 processor cores vs. the 2 cores of the BananaPi it was time for another Benchmark.

The use cases I used for this benchmark are the same as those used previously. The results are not fully comparable, however, as I have upgraded Owncloud from version 7 to version 8 in the meantime. Also, I have upgraded the NUC from Ubuntu 12.02 to 14.04 and the Truecrypt container was replaced by a dm-crypt partition. And finally, I've decided to run all tests over Wi-Fi instead of over an Ethernet cable as that's how I access my servers anyway.

An interesting thing to mention at this point is that after performing a software and kernel upgrade of my Raspian / Owncloud image on an SD card it runs on both the old and the new Pi. For the benchmark I used the same SD card in both the old and new Raspi which excludes differences due to different software installations and flash speeds. The Owncloud installation is identical on the NUC and the two Raspberry Pis as I used rsync to copy the Owncloud installation (/var/www/owncloud) and Owncloud's data directory from the NUC to the SD card that I then used to boot both Raspberry Pis.

Login Test

Like in the benchmark back in November the first test was about how quickly I could access my Owncloud account after typing-in username and password:

• NUC: 3 seconds
• Raspi 2: 5 seconds
• Raspi: 18 seconds.

Displaying Address Book Entries

Getting my 300 address book entries out of the database and onto a web page took the following time on the three devices:

• NUC: 5 seconds
• Raspi 2: 9 seconds
• Raspi: 26 seconds

Opening the Calendar

Entries of 5 different calendars are displayed on my calendar page and the time it took until all entries were shown on the web page are significantly different:

• NUC: 4 seconds
• Raspi 2: 13 seconds
• Raspi: 104 seconds

Picture Uploads

For this test I uploaded 28 jpg images into a new folder on my Owncloud instance with a total file size of 71 MB. After each picture was uploaded a thumbnail was generated on the server and shown on the web page. And here's how the three systems fared:

• NUC: 45 seconds
• Raspi 2: 75 seconds
• Raspi 1: 509 seconds

This is almost a 7 times speedup between the old and the new Raspberry Pi, due to the 4 CPU cores that are used simultaneously during the process. The two screenshots below (click to enlarge) show CPU usage on the old Raspberry Pi with a single processor and on the new Raspberry Pi with 4 processors.

On both systems, several Apache web server tasks are actively working on different activities of the multiple file upload activity. On the old Raspi they all have to share a single CPU core and each can therefore only use around 20% of the CPU's capacity.

 

On the Raspberry 2 the picture looks completely different. Instead of sharing a single CPU, several Apache web server tasks are running simultaneously and independently on several cores as can be seen in four bar graphs that represent CPU activity and the amount of processor time (CPU%) used by each. No wonder it is so much faster!

Show Link

The final test I ran was how long it takes to show the page with all pictures I have just uploaded if it is accessed via a "sharing link". This is the typical "I take pictures, upload them to the cloud and then share it with others" scenario. As it takes some time to generate and display the thumbnails of the uploaded pictures I have two results per system below, one for the page to show up in the web browser and one for the time it takes until all thumbnails are loaded:

• NUC: 2 seconds (7 seconds until thumbnails are loaded)
• Raspi 2: 5 seconds (16 incl. thumbs)
• Raspi: 14 seconds (85 inc. thumbnails)

Summary

In all scenarios the new Raspberry Pi 2 ran significantly and noticeably faster than the old Pi. While not as fast as the much more expensive NUC system I can fully recommend the new Pi as an Owncloud server for home. It's still possible by all means to run an Owncloud on a previous generation Pi but it takes patience. As there is almost no price difference between the new and the old Pi, setting up an Owncloud server at home today on very inexpensive hardware yields much better results and usability than just a year ago. At the time I spent around 200 euros to move my Owncloud instance from an old Pi to a NUC. With the Pi 2 now available, I'm not sure if I would do it again for this reason.

In the previous post I had a couple of links to interesting information on what is between an antenna and the baseband radio chip in today's smartphones. As a quick follow-up here's my cheat-sheet which lists the components which is best used with this diagram over at Anandtech:

Downlink (Receive, RX) Path:

RF Front End Components

• Antennas (e.g. 2 required for diversity or LTE MIMO)
  

• Optional:  Antenna Tuner – Matches the (changing) impedance of the antenna with the transceiver. Impedance scenarios can be loaded dynamically when the environment (hand, grip, body location) changes.

• Antenna switch – Pipes the signal to/from the antenna to band specific filters and power amplifiers for the band currently used.

• Duplexers – Sit in each path after the antenna switch to combine/split the uplink and downlink signal that is transmitted/received from the antenna(s). Also, the duplexers include band specific filters.

Transceiver – includes the following sub-components:

• Low noise Power Amplifiers (PA), several present, each covering different band(s). 

• Down-converter: converts the frequency of the signal to a baseband frequency (to remove the carrier frequency (700 MHz to 5 GHz). Have a look at the Superhetrodyne receiver article over at Wikipedia for more information.

• Another Power Amplifier stage

• (Latest development from a Qualcomm 9×45 point of view: No companion chip necessary anymore for LTE carrier aggregation!)

After all of these steps the analog signal is ready to be given to the baseband modem split into in-phase and quadrature components. It's still analogue so the first task of the baseband chip (e.g. the 9×15 / 25 / 35 / 45 Qualcomm MDMs) convert the signal from analog to digital and it then starts it's magic to decode the information (which is outside the scope of this cheat-sheet).

Uplink (Transmit, TX) Path:

• Baseband: The digital baseband chips's last stage is a digital to analog converter to deliver a weak analog signal to the transmitter chain of the transceiver chip.

• Transciever:

• Narrow-band amplifiers

• Up-converter: Raises the signal to the transmit frequency

• Driver amplifier raises the signal before it leaves the transceiver

• Power Amplifiers: A switch inside the transceiver chip forwards the output signal to one of several power amplifiers, each dedicated to a specific frequency range. Several power amplifiers are typically included in a single chip outside of the transceiver chip. Optional: An envelope tracker chip can control the power amplifiers to reduce power requirements. The envelope tracker gets information of how much power to apply directly from the modem (i.e. the component before the transceiver!)

• Duplexer: Mixes transmit and receive signals as they use the same antenna

• Antenna switch

• Antenna

Back in July 2014 I wrote a post with a link over to Anandtech with a great introduction to the components and chips that sit in front of the baseband modem chip of a modern smartphone. Now the team over at Anandtech has greatly expanded on this and have written another article on the topic.

If you are interested but new to the topic it's worth to read the older post first as it includes a great diagram that shows how the components are connected together and to then continue with their latest post.

And once you've done that it's worth having a look at the tear-down of the iPhone 6 over at iFixit where they show how most of the components discussed in the posts above are used in this device. By my standards, the iPhone 6 has the most advanced modem front end to date as it supports 20 LTE bands, more than any other device currently on the market I'm aware of.

And if you are still looking for additional background information have a look at Wikipedia for extra knowledge on Superhetrodyne receivers and Envelope Tracking.

Last year I bought a prepaid SIM card in Austria with unlimited Internet access for 18 euros a month. It's done me a great service and has done so again recently when I was staying in Austria for a few weeks again. The place I was staying had a 5 Mbit/s DSL line but I nevertheless preferred to use the 3G connectivity instead.

You might wonder why but there's a simple reason: The uplink! While the DSL line only provided a few hundred kilobits per second, I could upload my documents at almost 10 times the speed over 3G, i.e. around 3 Mbit/s.

But things were getting quite tight over the air. In the early morning hours I could easily achieve the 10 Mbit/s in the downlink direction which was the subscribed limit. During daytime and in the evening, however, I could only get around 2-3 Mbit/s, despite the dual-carrier configuration of the 3G base station. In other words, things are getting quite busy. Time for LTE to arrive in the Austrian country side.

Last year it was discovered that a Marriott owned hotel in the US was intentionally blocking private Wi-Fi access points in an attempt to force their guests to use their heavily overpriced Wi-Fi system. After a complaint to the FCC an investigation was started that led to a $600.000 fine and a public consultation. Cisco, Aruba Networks and Ruckus Networks came to Marriott's help and defended the practice, probably because they are selling the weapons, i.e. the equipment that detects other hotspots and send de-authentication packets to devices that use them. Shame on them!

Fortunately lots of companies such as Microsoft, Google and CTIA took the side of liberty and freedom of choice by positioning themselves against such active 'jamming' systems. A couple of days ago the FCC has now published a final 2 page 'enforcement advisory' with crystal clear wording:

"Warning – Wi-Fi Blocking is Prohibited

Persons and Businesses Causing Intentional Interference to Wi-Fi hotspots are Subject to Enforcement Action

[…] the Bureau is protecting consumers by aggressively investigating and acting
against such unlawful intentional interference. […]"

Thanks FCC and yes, Marriott you'll stay on my list of companies I will not do business with anymore!

via Heise here and here

Quite often I'm in multi-day meetings with lots of participants. In recent years more and more hotels have bought Wi-Fi equipment that can handle 80-100 participants with twice the number of Wi-Fi devices in a single room. Unfortunately, there's still ample opportunity to be trapped in meetings for several days where the Wi-Fi fails once the room starts filling up. For such cases I've developed a solution that can fix the issues for everyone but unfortunately it's not always possible to put it into action.

In such cases I'm now resorting to plan B, which is a Raspberry Pi that acts as a Wi-Fi access point for my devices that tunnels my traffic into the Internet via smartphone tethering, i.e. a second Wi-Fi link. In addition, the Raspberry acts as a VPN tunnel aggregator so all my data is transported over an encrypted tunnel to my home and only from there to the 'unprotected' Internet. If you are interested in the details and the scripts to configure a Raspberry Pi of your own for a similar purpose have a look at this blog post from a couple of months ago.

While this helps me it unfortunately doesn't help the other meeting participants as data over cellular is still too expensive to give 100 people access. But with the introduction of affordable global roaming data rates in 2014 I now have at least a solution for myself. This requires, of course, cellular reception in the meeting room which is sometimes also a challenge…

Over the last years I've seen Linux being used in quite a number of places from churches to airplanes. Here's an other airplane example of which I could take a picture when the on-board information and entertainment system of an A320 rebooted before the flight. Judging by the copyright notice and other messages during the boot procedure it was based on a Red Hat Linux from back in 2002 running on an Intel x86 based system with 500 MB of RAM. Each seat seemed to have it's own embedded system as the boot process did not go through the same stages everywhere at the same time. 2002, that was 13 years ago… Quite an eternity in the digital age…

Ever since I can remember I loved to explore all things around electronics and computing, to find out how things work and to find out what's possible with stuff. When I was a teenager, however, this meant that every now and then I pushed the limits just a bit too far. When one day a little soldering experiment broke my computer I was out of business for a couple of weeks as one couldn't just get a replacement around the corner or go online and order something on Amazon. No, in those days it meant sending the equipment back to the manufacturer and to wait anxiously for a couple of weeks for the repaired computer to come back with a nice little bill attached that more than just strained the budget of a teenager. It was a defining lesson and I got a lot more cautious after that. Later, when I went to university, the story continued. I would have loved to play around with Linux but computers were expensive and I was dependent on my computer to work. So I didn't venture out to experiment as I would have liked but treated my computer as sacrosanct.

Incredible how the world has changed since then. Experimenting with electronics and computers has become so much easier and the worst thing that can happen today when tinkering with devices like Arduinos and Raspberry Pis is to fry a 20-30 Euro device. Wi-Fi or other wireless technologies can keep a computer physically separate so even if the hardware fries the effect can't jump to that expensive notebook. And even notebooks are not that expensive anymore and I have an older spare at home that I regularly use to try out things with first before I apply them on my main machine or to one of my servers that I run at home. Actually it was a second generation eeePC that opened the world of Linux to me on which I could try out things I would have never dared to do on my main PC. Today, all my personal machines run Linux that let's me experiment freely and openly without any limitations. Microsoft stuff that limits me to a single device is all gone.

And most of the time these days it's not even necessary anymore to use a physical device for experimenting. Instead I can just try new things in a virtual machine. After all, if the installation in the physical machine is broken one can just go back to the last restore point and things are running again in a few seconds. The degrees of freedom all of these things offer today compared to what was possible 20 years ago is just staggering. Not that I regret having lived through those times but sometimes I wonder what would be different today if I had all these possibilities already then!?

Anyway, I still catch myself every now and then being too cautious as sometimes the thought crosses my mind that things could break if I tried this or that before I remind myself that I can just press the reset button to start things over. How liberating!

Looking through various log files for suspicious activities in my home cloud is part of my security routine. Recently, I found some interesting entries in the Apache web server log file on the server I run Owncloud and Selfoss, my RSS server. Every 7 days I get a couple of http requests from China. What!?

O.k. I am in China every now and then but not every 7 days. So since it's my private server and runs on a non-standard tcp port to keep crawlers and script kiddies away that is quite suspicious. Digging a bit deeper and having had a look at the requests before and after the requests coming from China I finally found the reason for those requests: On my mobile devices I use “Opera Mobile” for web browsing which includes accessing my RSS feed aggregated by Selfoss. For quick access I've added a shortcut to the speed dial screen. On this screen, shortcuts are represented with a thumbnail of the web page. It seems the thumbnails are updated every 7 days but the thumbnail is not created by the smartphone itself but by a server on the Opera backend that tries to fetch the webpage, creates a new thumbnail, which is then downloaded to the phone. And it seems that this server is in China as the requests are always coinciding with me accessing my Selfoss RSS web page via Opera from my smartphone. How interesting! The picture on the left shows the temporal correlation.

In my case the web page is http digest password protected so there is no real thumbnail. And that's a good thing because if there were that would mean that Opera would send my password to their backend. But they don't so that's at least something.

And just to make sure the IP address reported by the tool being in China really is in China, I ran a traceroute:

[…]

 5  80.157.129.186 (80.157.129.186)  32.988 ms  33.312 ms  33.885 ms
 6  202.97.58.53 (202.97.58.53)  233.826 ms  223.837 ms  223.892 ms
 7  202.97.53.241 (202.97.53.241)  222.172 ms  219.059 ms  240.293 ms
 8  202.97.53.109 (202.97.53.109)  243.943 ms  249.146 ms  250.505 ms
 9  * * *
10  bj141-130-74.bjtelecom.net (219.141.130.74)  301.600 ms * *
11  bj141-147-82.bjtelecom.net (219.141.147.82)  320.768 ms bj141-131-162.bjtelecom.net (219.141.131.162)  320.731 ms bj141-147-82.bjtelecom.net (219.141.147.82)  320.721 ms
12  242.88.202.1.static.bjtelecom.net (1.202.88.242)  306.327 ms  320.606 ms  320.585 ms
13  211.151.224.194 (211.151.224.194)  325.090 ms 211.151.224.106 (211.151.224.106)  221.285 ms  223.845 ms
14  59.151.96.162 (59.151.96.162)  228.515 ms  268.986 ms  270.306 ms
15  59.151.99.90 (59.151.99.90)  270.648 ms  273.096 ms  275.106 ms
16  59.151.106.247 (59.151.106.247)  274.853 ms  287.711 ms  292.621 ms

Hop 5 is the last leg of the route to the destination IP address in Europe before the packets hop into a transit link to China. The delay of hop 6 already shows the other end of the tunnel is quite far away and a Whois lookup reveals that this is a transit link of China Telecom. Hop 16 is the IP address from which Opera's requests have originated and Whois reveals that the IP address is assigned to 21ViaNet in Beijing.