Category: Uncategorized

After my somewhat down to earth mobile network experiences in Beijing I've traveled on to Seoul, Korea and here, network connectivity was just the opposite. Internet hotel access was fast, 3G mobile networks were everywhere, voice quality in calls to Europe was superb and my email and web browsing via the UMTS was again as it should be: Yes, fast. Just around the corner from the hotel were small shops and restaurants that seemed very popular with the local youth. People are stylish and everyone seemed to carry at least two Samsung smartphones with at least one in active use at any time. Many people in restaurants were students working with books and their notebooks, connected to the Internet of course. I've seen a lot when it comes to mobile network usage but this is a new dimension. So obviously I wondered how mobile network operators cover this area!?

I'd say government employees in French libraries complaining about headaches after Wi-Fi access points for visitors were installed would drop dead instantly from self inflicted fear in this area. It seems that everything that does not move has several antennas on top or on the side.  Cables from telephone poles outside seemed to spread out in a big web to the houses nearby in total chaos, Wi-Fi access points are mounted to poles and even to cable loops themselves (picture one on the left). Antennas on seemingly every second rooftop pointed in all directions (second picture on the left) and were almost as plentiful as the Wi-Fi access points at street level.

And then there were those strange antennas at street level everywhere that seemed to be pointed in random directions down alleys, at buildings and many of them seemed to be, well, not quite pointed into the direction anymore as originally intended. The third picture shows a not out of the ordinary example.

I tried to figure out what exactly those antennas are for. Some of them say "KT Wibro" on the side which is descriptive enough but none of those I had a closer look at with my mobile tracer seemed to emit a 3G signal. After I saw those antennas again in other less frequented parts of the city in even more impossible locations I am pretty much convinced they connect to home Wi-Fi routers or are  at the other end of indoor repeaters.

Despite the wired and wireless chaos, it seems to work as my calls got thorough, my Internet worked and probably also for the people glued to the screens of their smartphones in the streets. Stay tuned, in the next post I'll get somewhat more technical with an insight on on cell density, interference and signal strengths in this area.

When it comes to novels and movies that involve computer security, many book authors only have a superficial knowledge and at the point where the thief, agent, etc. uses a 'sophisticated' device that discovers the code for a security system digit by digit I usually switch off in disgust. But there are exceptions such as Mark Russinovich's novels.

Mark is one of the guys behind Sysinternals, bought by Microsoft a couple of years ago and has intimate knowledge Windows and its security architecture. And lately, he's ventured into the domain of writing cybercrime fiction. I first discovered his book "Zero Day" last year when I was in Seattle via a recommendation on the weekly Security Now podcast with Leo Laporte and Steve Gibson. Otherwise I'd probably have never picked up a copy as his name was unfamiliar to me. I read it within a couple of days and was totally addicted as the scenarios were very realistic.

A year later and Mark has come up with a sequel 'Trojan Horse'. This time I read it on a pad instead of picking up a hard cover version and again finished it within a couple of days and didn't sleep enough during that time. He gives even more technical details in this book and the only thing he got wrong from what I can tell is that to get root permissions on an Android phone, it has to be rooted and not jail-broken. The plot is fast paced and believable, the technical details are accurate and frightening but it's good to know that the protagonist needed some help from his friends at the NSA to get certain kind of data (no spoiler here…). In plots of non-tech authors that would probably have been just a few clicks away.

I'm totally hooked and I hope Mark will come up with another sequel. 5-star recommendation!

When it come to networking equipment in fixed and wireless networks, Chinese companies are selling their equipment to the rest of the world and their components can be found in many western countries. When it comes to network operators in their own country and providing connectivity to destinations outside the country, however, there is quite some room for improvement yet.

After a week in Beijing I have to say it was a bit of a sobering network experience. Both in the hotel and during the conference I attended in a different place, connectivity to Europe was good in early morning hours and my VPN tunnel to Germany established just fine. Over time, the connection got slower and slower and at some point, packet loss was so high that the VPN broke down and would not re-establish again. Even wihtout the VPN, data exchange was hardly possible. In other words, the link to Europe was hopelessly underdimensioned. It wasn't the local connectivity, however, as destinations in the US remained usable. When establishing a VPN tunnel to the US and going to Europe from there, the network remained quite usable. Interesting.

My biggest disappointment were the mobile networks in Beijing, however. There is only one (China Unicom) offering WCDMA 3G and due to a configuration error on the network side I could not use it for data. China Mobile is the other carrier usable with GSM/UMTS devices but only with 2G EDGE. Here, however, Internet connectivity to Europe was very slow to unusable, with page load times of even compressed pages by Opera Mini stretching to 30 seconds or more or timing out altogether. Again probably not due to local speeds but due to an underdimensioned backhaul towards Europe.

And finally, mobile voice calls between China and Europe usually had a very bad voice quality and I and other people had voice calls suddenly interrupted in the middle of the call and were connected to a confused Chinese speaker. During a call? Never had that before. Also, incoming calls usually had random calling IDs and type of numbers, national, international, sometimes even three leading 0's. Amazing that companies dare to ask for 3 Euros a minute for such service.

Not that this has to be that way. In other countries in Asia, such problems are non existent. I don't want to be negative here, but there is a lot of room for improvement here. Time to play catch-up in Beijing!

Everyone occasionally flying long-haul has probably experienced it before: The crappy in-flight entertainment system crashes in the middle of a movie and restaring the Windows-CE based system usually takes the better part of half an hour. Once restarted, navigating through the menu structure is still slow but often the movies work again. But it seems Windows is on the retreat here as well and not only in the church. Recently I've flown on a new Airbus that must have just rolled out from the factory in Toulouse. The in-flight entertainment system was behaving snappily to user input but had a little burb as well. A bit of an annoyance but it revealed what it's running on. Fedora (Linux), Apache Web server and pages generated using PHP. Apache 2.0.54 is just 7.5 years old (see here) but it seems to do the job, when it finds the information required, that is. Anyway, an interesting insight.

Now here is another number of ponder on: Once upon a time, back in the 1990's, GSM base stations where connected via 2 MBit/s E-1 backhaul links. With a data rate of 16 kbit/s required for one voice call, 120 simultaneous calls could be transmitted over such a link, minus some channels for control information. At the time, only a fraction was used and a single E-1 was usually daisy-chained to several base stations. Today, I have a 25 MBit/s DSL line to my home for my own use with a 5 MBit/s uplink. Voice has evolved and half-rate AMR now uses 6.75 kbit/s. Just think about the number of voice calls the DSL line I have for my own could transport: 5000 kbit/s / 6.75 kbits/s = 740. Subtract IP overhead, etc. and we should still be at around 500 simultaneous calls over my DSL line. And even if full-rate AMR was used it would still be 250 simultaneous calls over my private DSL line. Incredible how technology has evolved.

I recently reported on a new network study in Germany that  showed once more the significant differences between the four network operators in Germany. So far I thought that one of the main reasons for these differences might be a lower number of cell sites deployed in cities by the lower performing networks. But it turns out that this is not the case.

To verify my assumption, I extended my Cell Logger app available as Android source and executable via a link on this web page and via Google's appstore to not only record cell changes but also the locations where these cell changes happen and the distance from the last cell change. The data can then be put on a map as shown in the picture on the left. I'll shortly release the source and executable of the new version as well, so stay tuned for a follow up post on this.

So with this tool I then took a test drive from Colgone to Bonn which included densly populated areas such as the center of Cologne but also suburban areas and repeated the exercise for all four German networks. The result: To my surprise, all networks have pretty much the same number of cells on that route. In downtown Cologne, there is a cell change about every 300 meters (cell reselection ping pong between up to 5 cells already removed to get the true distance) and in less populated areas around 500 meters on average.

So even the lowest performing network with a significantly lower throughput than the highest performer in the network study linked above have the same number of cell sites. In other words, even the worst performer has the most important asset to improve: Cell site locations.

When always going from one smartphone model to the next it is often difficult to see how things have advanced as the differences are often only subtle. But when comparing devices that are three or four generations apart one can see a real difference. Taking web browsing speed for example between, a two year old Nokia N8 with OperaMIni and a current high end model such as a Samsung Galaxy S-III. When clicking on a link on the N8 it takes a second or two for the new page to show up, even on mobile optimized pages. A good browsing experience, no doubt, but totally shadowed by the web browser's speed on the S-III where the page is displayed almost instantly, even when the radio connection has been in a dormant state to conserve power. This speed-up is really impressive. Now give me world wide offline maps & navigation and a superb camera, two things I like on my N8 and I am ready to move one.

In the past most hotels charged extra for Wi-Fi Internet connectivity and while today some still do there is a growing trend to offer it for free. I wonder, however, what the motive is behind this trend.

More often than not, this "free" Wi-Fi Internet access is shoddy at best and doesn't work at all during busy times, i.e. in the evenings when people come back to their rooms. There are several reasons for this ranging from low signals to under dimensioned backhaul. During daytime, downlink speeds might exceed 10 MBit/s but when testing the uplink I seldom get more than 1 MBit/s. These numbers tell two stories: For one, it shows that no sort of traffic shaping is applied that could help handle the load when many users are online. And second, the uplink is the real problem as it saturates very quickly when the number of users increases taking downlink performance with it. A deadly combination for any network. But even with traffic shaping a 1 MBit/s uplink or even less is just not enough these days, when every hotel guest seems to bring at least 3 Wi-Fi capable devices ranging from notebooks over smartphones to tablets.

So "offering the Wi-Fi for free" is perhaps just the realization that you can't ask for money for something that regularly breaks down. Too much trouble with the guests. So I regularly go back to my 3G connectivity solution which is not free, but it works, at least in those countries with affordable local or roaming rates.

When traveling, I often use VPN tunnels to secure my data transfers e.g. in open Wi-Fi hotspots or to prevent cellular network based transparent "optimization" algorithms from compressing webpages and pictures. There are a number of companies out there that offer gateways around the world and good OpenVPN support. However, one thing I can't do with them is to securely access my resources at home (e.g. my NAS). Also some countries I travel to block access to their public gateways. For both reasons, I long wanted to set up my own OpenVPN Gateway at home. Finally, I had some time to my surprise the necessary hardware, a Linksys WRT-54GL can be had for 38 Euros. An OpenVPN gateway at home for 38 Euros, I call that a good price.

It was a bit tricky to get the gateway up and running though, I spent the better part of three evenings to get things working. Let's count it as part of the adventure. 99% of how to get the gateway up and running can be found in this post on How-To-Geek. One of the best tutorials on how to set-up something complex I have ever seen. Highly recommended. In short it works as follows:

• Get a Linksys WRT54GL router or any other router on which the open source DD-WRT Linux can be installed.

• Install the OpenWRT client, preferably on a Windows machine as the tutorial linked above shows how to do it on this OS, and use the tools that come with the software to generate a number of keys and certificates needed for the OpenVPN server and client. This is the tricky part but the tutorial describes it in detail.

• Copy/paste the required certificates to the OpenVPN router. One point that's not contained in the tutorial is that some of the key and certificate files created contain some explanatory text that must not be copied/pasted into the OpenVPN configuration. If done, the configuration won't be saved in the router.

• Make the OpenVPN server thread start automatically. As I use my DSL router as a gateway to the Internet, a number of configuration steps are required that are not described in the tutorial. As the VPN tunnel uses its own IP address subnet, it is necessary to create a static route to this subnet in the DSL router's IP configuration. Also, the NAT firewall has to be configured to forward UDP port 1194 to the VPN gateway router (I decided not to use TCP as described in the tutorial). And finally, for some strange reason, the OpenVPN server thread does not start automatically in my setup, probably because I don't use the WRR54GL box as an IP gateway with NATing. This can be fixed by adding the following command to the startup commands in the router GUI:

openvpn –config /tmp/openvpn/openvpn.conf –route-up /tmp/openvpn/route-up.sh –down /tmp/openvpn/route-down.sh –daemon

• Disabling Wi-Fi:  As I only want to use the router as a gateway there is no need for the Wi-Fi access point running. Unfortunately, there is no GUI option to disable Wi-Fi and I couldn't come up with a clean solution for it. There is a command to disable the Wi-Fi. However, if executed as a startup command the router ends up in a reboot loop. The kludge that works for me is to run the disable Wi-Fi command as a cron job periodically. Here's the line for the cron job:

*/5 * * * * root wl radio off

• Partial or Full VPN: The VPN tunnel can be used for tunneling only the traffic for the home network or as a full IP tunnel depending on how the client is configured. In full tunnel mode (the tunnel is used as a gateway to the Internet) all traffic is sent over the tunnel into my home network and from there to the Internet. When using the tunnel to encrypt all traffic one additional manual setting required in the client is the DNS server as it's not configured when the tunnel is established. An easy solution is to use Google's DNS server IP address (8.8.8.8). 

• Windows Clients: I got the setup working just fine with Ubuntu 12.04 as a client machine. I also tried Windows 7 and Windows XP but couldn't get the tunnel working. It establishes just fine but no data is flowing through it, not even to server side IP address. Very strange as the tutorial was written for Windows 7. But it's not my primary platform anyway so I grinded my teeth and ignored it for the time being.

Performance wise, the 200 MHz ARM processor in the router has its limits. The processor maxes out at a throughput of around 4.5 MBit/s as shown in the picture above. At this speed, the OpenVPN server thread takes 98% of the CPU time. My current VDSL uplink speed is 5 MBit/s so I am close to the limit. More up to date and more expensive routers that can run DD-WRT will probably do even better as they have much more capable ARM processors and clock rates of 600 MHz and beyond. As not the downlink speed of the DSL or cable connection is the limit but uplink line rate, which is usually much slower, the old low cost WRT54GL router will do just fine for most people.

There we go, infinite possibilities opening up with my new VPN gateway and I learned a lot in the process of making it work.

Most of us don't like change, especially when it comes to computers. Most people like what they have and dread security or feature updates because they could break something that already works. But they are a necessary "evil" because security updates keep us, well, more secure and feature updates in the majority of cases improve computing. I can well remember the days of DOS and there's no way I ever want to go back there so at least some of those at first unloved updates do something good in the long run.

But still, most updates are a pain and I can't remember when I last updated something because I really wanted to. But now I have at least one counter example. Recently, I noticed that the latest version of TightVNC, a remote desktop viewer I've been using for a decade at least was finally integrated to run as a service in Windows 7. What sounds benign at first turns out to be a major productivity increase. Ever since Windows 7 appeared on the computers I remotely administer, I couldn't do some things without human intervention on site as all security confirmation dialog boxes were off limits to user level programs. Very frustrating at times. So now TightVNC runs as a service and I can remotely acknowledge security notifications, I can even reboot and log on from the login screen. I'm ecstatic, finally an update I like! Time for Windows 8 to mess things up again.