Category: Uncategorized

I just had a look through my archive and found out that 2007 was the year Vodafone Germany introduced it's WebSession offer that I have used every since for Internet connectivity while traveling away from home when I didn't have a local SIM card. Since then the offer hasn't changed much, €15 for 50 MB a day with a nice little landing screen to invite you to spend another €15 when you exceeded the limit. At the time, I found the 50 MB quite sufficient and didn't have to control my usage to much. These days, however, the 50 MB are used up quite quickly and I have to watch my consumption. An interesting change! So Vodafone, no change in the tariff in 4 years!? It's about time, the world has moved on!

Here's an interesting thought I had the other day I'd like to throw at you to get some feedback. The main challenge faced by LTE is that the current GSM and UMTS voice infrastructure can not be used with LTE anymore as it is an IP only network. There are a number of solutions to the issue such as VoLGA, VoLTE and CS fallback but let's assume just for a minute that neither of them is able to get any traction due to one shortcoming or another. There is one more solution and that is dual-radio, the LTE radio is active at the same time as the GSM or UMTS radio.

Verizon, for example does this already, as shown with their HTC Thunderbolt. The Thunderbolt uses their CDMA 1xRTT network for voice calls and their LTE network for IP based traffic. For the CDMA part, CDMA credentials are used that are stored in a secure place in the device while the LTE security is handled by a SIM card.

So far so good. But what about countries that use GSM/UMTS? Here, a single set of security credentials, or, in other words, subscription is used so one can't be registered to, for example, GSM and LTE at the same time. At least that's what I thought so far. But is it really so? If, let's say, only a GSM circuit switched location update is performed, only the MSC is registered in the HLR/HSS. The packet switched part on the other hand is still open. Now the mobile device registers (only) the packet switched part over the LTE network. This would trigger the current MME to be registered with the HLR/HSS. In other words, there is no collision with the CS part of the network at all of this registration.

If the mobile runs out of LTE coverage it could then perform a routing area update in the UMTS network and also move the circuit switched connectivity from GSM. And once LTE coverage is available again, it could move the packet switched connection back to LTE while the circuit switched connectivity could either move back to GSM or stay on UMTS. From a network point of view I don't see anything that would speed against it. Do you?

Now how easily this could be implemented from a mobile device point of view is another matter. If there's an integrated GSM/UMTS/LTE baseband than that's likely to be difficult. But if there's just a UMTS/LTE chip for IP connectivity and a separate GSM chip for voice connectivity then the implementation would be straight forward, except for the physical access to the SIM card that would have to be multiplexed.

Obviously the power consumption of a dual radio device is higher than that of a single radio device. However, the power consumption of a GSM baseband while in idle is very small. While it would definitely have an impact to the idle standby time which is measured in the hundreds of hours these days, I think the impact it would have on total running time is much less, especially in smartphones. Most smartphone users make good use of their device today and regularly have to recharge it once per day anyway. So a hundred hours less standby time or so won't really matter very much.

Coming back to my question above. Perhaps I'm blind but I can't see any obstacle from a network point of view to have a mobile device CS attached only over the GSM network while PS only attached over UMTS or LTE. The HLR/HSS should not care at all. Let me know if you think I'm wrong.

One of the things I usually do when I go to meetings and conferences that are attended by more than 40 people or so is to get hold of a local SIM card for Internet access, as the public Wi-Fi at the conference venue and hotel is usually unusable. When I was in Seattle recently for a smaller meeting, though, I thought I'd give the Wi-Fi in the hotel a chance again. And indeed, things were working o.k at a steady 2 MBit/s. That changed, however, as soon as I got out of the hotel. Free Wi-Fi at Starbucks, so no problem you would think. Not really, the Wi-Fi was completely unusable. Next, I went to the airport, again depending on the Wi-Fi installation there. This time, it was sort of usable but still painstakingly slow. Very disappointing. And in Paris on the way back, the Wi-Fi in the lounge wouldn't even let me connect. Back to 3G then…

Back in August last year my last UTMS speed measurement at home resulted in a sustained peak data rate of 11 MBit/s. Since then, things have moved forward once again so it was time to perform another test, this time at 3 am in the morning once jet-lag caught up with me. And I was not disappointed, the sustained data rate was over 16 MBit/s as shown in the picture on the left. If you put the 10-15% of HARQ overhead on top that's just 2.5 MBit/s below the theoretical maximum speed of 21 MBit/s (again including HARQ). Performing the same test again in the morning resulted in around 14 MBit/s a second. Breathtaking values!

A self observation today: When I first signed up for a VPN service on the Internet it was to protect myself mainly when I am using unencrypted public Wi-Fi in hotels and other places. Since then, however, I have found various other uses for a VPN tunnel.

Lately for example, I have discovered that over some fixed line connections, Youtube HD videos don't stream very well and have lots of interruptions. Interestingly, when using a VPN over the same link and then streaming the HD video, everything is o.k. In other words, one part of the newtork between me and the VPN gateway seems to meddle with the data stream if it detects that it is a Youtube stream.

I have made similar experiences over cellular connections and some carriers by default compress pictures and other contents. While some offer a web page to disable this behavior I travel a lot and don't really have the time to figure out how this is done in each network. Again, turning on the VPN is a quick solution.

And then some content on Youtube, for example, can only be viewed while you are at home due to regional broadcasting rights. Again, the VPN helps to virtually bring you back home and makes things work.

Quite frankly, I've grown a bit tired by all this interference. Hm, net neutrality? Difficult to find these days without having a VPN exit point in a "neutral" part of the net. So more often then not these days I don't bother anymore to think about whether the VPN needs to be up or not, I just turn it on and be done with it.

This post is part 3 of the series that looks at how Android based devices interact with Google in the background. In part one, I've been analyzing what an Android device does if the user gives the device his Google login credentials and otherwise leaves the settings as they are. Part 2 then looked at what the ordinary user can do to reduce the exchange of data with Google. But even with all options turned off via the user interface there is still some interaction going on through encrypted connections. While encryption is obviously necessary to prevent eavesdropping it also makes it impossible to see from the outside what kind of data is exchanged. So I was wondering if there is a way to stop the device from talking to Google completely.

And indeed there is away. During my research I noticed that like most other Internet based services, Google uses the Domain Name Service (DNS) to resolve domain names such as www.google.com to IP addresses that the applications such as Google Talk, the Android market, maps, calendar and address book synch, etc. use to talk to servers in the cloud. In practice, name resolution comes into play when a program opens a connection to a server with a domain name. Before the server is contacted, the OS first sends a request to the DNS server in the network to get the IP address of the application server. By tapping into this process and giving the application the local loopback address instead of the IP address of the server, communication can be stopped. Obviously this should only happen for certain domain names as otherwise web browsing and other services would stop working as well.

So how can the local loopback address be returned for certain domain names? If you are in control of the DNS server that is used for a connection then it's possible to control it on the external server. In most cases, however, there's no way to control the external DNS server because for cellular connections, Android does not offer the possibility to specify a DNS server manually, i.e. the network operator chooses which DNS server to use.

The second possibility is to interact with the DNS resolver on the device directly. The Android DNS resolver, as it is based on Linux, always queries a file called "hosts" in the /etc directory for local name resolution before it queries an external server. Usually the file only contains one entry:

127.0.0.1           loopback

By adding additional entries for the domain name of Google services, communication can be prevented. Here's an example:

127.0.0.1     android.clients.google.com
127.0.0.1     mtalk.google.com
127.0.0.1     www.google.com

Depending on the manufacturer additional lines are necessary to stop the phone talking to HTC, Samsung, LG as well.

The problem with the hosts file is that it is located in a protected area so the device has to be rooted first. How this is done depends on the model and the maker of the device. Once done and after installing a terminal program such as "Terminal Emulator" to get to a shell, the final obstacle is that the partition the /etc directory is located is mounted as read only. So before the file can be changed the partition has to be remounted as writable. Here's the shell command to do that for a Samsung Galaxy S:

mount -oremount,rw /dev/block/st19 /system

Other devices might have the /etc directory mounted somewhere else which can be found out by using the mount command without any options.

It takes quite some effort to stop the conversation of background services but depending on your privacy needs it's an effort well worth taking. Every now and then, however, even I would like to use a Google service such as maps, I just don't want my device to exchange data with Google all the time. To do that the lines added to the hosts file have to be removed again (after making sure address book and calendar synch is still disabled in the settings). Perhaps that is something that should be automated…

You might have noticed that every now and then I not only discuss mobile related things on the blog but also security related thoughts, which usually have a mobile edge as well. In that regard I very much enjoy listening to the weekly "Security Now" podcast with Steve Gibson and Leo Laporte which recently pointed me to "Zero Day", a novel by Mark Russinovich. So far I was always very disappointed by authors putting computer and security related issues in a novel as they were not deep enough into the technology to describe things realistically. Quite a different story here. I can't remember when I last read a contemporary 300+ page novel in less than a week. This one is a first in many years and thus highly recommended. The link above leads to Amazon where you can find more details. No need to repeat them here.

In the past couple of days I've been discussing the idea of rooting an Android phone with a couple of friends in the industry. At some point, more than one of them said "it's like jailbreaking the…". That's interesting because even many knowledgable people in the industry do not see the difference between rooting an Android phone and a jailbreak.

So here's my opinion in this: With most network operators (exceptions prove the rule…) Android phones are open. You can install the apps you want, via Google's Android market, Amazon's market, GetJar, etc. Also, people can directly install apps they have downloaded to the memory card. Also, there are no restrictions as to which apps can run on the device and which not (again, exceptions prove the rule). In other words, these phones are free (as in free speech) so there is no need to "jailbreak" them.

So what's "rooting" then? Android has a security framework in place to prevent apps from doing malicious things. The first line of defense is during installation when the app has to present the list of required permissions to the user (e.g. for network access, for reading location information, etc.) so he can decide if he wants to install the app or not. Once the user gives the app the required permissions it is installed and can then be started. Android then insures the app does does not go beyond the defined security context.

But no matter how many permissions the user gives to an app there are some things that are never allowed such as for example, writing to a protected part of the filesystem that belongs to the operating system only. This is potentially dangerous as changing certain files in the system breaks the phone. This is the same concept that is also in desktop operating systems such as Windows, Linux and MacOS. Still, for power users there are good reasons to have access to restricted parts of the operating system and this is where "rooting" comes in.

Android is based on Linux and if on a Linux user wants to do something that only the root user can do he requests "root rights" and typing in a password. On Android, an app by default can't acquire root rights for security reasons. "Rooting" an Android phone makes this possible, i.e. the app can ask the operating system to get root rights and thus be able to do things that ordinary apps are restricted from doing.

Jailbreaking on the other hand is a concept required on devices where the user is severly restricted by the concept of the device, e.g. a jailbreak is already necessary to install apps from places other than the official market. In other words, jailbreaking is a method to circumvent a closed garden system while rooting is a concept in open garden systems (such as Android) for apps to get root level access to the system.

Obviously the main feature of my first self written Android App is to do some drive testing to see how many cells are out there and how good the network coverage in general is on a particular stretch. So in the past couple of days I took my apps for drive testing to see how many cells cover my way from and to work.

The distance between my home and work is 38 km. To see if there are differences in the number of 2G and 3G cells I did the exercise a couple of times to get the number for each network technology. And to see if there are differences between networks I ran the exercise with SIM cards of two network operators. As a result I could see around 63 cells on my way to work, both in GSM and UMTS.In other words the network density of 2G and 3G seems to be quite similar, at least in the part of the world I live.

Also there hasn't been a significant difference in the number of cells between the two networks so from a capacity and coverage point of view the networks are very similar. Perhaps I should run the exercise again with the other two networks as their marketing and budget approaches might be different.

The 64 cells and 38 km distance can be translated into 38 km/63 cells = 600m/cell. In other words, each cells covers on average 600m of my way to work. On my trip I go through cities and also a few kilometers through the countryside so it's likely the cells in the cities are a bit smaller while the cells outside are a bit larger.

This does not mean, however, that there is a cell tower every 600 meters as a base station usually has three sectorized cells each covering 180 120 degrees. So the average distance from one cell tower to another is somewhere between this value and and its double. It's somewhere in between as I imagine that while the trip covers two sectors of some base stations, it will only touch a single sector of others.

Ever wondered if your Wi-Fi Access Point at home is already in Google's Wifi location database? If so, have a look at this web page where you can type in the BSSID/MAC address of your access point. If present in the database, the location will then be shown on a map. With most Android devices collecting location information on the go, I wonder how long it takes until a new Wi-Fi access point shows up in the database!? Hm, an interesting experiment…

Note: The MAC address to be typed in here is usually not the MAC address that you see in Wireshark if you communicate with the web front end of your access point but a separate ID that you either have to find in the configuration menu of the router or if by using Wireshark in Wi-Fi sniffing mode. This exposes the real Wi-Fi MAC header that contains the source, destination and the BSSID MAC addresses instead of only source and destination.