Author: Martin

When I upgraded to my recent smartphone hardware (a Samsung Galaxy S4 running Cyanogen Mod) I noticed that the time it takes to get a first location via GPS (first time to fix) is stunningly quick compared to my previous device. Even after not having used the GPS receiver for more than half a day, it only takes a few seconds until at least 3 satellites have been decoded and a pretty good approximation of my location is being returned.

Obviously using Google's Wi-Fi SSID database gives an even faster first location approximation but I am not very fond of having to consent to periodically gathering SSID and location information for Google to return the favor. But with such a fast GPS startup time I don't need Google's SSID services anymore and thus I have happily switched it off to re-gain some of my privacy. Yes, I know, SSID location gathering should be anonymous but I don't want to do it anyway.

But getting a fast GPS fix means that the device has to ask for satellite location information which also requires a rough location approximation being sent to a server in the network in what is called a SUPL request. More about my 'adventures' to find out more about what's included in such a request in my next post on the topic.

I always assumed that my Ubuntu based servers would automatically keep their real time clocks synchronized to NTP servers on the net. But when I recently checked the time on my local Owncloud server at home, I was quite surprised that it was off by over a minute. Also, the time on a virtual server I use for my backup SSH tunnels on the Amazon cloud was off by over 30 seconds. It turns out that Ubuntu server only polls an NTP server at system startup and both machines have been up and running without a restart for over a month. Quite an RTC drift for only 30 days, I would have expected far less. The issue can be fixed quite easily with the following entry in /etc/crontab but I wonder why Ubuntu doesn't do it out of the box!?:

# Synchronize date with ntp server once a day and write the result to syslog
00 6    * * *   root    ntpdate ntp.ubuntu.com | logger

Agreed, for most services used in mobile networks today a NATed private IP address does the job. But there are some applications that require a reachable public IP address such as web servers, VPN gateways, chat servers, etc. Also agreed, these are mostly connected via fixed line connections but in some instances, e.g. for fallback solutions or in places where DSL links are not available, it's great for them to be reachable over a cellular network as well.

Unfortunately support of public IP addresses is seen as a niche service by most mobile network operators and hence they either don't support public IP addresses at all or only via obscure and unadvertised APNs. The more delighted I was when I saw that one of the mobile network operators in Austria is offering to use a public IP address for a connection via their web configuration interface with a simple on/off switch. Great, a mobile network operator who's willing to also cater for those with special applications!

And when thinking a bit more about it it's even more stunning in the light of many alternative fixed line network operators who are also not willing anymore to give out public IPv4 addresses, not even on request. Take a look guys, it can be THAT simple!!!

In a previous post I described how to use a Raspberry Pi as Wi-Fi access point and how to trace the data traffic of my smartphone in real time using tcpdump and netcat. The next logical step is of course to directly trace the network traffic on the smartphone. This has the big advantage that it's not only possible to trace the Wi-Fi traffic but also traffic that goes over the cellular interface. I've laid the foundations for this a couple of weeks ago by installing CyanogenMod on my Samsung Galaxy S4. Unfortunately, though, CyanogenMod does not include tcpdump in its standard image.

There are some sources on the net that provide pre-compiled tcpdump executables for Android but since these are not well known I had a hard time trusting them. Not that I think they are not trustworthy but I just don't know them at all. So I had to find a way to get a trusted executable. At first I thought that I could perhaps use a tcpdump executable from one of my Raspberry Pis as they also run on an ARM processor. That would have probably worked if the Raspberry Pi used static linking for it's executables, i.e. bundling all libraries required into the file which is required for Android. Raspian, like most other Linux distributions, I imagine, however, uses dynamic linking with the libraries in separate directories. O.k. so that was not an option.

After doing some more research I came across a 3 piece post over on the Symantec blog (see here, here and here) that explains in detail how to cross compile tcpdump for Android from the original sources on a Debian system. Fortunately I had something close to this, an Ubuntu 12.04 in a virtual machine on which I can easily try things without backing anything by creating a VM snapshot to which I could restore later-on to undo all changes. It turned out that cross-compiling the sources is not very difficult at all as only the original source and the gnu cross compiler. As I was using Ubuntu I had to install additional packages which is not described in the Symantec posts but the error messages are quite straight forward. Also, I had to set 'LDFLAGS=-static' in the tcpdump 'Makefile' as mentioned in the comments to the third part of Symantec's description.

And here's the command to trace the cellular interface once tcpdump is up and running on your Android phone and to save the traffic into a file on the SD card:

tcpdump -n -i rmnet_usb0 -s 65535 -w /storage/sdcard1/trace.pcap

Happy tracing on Android!

I don't mind some advertisement on websites as long as it's not obtrusive. Live and let live. On the desktop that line has long been crossed with major news websites looking more like a Las Vegas casinos than news websites. So I've been using Adblock Plus for many years there already and I'm always shocked when I switch it on and see how the unfiltered web 'really' looks like these days. On the mobile side, ads were somewhat more subtle on the web sites I frequent, at least until recently.

Within a short time, however, the three news websites I visit daily on my mobile have started to push ads into my face with full screen pop-ups or keep showing me the same stupid ad over and over again. Sorry, that's it, you've pushed me over the edge and I had to resort to countermeasures. Adblock Plus is available as well for Android but unless there is no alternative I don't want a proxy in the system.

The alternative is to make use of the 'hosts' file and block ad serving domain names. This requires root access to the device but that's not a problem on CyanogenMod. Also, I've already modified the hosts file to keep apps and the OS from frequently calling home so it was little effort to also include the domain names from which the ads come from.

Actually I'm a bit shocked at how many domains I had to block to get back my peace on three news websites. Here's the list of domains they include in their pages that have nothing to do with the main content:

#Ad blocking
127.0.0.1   ad8.adfarm1.adition.com
127.0.0.1   googleads.g.doubleclick.net
127.0.0.1   stats.g.doubleclick.net
127.0.0.1   mobile.smartadserver.com
127.0.0.1   www.google-analytics.com
127.0.0.1   pagead2.googlesyndication.com
127.0.0.1   ads.stickyadstv.com
127.0.0.1   pixel.rubiconproject.com
127.0.0.1   t1.visualrevenue.com
127.0.0.1   beacon.krxd.net
127.0.0.1   rtb.metrigo.com
127.0.0.1   c.metrigo.com
127.0.0.1   ad.zanox.com
127.0.0.1   cm.g.doubleclick.net
127.0.0.1   ib.adnxs.com
127.0.0.1   ih.adscale.de
127.0.0.1   ad.360yield.com
127.0.0.1   ssp-csynch.smartadserver.com
127.0.0.1   ad.yieldlab.net
127.0.0.1   dis.crieto.com
127.0.0.1   rtb.eanalyzer.de
127.0.0.1   connect.facebook.net
127.0.0.1   platform.twitter.com
127.0.0.1   b.scorecardresearch.com
127.0.0.1   sb.scorecardresearch.com
127.0.0.1   ads.newtentionassets.net
127.0.0.1   ak.sascdn.com
127.0.0.1   fastly.bench.cedexis.com
127.0.0.1   probes.cedexis.com
127.0.0.1   linkedin.com
127.0.0.1   x.ligatus.com
127.0.0.1   d.ligatus.com
127.0.0.1   a.visualrevenue.com
127.0.0.1   radar.cedexis.com
127.0.0.1   www.googletagservices.com
127.0.0.1   pubads.g.doubleclick.net
127.0.0.1   farm.plista.com
127.0.0.1   static.plista.com
127.0.0.1   video.plista.com
127.0.0.1   tag.yoc-adserver.com
127.0.0.1   ads.yahoo.com

Yes, that's from just three news portals. Quite shocking…

Knowing something in theory and experiencing something for real are two different things. I know of course that Android is based on a Linux kernel and shares many things with desktop Linux distributions. But it's all nicely hidden under the Android user interface so the concept felt quite abstract to me, even after using 'adb' for a long time and having experience with Debian running on ARM driven Raspberry Pis and all. But when I recently opened a terminal on the device itself and used the shell like I would use one on a PC with a hardware keyboard, auto command completion and on top of that write shell scripts with my favorite shell based text editor 'nano', e.g. to issue the commands to enable write access of the system partition and start the editor to modify the 'hosts' file, it started to feel quite different. Yes, there's really something under the hood I'm quite familiar with and it 'feels' very good indeed.

I'm quite surprised that pretty much the entire industry these days thinks that Wi-Fi Internet connectivity means that there is free, unlimited and ultra-fast connectivity. As a consequence many smartphones and tables are shamelessly downloading operating system updates and other things small and large without asking the user first.

A 150 MB Android update available!? No problem, there's Wi-Fi so it's downloaded by many devices without asking the user first. Now imagine you are hanging off a hotel Wi-Fi that is slow already or even paid by the megabyte. The former is still the norm rather than the exception while the later is rare these days but it still exists, which is why I would never stay in NH hotels if I can avoid it…

Even worse, you ask a friend in a café if you could tether your Wi-Fi only tablet over his phone to the Internet. He graciously agrees despite only having a contract that includes a few hundred megabytes of data a month. After all, a couple of web pages won't hurt!? Well, these probably won't but the 150 MB OS update starting automatically will. And unless you friend keeps his data counter in sight he probably never knows what hit him until a couple of days later when he hits his monthly data cap.

Therefore, think twice before you open your mobile network connectivity for anyone…

Fortunately CyanogenMod on my Samsung Galaxy S4 gives me root access so I've put the domain name of the update server in the hosts file and point it to localhost. This stops the madness and restores sanity so I will not be surprised by a bulk data download while I'm tethering or staying in a hotel.

Just a few weeks after I could use LTE for the first time while roaming in France I recently found myself in Belgium's capital for the weekend and could again benefit from LTE speeds while roaming. But how fast is it actually and is there a bottleneck on the link to the home network? The later is quite important as all data is tunneled to the PDN-Gatway in the home network and from there to the Internet. As you can see in the image on the left, Mobistar in Belgium and my home network operator have provisioned the link with ample capacity and I could reach speeds of 20 Mbit/s in the downlink direction and 14 Mbit/s in the uplink direction on LTE Band 20 (800 MHz) cell with a 10 MHz carrier in average signal conditions. Not too bad I would say. And the ping delay of 62 ms for a roaming scenario is great as well.

So there we go, somewhere along the way Android lost the radio network type (RAT) indicator over the signal bars when roaming. I wonder if that has something to do with Americans rarely leaving their country? Anyway, the important thing is that Android is open and flexible enough for someone to come up with an app to fix the issue. After looking around bit I chose the "Network Type Indicator" app and as it didn't want any suspicious rights I didn't hesitate to install it. It works as it should and my smartphone again feels as it should when I'm out of the country. It is even better than the original as I can now see the network type much easier when using the device for navigation in the car. Yes, I like to know what kind of network is around me when driving through the countryside…

I like having a good backup strategy and thus have a couple of Clonezilla images of my notebook's SSD. In case my notebook gets lost or stolen I can restore the image on a backup drive, overwrite the data partition with the latest weekly backup and put the result in another notebook and I'm up and running again in no time. The question I had, however, was how close the hardware of the replacement notebook must resemble that of the original hardware for Ubuntu to still be usable.

To find out just that I recently restored a Clonezilla image of the SSD of my PC to a backup drive and installed that in a 4 year old notebook with completely different CPU and graphics hardware and a 6 year Atom based notebook, again with a very different processor, GPU, screen, touchpad and Wi-Fi hardware. That can't possibly work now can it!? Wrong! My Ubuntu 12.04 installation booted and ran perfectly on both systems. Graphics worked, the touchpad worked, the Wi-Fi worked, suspend/resume worked, everything just worked, I could hardly believe it.

Now try that with a Windows installation…