8-day motorbike round-trip in Taiwan

I always wanted to do this during the years I spent more time in Taiwan (the good old Openmoko days in 2007/2008), but of course never found the time back then. This year, I finally manged to do it: A motorbike ride around the island.

To be more honest: It was not literally around the island on the coast line, as I find the west coast not very attractive for a leisure ride: It is quite densely populated and has lots of industry. I also skipped the north coast north of Taipei city, as I've been there so many times before. So in fact, it is a trip from Taipei along the east coast all the way down south, and returning back north towards Taipei on the western side of the mountains.

You can see (a smplified version) of the GPS track via Google maps or also via OpenLayers/Openstreetmap.

My biggest doubt in the past was whether I would be able to find accomodation 'on the go', given my very minimal mandarin language skills. If you don't know the road conditions, weather, etc. it is hard to plan all the stops in advance. Also, given that typhoon or earthquake induced landslides or rockslides are quite common in the mountains, advance planning is not the preferred option.

However, given the quite universal mobile wireless data coverage and a smartphone, I was able to always book the next accomodation (1 day in advance) using popular booking websites such as agoda.com or booking.com. This worked quite good, except in the rare case where those websites get the address/location of the hotel/homestay completely wrong.

Regarding the trip itself:
  • Day 1: Taipei to Hualien

    I don't even remember how often I have taken provincial highway 9 from Xindian (south of downtown Taipei) through the mountains to Yilan before. It must be the road that I travelled most frequently. What was different this time is that the departure was on a weekend, so there were literally hundreds of motorbike riders on the track. Also, interestingly, in virtually every curve there was at least one photographer taking pictures of the motorbikers.

    (Side note: I usually avoid leaving the hotel/apartment over the weekend, as Taiwan is simply to crowded. Doing any kind of travel, sightseeing or even going out for dinner is almost bound for a disappointment on saturday or sunday).

    Having travelled 'number 9' many times still doesn't make it a less interesting mountain ride, with plenty of serpentines and marvellous views, particularly when you can first see the coastline from high up in the mountains. I'm also quite familiar with the coastal provincial highway 8 down to the entry of Taroko Gorge, along the steep cliffs, passing the various industrial harbours and cement factories as well as the numerouns tunnels along the road.

    The remaining kilometers down from Taroko towards Hualien go much faster than anticipated, as it is suddenly quite flat terrain and a wide (two lane per direction) road that permits 60/70kph. The latter doesn't sound like much, but it is a lot, compared to the 30/40kph limits in the mountain roads.

    Accomdoation at a hotel inside Hualien city. Nice and clean room, close to the shore. However, difficult to actually get to the shore as a pedestrian, and aside from concrete bricks (to break the waves) there's really not anything. No natural coastline, no rock or sand beach, nothing.

    What was worth noticing where two anglers who were actually using a quadrocopter to take their hooks/bait way further off the shore than you would be able to achieve with manual casting of the fishing rod. I have no insight into current angling practises. To mee it seemed quite high-tech / nerdy / sophisticated ;)

  • Day 2: Hualien to Taitung County

    Accomdoation at Lehuo Shoudo Moli Homestay

  • Day 3: Staying in Taitung County

    We actually liked the location (and the "private beach") so much that we decided to stay for an extra night.

    Accomdoation at Lehuo Shoudo Moli Homestay

  • Day 4: Taitung to Kenting

    Accomdoation at Miami Hostel

  • Day 5: Kenting to Pingtung

  • Day 6: Pingtung to Chiayi

    Accomdoation at Tea Homestay

  • Day 7: Chiayi via Alishan and Yushan and Sun Moon Lake to Taichung

    Accomdoation at Sky Villa

  • Day 8: Taichung to Taipei

Another patch submit day.

Today I've submitted hashlimit, CLUSTERIP and CONNMARK to the 2.6.x kernel. After resolving some glitches with CLUSTERIP, DaveM took all three :)

This means we're again one step further submitting stuff from patch-o-matic into mainline, which is always a good thing.

Problems with OpenVPN on high-latency satellite links

So far I never had a need to look in detail how the OpenVPN protocol actually looks on the wire. It seems like not many people had that much of a close look, as the wireshark plugin is fairly recent (from 2012 I think) while OpenVPN is around for ten more years than that. If I was an OpenVPN developer, the wireshark plugin would be the first thing I'd write to help debugging and development. At least that's what I've been doing from OpenPCD to SIMtrace and through the various GSM and other protocols I encounter...

The reason for my current investigation is some quite strange and yet-unexplained problems when running OpenVPN on high-latency satellite links. I'm not talking about high-bandwidth VSAT or systems with dedicated / guaranteed bandwidth. The links I'm seeing often have RTT (as seen by ICMP echo) of 2 seconds, sometimes even 5. This is of course not only the satellite link, but includes queuing on the ground, possibly the space segment and of course the terminal, including (possibly) access arbitration.

What struck me _very_ odd is that OpenVPN is sending tons of UDP messages with ridiculously small size during the TLS handshake when bringing up the tunnel. Further investigation shows that they actually internally configure a MTU of '0' for the link, which seems to be capped at 100 bytes control payload, plus HMAC and OpenVPN header resulting in 124 to 138 bytes UDP payload.

Now you have to consider that the server certificate (possibly including even a CA certificate) can be quite large, plus all the gazillions of TLS handshaking options in ServerHello, the first message from server to client. This means that OpenVPN transmits that ServerHello in something like 40 to 60 fragments of 100 bytes each! And each of the fragments will have to be acknowledged by the remote end, leading 80 to 120 UDP/IP packets _only_ for the delivery of the TLS ServerHello.

Then you start reviewing the hundreds of OpenVPN configuration options, many of them related to MTU, MSS, fragmentation, etc. There is none for that insanely small default of 100 bytes for control packets during hand-shake. I even read through the related source code, only to find that indeed this behavior seems hard-coded. Some time later I had written a patch to add this option, thanks to Free Software. It seems to work on client and server and brings the ClientHello down to much smaller 4-6 messages.

The fun continues when you see that the timeout for re-transmitting fragments that have not been ACKed yet is 2 seconds. At my satellite RTT times this of course leads to lots of unneeded re-transmissions, simply because the ACK hasn't made its way back to the sender of the original message yet. Luckily there's a configuration option for that.

After the patch and changing that option, the protocol trace looks much more sane. However, I still have problems establishing a tunnel in a number of cases. For some odd reason, the last fragment of the ServerHello is not acknowledged by the client, no matter whether patched or unpatched OpenVPN is being used. I get acknowledgements always only up to fragment N-1 after having transmitted N. That last fragment is then re-transmitted by the server with exponential back-off, and finally some 60 seconds later the server gives up as the TLS handshake didn't finish within that time. Extending the TLS handshake timeout to 120 seconds also doesn't help.

I'm not quite sure why something like 39 out of 39 fragments all get delivered reliably and acknowledged, but always the last fragment (40) doesn't make it to the remote side. That's certainly not random packet loss, but a very deterministic one. Let's see if I can still manage to find out what that might be...

Attending HITCON and COSCUP in Taipei

It is my pleasure to attend the HITCON 2013 and COSCUP 2013 conferences in July/August this year. They are both in Taipei. HITCON is a hacker/security event, while COSCUP is a pure Free/Open Source Software conference.

At both events I will be speaking at the growing list of GSM related tools that are available these days, like OpenBSC, OsmcoomBB, SIMtrace, OsmoSGSN, OsmoBTS, OsmoSDR, etc. As they are both FOSS projects and useful in a security context, this fits well within the scope of both events.

Given that I'm going to be back to Taiwan, I'm looking very much forward to meeting old friends and former colleagues from my Openmoko days in Taipei. God, do I miss those days. While terribly stressful, they still are the most exciting days of my career so far.

And yes, I'm also going to use the opportunity for a continuation of my motorbike riding in this beautiful country.

Rest In Peace, Atul Chitnis

Today, very sad news has reached me: Atul Chitnis has passed away. Most people outside of India will most likely not recognize the name: He has been instrumental in pioneering the BBS community in India, and the founder and leader of the Linux Bangalore and later FOSS.in conferences, held annually in Bangalore.

I myself first met Atul about ten years ago, and had the honor of being invited to speak at many of the conferences he was involved in. Besides that professional connection, we became friends. The warmth and affection with which I was accepted by him and his family during my many trips to Bangalore is without comparison. I was treated and accepted like a family member, despite just being this random free software hacker from Germany who is always way too busy to return the amount of kindness.

Despite the 17 year age difference, there was a connection between the two of us. Not just the mutual respect for each others' work, but something else. It might have been partially due to his German roots. It might have been the similarities in our journey through technology. We both started out in the BBS community with analog modems, we both started to write DOS software in the past, before turning to Linux. We both became heavily involved in mobile technology around the same time: He during his work at Geodesic, I working for Openmoko. Only in recent years his indulgence in Apple products was slightly irritating ;)

Only five weeks ago I had visited Atul. Given the state of his health, it was clear that this might very well be the last time that we meet each other. I'm sad that this now actually turned out to become the thruth. It would have been great to meet again at the end of the year (the typical FOSS.in schedule).

My heartfelt condolences to his family. Particularly to his wonderful wife Shubha, his daughther Anjali, his mother and brother. [who I'm only not calling by their name in this post as they deserve some privacy and their Identities is not listed on Atuls wikipedia page].

Atul was 51 years old. Way too young to die. Yet, he has managed to created a legacy that will extend long beyond his life. He profoundly influenced generations of technology enthusiasts in India and beyond.

Hardware outage affectiong osmocom.org, deDECTed.org, gpl-violations.org

As usual, murphy's law dictates that problems will occur at the worst possible moment. One of my servers in the data center died on March 20, and it was the machine which hosts the majority of the free software projects that I've created or am involved in. From people.netfilter.org to OpenPCD and OpenEZX to gpl-violations.org and virtually all osmocom.org sites and services.

Recovery was slow as there is no hot spare and none of my other machines in the data center have backplanes for the old SCA-80 hard disks that are in use by that particular machine. So we had to send the disks to Berlin, wait until I'm back there, and then manually rsync everything over to a different box in the data center.

To my big surprise, not many complaints reached me (and yes, my personal and/or business e-mail was not affected in any way)

Recovery is complete now, and I'm looking forward to things getting back to normal soon.

OsmoDevCon 2013 preparation update

OsmoDevCon 2013 is getting closer every day, and I'm very much looking forward to meet the fellow developers of the various Osmcoom sub-projects. Organization-wise, the catering has now been sorted out, and Holger has managed to get a test license for two ARFCN from the regulatory body without any trouble.

This means that we're more or less all set. The key needs to be picked up from IN-Berlin, and we need to bring some extra extension cords, ethernet switch, power cords and other gear, but that's really only very minor tasks.

There's not as much formal schedule as we used to have last year, which is good as I hope it means we can focus on getting actual work done, as opposed to spending most of the time updating one another about our respective work and progress.

Update on what I've been doing

For the better part of a year, this blog has failed to provide you with a lot of updates what I've been doing. This is somewhat relate to a shift from doing freelance work on mainline / FOSS projects like the Linux kernel.

In April 2011, Holger and I started a new company here in Berlin (sysmocom - systems for mobile communications GmbH). This company, among other things, attempts to provide products and services surrounding the various mobile communications related FOSS projects, particularly OpenBSC, OsmoSGSN, OpenGGSN, but also OsmocomBB, and now also OsmoBTS + OsmoPCU, two integral components of our own BTS product called sysmoBTS.

Aside from the usual software development, this entails a variety of other tasks, technical and non-technical. First of all, I did more electrical engineering than I did in the years since Openmoko. And even there, I was only leading the hardware architecture, and didn't actually have to capture schematics or route PCBs myself. So now there are some general-purpose and some customer-specific circuits that had to be done. I really enjoy that work, sometimes even more than software development. Particularly the early/initial design phase can be quite exciting. Selecting components, figuring out how to interconnect them, whether you can fit all of them together in the given amount of GPIOs and other resource of your main CPU, etc. But then even the hand-soldering the first couple of boards is fun, too.

Of all the things I so far had least exposure to is casing and mechanical issues. Luckily we have a contractor working on that for us, but still there are all kinds of issues that can go wrong, where unpopulated PCB footprints can suddenly make contact with a case, or all kinds of issues related to manufacturing tolerances. Another topic is packaging. After all, you want the products to end up in the hands of the customer in a neat, proper and form-fitting package.

On the other hand, there is a lot of administrative work. Sourcing components can sometimes be a PITA, particularly if even distributors like Digikey conspire against you and don't even carry those low quantities of a component that we need for our 100-board low quantity runs. EMC and other measurements for CE approval are a fun topic, too. I've never been involved personally in those, and it has been an interesting venture. Luckily, at least for sysmoBTS, things are looking quite promising now. Customs paperwork, Import/Export related buerocracy (both in Germany as well as other countries) always have new surprises, despite me having experience in dealing with customs for more than 10 years now.

Also significant amount of time is spent on evaluating suppliers and their products, e.g. items like SIM/USIM cards, cavity duplexers, antennas, cables, adapters, power amplifiers and other RF related accessories for our products.

The thing that really caught me off-guard are the German laws on inventory accounting. Basically there is no threshold for low-quantity goods, so as a company on capital (GmbH/AG) you have to account for each and every fscking SMD resistor or capacitor. And then you don't only have to count all those parts, but also put a value at them. Depending on the type of item, you have to use either the purchasing price, or the current market price if you were to buy it again, or the price you expect to sell the item for. Furthermore, the trade law requirements on inventory accounting are different than the tax laws, not often with contradictory aims ;)

In the end it seems the best possible strategy is to put a lot of the low-value inventory into the garbage bin before the end of the financial year, as the value of the product (e.g. 130 SMD resistors in 0402 worth fractions of cents) is so much lower than the cost of counting it. Now that's of course an environmental sin, especially if you consider lots and lots of small and medium-sized companies ending up at that conclusion :(

So all in all, this should give you somewhat of an explanation why there might have been less activity on this blog about exciting technical things. On the one hand, they might relate to customer related projects which are of confidential nature. On the other hand, they might simply be boring things like dealing with transport damage of cavity duplexers from china, or with FedEx billing customs/import fees to the wrong address...

Overall I still have the feeling that I was writing a decent amount of code in 2012 - although there can never be enough :) Most of it was probably either related to OsmoBTS, OpenBSC/OsmoNITB or the various Erlang SS7/TCAP/MAP related projects. The list of more community-oriented projects with long TODO lists is growing, though. I'd like to work on SIMtrace MITM / card emulation support, the CC32RS512 based smartcard OS, libosmosim (there's a first branch in libosmocore.git). Let's hope I can find a bit more time for that kind of stuff this year. You should never give up hope, they say ;)

Back from FOSDEM 2013

As (almost) every year, I attended the annual incarnation of FOSDEM. It is undoubtedly (one of?) the most remarkable events about Free Software in existence. No registration, no fees, 24 tracks in parallel, an estimated 5000 number of attendees. I also like that it brings together people from so many different communities, not _just_ the Linux or Gnome or KDE or Telephony or Legal people, but a good mixture of everything.

I have to congratulate the organizers, who manage to pull this off, year after year again. And as opposed to many other events, they do so quietly and without much recognition, I feel. I'd also like to thank the many volunteers working tirelessly before, at and after the event. Last, but not least, I'd like to thank the local university (ULB Solbosch) hosting the event.

What made me truly sad though, is the amount of littering that surprisingly many of the attendees did. This was particularly visible in the Cafeteria. Imagine an event run by volunteers, who put in a lot of time and effort. Imagine an event where food and drinks are sold by volunteers at such low prices that there can barely be any profit at all. And then imagine people eating there and leaving all their rubbish around, as if they were in some kind of restaurant where they are being served and where somebody is cleaning up after them. It really makes me feel very bitter to see this. Don't people realize that those very volunteers who are creating the event will then have to put in _their_ spare time just because those who just enjoyed their coffee or lunch didn't have the extra 30 seconds of bringing their trash to the trashcan? I feel ashamed for members of our community who behave this way. Please think next time before acting and show your respect to the people behind FOSDEM.

Talk Idea: How to write code to make later enforcement easy

During FOSDEM 2013, I spoke with some fellow Free Software developers about how my knowledge on copyright and specifically legal aspects of software copyright has influenced the way how I write code, and particularly how I design architecture of programs.

This made me realize that this would probably make a quite interesting talk at Free Software conferences: How to architect and write code in order to make later [GPL] enforcement easy.

Of course there are all the general and mostly well-known rules like keeping track of who owns which part of the copyright, having proper copyright claims and license headers, etc.

But I'm more thinking in the sense of: How do I write code in a way to make sure people extending it in some way with their own code will be forced to create a derivative work. If that is the case, they will have absolutely no choice but to also license that under GPL.

This is particularly important in the case of GPL licensed libraries. The common understanding in the community is that writing an executable program against a GPL licensed library will constitute a derivative work and thus the main program must be licensed under the GPL, if it is ever distributed.

However, in reality there is of course no precedent, and in some particular cases, the legal framework, depending on the jurisdiction, might come to different conclusions if it ever ended up in court. The claim of a 'derivative work' would be particularly weak if the main program is only using a set of standard function calls whose function declarations are the same in many versions of the GPL licensed library you link against. So let's assume there was a GPL licensed standard C library for stuff like open(), close(), printf() and the like. I think it would be very difficult to argue in court that a program written against those functions and linked against such a library would constitute a derivative work of the library. As in fact, there are many other implementations providing the exact same interface, under different licenses, and the API was not even drafted by the author of the GPL licensed implementation.

So I think there are some things that an author of an (intentionally) GPL licensed library can do while writing the code, which will later help him to establish that an executable program is a derived work.

The same is true to some extent for executable programs, too. I very intentionally did not introduce a plug-in interface for BTS drivers in OpenBSC, even though while technically it would have been possible. I _want_ somebody who adds code for a different BTS to touch the main code of the program instead of just writing an external plugin. The mere fact that he has to edit the main program in order to add a new BTS driver indicates that he is creating a derivative work.

So I'll probably try to submit a talk on this topic to some upcoming conference[s]. If you think this is an interesting topic and want me to talk about it at a FOSS related event, please feel free to send me an e-mail.

Why I hate phone calls so much

The fact that I have more than 20 missed phone calls on my land line telephone after only half a day has passed triggers me to write this blog post.

It is simply impossible to get any productive work done if there are synchronous interruptions. If I'm doing any even remotely complex task such as analyzing code, designing electronics or whatever else, then the interruption of the flow of thoughts, and the context switch to whatever the phone call might be about is costing me an insurmountable amount of my productive efficiency. I doubt that I am the only one having that feeling / experience.

So why on earth does everybody think they are entitled to interrupt my work at any given point in time they desire? Why do they think whatever issue they have rectifies an immediate interruption in what I am doing? To me, an unscheduled phone call almost always feels like an insult. It is a severe intrusion into my work-flow, and has a very high cost to me in terms of loss of productivity.

Sure, there are exceptional absolute emergencies (like, a medical emergency of a family member). But just about anything else can be put in an e-mail, which I can respond to at a time of my choosing, i.e. at a time I am not deeply buried into some other task that requires expensive context switching and the associated loss of productivity. And yes, a response might be the same day, some days later, or even a week or more later. There are literally hundreds of mails of dozens of people that need to be responded to. I can never even remotely answer all of them in a timely manner, even if I'm working 12-14 hours a day up to 7 days a week.

Right now I'm doing the only reasonable thing that is left: Switch off all phones. And to anyone out there intending to contact me: Please think twice before calling me on the phone. Almost anything can be put in an e-mail. And if you really want to have a phone call, please request a scheduled phone call in an e-mail containing a very detailed agenda and explanation of the topic.

Strain of bad luck

From roughly September to December 2012 I seem to have had a quite unusual strain of bad luck and set-backs. I don't want to go into the details here, as most of the issues are of quite private nature.

This has kept me quite distracted from a lot of my other activity. Projects like the various Osmocom sub-projects, gpl-violations.org are in desperate need of attention, and I have severely neglected my responsibilities in the Chaos Computer Club Berlin e.V. :(

I don't even want to talk about actual paid work, where customers also had to put up with repeated schedule slips and lack of availability.

I let down friends and colleagues at a number of occasions, as I was unable to keep up with anything that remotely resembles my typical work schedule.

Last but not least, I regrettably have also not felt much of an urge to write many blog posts here.

My sincere hope and expectation is that things are going to improve quickly in 2013. At least most of issues from the last half year have been resolved. Now I need to work through a considerable back-log of work and find more time for my volunteer projects in the FOSS and hacker worlds. However, this will need some time and I would like to ask for some patience. I do intend to be up to speed with things just like before.

In this spirit, I am looking forward to a productive and exciting 2013. Happy hacking und Viel Spass am Gerät

29C3. The end of an era?

When I first heard that the annual CCC congress was moved to Hamburg, my immediate reaction was: Fine, but I wouldn't want to be involved in it. For the last 15 years I've been attending the CCC congress every year, in most years as a speaker, and in many years in some (small) contributing role, first in the team doing the video recordings, and in the last couple of years setting up a GSM network. Contributing to an event is easy if your home/lab is within 20minutes, so if you need another strange cable/adapter/tool/whatever, you can just go and grab it. Doing that at an event that's multiple hours of driving away, in a new/unknown venue is an entirely different story. I have more than enough stress already with (paid) work and the various FOSS projects that I'm leading or involved in.

I have no interest in "just" attending the event. That never was a primary reason for me. In all those years, I've probably attended an average of one talk each year. The event for me was about being able to contribute something actively.

Now, months after those thoughts and my decision not to attend, there is a schedule for the 29C3 available. And to say the least, I am shocked. The entire event seems to have turned into a SIGINT, rather than an xxC3. Lots of talks on politics and society, and lots of German talks.

The debate on implications of technology on society, culture, politics, etc. is an important debate, there is no doubt. And so far I always had the feeling that the xxC3 had a pretty good balance between hard-core technical talks and those non-technical talks. But if I look at the schedule this year, it really looks like an incarnation of the SIGINT conference. With too many German talks you are scaring off the international community. And with focussing on non technical topics, you scare away the die-hard technical hackers. So why move to a larger venue, if you at the same time seem to limit the scope of the event?

Meanwhile I have heard of a number of friends and colleagues who seem to share this view. A number of people who have attended in previous years are not interested in attending this year due to the issues mentioned above.

It's sad to see, but I somehow have the feeling that 29C3 might be the end of an era. The end of a highly successful series of events with exceptionally strong technical talks. To me, xxC3 has always been unique and special. No other event would ever compare to it. Who will fill the gap for the die-hard technical topics? I am feeling quite sad, up to the point that I want to start mourning about "the good old times".

I'm not writing this to put blame on anyone. It just reflects my personal and highly subjective view. Let's see what people will say after 29C3 has actually happened. Let's see how successful it is in terms of number of attendees, and in terms of feedback from participants. I'd like to explicitly thank the many organizers and volunteers (a lot of whom I know in person) for putting up their time and energy to make 29C3 happen.

Inside a cavity duplexer

In many cellular systems (GSM or otherwise) there is a frequency duplex between the uplink and downlink frequency band. If you use a single antenna to serve a BTS, then somehow you need to split the frequency band between the Rx and Tx side by means of a Duplexer.

The most common technology for this is the so-called Cavity Duplexer. I've used those devices (and seen them in use) for a long time, but never really opened one so far. The problem is that they are finely tuned, and each mechanical change can severely impact performance. As I had to repair a broken SMA socket on one of them recently, I took the chance to take a picture

In the first picture you can see the bottom side. This consists of a milled aluminum block, with a series of circular cavities. The Tx output of the BTS is connected to the SMA socket on the bottom right, the antenna to the SMA socket on the top side, and the Rx port to the SMA socket on the bottom left of the picture:

The small cylindrical objects in the center of the cavities are not milled from the same part, but they are separate pieces mounted by screws from the bottom of the unit.

The second picture shows the top section of the duplexer:

You can see a ~ 4mm aluminum plate with lots of (now empty) holes which are for the ~ 117 screws with which the top plate is screwed against the bottom part shown in the first picture.

The important part, however, are the screws that you can see sticking out of the top part. Those are used for tuning and present "obstacles" in the path of the waves as they pass through the cavities.

The big miracle for me is not that there are some resonances which build up a filter, but that you can actually transfer as much as 100W of RF power from the Tx input through to the antenna output.

Short report on the first Osmocom User Group meeting in Bavaria

It's already one week in the past, but I'm only now finding some time to report on the first Osmocom User Group meeting in Bavaria.

All-in-all, there were 6 people attending, some people already known in the community, but also two completely new faces, which is great.

Dieter gave us a tour of his large BTS equipment, including a Nokia Ultrasite and an Ericsson RBS 2206. We had an introduction round where the participants could get to know each other a bit. Finally, we spoke about a variety of topics, from OsmocomBB to SIMtrace, SIM/SAT/STK security, the CC32RS512 and of course OpenBSC and the sysmoBTS.

On the day after the meeting I also had the pleasure of attempting to get the RBS2206 working with OpenBSC. Unfortunately there was no success, but still a number of bugs in the OM2000 / RBS2000 code in OpenBSC that had been found and fixed.

I'd like to thank Dieter Spaar for organizing and hosting the event, taking care of the Bavarian sausage + cheese platter for lunch.

I did not create rtl-sdr / librtlsdr

In recent weeks, the number of private e-mails I receive about rtl-sdr has increased significantly. This is odd for at least two reasons:

First, I didn't create rtl-sdr and was not involved in its creation with the tiny exception of writing an e4k tuner driver for osmo-sdr, which was then used in a variety of rtl-sdr software.

Second, you should never contact the (presumed) software author in a private e-mail, but use the respective project mailing list. There is a community of developers, contributors and users out there, and it is a waste of everyone's time if you communicate by 1:1 private e-mail rather than enlightening the mailing list.

We're now working on a UMA/GAN controller

We've pondered it a couple of times in the past whether we should implement an UMA/GAN controller (UNC/GANC). GAN (formerly called UMA) is a method by which you can tunnel GSM/3GPP Layer3 signalling (Mobility Management, SMS, Call Control) over an IP based bearer such as 802.11 (WiFi).

The idea was that mobile phones that support both a GSM/3G radio as well as WiFi could then simply use WiFi to connect to their mobile operator. This has been deployed around 2007/2008 by some operators such as T-Mobile USA as well as Orange UK. Today it seems that not many operators have caught up and UMA/GAN is mostly a legacy technology, last but not least due to very few phones actually implementing it.

Nonetheless, there are some markets and applications where UMA/GAN is useful. We (Dieter and I) now have managed to secure a contract for an Osmocom implementation based on OpenBSC (and libosmogsm, libosmo-sccp, ...). The beauty is that from L3 up, it is just regular GSM, no change needed at all. Only the transport layer is different: IPsec with TCP + GAN is the bearer, instead of LAPDm/RSL in classic GSM networks.

Another good part unrelated to UMA/GAN is: This will finally force us to clean up the separation between the MSC and BSC part in OsmoNITB (in order to replace the BSC part with the GANC).

Progress has been good so far, the SEGW (IPsec with EAP-SIM) has been configured, and a simplistic start of a GAN protocol implementation gets us through DISCOVERY, REGISTRATION and up to the point where the MS is sending the LOCATION UPDATE message. If you are curious how the protocol actually looks like, I've attached a sample pcap file to the WRTU54G-TM page in the OpenBSC wiki. The source code can be found in the laforge/ganc branch of openbsc.git.

First month of running the openmoko.org USB Product ID registry

One month ago, I had announced the availability of USB Product IDs under the Openmoko USB Vendor ID. By now, there have been 37 registrations, and the List of assigned USB Product IDs in the openmoko.org wiki is turning into something like a directory of really cool projects with Open Hardware or at least Free Software device firmware.

So actually, I enjoy a lot seeing so much activity in this field, and being able to contribute a tiny bit by enabling people to get a unique USB Product ID that they can use.

Back from a 3-day motorbike ride to the central Taiwan mountains

I've wanted to do this for many years, but somehow never managed to do this even back while I was spending a lot of time in Taiwan: A motorbike ride crossing the mountainous center of the island using the Central Cross-Island Highway. This highway is probably not what most people imagine a highway would be like: A narrow road consisting almost entirely only of serpentines with a speed limit of typically 40 km/h. In other words, a motorbiking paradise.

You can enter that highway from the east by starting from Taroko Gorge. In order to get there by motorbike, you take the famous Provincial Highway No. 9 from XinDian via Pinglin to Yilan, which is frequented a lot by Taipei motorbike riders on weekends. The No. 9 further leads along the cliffs of the coast to Xincheng, from where No. 8 starts.

The trip from Taipei to Xincheng is only about 200km, but still you need at least something like 5.30 hours if you want to ride safely. This is once again due to the mountain roads. You can barely see 100m at any given time to the next turn in the road all the way between XinDian and Yilan.

So I stayed one night at the entrance of Taroko Gorge.

Upon arrival I was greeted by the hotel owner with the news that No. 8 had been closed temporarily due to rock fall at km 150.9. That was pretty devastating to my plan, as this road is the only connection in the northern two thirds of the entire island. There is no alternative, except for No. 20, which would have been probably three times the amount of distance (and thus time). However, as it later turned out, the road would be opened for 30 minutes between 6am and 6.30am. So I had to leave at 5.00am in order to safely ride the first 30 km up to the road block. This turned out to be the best thing that could have happened:

  • There was absolutely zero traffic in either direction (the first 25km to Tienshang that are normally full of tourist busses).
  • I was able to witness the sunrise at about 5.40am in the mountains
  • very clear sight, which at other times is not clear at all

So I reached the road block even ahead of schedule and was able to pass as intended.

I continued along the road, and due to the fact that the road was closed again after 30mins, there was close to zero traffic all day on the entire road. /p>

At Dayuling, you can either continue the 8 towards Lishan (but not much further due to repeated subsequent earthquake and typhoon damage), or you an continue along No. 14 A towards Hehuanshan (Mt. Hehuan). I first went to Lishan (a major tea planting region) and back, as due to my early morning start I had lots of time left for detours, to continue towards Mount Hehuan , where the road reaches an altitude of more than 3100m.

I spent the second night in Renai, where I arrived just in time: The first rain drops of a heavy afternoon thunderstorm were falling. In the morning, I was greeted by the following view from my hotel room:

I left again in the early morning, drove through Puli and headed for the Sun Moon Lake. It really is beautiful, as you can see in the following picture. However, it is also over-developed to care for tourists of all sorts, including lots of concrete directly at the lake, and bus-loads full of tourists, Starbucks coffee shops and everything that comes with it.
After two days in remote mountains with little buildings and almost no people, the experience was so shocking that I decided not to circle the whole lake but instead continue down south along No. 16 until it meets No. 3, which I then drove more or less all the way back to Taipei.

The first sixty-or-so kilometers are painful, as they lead through heavily populated areas around Nantou and Taichung. This means that there's lots of traffic, and very frequent traffic lights that make you stop. Later on, the road leads through less populated mountainous regions, and driving is more relaxed again.

Having managed this trip without any problems (nor getting lost even once), I'm hoping to find some time in the future to ride No. 7 from Yilan to Lishan, and particularly Provincial Highway No. 20, crossing the mountains much more south.

And if there's one part for me to remember: Always avoid the densely populated regions in the west of the island. If I wanted to ride stop-and-go all day long, I don't have to leave Taipei or New Taipei City in the first place ;)

Kevin Redon starts collaborative Osmocom project to collect terminal profile

As Kevin Redon writes in his blog, he has created some tools and a project for collaboratively gathering a database on the TERMINAL PROFILE capabilities of mobile phones.

The terminal profile describes which particular features regarding proactive sim or sim application toolkit a given phone supports.

This is not only important for SIM application / SIM toolkit developers, but it is also an important factor when trying to analyze the potential threat that can originate from a malicious SIM card attack.

I personally see no reason why my phone should ever report its GPS position to the SIM card, or why the SIM card should be able to re-write the nubers I'm dialling. Yes, there are cases where such features are useful, but then they should be explicitly enabled by the user, and the default should be that they are all switched off.

Who knows, after all, with some attention to this problem we might still see a SIM firewall / proxy, that you can put between the SIM and the phone to prevent any of those features from being (mis)used.

So all you need to do to contribute to the database is some way how you can read out the terminal profile from your mobile phone(s), and use Kevin's tool to upload it to the public website. And hwo do you read out the terminal profile? For example by using Osmocom SIMtrace to sniff the communication between SIM card and phone.