OpenBSC now has handover support

So far, OpenBSC already implemented mobility management, i.e. keeping track of which location area a mobile phone is locate in. However, this only works during idle mode, i.e. while there is no actual phone call in progress.

Throughout the last week, I've been working on getting real handover support into OpenBSC. This is now actually working very well! You can move from one cell into another cell while your phone call continues just like it is supposed to do.

The signalling part is actually not all that hard to implement. However, it has some dependencies on things like measurement reports, which in turn require us to send proper neighbor lists, which in turn requires proper generation of system information messages, etc.

The actual order of events in a successful handover case is as follows:

• OpenBSC send the neighbor cell information in the BCCH and SACCH
• OpenBSC regularly receives measurement reports from the phone, where it tells us how well neighbor cells are being received. OpenBSC then averages those measurements and decides
if or not to make a hand-over. If it decides so, it
• allocates a channel on the new BTS
• waits until the BTS acknowledges this
• sends a HANDOVER COMMAND to the phone through the old BTS
• waits for HANDOVER ACCESS bursts and a HANDOVER COMPLETE on the new BTS
• closes the old channel on the old BTS
• takes care of re-routing the voice channels

As indicated, the signalling part was relatively easy, and once the measurement processing and neighbor lists were in place, this worked really quick. What turned out to be a much bigger PITA was the handling of the actual voice streams.

Let's assume you have a call from A to B, where B is changing cells and now becomes B*. In this case, after switching cells, the speech frames from A need to be re-routed to B* instead of B. That's simple and works very easy. In the other direction, switching off B is easy. However, a completely new channel B* suddenly sends speech frames to A. In case of classic TRAU frames on E1 that is simple as they don't have any context.

In the case of ip.access nanoBTS, the speech frames are transported using RTP. Changing the source of your stream will change its CSRC (synchronization source identifier), timestamps and sequence numbers. The receiver in BTS A is not happy at all about this. So with handover, it is no longer possible to send RTP streams directly between BTS's, but OpenBSC's RTP proxy needs to process the RTP packets and hide the details of the changed source.

This is further complicated by the fact that during handover you are losing speech frames, somewhere between 10 and 40 in the cases that I've seen. This means that when sending the new RTP frames from B*, the sequence number and timestamp needs to account for those lost frames, i.e. incremented by the respective loss count. Otherwise the RTP receiver in BTS A will think it is only receiving old frames and will discard all of them.

Luckily, all of this seems to have been sorted out now and I'm confident we will have actual full handover at the GSM network at 26th annual Chaos Communication Congress in a few days from now. We'll be running 3 BTS's with a total number of 5 TRX's inside the conference building.

German Constitutional Court hearing on data retention law

Today I've taken one day off work in order to attend the publich hearing of Germany's constitutional c ourt on several constitutional complaints against a German national law on data retention of telecommunications data. As the topic is likely only relevant to Germans, and due to the fact that I am not very confident with my English legalese outside of copyright law, I'll switch to German for this blog post - which I believe is unprecedented in this blog so far.

Tja, da war ich also heute einer der wenigen auserkorenen Besucher beim BVerfG. Immerhin haben mehr als 34.000 Leute Verfassungsbeschwerde eingelegt, auch wenn rein formal heute nur eine Hand voll exemplarische Beschwerden verhandelt wurden. Diesen Trick hat sich das BVerfG wohl ausgedacht, um nicht vor dem Problem zu stehen dass jeder Beschwerdefuehrer sicher ein Recht haette, persoenlich vor Gericht anwesend zu sein.

Der Gerichtssaal des BVerfG ist sehr klein. So klein, dass bei besonders bedeutungsvollen Verfahren kaum mehr Platz fuer Besucher ist. Der eigentliche Gerichtssaal war schon durch die Beschwerdefuehrer, die zahlreichen Vertreter des Gesetzgebers und der Behoerden und Amstraeger (BKA, Polizeipraesidenten, Richter an diversen Gerichten, Bundes- und Landesdatenschutzbeauftragte, Mitglieder des Bundestags und nicht zuletzt die zahlreichen wissenschaftlichen Mitarbeiter des Bundesverfassungsgerichts selbst belegt. Hinten waren noch zwei Reihen fuer Besucher frei.

Diese beiden Reihen wurden durch Studentengruppen belegt - oder vielleicht koennte man fast sagen "verschwendet". Ein nicht unerheblicher Teil dieser Studenten (u.a. der TU Darmstadt) hatte tatsaechlich geschlafen. Was fuer eine Ungeheuerlichkeit, nicht nur ein Mangel an Respekt gegenueber dem hoechsten Gericht des Landes und dem Thema gegenueber - sondern auch eine unverschaemtheit gegenueber den vielen vmtl. hunderten von interessierten Buergern die gerne der Verhandlung beigewohnt haetten, aber einfach keinen Platz mehr bekommen haben. Freunde von mir haben am 2. Tag nach der Terminankuendigung versucht noch einen Platz zu bekommen - vergebens.

Da haben wir also die nahezu perverse Situation, dass das hoechste Gericht zwar faktisch von jedem Buerger angerufen werden kann, dies auch eine fuenfstellige Zahl an Buergern wahrnimmt - dann aber die eigentliche Verhandlung nur fuer eine kleine Elite zugaenglich ist, und Aufzeichnungen oder Uebertragungen nicht gestattet sind. Das erscheint mir doch irgendwie ungerecht.

Doch nun zur Sache:

Der 1. Senat unter dem Vorsitzenden Richter Papier hat die Anhoerung im Allgemeinen sehr souveraen geleitet. Es gab ein paar amuesante Momente, als z.B. die Vertreterin des Justizministeriums das Wort an den Prozessbevollmaechtigten der Bundesregierung uebergeben hat, obwohl doch das Gericht normalerweise das Wort erteilt, und nicht andersherum ;)

Wie auch schon bei der letzten Verhandlung: Die Beitraege der geladenen Sachverstaendigen waren bisweilen der interessanteste Teil, vor allem eben die diversen Fragen des Gerichts. Diese Fragen erlauben einerseits einen Blick hinter die Ueberlegungen der Richter - andererseits aber auch in wie weit die technischen Zusammenhaenge und deren Folgen vom Gericht bereits verstanden werden. Das jetzt bitte nicht falsch verstehen: Ich habe tiefsten Respekt vor dem Gericht, und es ist i.d.R. sehr erstaunlich wie weit sich die Richter in das jeweilige Fachgebiet einarbeiten. Wie auch schon bei der Verhandlung zu den Wahlcomputern lassen die Vertreter der Regierung bzw. der untergeordneten Behoerden da oft deutlich weniger umfassende Kenntnisse durchblicken.

Die ganze Debatte zur VDS (Vorratsdatenspeicherung) ist verzwickt. Wir haben da historisch einen Bundestag, der keine VDS will, einen Rat der EU-Innenminister der das dann einfach als EU-Richtlinie beschliesst, und einen Bundestag, der in Folge die exzellente Ausrede hat, dass er die Richtline ja umsetzen muesse, um von der EU kein Verfahren angehaengt bekommt.

Die EU-Richtline heisst nun eben auch, dass das BVerfG nun nicht nur in der Sache zur VDS entscheiden kann, sondern sich eben noch mit der Frage beschaeftigen muss, was denn passiert wenn eine EU-Richtline mit dem Deutschen Grundgesetz in Konflikt steht.

Ein paar voellig ungeordnete aber fuer mich bemerkenswerte Punkte der Verhandlung heute:

• Es gibt keine empirisch/wissenschaftliche Grundlage die belegt, dass die VDS zur bekaempfung von Terroristischen Anschlaegen geeignet ist (das war ja nach Dem 11.9. sowie den Anschlaegen von Madrid und London die Begruendung).
• Der Chef der Bundesnetzagentur hat mehrfach ganz unuebersehbar nicht auf eine wiederholte Frage des BVerfG geantwortet: Gibt es Unternehmen, die gesetzlich zur VDS verpflichtet sind, aber andererseits keinerlei Verpflichtung zur erstellung oder Abgabe eines Sicherheitskonzepts zur Sicherheit dieser Daten haben? (Meine Auffassung: Ja, die gibt es!)
• Die Bundesnetzagentur macht, wie sie selbst sagt, im wesentlichen Pruefungen der Sicherheitskonzepte am Schreibtisch. Das muss ja mit der Realitaet in den Unternehmen nicht viel zu tun haben.
• Einer der Beschwerdefuehrer, Minister A.D. Dr. Burkhard Hirsch hat wohl die lebhaftesten und unverbluemtesten Redebeitraege gehalten; sehr erfrischend.
• Der Polizeipraesident von Muenchen wurde gebeten, konkret zu begruenden, wie die VDS der polizeilichen Ermittlungsarbeit in Muenchen hilft. Fast alle seiner Beispiele waren ungeeignet, da sie auch ohne VDS aber z.B. mittels einer telefonischen Fangschaltung oder einer Verbindungsdatenspeicherung nach expliziter Aufforderung durch die Polizei (und nicht auf Vorrat) moeglich gewesen weaeren. Zwei seiner Beispiele haben sich zudem generell als falscher Alarm herausgestellt (Journalist macht einn Testanruf; gelangweilter Schueler kuendigt aus Spass Amoklauf an). Das klang alles eher nach Stammtischgeschichten als nach fundierter Ermittlungsarbeit in wichtiger Sache.
• Die Sicherheitsanforderungen an die Speicherung der VDS-Daten ist derzeit offensichtlich nicht hoeher als an alle anderen Daten innerhalb des Fernmeldegeheimnisses insgesamt. Also der gleiche Sicherheitslevel, der uns zu den Datenschutzskandalen wie z.B. bei der Telekom gefuehrt hat. Das ist ja mal echt vertrauenerweckend.
• Der Chef der Bundesnetzagentur spricht gerne vom "bill shock", was laut ihm eine ueberhoehte Telefonrechnung nach unabsichtlicher Nutzung der teuren Auslandsroaming-Tarife im Mobilfunk ist.
• Ein kleiner Schmunzler am Rande war dann noch Burkhard Hirsch's "Blueberry", als er den Blackberry meinte ;) Ja, klar, jeder weiss was er meint und niemand nimmt es ihm uebel - aber es zeigt einfach, wie unsicher die "alte Garde" mit den Begrifflichkeiten der heutigen Alltagswelt umgeht.
• Die qualitaet der Richterlichen Anordnungen laesst offensichtlich sehr zu wuenschen uebrig. Es ist aufgabe des jeweiligen Richters, einzuschraenken genau welche Daten denn vom TK-Dienstleister uebergeben werden sollen. Laut dem Vertreter des Verbands der Internetwirtschaft (eco e.V.) kommen hier anscheinend recht allgemeine Anordnungen im Stil von "geben Sie uns mal alles was Sie haben" vor. Das geht so natuerlich nicht!
• Es kam zur Sprache, dass deutlich mehr Leute jetzt ihre eigenen e-mail Server betreiben wollen (privat und bei Firmen), weil man sich damit der e-mail VDS entziehen kann. Ist ja schoen, dass es den Trend gibt, und gut dass das auch mal auf dieser Ebene zur Sprache kommt. (Fuer mich kaeme etwas anderes niemals in Frage. Meine Daten gehoeren mir. Ich wuerde weder die Speicherung meiner Mails noch jeglicher anderer Daten jemals einer anderen Person anvertrauen, weder einem Privatunternehmen noch einer staatlichen Stelle). Das ist genau einer der vielen Tricks, mit denen die "digitale Elite" (und garantiert auch die vermeintlich zu bekaempfende organisierte Kriminalitaet oder der Terrorismus) arbeitet. Letztlich trifft man dann nur den Otto-Normalverbraucher, und benutzt die Daten dann fuer harmlose Beleidungsdelikte oder Urheberrechtsverletzungen im privaten Bereich.

German National Education and Research Network reports on OpenBTS and OpenBSC

Issue 77 of the regular publication "DFN Mitteilungen" of the German National Research Network (DFN) reports on Open Source software for GSM networks, specifically OpenBTS and OpenBSC.

I'm happy to see that at least some parts in academia are now discovering this software and use it for research purpose. That's great news!

GSM and UMTS: The Creation of Global Mobile Communication

There is yet another really exciting book that I've been reading lately: GSM and UMTS: The Creation of Global Mobile Communication. It's a book on the history of GSM. From the early days at CEPT, through the creation of ETSI and the GSM MoU Organization, the 3GPP, ...

It puts the development into historical context, indicates who were the key participants at that time, political aspects of the European PTTs that initiated the project, the role of the European Commission, etc.

I've always been looking for this kind of information online anywhere, but there really is nothing that provides any level of detail. Wikipedia e.g. has only two paragraphs (which I believe to be even partially incorrect) on GSM's history. Contrast that with the many writings on the history of the Internet.

The book is accompanied by a CD-ROM with many old meeting notes and other documents from the various stages of the GSM development process.

Palm sued over GPL violation in muPDF

As you can see in this techworld post.

Apparently they are using the GPL licensed muPDF library and link it against their proprietary PDF viewing application. If that is true, then it would be a very straight-forward, FAQ-type violation. muPDF is not LGPL but GPL licensed, thus you cannot create derivative works without licensing them under GPL, too.

The whole license management and even software release management at Palm seems to be very sloppy. For example, based on the object code and disassembly, I can prove that the source code for libpurpleadapter on opensource.palm.com does not (or no longer) correspond to the object code that they ship.

What's particularly surprising is that Palm actually is forcing Artifex to go to court over this issue. You would expect such a straight-forward issue to be resolved fairly quickly and settled out of court, before it ever escalates or turns into a PR disaster.

You would expect a company that is regularly building and releasing firmware images to have an automatic process that packages the source code as part of the build process. In fact, Palm uses OpenEmbedded to build their images, and it is a standard feature of OpenEmbedded to create the corresponding source tarballs for everything it builds.

Furthermore, the Palm kernel contains several binary-only modules that indicate MODULE_LICENSE("GPL") in it - which is clearly not true. If you inquire about the sources, they will respond that they will not provide the sources.

Palm's failure with the App Catalog / Preware to the rescue

Especially since the 1.3.1 WebOS release, you can easily see the lack of success of the official Palm App Catalog: Only about 60 Applications are available to me from there. Why is that? Because the default setting in the app catalog for any developer uploading the application is "US Only", i.e. people who bought their Pre in other countries like Germany will not see the majority of applications. That's really weird considering how much effort Palm is spending in trying to convince people to write applications for WebOS to increase the attractivity of their product. Now they artificially reduce that for everyone outside the US.

So that's even one more reason to use the alternative package installer called Preware which is available from webos-internals.org. This alternative installer supports any number of feeds. It removes the single-point of failure that an official Palm App catalog creates, and replaces it with a proper community-driven approach. Anyone can write and publish applications, anyone can distribute them to the users, just like anyone is able to distribute/install MacOS, Windows or Linux applications on the PC!

Re-discovering the marvels of Nokia DCT-3: Blacksphere, MADos & Co.

About 4-5 years ago I first discovered Project Blacksphere, a group of hackers who were working on reverse engineering debug interfaces, as well as the actual phone firmware and hardware of Nokia DCT-3 phones like the 3310. Unfortunately, those projects have meanwhile been discontinued and seem to have died off.

When I last looked at that project, the status was still very limited with regard to the actual GSM side of things. You could run MADos on your phone and run some games inside it. Sure, being able to use the battery charger, keypad, LCM, etc. from your own software on an undocumented device is already great achievement, but if I want a small device without GSM then I just simply use any random PDA or build something myself.

The point about reverse engineering an actual phone is exactly to get what you cannot get from any other piece of hardware: Get access to the lower layers of the GSM protocol stack. Since MADos still looked quite far away from that, I didn't find it particularly interesting at that time.

Today I found a mirror of the project blacksphere, and discovered that apparently they had come much further with reverse engineering the interface between the DSP and the CPU, which is the interface between layer 1 and layer 2 in the GSM stack. If you fully understand that interface, you can write your own GSM stack on the phone and have a true open source phone. The code and information available is not quite at that stage at yet, but very close!

So since I have some 3310 phones (I constantly use them for OpenBSC testing) and the FBUS and MBUS cables, I am definitely going to play a bit with MADos and nlib in its latest known state. It might be the easiest way to write a MS-side layer2 + layer 3 GSM protocol implementation and put it onto an existing Layer 1.

FOSS.in/2009 has started

I've arrived in India to attend FOSS.in/2009 in Bangalore. It's always great to be here and get in touch with Indian Free Software developers.

Unfortunately I'm suffering from lack of sleep during the flight and jetlag, so I had to miss large parts of the first day of the event :(

My keynote on Ooening up Closed Domains went fine and was apparently fairly well received. The main points being:

• There are many areas in computing, beyond the desktop PC, where there's still no freedom and openness due to a lack of Free and Open Source Software
• There's no real reason preventing developers to bring FOSS into those areas
• As can be seen by existing projects like OpenPCD, OpenBTS, OpenBSC: Very small teams of developers can make a big difference

Leaving for FOSS.in

I'm just about to go to the airport and leave for FOSS.in/2009. Most of my time there will again be spent working out on GSM protocol analysis, i.e. the airprobe project.

The workout wiki doesn't really have any content yet, and I shall fix that as soon as I get the password for the Workout Wiki (apparently passwords from las year don't work anymore).

It's going to be fun to meet all my Indian friends again - and at the same time I'm happy that a large international community will be present, including Stefan Schmidt, Holger Freyther and Andy Green of Openmoko fame, as well as people like Milosch and Brita Meriac from projects like OpenPCD, OpenBeacon and txtr, James Morris of netfilter/iptables and SELinux, Lennart Poettering of avahi and pulseaudio.

OpenBSC: System Information + Rest Octet generation

During the flight to Bangalore I kept working on the system_information branch of OpenBSC. This branch has been lingering in git for quite some time, but I haven't yet felt confident enough to merge it into the official master.

In OpenBSC so far, the SYSTEM INFORMATION messages (type 1 through 6) are not really generated by actual code. Rather, we use some templates that are patched here and there with actual operational parameters such as the ARFCN of the current cell. This has been easy for the very early start of the project, but it has started to become more of a problem lately.

One example are neighbor cell lists. If you operate a network with multiple cells, then of course you want to provide proper neighbor cell lists. At HAR2009, we solved the problem by manually hard-coding the respective bitmasks. That's of course not a proper solution.

Another problem is the notoriously complex encoding of the rest octets, which culminates in the SI13 REST OCTETS describing the GPRS parameters of a cell.

After a couple of hours in-flight hacking at the code in the sytem_information branch, I am now confident that it provides superior quality SI messages and rest octets than the hard-coded templates we used to have before.

Neighbor Cell lists and even SI13 rest octets are looking great when checking them in the wireshark dissectors. I think it's ready for prime time now, and the code should get merged into the master branch ASAP.

Now I am only left with one question: Should I consider this the first part of the FOSS.in GSM workout? ;)

Performance Enhancements in a Frequency Hopping GSM Network

Dieter Spaar had pointed out this book some months ago when I first raised some questions regarding frequency hopping and the orthogonal nature of hopping sequences with the same HSN but different MAIO.

Last week while David Burgess was with me, he also indicated that this book was great and he unfortunately didn't think of bringing it along with him.

Meanwhile, I have immediately ordered the book and am already at something like 30% completion. It is a most interesting book to read, approaching GSM from an advanced network planning angle, with a specific focus on the effects of frequency hopping, uplink/downlink power control and DTX on the overall system performance of a GSM network.

The theoretical foundations are always put in a GSM network simulator with detailed channel model, but also actually implemented in a real-world GSM network in Denmark.

Next to all the GSM specifications with their plethora of options and operator dependent settings, this book gives a detailed (but still very technical) background on how and why an Operator would configure his network to maximize the service quality offered to his subscribers.

From the results, you can for example very clearly see that

• frequency hopping over a cyclic sequence gives higher gain improvement than random hopping, especially if the number of channels in the mobile allocation is low
• frequency hopping gain is very dependent on the speed at which the MS moves. At 3kph, the gain when hopping over 8 channels can be 7dB, while at 50kph the same hopping will only provide 1.5dB
• MAIO management (using different MAIO but same HSN) for all sectors in a cell gives significant FER improvements
• handover algorithms differ quite a bit between non-frequency-hopping and frequency-hopping networks

In the end, it seems, network planning is never about allocating your channels in a way they don't overlap. That would limit the network capacity way too much. Network planning seems to only be about averaging out the interference that cells inevitably have with each other and ensure that the quality of the system only degrades with increasing load.

The Emperor's Codes: The Breaking of Japan's Secret Ciphers

During the last weeks, I've read the book The Emperor's Codes: The Breaking of Japan's Secret Ciphers. As you can guess from the title, the book relates to the various UK, American and Australian code breaker teams working on breaking the encrypted communication of Japan during the second world war.

There have been plenty of books about the history of breaking Germany's Enigma ciphering machine, but information on how the Japanese codes were broken so far didn't seem to be as widespread - despite the resepective archives being opened up during the last decades.

It has been a most interesting reading. As you can imagine, at that time almost nobody had a sufficient understanding of the Japanese language, not even thinking about how to encode Japanese writing into morse code.

Nonetheless, all of the Japanese merchant, diplomatic, army and navy codes have been broken during the war. And surprisingly, the Japanese never really assumed something is wrong with their actual encryption method. All they did is to replace the codebook or the additive codebook.

Also, just like in today's GSM (A5/1) crypto attacks, even back then the importance of known plaintext could not be underestimated. The verbosity of Japanese soldiers addressing a superior officer and the stereotypical nature of reports on weather or troop movements gave the cryptographers plenty of known plaintext for many of their intercepted message.

What was also new to me is the fact that the British even back then demanded that Cable+Wireless provides copies of all telegraphs through their network. And that's some 70-80 years before data retention on communications networks becomes a big topic ;)

Overall, definitely a very interesting book. I can recommend it to anyone with an interest in security, secret services, WW2 history and/or cryptography.

Reverse engineering 16-in-1 Super SIM cards

In order to support some real cryptographic authentication in OpenBSC, we have to use SIM cards with a known Ki (secret key). For cards that are issued by a real GSM operator, the Ki is only stored in the SIM and in the Authentication center of the network. Since we cannot obtain it from either of those two sources, we have to program our own SIM cards.

Unfortunately, SIM cards with privileges and/or documentation how to set Ki, IMSI and other data are not readily available on the open market. There are a couple of other solutions, though:

• Use one of the old/cheap 6-in-1 / 16-in-1 SIM cards from the SIM cloning scene
• Implement the GSM 11.11 SIM card spec on a programmable card such as a PIC microcontroller card or Java Card
• Use something like the Bladox products to implement a SIM card or a SIM card proxy

The cheapest option with little R&D overhead is to use the so-called 16-in-1 SIM cards. They allow the user to set some of the interesting bits (Ki, PMLNsel, ICCID, IMSI, SMSP): Sufficient for authentication, but not sufficient for doing arbitrary tricks with the SIM.

Today I spent the better part of the day reverse engineering how both the SIM card as well as the included SIM card reader work. The result can be found in the OpenBSC wiki.

As I've already implemented+tested general authentication and encryption support in OpenBSC, all that is left to be done is some integration, configuration and testing. With some luck we can soon operate OpenBSC with full authentication and encryption support. This in turn will of course help with cryptanalysis and other experiments in a controlled environment :)

David Burgess (OpenBTS) visiting me for a couple of days in Berlin

On Friday, David Burgess of the OpenBTS project has come to visit me in Berlin. We're working on the final preparation of the two-day Deepsec 2009 GSM Security Workshop which will happen in Vienna next week.

David has more than 10 years experience in implementing GSM Layer 1 as well as the higher-layer protocols, so it's always great to talk with him and tap into his experience. Unfortunately the preparations for the workshop kept us too busy to work on some actual code.

The more than 200 slides for the workshop will be published after the workshop is over.

India setting up service stations to program IMEI into phones

This is not really current news, as it was released much earlier this year. However, I'm not following Indian news that closely so it has slipped my attention:

India's COAI is setting up hundreds of service centers where end users can have an IMEI programmed into their phone. This apparently relates to the fact that there are plenty of phones of Chinese origin with an all-zero IMEI in India.

Since there is a government law that requires every phone to have an unique IMEI number, operators have been ordered to refuse phones with an all-zero IMEI onto their network.

I personally find all of this very funny:

• Firstly, what law enforcement typically cares about is the subscriber identity (the SIM). Persons are identified by their phone number. The phone number in turn is associated with the SIM. The SIM is issued by the operator and has a world-wide unique number called IMSI. So why would you care about the phone serial number? People can switch their phones much more easily than they can switch their SIM card, since the latter would always mean using a different number.
• Secondly, for most common phones (and particularly the cheaper Chinese phones), tools to program/reset the IMEI are readily available on the Internet. So what's the point for a government initiative to even create more such software, distributed widely across the country. Chances are high that software leaks.
• Finally, if I get a COAI-issued IMEI programmed into my phone, I can at any time erase it again and go back to the COAI to have a new IMEI programmed into it.

So from a real IT security point of view, this entire exercise is nothing but an annoyance to keep people busy and create employment for the staff operating those IMEI programmers.

Tho those involved: Work smarter, not harder ;)

Android Mythbusters (Matt Porter)

Some weeks ago I was attending Embedded Linux Conference Europe. My personal highlight at this event was the excellent Android Mythbusters presentation given by Matt Porter.

As you may know, Matt Porter was heavily involved in the MIPS and PPC ports of Android, so he and his team have seen the lowest levels of Android, more and deeper than even cellphone manufacturers ever have to look into it.

The slides of his presentation are now available for download. I would personally recommend this as mandatory reading material for everyone who has some interest in Android.

The presentation explains in detail why Android is not what most people refer to when they say Linux. What most people mean when they say Linux is the GNU/Linux system with it's standard userspace tools, not only the kernel.

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

Just one more practical example: You cannot even plug a USB drive to an android system, since /dev/sd* is not an expected device name in their hardcoded hotplug management.

Executive summary: Android is a screwed, hard-coded, non-portable abomination.

I can't wait until somebody rips it apart and replaces the system layer with a standard GNU/Linux distribution with Dalvik and some Android API simulation layer on top. To me, that seems the only way to thoroughly fix the problem...

German news site Spiegel Online has video of my torched car

Some 9 months after some idiots have put my car on fire, the german news site Spiegel Online reports on a court trial unrelated to my car, but showing a video of my car.

Quite funny how they always dig out that footage. The court case was about an alleged failed attempt to torch a car, so showing two completely burnt cars in that article is not really sensible anyway.

As you can see from the article, there' already more than 250 burnt vehicles this year in Berlin.

Enabling jabber in WebOS on the Palm Pre using a binary patch

One of my main complaints about the palm Pre is that there is no support for the major IM protocol's such as jabber, icq, aim, msn, ...

As I discovered, they're actually using a library (libpurple) that supports all those protocols. It's just the UI and the intermediate LibpurpleAdapter program which artificially restrict the features that this library offers.

So it sounds to me like palm is getting money or other favors from Google to artificially restrict the capabilities of the Webos messenger.

As I have described in this mail to the webos-internals mailing list, you can actually use a very simple one-byte binary patch to LibpurpleAdapter to enable jabber support.

After that binary patch, you can add jabber contacts with the regular user@jabber-server.doma.in address and use the regular messenger application for keeping in touch with your jabber contacts. Just like how it is supposed to be.

Legal notice: Making this binary patch is legal, since LibpurpleAdapter is actually released under LGPL. If you have a working build environment for the Pre with all the libpurple headers, you can of course modify the source code and recompile it (as explained in the mail).

Side note: The libpurple-adapter source code that Palm has published on opensource.palm.com does not correspond to the actual binary code. This is a LGPL violation. However, since palm is the copyright holder, nobody can really do anything about it. But it once again shows that the software build/release process does not automatically generate the source code packages and that there is an erroneous manual process involved :(

India prohibits import of GSM handsets without IMEI

As has been reported at telecomtiger.com, the Commerce Ministry of India has banned the import of mobile phones with no IMEI.

This is somewhat funny, as the IMEI is stored in flash memory in all the phones that I have seen in recent years. Tools to erase or change the IMEI can be found for many popular phones, including (but not limited) to the many MTK based inexpensive phones from China.

So sure, you can now no longer import a device legally with no IMEI, but well, any self-respecting organized criminal will find a way to erase or alter the IMEI anyway ;)

Implementing the GPRS protocol stack for OpenBSC

During the last week or so, I've been spending way too much time implementing the network-side GPRS protocol stack as part of an effort to not only provide GSM voice + SMS but also GPRS+EDGE data services with OpenBSC

GPRS is fundamentally very different from the classic circuit-switched domain of voice calls and CSD (circuit switched data). Not only conceptually and on the protocol level, but also in the actual system architecture. They way it was added on top of the existing GSM spec is by making no modification to the BSC and MSC, and only the minimal necessary modifications to the BTS. They then added a new Gb interface to the BTS, and the SGSN and GGSN core network components, who in turn talk to HLR/VLR/AUC.

So in the most primitive GPRS network, you can have the GSM and GPRS domains completely independent, only using the same databases for subscriber records and authentication keys. This goes to the extreme end that your phone would actually independently register with the GSM network (ISMI ATTACH / LOCATION UPDATING) and to the GPRS network (GPRS ATTACH / ROUTING AREA UPDATE). While both of the requests get sent to the same BTS, the BTS will send the GSM part to the BSC (and successively MSC), and the GPRS part to the SGSN.

Also, the actual software architecture looks completely different. In the GSM circuit-switched domain you always have a dedicated channel when you talk to a phone. The number of dedicated channels is limited by the transceiver capacity and the channel configuration. In OpenBSC I chose to simply attach a lot of state to the data structure representing such a dedicated channel. In the packet-switched domain this obviously no longer works. Many phones can and will use the same on-air timeslot and there is no fixed limit on how many phones can share a radio resource.

What's further important to note: The protocol stack is very deep. If you look at the GPRS related output on an ip.access nanoBTS while your mobile phone makes a HTTP request, the stack is something like HTTP-TCP-IP-PPP-SNDCP-LLC-BSSGP-NS-UDP-IP-Ethernet, while the first HTTP-TCP-IP-PPP is obvious, I would not have expected that many layers on the underlying network. Especailly if you look at the almost zero functionality that NS (GSM TS 08.16) seems to add to this stack. Also, the headers within the protocol can actually be quite big. If we only count the number of bytes between the two IP layers in this stack: 8 bytes UDP, 4 bytes NS, 20 bytes BSSGP, 6 bytes LLC and 4 byte SNDCP. That's a total of 42 extra bytes. And that for every small packet like TCP SYN, SYN/ACK or the like! No wonder that mobile data plans have been prohibitively expensive all those years ;)

So with regard to the actual GPRS implementation in OpenBSC, the following things had (or still have) to be done

• Add support for generating System Information 3 + 4 rest octets and System Information 13

This is a very time-consuming bit-fucking experience, encoded relative to the padding pattern of 0x2b. Without this, the phones would not realize that the cell actually supports GPRS. DONE.

• Add support for the ip.access extensions to the A-bis OML (TS 12.21) layer

This is needed to configure the GPRS parameters such as channel configuration, coding schemes or the IP and NS/BSSGP parameters for the link to the SGSN (OpenBSC). Without it, the BTS would not even start to speak NS/BSSGP, i.e. not connect to OpenBSC for GPRS services. DONE.

• Implement the NS protocol (GSM TS 08.16)

Turns out this was really simple, as NS doesn't really do much anyway. DONE.

• Implement the BSSGP protocol (GSM TS 08.18)

This protocol is - among other things - responsible for the flow control. Both globally for the BTS as well as individually for each MS. I've implemented the basic functionality to be able to send/receive signalling and user data, but no flow control yet.

• Implement the LLC protocol (GSM TS 04.64)

This is actually the protocol that is terminated between the MS and the SGSN, so we have moved beyond the BTS level here. Actual data from/to the mobile phone. I've implemented a minimal subset of it, including the CRC24 checksumming. I'm not taking care of packet loss, retransmissions or fragmentation yet. Just simple S, UI or U frames.

• Implement the GPRS mobility management (GSM TS 04.08)

This is pretty much work in progress, but GPRS ATTACH and ROUTING AREA UPDATE is already handled. More work needed here, especially with regard to persistent storage of P-TMSI allocations as well as the last-seen position of every MS in a database.

• Implement the GPRS session management (GSM TS 04.08)

This is the messages for activating and de-activating PDP contexts. Work has not started yet.

• Implement GGSN functionality (PPP tunnel endpoints

After all, we need to terminate the PPP sessions that the phones establish somewhere. Work has not started yet

Once all that full stack has reached a level where it works to a minimal extent, issues like BSSGP flow-control as well as LLC re-transmission, fragmentation and [selective] acknowledgement have to be dealt with.

Finally, if somebody is bored enough, he could also work on things like combined GSM/GPRS attach, or SMS over GPRS.

As you can see, it's quite a large task. But we need to start somewhere, and a lot of this will still be needed when moving into the 3G and 3.5G domain. Even if not at the lower level protocols, but from the software architecture point.

If you're into communications protocol development and don't mind our ascetic 'plain old C language' approach and are interested to contribute, feel free to introduce yourself on the OpenBSC mailing list.

German constitutional court hearing on data retention

On December 15, there will be a court hearing by the German Constitutional Court (Bundesverfassungsgericht) on the law on data retention which was enacted in 2007 and has been valid since January 1st, 2008.

This law requires any communications network operator to keep digital records of every voice call and e-mail, including sender and all recipient addresses.

This law was required by the European Union Directive 2006/24/EG, one of those paranoid reactions against the perceived threat of terrorism. Laws implementing this directive in the EU members Romania and Bulgaria have already been invalidated by their respective constitutional court.

In Germany, more than 34,000 (I'm not kidding) people have filed a constitutional complaints against this law. This is the first time that such a significant number of individual citizens has ever made constitutional complaint. Only the documents about power of attorney have filled 12 large boxes, each with many folders. As you could probably guess by now, I'm one of those plaintiffs.

As an interim solution, the constitutional court has already decided on March 19, 2008 that such data can only be used under special circumstances, such as only certain criminal offenses, and only if there is already a very strong initial suspicion, and if there is close to no other way to prove or deny the allegations brought forward by the prosecutor.

I hope the court hearing on December 15 will bring the court closer to actually ruling on this case. This has been dragging on for a long time now.

Just like when the constitutional court had a hearing on voting computers, I am planning to be in the audience and want to see live what the constitutional court does with regard to matters that I strongly care about. I hope my registration will make it in time... given the number of plaintiffs I suppose there will be many more people interested in attending the hearing than they have space. Which raises another interesting issue: I suppose if you are an actual plaintiff, it would be weird if a court refuses you to be at the actual hearing. But which court would hold > 34.000 plaintiffs? ;)

A common misconception: GPRS encryption differs from GSM encryption

In the last couple of months, I've met numerous people with varying background all sharing one misconception about cellular networks. Even I was not very clear on this until recently: GPRS encryption is very different from GSM encryption. Most people know it uses different algorithms, sure. But it also operates on a completely different layer in the protocol, and is between two different entities.

Encryption in GSM networks happens on the Layer 1 of the Um interface between the MS and the BTS. It is a simple point-to-point encryption of only one particular network interface. There is no more encryption as soon as the signalling, voice and SMS data leaves the BTS (on a microwave link or actual land line) to the BSC, MSC, SMSC and other network elements.

In GPRS, the encryption is not on the Layer 1, but on the Layer 2 (LLC) of the Um interface. As the LLC layer is not terminated at the BTS but at the SGSN, the data is still encrypted when it leaves the BTS.

This means, among other things, that things like eavesdropping on unencrypted microwave links does not work for GPRS anymore.

Qualcomm launches Open Source subsidiary

As several news sites have been reporting (here a report from LinuxDevices.com), Qualcomm has announced the launch of an Open Source Subsidiary.

As usual, I very much welcome such a move. Qualcomm is one of those companies who have a very bad reputation in the Open Source and particularly Linux community. They have so far failed to provide user manuals or other reference documentation for any of their parts. They haven't even managed to publish reference documentation on the external interfaces such as the AT command dialect or the binary shared memory protocols that are used to interface the GSM/CDMA/WCDMA baseband in their product.

So when it comes to an Open Source project that wants to interoperate with Qualcomms hardware, they have so far been doing everything to make that as hard as possible. Neither the community as large has access to the information that it needs, nor do the Qualcomm customers get the respective document under a license that allows them to actually contribute to Open Source projects.

If that documentation was available, or if Qualcomm was actually working on FOSS licensed drivers and contributing those mainline, the support for Qualcomm's hardware in Linux would be much better - resulting in less time to market for companies interested in using Qualcomms parts in their products.

The actual press release does not indicate that this newly-founded subsidiary truly understands this. It speaks of hardware-optimizing the performance of mobile operating systems. That sounds like "we'll take the existing code, make a fork, do non-portable micro-optimizations and ship that to our customers". It does not mention actually contributing to the community or understanding the benefit that the Open Source development model.

I remain to be convinced. Let's hope Qualcomm has scored somebody with a lot of actual hands-on Open Source community experience to advise them properly.

Palm Pre: Nice UI, severe lack of functionality
Using the Palm Pre: Everything but an exciting experience :(

During the last week I've started to use my new Palm Pre (for those of you who're living under a rock: The Palm Pre is a smartphone powered by an Operating System called WebOS, which is in turn powered by the Linux kernel and lots of other "standard" Linux programs like glibc, alsa, udev, ...

This adherence to a more standard Linux userland makes the Pre much more attractive than the Android based products out there. Android is reinventing the wheel everywhere, and things that Linux users and developers have been taking for granted during the last five to ten years simply don't exist on Android.

To be honest, the experience was everything but exciting. More about that later. Lets' start with the positive side of things. Yes, I like the device for the following facts:

• it's using a not-too-ancient Linux kernel
• it uses a fairly standard Linux userland, that
• the development tools are also running on Linux (albeit proprietary)
• there is an easy way to access the command line of the device via USB
• there is software for re-flashing the phone in case it is bricked
• the WebOS "distribution" is built using OE and uses the ipk packet format
• they did not try to lock the device down from their users. You can easily be root on your phone, install additional ipks from third parties and own your phone

Which is what got me excited and made me buy one of those expensive devices.

However, looking at it from a strict user point of view, I am not very happy with it. It simply lacks so much in functionality that it is not even funny.

• No RSS reader

The Nokia web tablets had a working, built-in RSS reader even many years ago when the n770 was released. Given the importance of RSS feeds and blogs in todays web, I'm surprised that webOS does not ship with a RSS reader. To make it even worse, I could not find any third-party RSS reader for it!

• No Jabber / ICQ / AIM support

The messenger supports only SMS and Google Talk. WTF?!? What about the millions of Jabber, ICQ, YIM, MSN and other users? Don't you think they want to use their default messenger application with those accounts? This is particularly funny, since they're using libpurple for the actual messenger protocols, which is a LGPL'd library of the pidgin chat client. So the library has all those capabilities, but Palm decided to arbitrarily remove them in their LibpurpleAdapter program. Luckily that one is LGPL'd too, so removing the restriction is relatively easy. But not for a regular user!

• Some applications always want to use the cellular network, even when wifi is available

This is particularly stupid when using their e-mail client. While I'm at home or in some other area with wifi coverage, I don't want to squeeze every bit through a high-latency cellular network. Why not simply make that decision a per-application property that the user can set?

• Cheap mechanical quality

The mechanical quality is really disappointing for a device that sells for EUR 481. It's much lower than what one is used to from Nokia, Blackberry or HTC devices in a similar price range. As one example, the entire plastic of the device squeaks every time I carefully push one of the keys on the keyboard.

• E-Mail client does not support pre-downloaded messages in subscribed IMAP folders

A standard feature that every desktop e-mail program has: Pre-download and cache the message headers for fast listing / browsing through a mailbox. Not on the Palm Pre, where the interactivity of the mail program is close to zero, fetching every bit over a high-latency link. The entire point of using IMAP is to have local copies/caches and to not suffer the latency/interactivity penalty of e.g. webmail!

• Calendar offers no integration with standard calendar formats/servers

There is no way how you can simply feed data from ical or xcal calender data into the Palm Pre calendar. You can synchronize with Google and Exchange. WTF? Why do we have [more or less] standard file formats for calendar data? Exactly for enabling interoperability.

• No support for standards-compliant address books

You can import your contacts from Facebook, but you cannot import contacts from vcard files, or let's say from a LDAP based address book. Great. So I first need to disclose all the personal contact details from all my contacts, put those into Facebook (into the US jurisdiction and a company that I don't trust) to simply get my contacts on the phone ?!?

• Too low battery life

I can barely make it through one day even without making phone calls, simply having the e-mail client running. The battery is too small. I would not mind a bigger/heavier device in exchange for more power!

That is simply the user point of view. I also have many more technical points from a developer perspective, but that is probably better kept for another post. Meanwhile I'm not sure if the Pre was all that much of a good idea. The N900 is coming up next, and will be much closer to the standard Linux userland stack (including X11, GTK, Qt, ...) than the Palm Pre is.

Symbian kernel Open Source release and Tanenbaum

As most people have noticed by now, The Symbian Foundation has released the source code of their microcernel under an open source license. While any open source release of formerly proprietary software is something I warmly welcome, I doubt that it will take of as an actual open source project.

There's a difference between releasing software under a FOSS license and running a successful FOSS project. The latter involves a sufficiently large community of developers, ways how they can contribute, ...

Especially with special purpose code such as an operating system (kernel) for mobile devices, very few people will show interest as long as there is no actual hardware where they can run the software, without or with custom modifications. Sure, there will be academic interest and people who will look at the source code to find ways to exploit potentially existing security weaknesses, but no community of people who work on it since they will practically use it on their own device.

So what I'd do if I was the Symbian Foundation: I would release an actual mobile phone which is open enough for people to run (modified or unmodified) recompiled parts of the Symbian codebase which are now available as open source. This way it will be much more appealing. However, even at that point, many other parts of the system are (or even will forever be?) closed, limiting the amount of impact. Furthermore, since modified versions cannot be installed on any other regular non-developer phones, the impact of any contribution to the codebase can not be to the benefit of many people. Just compare that with contributing to the mainline Linux kernel, where a contribution will be used on at least almost every server/workstation/laptop after the next distribution (and thus kernel) update.

Another issue that I really was shocked is the following quote by Andrew S. Tanenbaum: 'I would like to congratulate Symbian for not only making the source code of its kernel open source, but also the compiler and simulation environment,' said Andrew S. Tanenbaum'

However, the compiler was not made open source. It is released as proprietary binary code, and is only "free as in beer" for organizations up to 20 employees. So either Tanenbaum did not really look at the hard facts of what was being released, or he was misquoted in a really bad way! That should not have made it into the final release, as it's now a damaging statement for both the Symbian Foundation and Mr. Tanenbaum.

By the way, according to a lwn.net comment thread, they're working on making it able to compile under gcc, and they're actually accepting patches, which is of course great.

Despite my negative comments: I wish them as much luck and success as possible with their new open source Symbian kernel. I personally just am not seeing it turning into a vibrant, community-maintained project - and I hope the founders of the Symbian Foundation did not start the project based on that assumption and will in the end perceive it as a negative experience when evaluating the open source move some years down the road.

One final note: The fact that they chose the EPL as license is really strange, as it prevents exchange of code with the major existing FOSS kernel projects (Linux, *BSD). Not that I think there is much to be exchanged, given the microkernel approach...

FOSS.in CfP running for quite some time

In case you have been sleeping throughout last week: On October 16, The FOSS.in Call for Participation had been released.

FOSS.in is one of my regular conferences, and probably the only event aside from the Chaos Communication Congress that I managed to visit in five consecutive years. I'm looking forward for this year's incarnation, and I'll definitely do my part to make the event more interesting :)

I hope everyone will now hurry to submit their proposals for talks, workshops and work-outs! It's a collaborative event, and it lives by your contribution.

Differential Power Analysis on mobile phone?

cnet.com reports some researchers succeeding in performing a differential power analysis (DPA) on a mobile phone in order to "steal cryptographic keys that are used to encrypt communications and authenticate users on mobile devices".

This sounds fishy. At least on GSM phones, the keys for authentication are stored inside the SIM card. And somebody claiming that within a mobile phone with it's many analog RF and digital circuits (causing interference and noise) he can still perform a DPA on the SIM card just simply sounds unreasonable.

I would like to see those results being fully disclosed and independently reproduced before giving them much credibility.

The current encryption session key is not used for authentication, it is very short lived (typically 1 to 5 calls before a new key is negotiated), and it is not considered very safe anyway. The phone writes it to the SIM card, and malware programs installed on the phone are likely to get access to that key anyway. So no need for a DPA here...

Letter to the European Commission opposing Oracle's acquisition of MySQL

As can be found here, Knowledge Ecology International, the Open Rights Group and Richard Stallman have issued a joint letter to the European Commission asking it to disapprove the acquisition of MySQL by Oracle.

I very much welcome this move. There clearly is a conflict of interest between Oracle's own proprietary database software offerings and MySQL. Sure, the community could always fork MySQL, but at what cost? Potential disputes about the trademark, being forced to rename itself, and confusion among the millions of users world wide (well, might just be hundreds of thousands).

Palm Pre GSM model source code available

Last night I got an e-mail by palm, that following-up to my request, the source code releases for the WebOS 1.1.2 and 1.1.3 releases have been uploaded to opensource.palm.com.

I think the response time was very quick, and I thank them for that. However, still sad that one has to remind them of it. Let's hope with future releases they have a fully automatic process for that.

Just to be very clear: The GPL does not state that you have to automatically have the source code on a web site. But the way how Palm's written offer is phrased, they say that you should visit the website to download the sources. In that case, the web site of course needs to contain the sources...

Additionally they also offer the source code on a storage medium, if you write them snail mail to a specific address - which is a good safeguard since the GPL says it has to be made available on a storage medium commonly used for software interchange.

ST-Ericsson Community Workshop 2009

Today, I had the honor to hold the opening keynote of the ST Ericsson Community Workshop 2009.

At this event, ST-Ericsson presented their Nomadik STn8815 SoC, as well as their work on getting the u-boot and kernel ports submitted back into the upstream/mainline projects.

As anyone following the linux-arm-kernel list will have noticed: For the last months, they have worked hard on cleaning up and submitting the code for this SoC. Like many people in the community, I personally appreciate this very much. Finally, ARM SoC vendors actively putting resources to become a "first class" member of the community.

The STn8815 is a ARM926EJ-S core based SoC, including a ST DSP for video codec acceleration as well as a number of standard peripherals such as I2C, SPI, UART, SDIO, etc.

The STn8815 reference software that they released today, includes 100% open source drivers for everything that runs within Linux, inside Linux or on top of Linux on the application processor. The codec implementations inside the DSP are closed source / proprietary. However, the infrastructure to communicate with the DSP, as well as the gstreamer/ffmpeg integration on the Linux side is fully open source.

The attendees of the workshop are receiving the NHK-15 reference boards, which have the STn8815 SoC plus a total of 384MByte NAND flash and 128MByte of DDR memory. There's also a number of peripherals that you expect in such a product, including LCM, SD card slot, Bluetooth, Audio Codec, and Wifi.

Unfortunately, the Wifi driver is closed source. However, the Wifi is a dedicated peripheral component. The use/choice of this Wifi chip on the NHK-15 is probably a bad design choice from an open source point of view. But: This proprietary Wifi does not affect the openness of the actual STn8815 SoC.

Included with the kit for the attendees also a full programming manual as well as register-level specification for the STn8815, as well as the complete schematics of the development board. No NDA required :)

As a summary: I welcome ST-Ericsson to join the Linux community and to provide Open Source friendly solutions, provide the documentation and holding this workshop. However, the STn8815 is already quite 'old' hardware, as it is still ARM9 based - while much of the competition is shipping ARM11 or Cortex-A8 today. Let's hope at some point in the future we will have more competitive hardware with just as much openness.

TI tries to stop alternative operating systems on its calculators by the DMCA

Apparently, TI has been trying to use the DMCA and U.S. copyright to stop third-party developers from working on or distributing alternative operating systems for some of their calculators.

The stock OS that TI is shipping uses a cryptographic signature process to prevent the user from booting any non-TI operating system. However, the signature verification was broken and people have managed to run their own software, developed independent from TI's software.

TI is not claiming that the DMCA DRM restrictions are applicable to this case, and that the signature process constitutes a DRM system. This is obviously bogus to any technical person. The TI firmware is not encrypted, and you can copy and run it on other hardware or an emulator if you please. The protection mechanism is rather the other way around: The hardware authenticates the OS.

The Electronic Frontier Foundation has taken up the case and is defending some of the affected people from the community against TI.

As you can see from the EFF letter to TI, the EFF cites a number of precedent cases where the courts have ruled in very similar cases that such mechanism is not a DRM system on the software.

That precedent summarized in the EFF letter is actually very exciting to me. It is directly applicable to all kinds of locked-down devices. Let's assume we're talking about a Linux-powered device like the Tivo, Motorola MAGX phones, the G1 phone (non ADP-Version). They all use GPL Licensed software that is cryptographically signed to prevent the user from exercising his Freedom to run modified versions of the GPL licensed program.

Precedent that indicates that such a system does not constitute DRM as protected by the DMCA means there is a lot more freedom for people to break such systems and freely talk about how it was performed, as well as distribute alternate software images for the respective devices - as long as the code they use is either their own or Free Software and does not contain proprietary bits of the device vendor.

Palm Pre privacy invasion

One great example of why we need more open source based mobile phones is that we can actually discover all the undocumented "features" of the devices that we use every day.

If I use a device for personal things like my private communication, my scheduling, contact information and similar, then I have to put a certain amount of trust into that device. I trust that the vendor selling this device will provide a device that is safe for me to use and where my information is stored securely.

However, the amount of closedness and control that equipment vendors and GSM operators traditionally have in the mobile world is a big conflict with my personal interest for privacy and security.

You can see this reflected by SIM Toolkit specifications that allow the operator to read and modify your phonebook, or with flash over the air where the operator is able to modify the software on your device.

In fact, in such cases the operators treat the device like they own the device, when in fact the customer has bought the device and owns it.

Since Palm's WebOS is [to a large extend] based on Free / Open Source software, we can analyze in more detail what they are doing. As it was pointed out in this blog post two months ago, they seem to regularly receive information when you were using which application, as well as the GPS coordinates of the phone!

This is outrageous, especially without any way for the user to switch it off - or even better: Have an opt-in, i.e. off by default but who wants it can enable it.

Palm has responded to it, but as that very same posting indicates: The Palm Privacy Policy is not even completely listing the information for which it is applicable.

I don't think Palm is particularly worse than other companies. But the question is: How do we know? How does the user know what his phone wants to communicate to the operator or the manufacturer without his knowledge or authorization? The only two ways I can imagine are:

• by having more open source software on the phone, so users can study the code, determine what it is doing and then modify the software to remove such privacy invading surveillance features
• by having more people with their own GSM/GPRS networks with projects like OpenBSC, where we can actually see from the network side what the phone is trying to do. Unfortunately GPRS support is still not finished in OpenBSC, but work is ongoing.

Since the Palm Pre units so far (CDMA and GSM) are not locked down, i.e. you can become root and modify the software, it will be much easier to have "custom ROMs" (where the name ROM is stupid since it is flash, ...)

I can only hope that people will quickly come up with custom Linux based firmware images for the Palm excluding the surveillance features.

In addition, everyone should write a letter to Palm, complaining about those features and the fact there is no way to opt out of them.

Palm Pre GSM Version sells in Germany - No corresponding source code

Some 4 months ago, I wrote about Palm shipping the Palm Pre CDMA version in a GPL incompliant way. You should assume that the company has learned about their mistakes and created opensource.palm.com as a site to host their source code, compliant with the GPL and other Free Software licenses

Yesterday, the Palm Pre GSM model started to ship in Germany through O2 Telefonica. The WebOS version installed on the device is 1.1.2, and they are doing an OTA upgrade to 1.1.3.

Both of those versions are not available on the Palm opensource website!

Again the same mistake!

I wonder how much this tells us about the development procedures and release management inside Palm. We know they use OpenEmbedded to build their packages and filesystem image. OpenEmbedded can automatically generate the source code tarballs (+ patches), so the entire process of putting them up at the website could and should be automatized. No manual intervention, no mistakes, no license violations.

I have asked my lawyers to send a letter to Palm, demanding immediate release of the complete corresponding source code. If they do not comply, I am prepared to take legal action against O2 who is distributing the devices in Germany. I desperately hope we do not have to escalate to this point. If we go there, I'd better not imagine how upset O2 will be about Palm and how this will affect their business relationship.

It is so easy for Palm to have that source code on their website. We know that for technical reasons (see above). Why are they deliberately exposing themselves to the legal risk? Why are they willing to accept all the negative PR from them not respecting copyright and the GPL?

Please don't get me wrong. I am not set out to continuously complain about Palm. I would like to see more Linux phones. But why do they have to do everything wrong they can do wrong? Why do they not have somebody to advise them on playing nicely with the legal requirements of the technology they use?

The txtr e-book reader hardware architecture released

Today, the Berlin-baased start-up txtr has released more technical details on their first e-book reader.

They have also released their developer website including a wiki and access to a svn server with sources as well as fedora11 based source and binary RPM's.

What's also interesting is that they have disclosed a hardware block diagram and a PCB footprint on their developer website before the product even starts shipping to the mass market.

As few of you will know, some my friends and colleagues are behind the system-level software and hardware R&D. The electrical engineering is done by Milosch and Brita of bitmanufaktur, with whom I've had the pleasure to work on OpenOCD, OpenPICC, OpenBeacon as well as for a dedicated assignment inside Openmoko. Andy Green of Openmoko kernel + bootloader hacking fame has also been involved... last but not least for porting Qi (originally developed for the never manufactured Openmoko GTA03 based on the Samsung S3C6410) to the Freescale i.MX31.

Report on the OpenBSC powered GSM network at HAR2009

I've finally finished the report on the GSM test network at HAR2009, which we operated with OpenBSC in August.

Lack of good Free / Open Source ASN.1 tools detrimental to FOSS in Telecom sphere

For years, I've been working with the GSM specifications by now. My contributions to wireshark, airprobe and most of all the creation of OpenBSC about one year ago further forced me to become very intimate with the various GSM related protocols.

Over the last month or so, I've been looking into some 3G/UMTS specific protocols such as RANAP, as well as more recently at various LTE protocols. It seems like they're more or less all specified in ASN.1 and use a variety of encodings, e.g. PER aligned and unaligned.

Not having useful tools like a code generator for parsing and formatting messages as per those ASN.1 specifications is a major turn-off for starting any Free Software or Open Source project in this area.

It's like having to start from designing tires if you want to build a car. asn1c is a start, but it does not support all the required encodings and even ASN.1 syntax that is used in the 3GPP specs.

I really see a big demand here, otherwise Free and Open Source software development in this area will be severely hampered by the lack of required tools for even more time.

If anyone is interested in helping out to change this, please contact me!

Netgear trying to fool their users with "Open Source Router"

Two days ago, Netgear has announced the so-called "Open Source" WNR3500L router, together with an equally "Open Source" MyOpenRouter community.

The problem with this Open Source router is: It ships with binary-only kernel modules. Not only is this extremely Closed Source, but it also

• has very practical security implications: You can never update your Linux kernel to get the latest security fixes, but have to run vulnerable old kernel versions
• is a very questionable legal practise. Netgear as the vendor is simply relying on the fact that none of the authors who have written parts of the kernel against which their binary-only module links will ever make copyright claims against them

One would have hoped that Netgear did thoroughly study the Open Source market that they're trying to address. Apparently they either did not do that, or they chose to ignore the values/rules by which this community works, or they had somebody with limited understanding to advise them on this.

If anyone has a relationship with Netgear and contacts to the product manager responsible for this product, I would like to ask them for an introduction to that product manager. I would be very happy to help them understand the embarrassment and PR impact that they are putting themselves into by releasing an "Open Source" product that is in fact legally questionable and proprietary.

There are people in the various communities (like OpenWRT or OpenMoko) who have a very clear understanding of what it takes to create a true Open Source product to address the Open Source market. Why are they not asking those experts?

Netgear, you can do much better than that!

Palm has noticed their mistakes

As has been described at TechCrunch, Palm has announced to fix their most prominent issues that many bloggers, including myself, palm has realized that they need to fix some issues with the way they are trying to over-control webOs development.

According to the TechCrunch article, Palm will allow people to write and distribute their own applications (though still you need some kind of URL forward from Palm), and there will be no registration or other fees for people who write open source software for webOs.

This is definitely good news. Let's hope the respective changes will be implemented soon.

Palm gives us a demonstration how they have _not_ understood Open Source

As you can see in this post by Jamie Zawinski, Palm is doing as much as they can to prevent any Free / Open Source application development on their WebOS.

One really has to ask himself whether they have completely lost their mind. This very Free Software and Open Source development model has created the kernel, libc and many other components of their software stack. So Palm can clearly see and experience the benefit this model has to them.

Yet they chose to deprive all third party developers and their users from that very same freedom by

• Not providing a way to install applications from third party websites or even physical storage media, thus
• forcing all application programmers to use their application store, and
• requiring that those application programmers do not disclose the software source or object code on any other website

This is so screwed, I literally want to bang my head on the wall for this level of stupidity. Can somebody please get some sense into Palm? They seem to have not only forgotten what has made their old PalmOS so successful (thousands of 3rd party apps that anyone could write + distribute), but also seem to lack any understanding of Free and Open Source software.

Migrating from Panasonic CF-R5 to CF-R8

I've just received my new laptop, a Panasonic CF-R8. As you may remember, some time ago I ranted about the lack of reasonably small laptops with decent number of pixel lines in the LCM. Since I was not able to find any other product that really qualified according to my requirements, I had decided to buy the CF-R8, the successor of my 3 year old CF-R5.

The specific configuration of this unit is:

• Intel Core 2 Duo CPU U9400 (1.4GHz, 3MB Cache)
• 4GB of RAM
• 320GB 7200RPM SATA drive (Hitachi HTS72323)
• Intel 82567LM Gigabit Ethernet
• Intel ICH9 chipset
• Full black color case / keyboard / everything

It's a nice device, the dual-core CPU and much faster/bigger hard disk as well as the 4GB RAM make a real difference. At the same time I still have the same 4:3 aspect ratio display, and the same keyboard layout, i.e. I don't need to get used to different location of function keys or the like.

Comparing it with the CF-R5, I think the following main differences have to be noted:

• the case design is more modern and looks more ruggedized
• on first sight, it seems a bit thicker than the old model, but careful comparison reveals that this is just an 'optical trick' and in reality the height is the same
• The battery form factor has been changed completely. This means that the display can be folded further back than it used to be the case. Great!
• There is no need for the pcc_acpi/panasonic-laptop ACPI driver in the kernel anymore, display backlight and function keys are just controlled using regular/standard ACPI methods.
• They did actually add a very small fan to the back of the device. However, it is so silent that it's actually hard to notice during normal operation.
• The new hard disk is even more silent than the CF-R5 one
• The power switch has been moved to the inside, i.e. under the LCM. This prevents accidental power-on/off while shoving the device into a notebook bag/sleeve. Again, a very useful modification.
• The old 100-Base-T Ethernet has been replaced by 1000-Base-T. 100MBps was pretty embarrassing for the CF-R5 even 3 years ago, considering my 3 years older powerbook G4 already had Gigabit Ethernet...

One week visit with Ben Dooks at Samsung System LSI

I have just spent one week with Ben Dooks (the mainline Linux kernel maintainer for the Samsung s3c24xx and s3c64xx system-on-a-chip devices) in Korea, meeting extensively with Samsung System LSI and discussing future cooperation and a way to get support for all Samsung SoCs into mainline.

This is a remarkable step, considering that in the past, Samsung was working on their own Linux kernel ports, done in a typical semiconductor-vendor style and not very mainline-compatible - while Ben Dooks was writing his own independent code, accepting contributions from various individuals and companies.

Now everybody was on one table, discussing and defining a strategy and workflow how we can achieve complete support for all Samsung SoCs in the mainline kernel. It was a very constructive discussion, and hopefully we can follow quickly with a just as constructive and productive integration.

I'll report back to this blog once there is some visible result in terms of 'show me the code'.

Flying with KLM: Feeling like time-travel to the past

Today I found myself on my way back to Korea. This time not on the Finnair flight that I'd used before, but on a KLM flight. What was a big surprise and almost a shock to me is that KLM operates airplanes on long-haul intercontinental routes (Amsterdam - Seoul/Incheon) which do not have a personal in-flight entertainment system in economy class.

I think the last time I have experienced this must have been 6 or 7 years ago. And actually, now that I'm thinking of it, even while I was working in Brazil in 2001 many planes already featured this.

How on earth does KLM think they can compete with that level of service? I mean, European airlines suck as opposed to Asian airlines, I have realized this... but even among European airlines I have not seen something like this for a long time.

It's not so much that I absolutely need the personal entertainment system. It is more a shock about how KLM can risk looking that old-fashioned against all of their competition.

Today, many of the planes on the EU-Asia routes that I frequently use already have the second generation of in-flight entertainment with the 7" or bigger wide screen displays, or even have 110V power outlets for laptop power supplies in every seat...

LiMo foundation analysis explains business value to merge changes upstream

The LiMo foundation has released an economic analysis that (among other things) explains business and economic reasons for 'deforking', i.e. contributing vendor-specific changes back into the upstream projects.

If you don't want to read the full paper, skip to Chapter 4.3 (Page 20) where they say things like: It is important that mobile industry platform providers engage with the open source communities as early as possible so that platform maintenance strategy is fully aligned with the upstream development agenda of these communities, which is far more cost efficient than managing the entire maintenance burden in-house.

Cancelling my trip to Linux plumbers conference

I might have told some of you that I'd be visiting Linux Plumbers conference this year, but unfortunately I'm not able to make it, despite earlier planning. There's simply too much work at the moment :(

So to everyone who will be there: Have fun.

My personal conference schedule for the remaining year 2009 is something like this:

• CELF Embedded Linux Conference Europe, Grenoble, France
• Linux-Kongress, Dresden, Germany
• Deepsec, Vienna, Austria
• FOSS.in, Bangalore, India
• 26C3, Berlin, Germany

I'm looking for Ericsson BTS (RBS) A-bis OML traces

After supporting Siemens (BS-11) and ip.access (nanoBTS) from OpenBSC, I'd like to add support for Ericsson BTS's (RBS).

What is needed to do that is to implement those 1% of A-bis that are typically vendor-dependent. And in order to do that, I'd need protocol traces of the A-bis OML (organization and maintenance layer) while an Ericsson BTS (RBS) is brought up. The data format doesn't matter, and the RBS model doesn't matter. My biggest interest would be in the RBS 2308, though - as this is what I can actually test with real hardware.

So if anyone is able to provide that kind of trace, it would help OpenBSC to grow more hardware support. Thanks in advance.

ST-Ericsson Open Source Community Workshop 2009

ST-Ericsson is the maker of an ARM based SoC family called Nomadik. Over the last couple of months they have been working with members of the community to get their support into mainline Linux and u-boot.

They have recently announced the ST-Ericsson Community Workshop 2009, a small event limited to only 25 seats, where members of the community, together with ST-Ericsson present on the development of GNU/Linux on their Nomadik SoC platform.

The workshop registration fee is 200 EUR, but it includes a full NHK-15 development kit for the Nomadik platform!

I really think ST-Ericsson is doing the right thing, reaching out to the community, actively trying to get their code mainline, plus providing subsidized development boards at a to interested community members.

If you're interested, make sure you register soon, seats are limited...

FOSS.in turning from Linux/FOSS only event into more general hacker conference

As can be seen from the FOSS.in/2009 "Omelette Post", in addition to the regular FOSS.in schedule until 5pm every day, there will be additional hacker talks until 10.30pm, which might not necessarily be directly connected with FOSS.

Since I'm personally a member of both the hacker community (in the very specific sense of working and uncovering weaknesses in communication systems) as well as a 100% Free and Open Source person, I obviously like this kind of combination. To me, both go hand in hand - even though I know not everyone will have the same opinion.

In the end, learning about and playing freely with technology is what both communities want to do.

I'm looking forward to see the FOSS.in CfP...

Wide-screen sucks for heavy terminal users

I've always been complaining loudly about wide-screen displays. 4:3 is much better for those of us who mainly work with xterms of 80 characters width (due to e.g. kernel coding style and e-mail conventions). The additional width is typically not enough for having three terminal windows next to each other, but the lacking height means way less visible lines of code.

This is why I'm still using my Panasonic CF-R5 (10.2" 1024x768 sub-notebook) from 2006. Despite it almost falling apart on all sides after three years of most intensive daily use, despite it feeling slower than any Atom based netbook that I've used.

So despite having tried an ideapad S9e, a HP mininote 2133, I can only deem them unusable for any serious without an external display.

Right now I'm desperately looking for a device that can be the successor for the CF-R5. I don't need much computing power, a Atom N270 would be the minimum but would work. I am happy with narrow keyboards as I'm using one for 3 years every day. I don't need tons of memory as I'm not using any bloated graphical desktop (just ion+uxterm). All I care about is Intel integrated graphics, a small device, ideally 10", with at least 768 pixels height.

It seems there are now 1366x768 based 10" netbooks, but all you can find is nVidia based Samsung devices, which are obviously completely unsuitable for, considering nVidia treats the FOSS community like crap.

I've spent half the day in Seoul's Yeoksam Electronics Market. The only thing that would remotely resemble my requirements is the ASUS eeePC 1101HA. But it's 11.6" wide screen, which makes the device considerably wider/larger than the CF-R5. Plus, the maximum memory configuration is 2G.

The other options is to buy a CF-R8. Still 4:3 ratio, almost the same size as the CF-R5. If only Panasonic was selling them outside the US. Yes, I know you can mail order them. But I'd love to have a look and try it before spending at least 1500 EUR on it.

So the Notebook industry still fails to impress me. Noisy (with fan) devices with ever wider screens. Apparently ignoring the fact that there are people who can imagine more interesting things to do with their computer than to play movies.

The reason for my trip to Korea: Samsung and mainline Linux

Some weeks ago, I wrote that I'll be again in Korea without mentioning any details. As you can see from this and this mailing list posting to linux-arm-kernel, I have the pleasure of assisting the Linux kernel team at Samsung System LSI with adopting a development model that follows (and contributes to) mainline Linux.

Despite all the enthusiasm this might now create among users of the various Samsung ARM SoC's, I would like to keep the expectations low for now. After all, "talk is cheap, show me the code", I will only blog again about this once we see the first code submissions coming from the Samsung team.

I'd like to thank Samsung System LSI for their warm welcome and their willingness to change. I hope the community will understand what a big step it is for an organization like this, and will take it easy in case the first code submissions still have some glitches here and there. After all, everyone of us has started at some point.

3G and: I hate ASN.1

I've recently spent quite a bit of time looking at 3G protocol traces and I already hate them. Why do they have to use ASN.1 PER everywhere? The 2G / 2.5G protocols are much easier to understand. You can look at the hexdump and decode it in your head. You can read the spec and understand what they do. You can implement them without thinking too much. But 3G with all its ASN.1 crap, sometimes even unaligned PER encoded? Simply impossible.

Why do people want to save a couple of bits, especially on the back-haul interfaces in the core network that shouldn't matter - at least not if you can reduce the computational complexity for the involved network entities _and_ lower the R&D cost due to easier debugging for everyone who ever implements or deploys such protocols.

Learning Hangul characters

Since I'm in Korea currently, and I'm expected to come back a number of times during the next months, I thought it might be a good idea to start learning Hangul, the Korean alphabet.

It really is surprisingly easy, there are only 24 basic glyphs that are combined in sets to form syllables. So it actually is less complex than the western alphabet, especially if you consider upper and lowercase glyphs (which Hangul doesn't have).

Of course being able to read the alphabet only allows me to convert from written to spoken language and back. Without any vocabulary, there's no way to make any meaning of the words - which is fine for me now. At least I can start to memorize names of locations/restaurants/shops this way. There really is almost no English writing anywhere - at least much less than I'm used to from my extensive time in Taiwan.

What I found particularly funny are the borrowed words from English. Things like Like "laserprinter" or even the names of the various fast food items at KFC really sound funny once you read them in Hangul and pronounce them (or hear them pronounced) ;)

GPL case in Denmark potentially involving NDS Viasat A/S and/or Samsung

As you can at this website, somebody has discovered what seems very clear GPL violations in a device called "Samsung DSB-H670N". At the moment it is not clear who is the actual cause of the GPL violation.

However, what is outstanding about this case is that an individual on its own tries to bring the respective companies into compliance. I think it serves as a great example what somebody can do even if he is not one of the clear copyright holders and just keeps insisting enough and communicating with the companies involved.

I'm definitely looking forward to see how this turns out. gpl-violations was not involved in any sort. We're continuing with many cases at any time, so don't worry. I just thought this particular action is worth mentioning to the interested reader. Maybe some other people get inspired by it and also stand up for their rights to the source code of GPL licensed programs.

HAR2009 is over

Running our own GSM network at HAR 2009 has kept me too busy to actually attend any lectures myself - apart from the A5/1 lecture in the GSM track just after my own presentations on OpenBSC and airprobe. So I'm hoping for the recordings to be available in some non-proprietary format soon. Apparently all they have now is some website with flash videos, something I'd almost call an abomination.

In any case, thanks once again to the HAR Organizers for obtaining the GSM test license. Thanks to the Agenschap Telecom for actually granting us such a license. And thanks to the many helping hands from the OpenBSC community, as well as the several hundreds of people who have tested the GSM network 204-42.

We shut down our operations at 2009-08-16 at 16:00 CEST. There were no complaints of either the regulatory authority nor the commercial network operators during the event.

We have complete debug logs of OpenBSC, as well as pcap files of all signalling data. In the weeks to come, we'll be working on extensive statistics on network usage / load, as well as relationship graphs i.e. who called/texted whom.

After a 7 hour car ride to my home in Berlin, and an 8 hour stop-over to pack my suitcases, I'm now currently in Helsinki enroute to Seoul, Korea. Following-up to my last trip in January, I'm happy to be able to visit the country at a time of much more pleasant weather (26-30 centigrade) this time.

I'm very excited about my work there in the coming months. As soon as there's anything I can state publicly about it, I'll keep you posted :)

GSM Security Workshop at DeepSec, Vienna

As David Burgess has been posting, we'll be running a joint two-day GSM Security workshop at the DeepSec security conference on November 17 and 18 in Vienna/Austria.

This will be an excellent opportunity to provide a comprehensive and in-depth view on GSM protocol-level security and its flaws, both in design as well as implementation. I don't think anything like this has ever been done before in the free/open world, i.e. outside GSM equipment vendor, operator or intelligence crowds.

So if you've always been looking for a deep tour into the subject, presented by people with IT security background who have actually implemented the GSM protocols themselves: Go ahead and register for the workshop.

OpenBSC powered GSM network live at HAR2009

Here at the amazing HAR2009 hacker conference + camp, I have the pleasure of operating a camp-wide GSM network.

Under license of the Dutch regulatory authority, we operate two BTS with two TRX each, forming the network 204-42. The BTS are positioned on the top of a hill, with the antennas mounted back to back on a tree, each covering about half of the HAR2009 camp site. Every transceiver runs at 100mW transmit power, which is the maximum output as per our license.

From that tree, we run AC power and a single E1 line down to the GSM tent, where it runs into the Linux PC that runs our OpenBSC software.

If you register first to the network, your phone will receive a single SMS and then get kicked off the network. Inside the SMS we send your IMSI and an authentication token, which you have to use on the HAR2009 GSM registry. After registering at this website, the SIM will be permitted onto our network for regular voice call and SMS service.

Right now, as you can see on our phone book, we have 391 authorized subscribers (out of a total of 1029 different IMSI's that ever tried to log onto our network)

The coverage of the network is good, we have only very few spots without signal reception.

OpenBSC has proven to work quite stable. We have the occasional segfault every 3-4 hours, but I'm at it, debugging.

Thanks to everyone who helped to make this a success, especially Stichting Hxx for obtaining the license and Daniel, Stefan and Jan for helping me with operation and debugging of the network.

Embedded Projects Journal

As it seems, for about one year there has been a new Embedded Projects Journal (in German). This magazine focuses entirely on FOSS embedded projects and open hardware. The idea is to have a magazine written by the community for the community. Plus, the magazine and all its articles are freely redistributable.

It's a pity that I've only noticed about this now. Let's hope more people learn about it, now that I'm mentioning it here.

If you want to contribute, feel free to contact the journal's makers.

FZ6 Fazer is beyond reasonable repair

As it seems, the cost of spare parts and labor to fix the engine of my recently bust FZ6 engine are well beyond EUR 4000, so there's no point in repairing it.

As it further turns out, the previous owner of the bike (I bought it in April last year) had forged some signatures in the service booklet, i.e. the motorbike has likely not seen the regular inspection and service like it should. Haven't yet decided whether to file any claims against that previous owner or not.

Now I've decided to buy a new one of the same model, and keep the old one for spare parts. At some point next week I should be the proud owner of a brand-new FZ6 Fazer. With three full years of Yamaha warranty. Hopefully this one will live longer than 17,000 kilometers.

Linux-Kongress date change - now longer collides with Linux Plumbers

As I have just received today, Linux Kongress 2009 has shifted its dates to October 27 through October 30 (and changed the Location from Hamburg to Dresden).

This is good news, since it no longer collides with Linux Plumbers Conference 2009 on September 23rd through 25th. I guess that many speakers and some attendees would otherwise have ran into scheduling problems - with many preferring Linux Plumbers.

Also, the Call for Papers is out, it runs until August 31st, i.e. you (yes you, the reader!) have more than four weeks of time to decide what kind of topic you want to talk about :)

OpenBSC talk at HAR2009

My talk about OpenBSC has been accepted at HAR2009 quite some time ago, I just thought I'd mention it here since the schedule now is public/online.

It's a pity though that HAR2009 is already sold out - but then better an early sold-out than an event where only half the available tickets are sold.

I'm looking forward to meeting up with other GSM hackers for improving the various projects such as OpenBSC, airprobe.org or other not-yet-public projects related to Free Software and GSM.

Playing with the new airprobe.org GSM receiver

Within the airprobe.org community, Piotr has recently a new GSM receiver codebase that he has developed. It seems like the reception/decoding quality is significantly better than gsm-tvoid, at least from my experience. But it might just be me using gsm-tvoid in a suboptimal way.

Today, Piotr has managed to fix some of the bugs regarding certain BSIC configurations, and I can also decode Um traces that were captured from a nanoBTS running with OpenBSC.

Piotr also has already integrated my old gsmtap code that I was hacking on during FOSS.in/2008. As I've also received in e-mail today: The pcap data link type for the GSMTAP header has been assigned.

I'm spending a bit more time testing the entire stack, but I'm confident the GSMTAP wireshark dissector can be submitted soon - closing yet another gap for GSM protocol analysis.

However, there still remains a lot of work to do for airprobe.org. I am willing to put in some time to help the gsm-receiver along, particularly for the layer2/layer3 decoding, which will then feed the channel configuration and CCCH configuration back into the upper half of layer 1 that takes care of generating MAC blocks from the actual GSM bursts.

GSM test license for GSM900 at HAR2009

I have just received the news that today the Dutch regulatory authority sent us the final "ACK" for a GSM test license during HAR2009.

This means we can use four ARFCN in the GSM900 band, each with up to 100mW transmit power.

We also will be able to use certain GSM1800 channels, but then I expect almost nobody has equipment to make use of it.

I have created a GSM wiki page in the HAR2009 wiki for coordinating GSM related activities at the camp.

If you are a bit familiar with BS-11 and/or OpenBSC and you're at the camp, please let me know. We can use any help you might be able to provide.

Legal dispute on OpenBTS has been resolved

There's only small message on David Burgess' blog, but according to it the legal dispute surrounding the OpenBTS software (the USRP+gnuradio based software defined radio "BTS+").

This is great news, I hope it makes it easier for OpenBTS folks to focus on their actual work rather than being distracted with fighting legal battles.

Launch of International FOSS Law Review

I'm a bit late with this, but the occasional reader of my blog might be interested to hear about the launch of ifosslr.org: International Free and Open Source Software Law Review, the only legal journal that focuses entirely on legal aspects of FOSS, which obviously includes license and specifically GPL related issues.

If you look at the editorial committee, you will realize many prominent names in this field.

It's very good to see this, as it means that more lawyers now have a resource for enhancing and sharing their knowledge about legal aspects of FOSS.

I have heard about this project from its beginning in the Legal Network of the FSFE Freedom Task Force. I know there has been a lot of (volunteer) work into the publication of this first edition/volume. Thanks to everyone involved, from authors to editors to people who took care of administrative issues.

Bad luck with motorbikes, episode 2342

Last night I was riding back to Hamburg (on my Fazer FZ-6) from a two-day visit to my home in Berlin. It was a pleasant ride, at least for about the first 210 kilometers. Suddenly at about 1am when I was riding at smooth 190kph (far away from full throttle), there was a sudden loss of engine power and the engine sounded as if it was running on 3 instead of four pistons. I immediately pulled over and used the conveniently placed highway exit. While I was getting slower I realized enormous amount of smoke (identified correctly engine oil that vaporized on the surface of the exhaust pipes). As soon as the clutch was pulled, the engine went off.

I then realized that a lot of oil had spilled to the rear wheel, including the tire. There was no other solution then having the bike transported to Hamburg in a van... Thinking about the possible cause, I thought of something along the lines of a blown cylinder head gasket. Arriving in Hamburg at roughly 4am in complete darkness, there was no way to dig any deeper into it.

This morning, in bright daylight I could clearly see the actual cause: An about 5x7cm wide hole in the engine case! WTF ?!?.

So it seems that suddenly, while travelling, the aluminum-cast engine case decided to blast a part off. Quite amazing. And that not at any particularly high rpm or under high load... let's see what the Yamaha mechanics will say about that.

So now I have a broken BMW F650 in Berlin and a Broken Yamaha Fazer FZ6 in Hamburg. And that in the best part of summer. *sigh*. The only remaining bike is in Taipei and not really of much use to me right now.

NerdAlert podcast / radio show

Today, I was invited for an interview with the German nerd alert podcast. The show was also broadcasted live via the free public FM radio station FSK Hamburg.

Much of the interview is about my work at gpl-violations.org, but we also covered quite a bit about Openmoko as well as OpenBSC. I had a good time in the more-than-one hour interview, despite it somehow being too short to cover more about the motivation and reasons behind each of the projects....

I'm not sure if the podcast is available yet, but I suppose it will be accessible from the homepage of todays show.

Wireshark packet dissector for GSM 12.21 (A-bis OML)

During the last weeks I've been spending some time to start a wireshark dissector plugin for GSM 12.21, which is the Organization and Maintenance protocol between BSC and BTS. Using this protocol, many aspects of a BTS are configured by the BSC.

I have already implemented the BSC side of 12.21 inside OpenBSC, and OpenBSC contains parsing code and debug logs about what is happening on this protocol. However, I think it is much better to remove most of that debug printing code from OpenBSC and move it into wireshark. Whoever needs per-message debugging, can start wireshark and look at the output - with the advantage of extensive filtering capabilities.

The protocol is quite complex and has many different messages with each their own set of attributes. So the current work is far from being complete, but it's already at a point where it is really useful.

I've put a specific focus on implementing the vendor-specific bits for ip.access, since those are hard to figure out and much more difficult to implement for anyone who hasn't spent as many weeks looking at hexdumps from their Abis-IP protocol as me. Parsing standard 12.21 messages is easy, just read the publicly-available spec and add wireshark code for it.

In case you're interested, the plugin is available from this path in the OpenBSC git tree

ip.accesss nanoBTS serial port CLI

As Dieter has recently discovered, the nanoBTS has an optional serial port. You need to solder two small bridges on your nanoBTS PCB and then you will get a RS232 port (at 3.3V) to the embedded PowerPC.

On this serial port, you can use an extensive command line interface (CLI) to display the status of the BTS, and for any kind of interactive debugging.

I only wish they had made that interface also available via TCP/IP :) Not many people will want to risk soldering their nanoBTS and thus loosing their warranty... it's not a cheap device, after all.

A description of the pin-out, including a picture for which solder bridges you have to set can be accessed in the OpenBSC wiki

Free Software Foundation Europe elects new senior leaders

A couple of days ago the FSFE has announced its new president, vice president and executive team. This marks a big milestone, since the former president, Georg Greve, has been the president for more than 8 years, ever since the FSFE was conceived.

As you can reed in Georgs blog, him stepping back as president has been announced at the assembly last year, giving the organization a full year to prepare and think about potential successors.

I want to thank Georg for his dedication and exceptional work during the last years. The FSFE has played a very vital role with regard to Free Software related issues on a political level in Europe during that time. Involvement with the WIPO, the Microsoft anti-trust trial, the software patent debate, just to mention a few highlights.

When the FSFE was started, I always hoped to find some time to get personally involved and to contribute to it - but it seems that my many technical projects as well as gpl-violations.org have been draining already more time than I had.

I wish the new team all the best and hope (and expect) the FSFE will continue to play an ever-increasing role in the political debate around Free Software related issues.

GSM wardriving has started

As you can see in this picture referenced by this blog post, somebody is having real fun using the BS-11 and OpenBSC for GSM wardriving.

Please note that the BS-11 is a 200W AC powered device, so you need the entire trunk full of lead batteries and a reasonably sized UPS to provide it with power.

There are much lighter setups using a laptop and a nanoBTS, but then those setups are likely a factor 10 more expensive (and provide less RF power).

But what this all tells us: GSM wardriving has started. More security researchers are looking into GSM security than a year ago, much due to the successful growth of a community around OpenBSC. Many people are only starting with GSM and mainly using/playing with the software, the number of actual contributers to the code is still small...

On a larger scale, you can see that GSM insecurity is finally going to become a much more popular topic, with more people able to demo the various long-known issues such as lack of mutual authentication and insufficient threat models/analysis during protocol design.

ScummVM settles GPL duspute with Mistic software

As you can see from this press release, ScummVM alleged Mistic Software and its distributors from infringing the GNU GPL in some proprietary games based on ScummVM.

As it seems, this case was now settled. The press release does not make any statement on how the actual GPL issues were solved (i.e. "where is the source code"), but I would assume they would not want to settle unless the conditions of the GPL are fulfilled...

If anyone has more information, I'm interested to learn about that.

Palm Pre wanted for FOSS hackers

A number of people from the various community-based Linux mobile phone projects (OpenEZX, gnufiish, freesmartphone.org, openmoko, openembedded) are interested in adopting the Palm Pre into the portfolio of supported devices.

If anyone wants to support those communities with Palm Pre hardware, please let me know. Right now, all the people I know are in Europe. Yes, we don't have CDMA hare - but those hackers don't care. All they want is to make sure you can build a number of different distributions on the application processor, and to support everything _but_ the CDMA modem in preparation for the GSM variant that is to be released at some future point.

Palm has released sources for WebOS 1.0.1

On this page, Palm has started to release source code + patches for a number of FOSS programs that they use in the Pre. I suppose the page is only an interim solution, since the entire site (nor the page URL) doesn't yet really seem to consider the fact of OS updates, etc.

Of course I have no idea yet if those sources can be considered complete and corresponding, but at least an initial look seems quite promising.

I've spent about 10 minutes looking at their 9 MByte (!) kernel patch against vanilla 2.6.24. The modem interface seems to be a UART + USB. The UART is required for stuff like waking up the OMAP3 from the baseband, and then you use it to set up a USB connection to the modem, where a hacked/extended version of the cdc-acm driver appears to be used.

I don't have time to look further into it, but I'm sure somebody with actual device hardware will - now that the source is out there.

Soon I'll say hello to Hamburg

Some of my friends already know it: I'll be spending some 6 weeks in the city of Hamburg starting from June 21st. I can't talk about details of the particular project that I'll be working on, but I'm extremely excited since it's related to what I've been most passionate about recently: GSM networks and their security. And no, it's not about any software development and it is completely unrelated to OpenBSC.

If you happen to be in Hamburg and want to meet at some time to hang out, feel free to drop me an e-mail.

OpenBSC now has an API for integration with PBX systems

In recent days, we have finally merged a series of patches from Andreas Eversberg implementing what we call the MNCC [mobile network call control] API. Using this API, it is possible to glue existing PBX or other telephony applications to OpenBSC and thus add GSM extensions to your PBX.

So far, only Linux Call Router (LCR) has been extended to use this MNCC interface. Andreas reports that he has successfully established both mobile originating and mobile terminated calls to GSM extensions of his LCR PBX.

It's great to see this kind of contribution, especially in an area which I personally am not all that interested in... I still want to focus on the actual GSM side of things and implement more features as well as work on stability, the vty/telnet configuration interface, GPRS support and the recently-announced plans for implementing an actual A interface.

Right now, other projects require more time slices, but I'm still spending quite a bit of work on integrating better SMS support, with actual store-and-forward of messages in our SQL database.

I'll be talking about GPL violations at LiSoG on July 1st in Munich

At the LiSoG meeting on July 1st, I'll be presenting on GPL violations and their international enforcement.

The LiSoG meetings have been repeatedly pointed out to me as some of the best Linux meetings out there, with a lot of professionals from the Munich area being present. I'm happy to be invited to join and present, even if it means I'll have to escape for a day from my most exciting project in Hamburg.

So if you happen to be in the Munich area and interested in meeting with a crowd of Linux people and/or interested in hearing about GPL enforcement efforts, feel free join.. But you have to to register [for free], as per instructions on the page linked above.

OLPC XO1.5 samples has arrived for VIA driver related work

I've just received one of the few precious XO 1.5 samples, since I'm supposed to be working with Chris Ball and others at OLPC to help them with getting the VIA hardware fully supported, e.g. integrating/testing support for the specific panel, etc.

It seems to be booting fine the current xo-1.5 branch of the OLPC git tree, and the basic operation of all major peripherals is fine. Stuff like power management and support for DCON are still requiring some work, of course.

Today I'm still busy with generic non-OLPC VIA driver related work, but tomorrow I can hopefully look into OLPC related issues.

Working on a new VIA graphic chip debug tool

As there are a number of confirmed bug reports with the viafb kernel driver, and I've been working on openchrome VX855 support, as well as OLPC XO1.5 support for viafb as well as openchrome, I've decided to write some better tool for debugging graphics problems.

The userspace tool will dump all the registers (currently only CRT / LVDS / DVI / Sequencer / Power management) and parse them into human-readable form. This way we can set a certain mode or display configuration, and verify what the respective driver[s] have actually done in the hardware.

The idea is to ssh into the respective system and run that tool, even if the actual monitor is no longer showing any userful output.

viafb still needs quite a bit of re-work, I'm not really happy with e.g. how it directly uses the I2C controllers rather than registering proper i2c client drivers. What's also sad is that it doesn't use the common kernel interface for modelines (modedb). Also, there are _way_ too many module parameters. I guess close to nobody but the original authors understand how to set all this correctly.

Since I actually have a CLE266 and CX700 system at home, I'll be able to test any new code or changes on those two as well as VX800 and VX855, which should cover all the major generations of VIA integrated graphics hardware out there.

You can see the early beginnings of that tool at svn.gnumonks.org/trunk/via-chrome-tool. Theres lots of uncommitted code not yet in that repository, will push it tomorrow after I'm back to Germany.

Updated via-sdmmc driver submitted to mainline

Today, I've submitted the latest version of the via-sdmmc driver to lkml and Pierre Ossman, the kernel sdmmc maintainer.

Since the last submissin in early april has not received many additional fedback, I hope we can make the 2.6.31 merge window. This has been once again taking way too long. VIA has to improve its turnaround time significantly in the future.

Palm Pre is shipping GPL incompliant

As it has been reported at many places online, the Palm Pre has started to ship as a CDMA model in the United States. However, as it seems, at this time it is not GPL compliant and thus a copyright infringement!

The Pre undoubtedly contains Linux and other GPL licensed software. So it ships with the GPL license text as well as a written offer indicating to obtain the source code. So far so good.

But if you contact the respective address, you get a response like this:

Hello Harald and thanks for your email.

We are in the process of preparing the packages and our modifications
to upload them to our open source web site - http://opensource.palm.com.
We expect to have all packages and modifications uploaded and available
to the public in about 2 weeks from today.

If you prefer to get the packages and our modifications on a CD/DVD,
please provide us with your mailing address and we will gladly ship it to
you as soon as they are available on our web site.

Please let us know if you have any further questions.

All the best,
Palm Open Source Team

I think it is a bad sign that they write they are in the process of preparing the packages and our modifications. This sounds suspiciously like "we didn't think about it early enough and now we need to reproduce the soruce code that was used for actually compiling the build that is installed on the devices".

Since when did the object code exist before the source code? If you compile e.g. the Linux kernel, you _have_ the source code before you generate the object code. So you should be easily able to make the source code available at the same time as the object code!

I would have expected much more from a company like Palm. If you as a commercial entity want to use GPL licensed software, you don't have to pay one cent in licensing or any royalties. All that you have to do is to make sure you have the complete corresponding source code that was used for compiling the actual binaries available at the time you start shipping the object code.

Providing a written offer and then delaying is not good GPL compliance practise and introduces legal [and thus business] risks that could have been easily avoided. Let's hope the source code is really complete and corresponding within those two weeks. And let's hope they never repeat this with another product, or with software/firmware updates for the Pre.

Palm Pre supposed to be closer to traditional Linux than Android

As you can read here, it seems that based on initial analysis the Palm Pre seems to be closer to what mainline Linux is doing that Android. That's not really surprising, but still definitely great to hear.

I can't wait to get my hands on the actual source code. If anyone has seen the written offer as provided by Palm, please forward me the contact information indicated in it so I can request the source code.

If anyone already has their complete corresponding source code (as per GPL), please upload to ftp://ftp.gpl-devices.org/incoming (write-only) and drop me an e-mail.

Linux kernel cpu_debug support for VIA CPU's

I've recently been hacking on adding cpu_debug support for VIA CPU's to the Linux kernel. The code has today been published in the via-cpudebug branch of my linux-2.6-via git tree, the relevant commit is available here as commitdiff.

cpu_debug allows you to read all existing MSR (machine specific registers) from userspace using a debugfs interface.

Let's hope this code will - among other things - help us to debug any power / thermal management related issuses. I'm now going to be working on a small perl script that can interpret the power/thermal management related MSR values into something human-readable.

Linux kernel hwmon driver for on-die temperature sensor of VIA CPU

Today I've hacked up (and posted) a hwmon driver that prints the current temperature of the digital on-die temperature sensor integrated in VIA's C7 and Nano CPU's.

You can get the code from the via-cputemp branch of my linux-2.6-via git tree. The code is also available as git commitdiff.

Let's hope this is another building stone in debugging any problems related to power management on VIA's CPUs.

OpenBSC on its way to get funded A-interface development

There is more commercial interest in OpenBSC than I expected initially when I started the project as a 'just for fun playground for GSM hacking'. Now we have received an inquiry from a company who wants to fund the development of an actual A interface to OpenBSC. This basically means that somebody wants to hook up OpenBSC to an actual real-world MSC (Mobile Switching Center) of an actual real-world GSM network.

The A interface is the interface between the BSS (BSC + BTS) and the higher levels of the telephony network. The interface is based on SS7 and lives on top of SCCP. There's BSSMAP, DTAP and OMAP. Both connection-less and connection- oriented modes of SCCP are required.

What this means is that OpenBSC's software architecture will shift even further towards the traditional GSM network architecture. So far, we have a "full GSM network from BSC to MSC/HLR in a box" approach. This makes it easy to implement, but is quite restrictive. You cannot route/switch calls to a different network, e.g.

The recent patches posted by Andreas Eversberg already introduce a software interface called mncc into the OpenBSC codebase. While those patches are not merged yet, they are introducing a functional split between the call-control entity on one hand, and the RR and NM as well as Abis RSL/OML functionality on the other side.

When we introduce the A interface, the functional split in the software will be driven even further. We'll first introduce an API at the traditional BSC/MSC split, and then write a BSSMAP/DTAP/OMAP protocol interface to that API.

One thing is for sure: We'll always keep the 'run everything in one box' mode around. This is still the most useful case for small-scale experimentation with GSM.

I'm definitely looking forward to see this project grow. We still have no agenda for things like GPRS/EDGE support, or any kind of handover. But then, development one step at a time is more healthy than trying to do everything at the same time.

I'm really excited to play with the A interface, and to interact with an actual MSC on a protocol level. This sort-of completes my ventures into GSM protocol land, from the Um (on-air) over A-bis to the A interface, one iteration up the network hierarchy at a time.

On my way to FreedomHEC Taipei 2009

In about 8 hours I'll depart for FreedomHEC Taipei 2009, an event where members of the Linux development community try to help Taiwanese hardware vendors understand the Linux development model.

I personally believe this kind of event could not be any more important. The traditional PC and embedded hardware industry still has a very, very limited understanding when it comes to properly supporting Linux, aiming at the universal solution for best end-user experience. In order to achieve this, the FOSS development model needs to be understood, as well as the value of going mainline with the drivers/ports.

Once that point is reached, there needs to be understanding _how_ to achieve that. Availability of documentation is another key issue. If you want to enable people to help you with development, bug fixing and maintenance, you need to release programming manuals for the hardware..

I'm happy to see that this year the organizers were able to get prominent speakers such as Jon Corbet from lwn.net, and Greg K-H who is doing marvelous work with his Linux Driver Project. Last, but not least, Peter Stuge will be presenting on coreboot as a FOSS alternative to legacy BIOS.

I'm also happy to see more native/local speakers, such as the presentations by jserv (aka Jim Huang) on Qi, the bootloader that was developed as part of Openmoko - or the presentation on VIA's experience of merging code mainline by Joseph Chan.

Openmoko announces Freerunner transitions fully into the hands of the community

As the CEO of Openmoko Inc. (Sean Moss-Pultz) has announced yesterday, there have been layoffs last week and the further development of the Openmoko FreeRunner (GTA02) will be tunred over to the community.

Openmoko Inc. will continue to provide funding for operating the infrastructure such as wiki/git/mailinglists/etc. Furthermore, the community explicitly has permission to use the Openmoko brand/trademark for their efforts.

I'd like to thank Openmoko Inc. and specifically Sean for all their support over the last years. It makes me happy to see a friendly transition into a pure community-based project.

Back to Germany, travel plans during next weeks and months

Just as a quick note, I'm back to Germany. Besides catching up with various aspects of work, I'll be visiting what I think is the world's biggest Gothic / Dark Wave / EBM festival, known as Wave Gotik Treffen over the extended weekend, and in less than two weeks I'm heading back to Taiwan for FreedomHEC Taipei 2009.

From the second half of June on I'll spend quite a bit of time in Hamburg on a customer project. I'm looking forward to using this opportunity to get to know the city better...

Some more VX855 work related to OLPC

Today I wrote a VX855 southbridge GPIO GPIOLIB driver, which is required by the OLPC DCON display controller.

I've also spammed a queue of 15 patches to linux-fbdev-devel, hoping that the majority of the viafb improvements/extensions can go mainline quite quickly.

What the XO1.5 DCON also needs, is a redesign of how viafb drives its multiple internal I2C busses, but this is not ready for submission yet.

Let's hope that this helps OLPC to get Linux up and running very quickly...

VX800/VX855 accelerated kernel framebuffer

I've been working long hours to hunt the remaining bugs in the code, but it's finally working: this branch of my git tree now contains everything needed for having 2D accelerated kernel framebuffer, i.e. fast scrolling console text without much CPU usage :)

On the way to get there, there was a lot of viafb general cleanup - but I'm afraid it is just the tip of the iceberg. There are so many duplicated structure members in the code that it is hard to know which one is supposed to have the current bit of data. But right now I already have 14 pending patches that need to go mainline, I'd rather not start piling up more right now. Maybe after things have settled.

The other odd bit is that on all VX800/VX855 system that I've had access to in the last days, I cannot get the I2C / DDC to work. Not with the kernel code, not with VIA's Xorg driver, and neither with Openchrome. On the other hand, using custom hand-crafted userspace code, I can set (and read) the SDA and SCL lines on the VGA connector and take the correct voltage readings with a multimeter. So my thought was: Maybe it's working slowly, but at faster speeds there's some capacitance/termination problem? Well, even if I slow down the clock rate to 1kHz, I still don't get it working.

VIA Integrated Graphics / VGA De-ja-vue!

Since I'm playing with the kernel framebuffer and openchrome graphics drivers for the VIA integrated graphics chipsets right now, I have a somewhat of a de-ja-vue.

In order to access the GPIO ports that are used for I2C/DDC, you need to use 8-bit I/O read/write to an indexed VGA register. You write the register number to 0x3c4 and you can read/write the actual data from/to 0x3c5.

This remembers me of the 1991 to 1993 time frame, when I was a teenager peeking and poking the registers of my then brand-new VGA card from turbo pascal programs on DOS.

I cannot believe that this kind of legacy is still around, in hardware that is produced 2009 :)

Intel (and Nokia) announces not-invented-here-syndrome

So Intel has co-announced ofono.org. It's clearly a sign that they are preparing themselves for times where we will see x86 SoC based smartphones or other mobile connected devices, which is good.

However, it just looks like a complete not invented here syndrome. It would be great to understand why on earth Intel did not just base on freesmartphone.org (FSO). Even if you don't want to use FSO's [current] implementations, they have spent man-years designing the d-bus based telephony API's and gathering experience with actual use cases as well as a variety of different GSM modems.

Neither on the ophone.org website, nor in their announcement I can see an explanatin of "how this compares to FSO and why FSO doesn't work for us". There might be valid reasons, but they would probably do good at publicizing them. I could also not see them publicly participating at the FSO lists raising those concerns and trying to get a compromise worked out.

So rather than working with an existing community of experts in the Linux telephony field, Intel and Nokia chose to create their own project. Is it desire for control? I'm really surprised of it, and would have thought better of both companies :(

Some VIA VX855 integrated graphics related work

Today I've managed to work on bits and pieces on the minimal support for VX855 graphics such as ensuring the viafb driver works on x86_64 builds as well as a preliminary patch to get VX855 supported by viafb.

I've also played a bit with openchrome and got it to the point where it can display X11 at various resolutions on a CRT (analog VGA out) including hardware accelerated cursor support. The patch is not yet posted, but I hope I'll soon find time to complete this.

Some more testing with the PadLock hardware on VIA Nano CPU

During the last days, I have finished my tests with regard to the hardware crypto part (PadLock) of the VIA Nano CPU. Now my kernel supports hardware rng, aes and sha engines in both x86_64 and x86_32 modes, at least as far as tcrypt and dm-crypt go.

The performance is quite impressive. It seems that AES256 ECB encryption and decryption gets something like 1.3 gigabytes per second with the tcrypt tests. And this is an evaluation board with probably some slow memory and a chipset that is not in its final silicon yet.

I'm not sure what the typical software implementation gets on modern CPU's without hardware crypto, but I'll do some testing by myself soon.

I'm also planning to write some paper about the performance numbers I get, extended with some figures for actual IPsec and dm-crypt workloads.

Marvell PXA310/PXA320 SoC manuals public

As it seems, Marvell has released the PXA310 and PXA320 developer manuals. They can now be downloaded and used by anyone, without a need for a NDA. This is great, as it removes one major obstacle for Free Software developers to write code (e.g. Linux kernel / driver code) for those System on a chip (SoC) devices. Marvell also re-released the PXA27x manuals, but this is of less significance considering that back when the PXA was still with Intel, Intel had the full manuals public.

Ti has done something similar, at least for the OMAP3530: Publicly releasing their Technical Reference Manual without any requirement for an NDA. Sure, it is only one of their many products. But I think they have been showing progress even on one of the older OMAP24xx product, as far as I remember.

Now the only major vendor of ARM SoC's for mobile handheld devices like smartphones that has currently no reference manuals public is Samsung. This is really sad, as their S3C2410/2440 manuals always used to be publicly available from their website. Now the S3C6400 and S3C6410 manuals are under NDA, effectively preventing anyone to develop Open Source (and specifically Linux) code for their systems. I sincirely hope they understand what a competitive disadvantage they are now facing in the Linux market.

Will have the honor to assist with OLPC XO1.5 bring-up

As you can see at the XO1.5 bring-up page, I've been invited to helping the various OLPC, Quanta and VIA folks with the bring-up of the XO1.5 board from OLPC.

I'm looking forward to doing some more x86 work. It is a welcome change after my predominantly ARM based work during the last years (Openmoko, OpenPCD, OpenBeacon, OpenEZX, gnufiish, ...).

OpenBSC: Support for multiple BTS / ipaccess-config

Today I've been working on adding support for multiple BTS to OpenBSC. This means, using the [still uncommitted] new code, we can now connect multiple BTS and route voice calls between them. The actual data structures and the bulk of the code were already designed in that way, but the 'input driver' still had a lot of assumptions about talking only to one BTS at any given time.

This feature is currently only available for ip.access nanoBTS, as there is no special need for switching the RTP streams of the actual voice data. The BTS send that data directly between themselves. Dealing with E1/A-bis based BS-11 is slightly more difficult, since the TRAU frames with the voice data need to be

Still, even with two BTS at the same BSC, there is still no support for actual handover. So a handset is either registered to one BTS or the other. This matches a situation where you might have multiple different locations (let's say two branch offices) with one BTS in each location and the ability to make voice calls between mobile phones registered to either one of the branch office BTS's.

Actual handover between adjacent cells is not something that I'm personally interested in, so I'll probably leave this up to some contributor who finds it interesting (or a company who wants to fund me for that particular work). Right now we have more important missing features anyway (like proper SMS store-and-forward).

One other small bit that I implemented today is the ipaccess-config command line tool, serving as a tool to perform the most important initial NVRAM configuration of a new nanoBTS. You can use it to set the IP address of the primary OML Link as well as the Unit ID. From that point on, the BTS connects to the BSC and all further configuration can be done from the BSC.

The best linux kernel commit message ever

As you can see at this patch, Stephen Hemminger has submitted what I would call the best Linux Kernel commit message ever:

In days of old in 2.6.29, netfilter did locketh using a 
lock of the reader kind when doing its table business, and do
a writer when with pen in hand like a overworked accountant
did replace the tables. This sucketh and caused the single
lock to fly back and forth like a poor errant boy.

But then netfilter was blessed with RCU and the performance
was divine, but alas there were those that suffered for
trying to replace their many rules one at a time.

So now RCU must be vanquished from the scene, and better
chastity belts be placed upon this valuable asset most dear.
The locks that were but one are now replaced by one per suitor.

The repair was made after much discussion involving
Eric the wise, and Linus the foul. With flowers springing
up amid the thorns some peace has finally prevailed and
all is soothed. This patch and purple prose was penned by
in honor of "Talk like Shakespeare" day.

Signed-off-by: Stephen Hemminger 

---
What hath changed over the last two setting suns:
  * more words, mostly correct...

  * no need to locketh for writeh on current cpu tis 
    always so

  * the locking of all cpu's on replace is always done as
    part of the get_counters cycle, so the sychronize swip
    in replace tables is gone with only a comment remaing

 include/linux/netfilter/x_tables.h |   55 ++++++++++++++--
 net/ipv4/netfilter/arp_tables.c    |  125 ++++++++++--------------------------
 net/ipv4/netfilter/ip_tables.c     |  126 ++++++++++---------------------------
 net/ipv6/netfilter/ip6_tables.c    |  123 ++++++++++--------------------------
 net/netfilter/x_tables.c           |   55 ++++++++--------
 5 files changed, 188 insertions(+), 296 deletions(-)

Thanks Stephen, you made my day :)

Without words

$ dig -t MX openmoko.com

Some notes about the FSFE FTF Legal Workshop

I'm currently on the train heading back home from Amsterdam, where the last two days I've been attending the 2009 Legal Workshop of the Legal Network of the Free Software Foundation Europe.

I have to admit that it was a big surprise to me that the constructive atmosphere and the quality of the presentations, panels and hallway discussions has even improved beyond the already exceptional level last year.

So even if some of the more technical readers of this blog would find it hard to agree: It can actually be a lot of fun to spend two days locked up in a conference room full of 40 lawyers :)

It was very clear that the Free Software license compliance has moved ahead quite a bit since its early days. We have had a number of independent lawyers as well as corporate legal counsels from various backgrounds, as well as some folks like myself with a very technical background but a vested interest in legal aspects of FOSS.

Let me report on some of the most exciting parts of the workshop, at least from my perspective:

• An official representative of WIPO reporting on their recent considerations regarding collaborative creative work such as FOSS and the creative commons projects
• Very insightful talks about software patents and the various new projects like the Open Innovation Network, LinuxDefenders, Peer-to-Patent, etc. I believe the significance of this work for the future of FOSS cannot be underestimated, no matter of which jurisdiction you are in.
• This year, two legal experts from Taiwan were attending and received considerable attention given the many problems that FOSS has both legally and technically with products from the Taiwanese industry
• Last, but not least, I have made some very interesting new contacts from people involved in Linux on mobile phones

Thanks a lot to the FSFE and particularly Shane's excellent work in putting the Legal Network and the conference together. Thanks also to the sponsors of the workshop, including Canonical and Black Duck.

Podcast about OpenBSC at Chaosradio Express

About a week ago, I had the pleasure of recording a Chaosradio Express (CRE) podcast about the OpenBSC project, as well as briefly addressing other GSM related FOSS projects such as OpenBTS and airprobe.org

As always with CRE, it was a most pleasant experience talking with the host Tim Pritlove and explaining the scope of the project as well as the overall how and why.

Unfortunately, unlike my blog (and most of its readers), the podcast is not in English language. But if you understand German and want to hear more about OpenBSC, I obviously recommend to check it out!

OLPC 1.5 to be using VIA C7-M CPU and chipset / VIA reference documentation

To many of you this might not be new. About a week ago, OLPC announced that they have selected a VIA CPU and integrated graphics chipset for their OLPC 1.5 hardware version.

I was expecting this to happen, not because I am working part-time for VIA or because I had any kind of insider information. As usual, I speak for myself and not for VIA. But for anyone who understands the x86 marketplace it would have been pretty clear. AMD's Geode is aged and slow, and there are not really any successors. Intel's product portfolio has recently become great for small mobile devices, but I would imagine the pricing is probably a bit too high for an extremely-low-cost product like the OLPC. Going for an embedded MIPS or ARM processor would rule out running a [un]popular OS from Redmond, and whether we like it or not OLPC is apparently looking at supporting such a OS, too.

Intel would obviously have been the perfect choice from the FOSS point of view, a lot of open documentation as well as GPL licensed and stable drivers in mainline Linux and X.org. VIA is not quite there yet, but I can assure you the changes are still ongoing.

Some people, most prominently John Gilmore have raised concerns about the lack of any public documentation for neither the C7-M nor the VX855 chipset. This is unfortunately still the case. The CPU data sheets should have been public for quite some time but haven't been due to resource constraints. And the VX855 manual is not yet public, as the silicon is still being verified. But as you can see from the publicly available manuals for the VX800/820 as well as the chrome9 2D and 3D graphics reference manuals (all linked from the OLPC wiki page now), the immediate predecessor of the VX855 already has open documentation, and this will not change for the VX855 either.

So rest assured that the documentation for the VIA chips to be used in the OLPC1.5 will be publicly available. I'll also try to get personally involved in the VIA/OLPC discussions and see what I can do to help both on the technical side, as well as helping with the interaction and mutual understanding of both sides.

Departing for the FSF Europe Legal and Licensing Workshop 2009

In about six hours I'll be travelling to the Second Free Software Foundation European Licensing and Legal Workshop in Amsterdam. I've been to the fist workshop last year, and it was an excellent event, with all the important stakeholders present. Corporate legal departments of companies that already had their fair share of GPL incompliance, independent lawyers and legal experts, as well as folks with a Free Software community background such as myself.

The FSFE Freedom Task Force has done quite a bit of work during the last year, and their Legal Network has been growing. So there are a lot of signs indicating that this years workshop will be at least as good as the previous one.

I'm especially happy that this year we have a legal expert from Taiwan among the participants. Somebody who understands both the Free Software culture but also has had contact with the Taiwanese Embedded Industry: Florence (Tung-Mei) Ko. Given the many GPL problems that we see in embedded gear that was developed in Taiwan, I think many people at the workshop will be interested in the experience and insight that she can share with us.

So for the next two days, I will once again have to put my glofiish reverse engineering, OpenBSC and VIA related work aside and put my gpl-violations.org hat on. Not really pleasant for the engineer that I am - but a necessity to help bring more GPL compliance into the industry.

Some updates on the gnufiish project

Over the last weekend, Stefan, Zecke and myself have been focusing on getting some work done for the gnufiish project. As usual with this kind of reverse engineering project, you never really know how long you need until you've cracked all the major difficulties.

The biggest issue with gnufiish is the lack of working support for the 3.5G modem in the device. Obviously, without such support the device is nothing else but a nice PDA. Disconnected from the rest of the world.

We still don't have a working 3.5G modem under Linux, but we have made the following progress:

• confirmed that the modem is attached over UART in addition to SPI
• learned that the modem uses some kind of binary protocol on the UART at least for firmware updates
• discovered the meaning of quite a number of additional pins on the debug connector, including the serial console. Almost all pins should be known by now.
• a preliminary u-boot port has been produced. It can be loaded via OpenOCD/JTAG and accessed over serial console or USB serial emulation. It doesn't yet have the full feature set as people are used from Openmoko GTA01/GTA02, but NAND and SD card access are working
• ported Werners Linux userspace s3c24xx-gpio tool into u-boot. This makes it much more convenient to play with the GPIO's without computing boolean bit masking operators in your head. And since booting into Linux userspace takes way too long right now, having this in u-boot really is the right thing.
• learned more about the various programs installed in the E-TEN ROM image, i.e. their initial loader, usb downloader as well as the Empire/Knight test environment.
• we discovered some bug in OpenOCD leading to problems with breakpoints, Zecke cooked up a patch for this.

If you're interested in the intermediate results / notes, feel free to check the M800 as well as 3.5G modem related pages in the wiki.

Will be in Taipei in May after all

Despite the cancellation of OpenTechSummit, I will be spending three weeks in Taipei soon (May 05 through May 25). I am looking forward to both the business side of this trip, as well as actually enjoying the life in this vibrant Asian metropolis.

I'll be doing some work for VIA, as well as some of my other customers and also be doing some gpl-violations.org related meetings.

Samsung Omnia: A phone suitable for (Linux) hacking?

Samsung is currently shipping a phone called Omnia, or more precisely, the SGH-i900. It is a touch screen only phone shipping with Windows Mobile. Recently at Mobile World Congress, Samsung has shown that there is a LiMo port to the Omnia. Obviously, this port is not available publicly, so there's no easy way to just re-flash any other Omnia.

However, as it seems some folks at xda-developers.com have booted a generic PXA3xx kernel on the device, which shows us two things: One, there appears to be no cryptographic lockdown, i.e. we can execute what we want on the CPU. Second, that at least a core kernel with framebuffer is already working.

I did some more research today, and put most of the findings at this page in the gnufiish wiki. Among other things, apparently a service manual has leaked, containing schematics excerpts, component placement and similar useful information. I've linked various data sheets of components that are used in the device.

As it seems, the big unknown part is the GSM Modem interface. It uses dual-ported RAM to communicate with a Qualcomm MSM6281 3.5G modem. Now maybe the shared memory protocol is similar or even the same to what Android/HTC/Google G1 uses. At least typically, if you roll out an architecture of a chipset like the 3.5G chipset, then all members of that architecture are likely to speak more or less the same protocol. Of course this is just guesswork, it yet remains to be confirmed.

With some luck I should receive one of those devices soon to do my share of reverse engineering.

Meanwhile, I'm looking forward to the upcoming weekend, where Stefan Schmidt and myself will try to finally get the SPI based 3G/3.5G modem interface of the E-TEN glofiish devices implemented on Linux.

OpenTechSummit Taiwan 2009 cancelled

I was very sad to hear that OpenTechSummit Taiwan 2009 had been cancelled by its organizers.

I was really looking forward to this event as an opportunity to provide some more information to Taiwanese hardware makers about properly supporting Linux and other Free and Open Source Software. On a more personal note, I was also really looking forward to spending some time in Taiwan again. It's currently questionable whether that will now happen in may, as originally planned.

New "linux/mobile" section

This is where I will write about stuff that happens with regard to Linux mobile devices after closing the linux/opemoko section.

Closing the "Openmoko" section of this blog

I have decided to quit blogging in this section. I have left Openmoko Inc. quite some time ago. Openmoko Inc. has announced to discontinue Linux smartphones, and I'm not interested in any Project "B".

For those who want to follow what I have to say about Linux on mobile devices, I have created a new section linux/mobile in this blog.

Cancellation of GTA03 / thoughts on OM Inc.

As you can see at lwn and h-online, as well as slashdot: Openmoko Inc. has discontinued smartphone related development.

It's good that there is now some official statement from the company. They way this came about was less than pleasant, though. There would have been a number of ways to avoid the need for discontinuation.

For me, things now finally come to an end. I still very much believe in the idea of having more open mobile phones, both on the software stack as well as on the hardware side. I also believe that there used to be a number of very good people inside Openmoko who could drive the development to create such open products. But over time, I have started to have severe doubts whether Openmoko Inc. is really the most productive and/or best environment to do this kind of development. Priorities and directions changed a lot.

So as of now, even though Openmoko Inc. states it wants to re-start smartphone development at some later point, I am happy that I can finally let go. I do no longer have to hope that Openmoko Inc. gets their act together to actually get an (to my standards) acceptable product out into the market.

The pain and suffering is over. The engineers behind the 'open smartphone project' are all "free" now, and they are more than ever interested in continuing the mission that they once set out to get done. Very much like me some time ago. I've never stopped believing in the idea of building more open mobile phones. I just started to doubt if Openmoko Inc can do that, which is one of the key reasons why I left a very key position at the end of 2007. Now my doubts are "complete". People can move on and try to find a way to get what they were fighting for - probably with less interference and no side-tracking and constantly changing priorities.

Now some people might argue that I'm trying to do Openmoko-Inc-bashing here. That is not the point. I, as an individual, have just expressed my doubts and my assessment of the situation. I've held back a lot of grief for a long time, trying to not interfere with the business of Openmoko Inc. But since the Openmoko project is an open source project, and it is developed and supported by a much larger community, I feel more connected to that community than to the company. I feel obliged to let them know my opinion, since I have more insight into the project than most other people have. It's a personal opinion, I don't claim that it is "the one and only truth (TM)".

TomTom settles with Microsoft on patent dispute

They were acting quick. TomTom and Microsoft have settled their patent dispute. Of course, it's business as usual. They have to protect the interest of their shareholders, and a lengthy patent lawsuit is probably creating too much uncertainty for business partners.

I don't particularly mind them settling their [sometimes ridiculously trivial] claims on car navigation systems. But the settlement also includes the long-filename-patent that e.g. has been dismissed by Germany's Federal Patent Court about one year ago on the grounds of being too trivial and ISO9660 RockRidge constituting prior art. So given that the highest patent court in Germany has already issued such a judgement, I would be quite surprised to see a completely different verdict in the US. Either ISO9660 is prior art or not. I doubt there's much to debate on it.

So well, MS will still uphold their implicit threat against anyone who uses Linux + VFAT filesystem in a commercial product. In the end, I hope, this will simply drive people away from using FAT or VFAT altogether. It's not that they are particularly great filesystems anyway... and vendors just want to make it convenient for _windows_ users to use their products by enabling them with VFAT.

OpenBSC:Work in handling incoming SMS

After returning from my holidays, I've spent the last couple of days hacking on improving the SMS support of OpenBSC. In order to facilitate the intended store-and-forward model, we now store all incoming SMS in a SQL table. Things like validity period or even more esoteric things like SMS compression as per GSM 03.42 is obviously still missing. I try to get it working fist, and leave the gaps to be filled later.

Next will be the code for sending a SMS from an entry in the SQL table, and invoking that code every so often, based on timers and/or events such as a phone registering to the network.

The trickiest part here is how to handle the paging code. We could have a phone call and a SMS, or even more events that all want to page a phone at the same time. There needs to be some kind of arbitration and a queue, deciding what kind of event will first get access to the SDCCH that we have after paging succeeded.

There have also been suggestions to split the SMS processing into a separate process, much like in a traditional GSM network. Sounds reasonable to me, but I am not very familiar with the existing protocols (like UCP) and implementations (like Kannel). So I'll probably leave that as a second step, making the OpenBSC internal SMS handling optional at some later point. UCP would obviously also ease the integration with existing SMS operators (vSMSC and the like).

FOSS.in/2009 event / venue / date announcement

Much earlier than in previous years, FOSS.in has announced the date + venue for the 2009 incarnation of the event.

The CfP is not out yet, but I hope it will also be out sooner rather than later, as scheduling long-distance travelling is something that most speakers prefer to do rather sooner than later. And you won't book your ticket before you know your paper has been accepted, etc.

I'm definitely looking forward to it. As the frequent follower of my blog will know, I've been there every year since 2003, which probably makes it the only conference (next to the Chaos Communication Congress) that I've been visiting that often in a row.

Openmoko [again] loosing some of their key engineers

I did not want to blog about it due to my intricate knowledge of Openmoko internals and my own past within the organization. But the news has made it to the various mailing lists now anyway: Andy e.g. is now longer working for Openmoko. He has been the main Openmoko kernel and bootloader developer (and maintainer) ever since I left in November 2007.

This is really sad news. There used to be really great engineers at Openmoko some time ago, but at least a number of good, senior folks are no longer working there at this point in time, or are working on a much smaller scope for Openmoko Inc.

Sure, it is not the right way to discuss the details of every HR matter in a public way. But I would have at least expected Openmoko to use the power they have to publish a statement on what this means _before_ the news get released in an out-of-control way by rumors and hearsay. If you allow this to happen, then you subject yourself to somebody else presenting their [distorted?] view of what he believes as reality first, and you (Openmoko Inc.) get into a defensive position.

True heroes at the German constitutional court

For many years, especially ever since 9/11 in 2001, German governments have been pushing very hard for so-called security legislation, removing civil liberties and enhancing the surveillance capabilities of the various government agencies.

The only sensible response is not coming from _any_ political party in the opposition. Neither the self-proclaimed civil liberties friends of the FDP nor the Green party are cutting it.

This, by the way, extends beyond just security/surveillance related legislation, but also e.g. with regard to the use of voting machines in federal elections. Only recently the constitutional court decided that the legislation as well as the actual devices used in the last election were unconstitutional.

The only people involved in the public debate who show a lot of reason are the judges of the German constitutional court (Bundesverfassungsgericht). Particularly the president of the court, Hans-Juergen Papier is a true hero to me, constantly fighting for the values of our constitution - not irritated by the general mood of the day or any hectic political activism by the government.

What is even more surprising: Mr. Papier is himself from a conservative political background: The Bavarian CSU party.

In recent times, there is an actual fight between Mr. Papier and our ultra-conservative home minister (Schaeuble). Mr. Schaeuble is now going as far as to publicly stating things like 'those who want to be part of legislation should aim for becoming of parliament' or 'i have doubts on how far it is constitutional what the constitutional court is doing'.

This is just unbelievable. How can the government afford to have a minister who openly doubts the legitimacy of the decisions of the highest body of justice in this country? If people really cared about justice and our constitution, it should be immediate grounds to dismiss this minister.

Enjoying holidays in Brazil

I've been offline for an entire week, something that rarely happens to me as long as I can think back. It has been great. I took the time to read Cryptonomicon again, and it was just as great as the first time. I also found sufficient time to continue my (still embarrassingly little) chinese studies, and had even more time to think and reflect about my life.

So all in all it is a holiday like it should be. Don't expect any news from me in the blog or by e-mail before March 26th.

Enjoying the BOSSA 2009 conference

This year's BOSSA incarnation has once again turned out as an excellent event. It was good to meet and talk again with a number of people like Marcel Holtmann or Rasterman.

This year it seems the organizers went out of their way to please every speaker. Since their conference shirts were available in three colors (but not black), they actually prepared a special edition of a black t-shirt for me.

It will be important to see how many other conferences can live up to that standard ;)

OpenBSC now has a Cisco/zebra/quagga style telnet interface

Since I'm currently at the BOSSA conference and thus basically on a break in my Brazil holidays, I decided I might as well get some work done and imported the zebra/quagga VTY code into OpenBSC. I used a fork of that code that I used some time ago for a never-announced (but in my public svn) 'cardshell' project.

What this means is that we now have a quite nice shell interface into OpenBSC, where you can interactively explore the data structures with commands like 'show bts 0', 'show e1_line' or 'show timeslot'. Over time, I hope we can easily add also interactive commands for [re]configuration, i.e. reconfigure the BTS on the fly, change administrative state via OML, or set TEI/timeslot configurations or the like.

Importing those bits from zebra/quagga has the advantage the we have things like a history and tab-completion without having to spend much time on it. Also, we can use the same codebase for saving/restoring the current configuration from/to a text file.

To give you an idea, it looks like this:

ideapad.de.gnumonks.org> show bts
BTS 0 is of nanobts900 type, has LAC 1, TSC 7 and 1 TRX
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Site Mgr NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Paging: FIXME pending requests, 100 free slots
  E1 Signalling Link:
    E1 Line 0, Timeslot 1, Type OML
    E1 TEI 0, SAPI 255

ideapad.de.gnumonks.org> show trx
TRX 0 of BTS 0 is on ARFCN 123
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Baseband Transceiver NM State: Oper 'RFU', Admin 0, Avail 'In test'
  E1 Signalling Link:
    E1 Line 0, Timeslot 2, Type RSL
    E1 TEI 0, SAPI 0

ideapad.de.gnumonks.org> show timeslot 0 0 0
Timeslot 0 of TRX 0 in BTS 0, phys cfg CCCH+SDCCH4
  NM State: Oper 'RFU', Admin 0, Avail 'In test'
  Bound IP: 0.0.0.0 Port 0 FC=0 F8=0

First couple of days in Brazil

I've arrived in Brazil for 2.5 days of Rio de Janeiro before heading to Recife and Porto de Galinhas for BOSSA 2009.

Rio actually was a much more pleasant experience than anticipated, and as far as I can tell after that short of a visit, I seem to like the city - at least much more than Sao Paulo which I felt was a big disappointment while visiting it last year for a similarly short period of time.

Being in Brazil always fills me with some kind of strange sentimentality. I've spent most of the year 2001 in this country, it was my first long-term experience in a foreign country. It was a great work environment at Conectiva, and times without a lot of the sorrows and worries that I am having today, working with hardware companies who often still not have noticed even remotely what was happening in the Linux world eight to ten years ago.

And I'm always surprised how well I can manage with those few bits of Portuguese that I learned during my 2001 stay. It's actually more than just barely managing, but being able to grasp at least the key aspects of most conversations, etc. And this despite not having had the slightest bit of practice between 2002 and 2007.

If only I could ever get my Mandarin to that level. Well, this is also the reason why I've brought my Chinese language books with me and I'm planning to study quite a bit in them during the two weeks of holidays following after BOSSA. With some luck I can also find some time in May or June to take up my language classes in Taipei again.

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.

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.

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.

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.

Using serial ports for binary protocols on UN*X/Linux

It's been a very long time since I've actually been touching any application code using serial RS-232 ports on Linux or similar OS's. If I think more about it, it's probably about a decade now.

So in the last couple of days I was starting a program called bs11-config, a small command line tool for initial configuration of the BS-11 GSM BTS, part of the OpenBSC project.

The longest part of that program was actually not the code for the program itself, but rather finding out how to properly configure the serial port in a way that it really is completely raw, i.e. doesn't meddle with any of the rx or tx bytes in any possible way. It's always amazing how baroque some of the traditional UN*X interfaces are - particularly something like serial ports which traditionally have only been used to transport ASCII characters to serial (hardware) terminals, modems or similar equipment.

In any case, it's now working just fine. No more need for any proprietary 16bit windows programs such as LMT (local maintenance terminal) for doing the initial configuration of a BS-11. What a relief.

What I found incredibly useful was the Serial Programming Guide for POSIX Operating Systems. Thanks, Mike!

I have back my old car

In late 2008, I 'sold' my old car (Opel Vectra) to a friend from the local Berlin CCC (starbug) for the symbolic price of 1 EUR. I didn't mind, since the car was not worth all that much, and it was for a friend.

As it turns out, starbug immediately said "if you need it back at any given time, just let me know". I never thought that case would happen, but due to recent events it actually happened.

So now I have my old car back, which makes the feeling of the Golf even more surreal. Owned a car for about 3 months of which I was probably travelling at least two, then suddenly lost it, and am back with the old car. Feels a bit like I'm back in the past, rewinding back to times that one thought were gone.

In any case, big thanks starbug!

German radio station to talk with me about GPL Violations

Tomorrow at 2pm CET, I'll have a live interview in the Breitband show at the nation wide Deutschlandradio station. The show covers the topic "Open Source and Business", and they want to talk to me for a couple of minutes about the side-effects of businesses getting involved with copyleft-style FOSS without respecting the rules as put forward by the licenses.

Photographs of my torched car

Today I arrived in Berlin and could take some pictures of what was my car:

As you can also see on the following pic, I was "lucky" not to be the owner of the Porsche next to it - apparently the actual victim of the attack:

What I cannot describe or show here is the actual smell of that burnt car.

Rest in Peace.

UPDATE: There's even a picture while it is still burning in the newspaper

Some idiots apparently put my car on fire

While I'm still in Taipei, I suddenly get a mobile phone call from the Berlin police department. It seems that somebody has parked a Porsche next to my car, and then some retarded people put that Porsche on fire, and the flames from the Porsche then torched my car (a VW Golf), too.

I currently don't know the extent of the damage, but it makes me quite sad, as I just had that car for some three months. Luckily I'm leaving Taipei today, just in time to get home tomorrow and have a look at my [partially?] burnt car.

Oh, and it still had one of the BS-11 GSM Base Transceiver Stations in the trunk. Curious to see if and how that one has survived.

So I'm returning to my home in Berlin. The car is torched. My BMW F650ST motorbike is broken due to some carburetor issue. And the Yamaha FZ6 is only registered from March through October for the summer season. *sigh*. Must be Murphy's law.

As if I didn't have other things to do.

UPDATE: The car is apparently completely burnt out, beyond repair.
Farewell :(

Taking the DX900 apart, taking PCB photographs

I've taken the DX900 apart and taken the usual PCB photographs. You can find them attached to the DX900 page in the gnufiish wiki.

In the process, I learned some new bits about the DX900:

• They have used a Sunplus 2.5G modem (next to their usual 3.5G modem design)
• They have added a second small CPLD (2C64)
• They are now using a Power Management IC (older glofiish don't)
• The DX900 does no longer have the standard glofiish test pad arrangement like all earlier devices
• There probably is no M900 (key-board version), since the PCB is now heavily using components and shielding covers on both sides, adding to the overall thickness of the device

Some reverse engineering on the E-TEN glofiish DX900

Today I've found a bit of time to start my reverse engineering efforts on the E-TEN glofiish DX900. In case you don't know what that is: It's E-TEN's latest PDA-phone model, 2.8" full-VGA touch-screen, GPS, WiFi, Bluetooth, 3.5G and dual-sim (it has a 2G modem next to the 3.5G modem). It runs the Samsung S3C6400 application processor. It is so new, that it doesn't even yet have FCC approval. Luckily it was available in Taiwan at PDA king for NT$ 16,900.

It seems like a great device. There's basically only one big flaw: It runs Windows Mobile. And it does that in a really bad way. From how sluggish and unresponsive the UI is, you can clearly see that they don't use any of the 2D acceleration functions of the S3C6400 hardware.

Now in order to get rid of Windows Mobile, we need to discover more about the device hardware. The first step for that is HaReT, the Hardware Reverse engineering Tool. Unfortunately the S3C6400 is so new that HaReT doesn't yet have support for it. So I had to dig into the code and add support for it. You can find the preliminary patch here.

The information that I was able to dig out using the first round HaReT can be found at this DX900 gnufiish.org wiki page. As expected even before touching the device:

• the 2G modem connects to a UART
• the 3.5G modem is SPI slave just like in the M800
• the wifi is still Marvell 8686 connected to SPI
• the GPS is still SIRF3 connected to a UART
• the buttons still are the same, some connected to GPIO some not

I won't have much time to work on this right now, as too many other higher priority tasks are pending. But it seems like the DX900 is a nice s3c6400 based device to play with, and a Linux port to it is not really further away than for the M800 or X800

deDECTed.org receives massive number of hits

One of the projects that I'm hosting (and which I've helped to initiate) on gnumonks.org is the deDECTed.org project about security research and analysis of the DECT protocols.

Like I've pointed out in many of my presentations and here in this blog, there are many communication systems in use today which don't even remotely receive as much scrutiny as TCP/IP, the Internet and the PC world. RFID is one of them, which is why I helped to get OpenPCD, OpenPICC, librfid and other projects started. My recent work on GSM protocol analysis as well as OpenBSC are of similar nature. And deDECTEd.org is doing the long-neccessarry scrutiny to evaluate practical DECT cordless telephone security.

As it seems, the news about the insecurity of most cordless phones has made its way into mainstream news, and the website is now getting thrashed quite a bit, despite running on a dual-core Opteron with quite a bit of RAM and fast SCA disks. Which is good. This means that people are indeed caring about the confidentiality of their cordless phones. It's a pity that the industry missed that fact and is shipping outdated technology way beyond todays state-of-the-art in IT security. Proprietary symmetric ciphers, weak RNGs, no user indication if the protocol falls back to no encryption, etc.

I've changed one of my e-mail signatures a couple of years back to a quote from the ETSI DECT spec: "Privacy in residential applications is a desirable marketing option". A Marketing option. Not something anyone would have to give much thought about. I hope the hardware vendors will now get sufficient public pressure to get their act together...

It's also great to see Patrick McHardy of netfilter.org fame now work on implementing a DECT protocol stack for the Linux kernel. Very exciting work.

The only sad thing is that all I can do is sit back and watch. I so much wanted to work on this project, but never got a chance. There are too many high-priority things going on, and I'm basically spending all my time in exciting (but unpaid) GSM protocol related work right now.

Presenting on Linux Coding Style / Mainline Merge and gnufiish at III

Today I was invited to present at the Taiwanese Institute for the Information Industry about two topics.

The fist talk was on How to write code compatible with the Linux Coding Style and submit patches to the mainline kernel, a seminar that I have given a number of times before, but which still raises a lot of interest.

The second talk that the III requested was surprising: About the gnufiish.org project, an effort to port Linux to E-TEN glofiish PDA phones. It is a very low-level hacker-oriented talk, and I was surprised that I should give it in front of an audience consisting of software developers working for "the industry". But I think it was received very well, and maybe it has made some people to start thinking about why people have to go to that extreme (reverse engineering) rather than some hardware vendor actually embracing the Open Source revolution and helping those people to make more software run on their devices.

Meeting Taiwanese RFID security researchers

Today I had the pleasure of being invited to have lunch with by Professor Bo-Yin Yang of Academica Sinica, Chen-Mou Cheng from National Taiwan University as well as some research assistants.

It was good to hear that they are working among other things on RFID security, and that they're excited about analyzing actual real-world systems. They also seemed pretty excited about the open source efforts in the GSM world, being a key milestone towards enabling more practical security research in that area

I hope to stay in touch and am looking forward to any publications in those respective subjects.

Talking to ASUS about preventing further GPL violations

Had a very productive meeting today with various representatives from ASUS about how to make sure they don't continue their rather unfortunate series of GPL violations in the last year.

It was a very good and productive atmosphere and I'm confident that they are now committing the required resources and effort in fixing the mostly organizational issues that prevent them every so often from fulfilling their obligations under the GPL.

But in the end, what counts are hard facts. Let's look at the situation again in one year and see what kind of progress one of Taiwans leading companies has made in this regard.

Why do all those netbook need to have fans?

This is a question that I've been asking myself ever since the first eeePC was released. Sure, there are other problems like bad keyboards and mechanical design (with the exception of the HP mininotes) and too small / low-res displays. But the question that bothers me most is: Why do those supposedly-so-power-saving new processors still need a fan in those systems?

I am the happy owner of a Panasonic Let's Note CF-R5. It was bought in September 2006, where it was already end-of-life. It does not have nor need a fan, the Intel U1300 (1.06GHz) CPU and the Intel IGP chipset are doing quite fine without it. So why are the supposedly less power-consuming later systems like Intel Atom built with fans? It's really annoying to me. I don't want this kind of noisy design. It sucks. It is a clear sign of bad engineering.

So far, the only replacement for the CF-R5 that I would consider is a CF-R7 or CF-R8. A netbook faster than the CF-R5 without fan could make me reconsider.

OpenBSC: Coding multiplex/demultiplex of TRAU frames

In order to make OpenBSC to actually support switching of the TCH (traffic channels) associated with voice an data calls, we need to implement the following bits:

• A 16kbit sub-slot processor that splits a given E1 slot (64kbits/sec) into its four sub-slots
• TRAU-frame synchronization inside those sub-slots (each of them has different alignment which might also change over time, depending on the distance of the phone from the BTS)
• TRAU-frame decoding (C/D/T bits)
• TRAU-frame uplink to downlink conversion
• TRAU-frame re-encoding
• multiplex of 16kbit sub-slots into E1 timeslot

I've been working on quite a bit of code for this during the last week, but its still not finished yet (and I cannot test, since I don't [yet] have a BS-11 in Taipei).

At some later point we also definitely need to add code to implement the timing adjustments which result from BTS transmit buffer fill level metering requiring us to advance or delay further frames by certain amounts of microseconds. For now I'm just ignoring this, since the BTS is required to buffer the data anyway.

Zecke seems to be debugging the paging code whenever he has time. With some luck we both finish soon and then finally have decent voice calls between phones.

More VIA related hardware manuals

Just as a quick update: VIA has silently released more hardware manuals about current-generation products at ftp://ftp.vtbridge.org/Docs/. We will try to make this the premier location for all hardware related documents, and will also copy those from linux.via.com.tw as well as those from x.org to that new site.

Once again, if you are working on some Free Software and require certain VIA hardware manuals, please contact me and I'll do my best to make it available.

Photos from Korean barbecue with Samsung System LSI kernel developers

Just in case you're interested: Kwanghyun La has put up some pictures from the barbecue that I enjoyed with the kernel developer team there.

An exciting week at Samsung LSI

I've just finished one exciting week at Samsung LSI (the group inside Samsung responsible for the System-on-a-Chip line like the s3c24xx, s3c64xx as used in Openmoko, TomTom and E-TEN glofiish devices). Specifically, I had one week of close contact with the team there developing the Linux kernel port and drivers for those products.

I do not want to go into too many details here in public, but it was a very productive week, and I think everyone involved is drawing a very positive conclusion. Let's hope the actual results from the now-improved understanding of the Linux and FOSS development model will be of mutual benefit to the community as well as Samsung. I'm also hoping for better and faster integration of Samsung's codebase into mainline Linux.

Parts of this Openmoko-triggered drive can be already seen on git.kernel.org, where Samsung LSI has started to push their current development trees to.

Since this is not the first time that I'm trying to lobby for more understanding of the Linux development process, the benefits of going mainline, etc. - I wonder if this kind of work should not be done in a much more scaled and proactive way by somebody like the Linux Foundation. Especially in the embedded world, there are many companies who are probably very interested, but just don't know where to start or whom to talk to. There just is no (or no easily identifiable) entity catering to their needs - and since they are always busy with developing new products and working on ports for other operating system, the initiative should probably come from the outside.

Right now this field is left to embedded distributors who have their own agenda and are always only representing a small fragment of the Linux stakeholders

First Impressions of South Korea

So today I arrived in South Korea, after a one day stop-over in Taipei (following a flight connecting in Abu Dhabi). I've arrived at about 6pm local time and had a 90minute bus ride to the hotel in Yongtong-gong. So besides check-in and a quick stop at the convenience store, I didn't yet do much.

Some first impressions, in no particular order:

• Heating like crazy. This first occurred to me in the airport, but became more of an issue in the bus. I was actually sweating with my long-sleeved shirt, without any jacket. The hotel has a default temperature of 28 degrees Celsius, not only in the lobby but in every room. you can adjust it, but as soon as you leave the room, it resets to 28. So the setting is not very useful, considering that a floor based heating has a very high latency, since the entire floor tiles are heated up and dissipate heat even hours after adjusting the temperature.
• The hotel clerk asked me in the elevator what kind of power plug my laptop had, and if I needed any kind of adaptor. Furthermore, he actually showed me the LAN cable and indicated "IP address automatic" ;)
• After a first try, that automatic IP address is actually a public IPv4 address. Wasn't there something about IP addresses running out in Asia? Weird, but definitely very welcome! Traceroute indicates all intermediate routers in Korea don't have any reverse lookup. Even more weird ;)
• The hotel room has flat screen plasma TV and a PC (running Windows, so I just disconnected the screen and run it in multi-head. Interestingly, the VGA and audio inputs of the plasma TV are connected with the PC at the desk, so you can play back video from the Internet or DVD's on your plasma TV. That's way better than crappy pay-TV in western countries :)
• Samsung is apparently so big, that they have a dedicated bus stopping at this hotel, taking people to the company twice every morning. A sign in every hotel room indicates this fact :)
• I totally love the sound of the language. To me, it actually sounds even better than Japanese.

So I remain thrilled what happens next. Not sure how much time I will have during the week, depends how busy it is at work.