WirelessMoves

Just around this time last year I wrote about 3G Roaming in the US with a Local SIM card that could be ordered from abroad before starting the trip. While it worked well, the main drawbacks were finding a mobile that would work on US frequency bands and the 'limitation' to UMTS. Also, the network kept dropping my VPN connection at random intervals. A year later, networks and offers have significantly advanced.

This time, I bought a T-Mobile US Prepaid SIM for Internet connectivity after arrival that would not only let me use their UMTS but also their LTE network. The cost for the SIM card was $15 and options that can be selected online range from $5 per day for 500 MB over $30 for 3GB for 30 days to $50 for 7 GB for 30 days. Not cheap but 'business traveler' affordable. Also, the SIM card is kept active for up to 365 days which is great if some time passes between trips to the US.

Speed wise I could easily reach data rates of 10-15 Mbit/s in downlink and 8 Mbit/s in uplink while my tethering device was camped on LTE band 4 (1700/2100 MHz) on a 10 MHz carrier at the hotel I stayed in Kansas City. I also noticed that another 5 MHz LTE carrier was on-air on band 2 (1900 MHz PCS). Reliability wise the network has also made a great step forward as I didn't notice a single VPN drop over the days.

Another thing that has significantly improved since last year is the availability of mobile devices sold in the EU that support some of the US LTE frequency bands. The iPhone supports a phenomenal 20 LTE bands and other devices, e.g. some from Sony, include support for LTE band 4 that is used by T-Mobile US and others. Here's an example from their German web presence. So if you travel to the US it's worth finding out which LTE bands are supported before you buy it.

All in all, the SIM has served me well and offers like this are another step in the right direction towards global affordable and fast Internet access.

Recently the FCC made it crystal clear that Deassociation Attacks by hotel Wi-Fi installations to force their 'guests' using the hotel's Wi-Fi instead of tethering their equipment to their smartphones and tablets is illegal. That only applies to the US, of course, and despite it being a very effective move to aggravate customers it doesn't mean nobody else will be trying to use it in the future. But it turns out, there's an effective countermeasure against this, at least in the foreseeable future.

The attack vector used by such Wi-Fi installations is to send De-association management frames to devices connected to a hotspot other than that of a local venue. Unlike data frames which are encrypted and thus can't be forged, Wi-Fi management frames are sent in the clear and can thus be sent by anyone. To mitigate rogue de-associations and other attack vectors the 802.11w amendment to the Wi-Fi standard describes a way to also protect management frames which effectively counters such attacks.

There are many amendments to the Wi-Fi standards that have never been implemented and for a long time it looked like this was yet another one. But since July 2014 the Wi-Fi Association requires implementation of the protected management frames amendment in its Wi-Fi certification scheme when a device supports 802.11ac, the latest super high speed transmission mode as reported here, here and here. That's good news as this certification is required for the Wi-Fi logo on the sales packaging and as a precondition by many companies (such as mobile network operators) to sell a Wi-Fi capable device. Also, a growing number of access points and devices such as notebooks, smartphones and tablets support 802.11ac today and even more will do so in the future.

I ran a quick trace of all access points in the neighborhood but didn't find any indication of the feature being supported in their beacon frames. As described here in detail and shown in the screenshot on the left there are two bits towards the end of the beacon frame that indicate to devices whether PMF (protected management frames) are supported or not. These indicator bits are also sent by devices during connection establishment so it's easy to find out if a device supports PMF. One source claimed that the Samsung S5 already supported it but when I traced the connection establishment both bits were set to 0. So at least my S5 does not or doesn't want to indicate this capability to an access point that itself doesn't support it. The result is perhaps a bit disappointing but not really surprising as the new rule just came into effect half a year ago. So I will have to get hold of devices certified after that date. I'll keep you posted.

The article linked above remarks that PMF counters all management frame attacks observed so far. One thing it can't protect against are attacks with Ready To Send / Clear To Send frames that include long reservation times for transmissions (up to 32 milliseconds). The good thing is, however, that such frames are not network specific and thus would not only slow down an attacked network but also the hotel Wi-Fi itself on the same channel. In other words this is no caveat for hotels that have a special treat for their customers…

It's standard practice for mobiles for many years now to implement GPRS to 3G reselection during data transfers. It might sound like a small and unimportant feature but in mobility scenarios it's very important when a subscriber losses 3G coverage during a data transfer and drops down to 2G. Without this feature the device would be stuck on the very slow 2G layer until the data transfer has finished. Quite to my surprise the same feature for LTE has only become available in mobile devices in the last year or so. My Galaxy S4 can still get stuck on 2G during data transfers or when I use it for tethering on the train and kind of 'rescues itself' to 3G rather than going back to LTE when both networks become available again. But on newer devices I have noticed that they now have the ability to also search for LTE during 2G transmission gaps and go back to LTE. That makes a real differences especially in areas where only 2G and LTE is available. In Germany that is the case in a lot of rural areas. A small feature but a big benefit to the traveling user. What's still outstanding, however, is 3G to LTE redirection/handover.

While it very rarely happens where I tend to go but still every now and then there are roads and paths I take that are not in Openstreetmap. To my pleasure I recently discovered how easy it is to add them to the OSM database with the Openstreetmap for Android (OSM) GPX plugin.

The pictures below show how it's done. First, activate "Record your trips" in the Osmand 'Plugins' settings. Afterward a "GPX" button is shown in the map on the right hand side that can be tapped-on. Once tapped-on, the path that is recorded is shown in turquoise color on the map and the GPX button is replaced by the distance to the location where the GPX recording was started. To stop the recording, a tap on the distance indicator brings up a pop-up menu from which "save" can be selected (the third option in the pop-up menu, don't mix it up with 'stop' which doesn't save anything). The resulting GPX file is put into the Osmand folder in internal storage or on the SD card.

Once the GPX file is on a PC it can simply be dropped on the Openstreetmap web site after 'editing' mode has been activated. As can be seen on the last screenshot the my GPX track is exactly on the railway track of the train I was sitting in when I took the GPX recording.

VoLTE certainly is an 'interesting' beast and continues to occupy the minds of thousands of engineers to make it work in networks around the globe. I wonder how this monumental effort stacks up against other VoIP services such as Facetime, Skype and others that are centrally managed!? That probably costs a lot less money and they are already up and running for many years now. So far I've seen one major advantage of VoLTE over other voice over IP service on mobile devices: It can do a fallback to 2G and 3G circuit switched channels once you run out of LTE network coverage.

Recently, another advantage came to my mind: Instead of globally managed from a single country there are several independent VoLTE systems in each country. While that creates all sorts of problematic disadvantages, the advantage of such a distributed system is that there is no single point of failure and no single point of control and interception. So if somebody wants to spy on VoLTE installations they have to make the extra effort to break into each and every system independently. Not that I think that this is beyond the capabilities both in terms of knowledge and man power of some organizations but it's a lot harder to do and a lot more difficult to conceal.

Not that VoLTE is an end to end encrypted system but at least it makes it a more local problem.

In part 3 on my series on OpenStreeMap let's have a closer look at Openstreemap for Android, or OSMAND for short. OSMAND is open source and hosted over at Github. Apart from the great navigation system it has been for me over the years (see point 8 here) it also serves me pretty well when searching for 'points of interest' (POI) such as supermarkets, nearby restaurants, etc. when I'm traveling.

What I didn't notice so far, however, is that POIs can also be shown in the map instead of just being searched for. The first screenshot on the left shows the default map, the second shows how the map looks like when all types of POIs are displayed and the third screenshot shows the left 'swipe-in' menu from which the display of POIs can be enabled. In my examples all types of POIs are shown but the menu also offers a list from which a subset can be selected, e.g. only restaurants and supermarkets. When touching one of the orange POIs, additional information is presented such as the name of the restaurant and, if available, other information such as opening hours, URL of the web site, phone number, etc. All very useful.

For those of you who would like to add, modify or delete POIs that are no longer there, OSMAND offers the option to do just that while one is on site. To add additional information to a POI, a long press brings up an edit menu. Editing POIs requires an Openstreetmap account and to configure the log-in credentials in the OSMAND settings on the device. The only quirck is that changes are not immediately visible on the map as it is an offline copy. Changes are uploaded immediately, however, and can be seen after a few minutes on the main OSM web site. It takes a couple of days for them to appear in the next update for the downloadable maps, however. Still, very useful, too.

I was recently asked by a colleague if a mobile device keeps its PDP context with the UMTS network or the Default Bearer with the LTE network when it goes to Wifi. In the past the question was easily answered but today there are a number of different scenarios. As I'm sure that I will be asked again in the future I decided to write down a note here for easy reference.

Let's start with UMTS to Wi-Fi. Most devices on the market today deactivate the PDP context once a connection with a Wi-Fi network has been established. In practice this means that the IP address goes away and a new one is assigned when the device establishes a new PDP context again. You can easily check this as follows: While connected to UMTS go to a web pages such as "whatismyip.com" to find out your current IP address. Then switch to Wi-Fi, reload the page and you will see a different IP address. Once done, disable Wi-Fi again, wait until 3G connectivity has been reestablished and again reload the page. Again the IP address has changed. While this behavior can be observed with most smartphones and tablets, some keep the PDP context when changing to Wi-Fi so the IP address that was assigned before switching to Wi-Fi is shown again after disabling it again.

With LTE things are different in most mobile networks. Unlike UMTS that could live with a device not having a PDP context due to its dual circuit switched / packet switched nature, LTE requires a device to always have a default bearer, i.e. an IP address. Even if data connectivity is disabled in the menu or Wi-Fi is used the device keeps the IP address in the baseband chip for future use. Again, this can be easily verified with reloading pages such as "whatismyip.com" after changing networks. Some networks however, assign two default bearers for various reasons. In such cases the second default bearer is usually used for Internet connectivity. In such a configuration the second default bearer is disconnected when switching to Wi-Fi so one will observe different IP addresses before and after using a Wi-Fi network.

Not as straight forward anymore than it used to be.

This is part 2 of my post series on Openstreetmap. Before having had a closer look I always assumed that Openstreetmap was something similar like Google maps, just open, free (as in freedom) and not as privacy invading. While this is true, I was quite amazed to find out that the structure of the project is quite unlike that of commercial map services.

Let's have a look at Google maps and other popular map services first. These are usually integrated products, i.e. Google owns the program, the render the map, they own the database behind the maps and the information where shops, hotels etc. that are are put into the map.

Openstreetmap on the other hand first and foremost is only one thing: A database. Yes, when you go to Openstreetmap.org you can see a map and do great things with it. But it's not as versatile as Google maps and others, perhaps, despite the routing capabilities that were recently added. And that's not it's intention anyway, it's sort of a technology demonstrator for the database. The applications that run on the Openstreetmap database are not developed by Openstreetmap, they are done by third parties. Openstreetmaps for Android (OSMAND) is a good example, it's not done by the entity known as Openstreetmaps. And Osmand is just one of many programs using the OSM database. OSM describes this in more detail in their FAQ so have a look here if you want to dig deeper.

And here's a link to a very long list of OSM-based services and a link to Android Apps that use OSM data of which OSMAND is just one. Lots of interesting stuff to discover there!

Not being a fan of being tracked online, especially not location wise, I've been using OpenStreetMap (OSM) and OSM for Android (OSMAND) a lot over the years. I've grown especially fond of OSMAND as it enables navigation with offline maps and both the program and the map data is open source and open data respectively. There are some things, however that others could do better on the PC, so I still had to resort to Google Maps if I wanted to get a first idea how a route could look like or to find out the distance between two locations. I don't use a Google account, my browser forgets Google's cookies whenever I close it and I regularly get a new IP address so privacy is more or less still retained. Nevertheless I would always have preferred an open solution. So you probably understand my joy when OpenStreetMap recently announced that they have integrated routing on their main page. Look for the arrow icon next to the "go" button. It's not a new feature, I take it that it's been available for quite some time on Open Source Routing Machine but I have to admit I didn't know until recently.

Actually there is a lot of stuff I didn't know about OSM and OSMAND and after watching the recording of the OSM presentation at 31C3 (in German only…) I had a closer look and found lots of amazing things that I have since made good use of. That's why I titled this post "part 1" and I will write down some notes about other topics such as editing the map via OSMAND and on the desktop, adding features, services that use OSM, etc. in a couple of follow-ups.