OpenBSC interoperability testing

As expected, it seems that the various different GSM cellphones expose quite big differences in their behavior towards the GSM network. In part this is due to the evolving GSM standard, where features were added over time in a backward- compatible manner, so old phones still work on modern network. The biggest part is probably due to implementation differences in the GSM stack or the particular hardware drivers that glue the stack to the given digital + analog baseband circuitry in the phone.

I have started to collect a number of different phones to test them with OpenBSC, you can see my current collection here: In addition, at the Berlin CCC we also have an old 8W Siemens P1 for testing against Phase 1 GSM phones.

The old Nokia DCT3 phones seem to be the most tolerant ones when it comes to violations of the protocol. I had a number of bugs, such as using the wrong training sequence in the CHANNEL MODE MODIFY as well as ASSIGNMENT COMMAND messages, but they simply ignored it and used the TSC from the SYSTEM INFORMATION. The various Siemens and Motorola phones are way less tolerant, which is good since it enabled me to actually find the respective bug in OpenBSC.

Also, Phase1 support in OpenBSC hasn't really been there so far. We kept asking the phones for their IMEISV, and apparently Phase1 only have IMEI but no IMEISV, leading to us rejecting the LOCATION UPDATING REQUEST. This is also fixed now. The remaining Phase1 problems are:

• correctly dealing with FR (as opposed to EFR) codec
• figure out why they send a MOBILE IDENTITY TYPE 5 instead of an IMSI on establishing a mobile-originated (MO) call

Microsoft sues TomTom over FAT patents

Finally, it has happened in a public manner: Microsoft sues TomTom over patent violations in the Linux kernel [V]FAT implementation. Sooner or later something like this was bound to happen.

For a number of years, I have heard rumors by various companies producing Large-quantity embedded Linux products that Microsoft is claiming the Linux kernel infringes upon their software patents, and they should sign extensive patent licensing agreements with MS.

The underlying strategy is very obvious: Make those patent licenses high enough to reduce the cost advantage of a Linux based OS over Windows CE and thereby demotivate companies from using Linux in the embedded world.

This has so far happened behind closed doors, but if you google you can find a couple of strange press releases of Asian companies buying into those MS patent deals for Linux.

Now finally, one company, TomTom, has had the guts to stand up against Microsoft and fight their ridiculous claims.

The VFAT patent in question has been invalidated in some jurisdictions, since it has clear prior art: the ISO9660 Rock Ridge Extensions in 1994. Also, in light of the new software patent evaluation rules emanating from the Bilski case in the US, it seems Microsoft has a quite bad stand.

I myself, as well as numerous other people in the Free and Open Source world are asking themselves how this legal action fits into the Microsoft-proclaimed Free Software friendly strategy. As you can see now, that was nothing but vapor.

And MS goes even further. They claim that this lawsuit has no relation whatsoever to Linux, and they're only targeting TomTom's specific implementation of Linux. I have actually reviewed the TomTom kernel sources a number of times during the last couple of years as part of gpl-compliance reviews. I can tell you, there is nothing "TomTom specific" in their FAT FS code. It is the plain fat/msdos/vfat file system like in every kernel.org kernel.

I seriously hope that TomTom will keep up their spirit and be strong enough to fight this attack by Microsoft. We need to see more companies who stand up like TomTom.

OpenBSC: we now have working TCH/F voice calls

Finally, close to 5am after a long day of hacking, I was able to make the first actual voice calls through OpenBSC. This has been _much_ harder than anticipated, with bugs spread all over various places of the code (my code!) as well as some conceptual shortcomings in my understanding of how the exact interaction between GSM 12.21, 08.58 and 04.08 happens.

Initially I was working with the ip.access BTS, but was stuck and didn't see any progress so I decided to try the BS-11, since that one is at least according to spec as A-bis over E1 is publicly documented. Some six hours of problems in my E1 sub-channel multiplexer and TRAU decode/recode later, I actually had a working voice call. To my big surprise, the delay between two phones at the same BTS is incredibly long. Feels like VoIP between two continents.

I then tried whether the fixes have changed anything for the ip.access situation. And yes, they did! It was working straight away, and the delay is non-existent. Isn't it ironic that the traditional E1 system is much worse than the fancy new IP based system? I really need to hunt down where the delay is introduced in the E1 TRAU frame handling, this is not really acceptable right now.

Some further experimentation discovered that my Motorola EZX phones somehow refuse to work, while all the Nokia ones do. Well, some more bugs to fix down the road. At least conceptually everything is working now.

Progress on OpenBSC

After an intense weekend of hacking, I have made once again quite significant progress with regard to OpenBSC:

• ip.access nanoBTS support is now as good as BS-11 support, i.e. there is no functional difference between what you can do with either of those two BTS types
• As part of this work, A wireshark dissector for ip.access Abis-over-IP as well as some protocol documentation have been created
• simplistic call switching is implemented. This means that you can now register multiple phones to the network, and calls dialled to the extension numbers indicated in the SQL tables will result in paging and ringing of the respective recipient phone. However, voice data is still not routed, even after you pick up the phone.
• internal infrastructure work. OpenBSC now have a TLV parser together with data structures defining the TLV types for every IE in RSL, 04.08 and OML, as well as an internal signalling mechanism where some parts of the code can issue signals while other parts can listen for those signals

This means we're getting very close to being not just an experimental playground but actually doing something useful (like: actual voice calls) soon. SMS switching should also be really easy, in fact much easier than voice call switching. We can already send and receive SMS, but not yet route them through.

Other things on the to do list are: Switch to talloc as memory allocator, cleaning up a lot of the quickly hacked together code, looking for refcount and other resource leaks.

I also want to add an interactive 'Cisco-style' telnet interface for configuration, administration as well as debugging, utilizing the vty code from the quagga codebase

Thanks also once again to zecke for all his help. It's good to not have to care about everything, and just be able to use the working paging layer.

Maemo / Mobiln / Meego

Every reader of this blog will already have read the news about Nokia + Intel merging their Maemo and Moblin projects to form what's now called MeeGo.

I am not quite sure what to think of it. Of course, two big players teaming together to reduce fragmentation of the "true Linux" mobile software stacks (as opposed to Android) is a good move. There can be a lot of synergies from the combined effort of the Nokia and Intel Linux teams...

Maemo always seemed to be heading in the right direction, embracing and growing a developer community. Moblin on the other hand always felt much more like an industry kind of thing. Sure, there were/are lots of well-known developers from the community working on Moblin, but the involvement of the larger Linux/FOSS community seemed to be quite little. So I hope the new MeeGo project doesn't loose the increasingly good community interaction that that Maemo.org was showing.

On the other hand, Maemo was troubled by political decisions such as the move from GTK to Qt (following Nokias acquisition of Trolltech). No matter what you believe is the better technology, changing the UI stack from one version to another inevitably confuses and disappoints all 3rd party application developers.

What puzzled me most about the announcement was this post by well-known kernel hacker Arjan van de Ven, showing an architecture diagram where the Linux kernel is called "MeeGo Kernel". I almost wonder how much they had to pay him to use that diagram in a public article. If they use the Linux kernel, they should simply call it a Linux kernel, even in marketing-oriented architecture diagrams. Everything else is nothing but an attempt at misleading people. Both the Maemo 5 Software architecture and Android Architecture diagrams clearly indicate it is Linux!

Also, the diagram claims to have a Hardware Adaption Software layer below the kernel, which I am quite sure it won't have. No self-respecting Linux Kernel developer believes in hardware abstraction layers.

OpenBSC get support for ip.access nanoBTS

I've been contacted by a company who will support further development of OpenBSC, including the integration of support for the ip.access nanoBTS. Those beasts are unlike any traditional BTS, as they don't use a E1 link but rather route everything over TCP/IP. They even use Power-over-Ethernet and look almost as innocent as a WiFi access point.

After yesterdays meetings were finished at 7pm, I spent another eight hours of intense hacking and looking at protocol traces between a commercial BSC and the nanoBTS. It seems like everything is as far as possible according to the relevant GSM specs 08.58 and 12.21, which means adapting OpenBSC will not at all be hard, at least not for the signalling part. I haven't yet looked at the actual voice channels, but I'm confident it will all work out just fine :)

It turns out the abstraction of the input interface and introduction of something like a "BTS link driver" during the last weeks has helped a lot to ease the integration of a completely different BTS with a TCP/IP based link.

Unfortunately I currently have to deal with some rather dull and boring other work, but hopefully will be able to continue a lot over the weekend.

Becoming the deDECTed.org spokesman

Yesterday the members of the deDECTed.org team decided to pronounce me their official spokesman.

It's not that I didn't already have way too much work anyway - but I strongly agree that the project needs somebody who is non-partisan and not affiliated with some of the bigger entities involved with the project.

Hopefully I can use this role to clarify some of the misunderstandings and apparent misrepresentations that the project had to suffer with.

Pavel Machek looking for Android exploits

In his recent bog post and mails, well-known Linux kernel developer Pavel Machek is looking for exploitable security holes in his Android phone in order to root it.

He is addressing the very fact that I also cannot re-iterate often enough: If I buy a product, then I own it. If I own it, only I decide what software runs on the device or doesn't run. The cell phone makers and mobile operators make us buy the devices, not rent them. So they have not the least right to restrict their customers from doing whatever they want on the product they own.

If those companies want to own their devices, they should resort to renting phones rather than selling them. But rather than following this logical consequence, they decide to use technical measures to distort the ownership/property situation of the product. They can still charge the customer for the full price of the product and literally sell it, while not actually transferring the inherent power of ownership. It's like selling a car but don't giving the keys along with it.

This is now the "Thanks" that the Linux Kernel developers get from companies like Google, Android or T-Mobile. They thank for being able to use the Linux kernel with locking out the very same people who wrote that kernel in the first place - as well as every other legitimate FOSS developer who wants to exercise his right to run modified versions of the program.

Welcome to the brave new world. I wish I had the time and resources to fight an example case against this kind of behavior. It is not against the wording of the GPLv2, but for me (and my lawyers) definitely against the spirit and the intent of it. Maybe I need to change priorities, as it now isn't only Motorola but also Google/Android/T-Mobile who are engaging in this outrageous act against what is probably the most important practical freedom of Free Software.

For the Motorola MAGX devices, OpenEZX hackers were luckily able to find relatively simple ways to circumvent its security, and thus the practical immediate need for any legal action. Let's hope the G1 has a similar fate soon.

Preparing the second big shipping of GSM BTS

Today I've mostly been in my recently-rented warehouse to prepare the shipment of the next 13 units Siemens BS-11 microBTS

Some people are asking: Why are you doing something like renting a warehouse and taking care of shipping those heavy (48kg each) units?

The answer is simple: I care about IT security, and GSM is (just like DECT or Mifare) one of those massively-deployed systems with much too little security research going on. It has security issues that were known for probably about a decade now, with nobody working on any fix.

In order to encourage more security research (aka 'hacking') of GSM, we need to give the required tools into the hands of more people, and make sure those tools are not too expensive. The BS-11 in combination with OpenBSC will hopefully have this kind of effect: More people playing with the GSM protocols, discovering and releasing protocol as well as implementation weaknesses.

If you ever wanted to see how your mobile phone behaves when you use (in the Internet) well-known attacks such as fuzzing, projects like OpenBSC(+BS11) or OpenBTS finally put you into a position to do so.

Clarifications to my Reflections

A couple of days ago I posted about Reflections on the hardware industry which received quite a bit of attention and feedback. Great!

A number of people raised the issue that the chip-makers cannot deal with lots of small-volume customers. I am very well aware of that, and that was not what I was suggesting at all. But if the chip-makers take action that helps the downstream customers of their tier-1 customers (the board-makers), then in the end everyone is able to address a larger market. No additional support/sales required, no need to deal directly with more and smaller customers.

All I'm arguing for is a deeper understanding of the downstream market, for more care what happens beyond the next element in the supply chain.

Reflections on the hardware industry

I'm currently quite frustrated with a lot of the work that I've been doing recently. As some of you know, I've been talking a lot to various players in the semiconductor and embedded board-level industry, trying to educate them about the Free and Open Source Software development model and the specific business advantages that they might get from opening up with their code, or even actively going mainline, or providing freely available documentation.

You know the names of some of the companies that I've been talking to, but I can assure you there are also a number of companies about whom I didn't blog or whom I don't mention publicly. In this blog article, or any follow-ups, I will refrain from mentioning any names. I do not want to point at specific organizations, but rather just raise the awareness about industry-wide observations that I'm making. They reflect - as everything - my own, personal view and do not represent anyones' opinion.

In the end, there is a surprising similarity to the situation to all of those companies, independent in which country they are, how big their market share is, and in which particular market they deal.

They all have some people inside their own organization, most often actual engineers or even engineering managers up to the very senior R&D managers who understand the FOSS model and the benefits that this would or at least could bring to their products and their organizations. They want to release the source, they want to push mainline, and they might even want to release the user manuals.

But inside the industry, nobody listens to what their own R&D department or event some external entity - even the very representatives of the operating system they use (Linux). The chip makers will only listen to one thing: Demand from their tier-1 customers. Whatever is in the spec of those who buy their components in millions of units will get implemented. Only those maybe biggest five board-makers are considered 'customer'. Everybody else is not. The Telco who buys from the board maker _might_ still be perceived as having some indirect influence, but the actual end customer, both corporate and private, does not exist.

On the other hand there are those many small, innovative start-ups and medium sized organizations at the other end of the market who want entirely open source Linux drivers, in recent kernel versions, because that is what they can use as the basis for innovative products. But they are invisible to the chip maker.

The entire food chain in between, at least one level of OEM and ODM - possibly more - prevents the actual existing demand from those smaller innovative companies to ever reach what the chip maker perceives as specs. Those intermediaries (OEM/ODM) typically have very limited skill and understanding about anything related to Software, not even talking about FOSS. They know how to make many boards cheap. In fact, their skill typically is so low that all they can use for their products are so-called turnkey solutions: A full reference board design and complete software stack that they can copy+paste with only the most superficial modifications.

This is why no single mainboard maker (probably apart from Intel's mainboard division and some parts of Dell) ever tries to boot a Linux Live-CD on one of their boards before shipping it, or bothers to get their ACPI tables correct. Whoever buys most of those boards doesn't have "ACPI compliance" or "Linux support" in their specs. The fact that there are hundreds of small companies who each might do thousands of units for niche markets desperately look for products with good Linux support [which is impossible without open source] doesn't matter.

Or in the embedded networking market for DSL modems, WiFi routers or the like, none of the large buyers (i.e. ISPs or Telcos) has "frequent security updates" on their spec. The security updates would be something that requires the chip maker to use (and follow) more recent kernels, and could even drive them away from proprietary kernel modules, since the ABI and API incompatibilities would probably make them quite hard.

So despite senior R&D management at the chip makers understanding those dynamics, and knowing that they could achieve superior product quality, reliability, security and encourage innovation - the companies don't do it until the requirements show up on the major buyers shopping lists.

The fact that the current policy of not releasing documentation and providing source code only to their immediate customers, as well as the frequent abomination of binary-only kernel modules also effectively prevent any independent third party (commercial or non-commercial) to actually provide such a solution based on a particular hardware offering.

Thus, it is actually not an anti-FOSS environment, but an anti-competitive environment. By opening up at whatever level and enabling (or even encouraging) any third party to build on top of your product, you encourage a market and encourage competition. A market with actual competition will increase innovation due to competition. In the end, any customer who wants to use the actual chip will have more software options, and thus the resulting product will be able to reach more markets and boldly go where it hasn't gone before.

As a chip maker, you first and foremost concern should be to sell as many units as possible. You don't care what kind of software your customers use. You don't care where they get their software from, or what development methodology they use. So if you can take any step to encourage more alternatives and more competition/innovation on top of your chip, you can only gain market share, but not lose it. And if you don't gain market share, well, you didn't have to make any investment. So no matter what you do, you can hardly loose anything.

I think the key issue is to be able to think beyond your immediate board-level customer. By going open source, you help those board makers (even if they don't know how and why) to sell to markets that they cannot address. And you will see new applications on your chip as opposed to the more closed competition. And in the end, if your customers customers customer sells more, you also sell more.

So as a chip maker, you can either sit back and wait for your competition to fully realize this potential, or you can proactively take steps ahead and be the first one. First time-to-market is key. Why can everyone afford to sit back and do nothing, despite the increased pressure from a collapsing market/economy?

Just booked my flights for BOSSA in Brazil

After last years' experience at BOSSA 2008, I was very interested to attend BOSSA 2009 in Porto de Galinhas, Pernambuco, Brazil. This time I hope I can contribute by talking about the various FOSS projects in the GSM protocol area, such as gssm/gsm-tvoid, OpenBSC and OpenBTS. Lets hope I can get some more people excited about liberating the protocol part of mobile communications devices.

Like last year, I will also add some holiday after the conference. The nice and empty beaches of Pernambuco and Alagoas are quite irresistible during the off-season.