25C3: Total Overload

In my 10+ years of CCC congress, I've never been trying to run any significant project at the hackcenter so far. In the first couple of years I was just hanging out there, chatting with people and working on stuff here and there, operating FTP sites (like the trial we once had with then-experimental ext3 vs. Reiserfs on machines with Gigabit Ethernet interfaces [I was operating the ext3 one]). The years following that I was trying my best with the audio+video recording and streaming - with mixed results, as all people from that time remember. I was just trying to help, digital A/V not being my particular area of expertise.

So this year I decided it would be a good idea to do some serious GSM protocol side development at the hack center, which would complement the talk I was giving on running your own GSM network.

So far so good. The only day where I really could hack the way I wanted was on Day 0 (the day before the event officially started) and Day 1. Friends with various backgrounds started to join and help with issues here and there. Everyone was excited by the numerous new possibilities a project like this provided.

However, starting with Day 2, and particularly Day 3 and Day 4, the amount of constant interruptions by various people was simply unbearable and brought the development close to a complete halt. Not only that, it caused severe lack of sleep, stress levels even beyond what I had ever experienced before, and I developed a cold and even some fever.

In general, I am completely disappointed by many of the crowds. I would have assumed that most people _know_ that frequent interruptions lead to inproductivity, and that they would also know and understand that a project that literally hundreds (if not thousands) of people are excited about cannot answer RTFM style questions that everyone would have been able to read up by themselves on wikipedia or similar sites. Sure, there were some exceptions to that rule. But overall, it was a very unpleasant experience.

So from next year on, I will certainly refrain from running any kind of project in the hackcenter. I will be a regular attendee, possibly speaking on some kind of subject or the other, preferably on the last day so people won't drive me nuts with their never-ending questions.

The DDoS attack on the GSM/BS11/OpenBSC hackers, combined with the overcrowded 25C3 has in the end led to a point where the only two talks that I've been able to attend were the ones in which I was speaking.

"Thank you" :(

Announcing project OpenBSC

Yesterday I was co-presenting with Dieter Spaar on Running your own GSM network at the 25C3. The talk went quite well, and received an overwhelming response.

Together with the talk, we also announced, described and released the current development version of OpenBSC, a software implementation of the minimal subset of the GSM BSC/MSC/HLR in order to get a GSM BTS up and working.

The code is available in svn, there's a wiki describing it's current status and features (or lack thereof).

If you're at the 25C3: Don't miss the DECT talk

If you're at the 25C3, I strongly recommend visiting the DECT security talk. Trusty me, you won't be disappointed.

It's one of the most exciting thigs that I've been seeing happening recently. Finally, some more people transcending beyond boring Internet security and moving into other areas of communications security that are desperately needing more research.

The "Deutsche Bahn" experience

Given that I'm a person who constantly interfaces with a very international crowd and travel a lot, I used to be quite positive about the great railway system Germany had. The comfortable travel in high-speed trains, with power outlets under your seat, from one city center to another city center faster than you would ever be with an airplane. Just enter a train, sit down, hack for something like five hours straight the entire trip.

Now I know that the railway company "Deutsche Bahn" has had its fair share of trouble in recent months with technical problems and what not. But given the fact that those problems (resulting in less trains/cars being available) exist for some three months now, I would suppose that they deal with this properly

Having said that, the online ticketing and reservation system made a reservation in a car that doesn't actually exist in the train that I'm using today. So I was confident that I had a reserved seat for the five hour trip back to my family in southern Germany. What a misconception :(

How difficult can it be to update the reservation system with those trains / car numbers that actually operate? Or at least refuse to make reservations at all, if you cannot guarantee them? It would probably be a couple of SQL updates here and there in the database.

This is not the kind of quality that I expect from DB. And I won't even start to complain about the complete lack of heating in this particular car. There we are in hyper-modern, super-silent train cars at 200+ kph, in the middle of winter, without heating. Yes, I can wear a jacket, sure. But my fingers are freezing from typing at this temperature. And no, gloves + keyboard don't make a good combination. Maybe I should start bringing an electrically powered heater net time, given the fact there is a power outlet...

Some more progress with the BS11 Abis (BSC) implementation

Very infrequently I've been reporting about my humble attempts in talking the A-bis protocol to the Siemens BS11 microBTS GSM base station.

Since Dieter Spaar and myself are going to have a talk about this at the 25C3 in a couple of days, I'm currently working every minute of each day to get that Free Software BSC-side A-bis implementation going.

While the actual code is getting more and more in shape, I'm now back to fixing the underlying infrastructure: mISDN. The mISDN kernel code base is _really_ hard to understand... if I have problems with it - despite about a decade of experience with network protocols and Linux kernel development - then that probably says quite a bit about it. It would definitely benefit from quite a bit more documentation. Anyway, it's FOSS, so no reason to complain. Use the source, Luke.

So just about one hour before I had to leave to travel to my parents (where I could not take a 48kg GSM BTS with me) I finally had mISDN in shape to be able to support multiple TEIs with different SAPIs on the D Channel of timeslot 1 of the E1 interface carrying A-bis. My userspace code was happily sending and receiving OML (Organization and Maintenance Layer) and RSL (Radio Signalling Link) frames, while the L2ML (Layer 2 Management Layer) is entirely handled by the slightly patched TEI manager that mISDN has in the kernel.

Funny enough, after initializing OML and RSL, the first unsolicited message I got was the error event report about the 'intrusion detection' at the BTS, since I was operating it with open connector panel ;)

So now I've returned to the actual BSC/MSC subset implementation. I'm still confident to finish something that can handle reliably handle voice calls between two handsets registered to that BTS. All on one TRX, no frequency hopping, not using any A5 encryption. POGS (Plain-Old-GSM-System).

I'm very excited about everything that I've learned about the various higher-layer parts of GSM in the last weeks since FOSS.in.

Let's hope that our software plus the presentation at 25C3 can trigger other people to show similar enthusiasm about this topic. There's an almost endless number of opportunities for GSM related security research out there.

Klangstabil in concert @ Schlagstrom

Last night was the greatest fun I've had in a long time. I've attended a Klangstabil concert as part of the Schlagstrom Industrial/Noise events in Berlin.

There is probably not much music that provokes as many endorphines to be released in my body as some good, loud, noisy and rhythmic electronic music :) Klangstabil have been one of my favorites for quite some time, but this concert was the first of their concerts that I actually attended. Now after it, I'm asking myself why. Probably due to the fact that contrary to some others I actually think the latest album "Math and Emotion" is great. Will make sure not to miss another concert in the future. promise!

I remain speechless, fascinated, moved. Happy.

FreeSmartphone.Org (FSO) developer meeting in Braunschweig

Yesterday I had the pleasure of attending a developer meeting of the FSO core developers Mickey, Daniel, Stefan and Jan in Braunschweig, Germany.

So far my actual involvement with FSO code has been minimal, apart from some profiling here and there, as well as a couple of comments/opinions, mostly offline and not on the mailing lists. I think this is sad, since FSO is the best thing that ever happened inside Openmoko. Focussing on the actual platform/architecture/middleware, standardizing and implementing the interfaces by which application programs interface with the actual device.

So while I haven't been able to contribute much to the python reference implementations, I hope I can contribute a bit more in the future. Also, my involvement with Swisscom Innovations as well as the gnufiish project will probably sooner or later drive me into touching some more FSO code.

It was good to hear the various reports and to see how much thought is given to the various details. Most notably was the quite lengthy debate about how a suitable battery / power supply API should look like. The devil is in the details.

As far as my actual work at the meeting is concerned: I've been asked by the FSO guys to show them how to play back PCM audio into a GSM voice call, and how to record a GSM voice call. Allegedly nobody has ever done this inside Openmoko again, after I demoed it ages ago, most likely still on GTA01.

The resulting information can now be found in the wiki. Unfortunately the actual capture is not working, apparently due to a ASoC driver kernel bug which I tried to debug but gave up after some intermediate results, since my understanding of the audio subsystem is limited and I have tons of other tasks.

The other bit I've been working on is a serial port LED trigger, i.e. the ability to make a LED class device blink if RX or TX activity is detected on a serial port. The code is not finished yet, but will be hopefully soon.

We've also been talking a bit on how to integrate keyboard-based devices with FSO, i.e. how the framework should indicate this to the window manager. The key part is that we're not as much interested in the actual existence of the keyboard, but the fact of whether it is slided out or not (for devices with a slide, such as the glofiish M800 or the TyTN/Kaiser).

Some further bits were spent with Stefan trying to hook up the libertas GSPI driver with the S3C24xx SPI host driver in order to get WiFi to work in project gnufiish.

First-time visit to (South) Korea in January

Despite being a business trip (more details might be disclosed later, after it has happened), I will talk about this in the 'personal' section of my blog.

I'll be in Joungin-City and Seoul for about 10 days in early January. Most of them are probably spent with busy working days, but the weekend is definitely free for some sight seeing and the like.

I've always been excited about Korea (for whatever reason), and it is definitely one of the major countries in South-East-Asia that I haven't visited yet. I know it is culturally very difficult and probably hard to get adjusted. Some business travellers rank it as higher difficulty than Japan, let even aside China or Taiwan.

In any case, I'm happy to go there and get a first impression. Too sad that it's the wrong (cold) time of the year. But well, the first trip doesn't have to be the last.

Some almost two more weeks will be spent again in Taipei, where I am looking forward to some exciting appointments, before I seem to be heading for some more work in India in February, potentially visiting FOSDEM before.

VIA submits SD/MMC driver to mainline kernel

Just a quick note, one more GPL licensed Linux kernel driver from VIA is on its way to get integrated into mainline: The SD/MMC driver.

Sure, there is some minor feedback with requests for code changes here and there, but generally the code looks good, so the journey into mainline could be fast.

Please note that I was not involved in writing the driver or any review. VIA's engineers have done this entirely on their own.

glofiish M800 keyboard driver

I've been hacking on a glofiish M800 keyboard driver, and most of it is now implemented. Even the Caps and Fn LED are in operation, and sliding out the keyboard causes a led_trigger to enable the keyboard backlight.

However, I still get the timing wrong when to read the CPLD. In most cases it works, but sometimes I get bogus characters and the like. Also pending: A more comprehensive keymap, plus support for the Fn-shift-key.

Free Software Foundation lawsuit against Cisco

As covered at lwn and other sites, the Free Software Foundation (FSF) has filed a lawsuit against Cisco. This came as a big surprise to me, but a very welcome one.

At gpl-violations.org, we had our fair share of dealing with Cisco (and particularly Linksys, a Cisco division). Never we have received any entirely satisfactory response. Sure, when you notify them of some GPL infringement, they will take some steps here and there. But in all those years, I have not seen a case where there was a thorough response. Whatever was disclosed as 'GPL source' was incomplete, didn't compile, and with the next firmware release there was again no source code for that new release. And then came the next product, sourced-in from a different OEM, and the entire process had to re-start from scratch.

Yes, they have gone and hired some engineer[s] to explicitly deal with the GPL related issues, like they have taken other steps in the right direction. But it was always superficial. Never addressing the problem at the root, i.e. have a proper in-house business process and supply chain license management to ensure the next product is not yet again a copyright infringement on GPL licensed software. It is so easy to resolve at the source, and so hard to fix later.

So the FSF's decision to take this problem to court is the most appropriate response that one can think of. A company of the size of Linksys clearly has the manpower, skill and resources - as well as the economic power on their suppliers - to once and all resolve any GPL licensing issues they might have. Not only to the bare minimum that they might think, but all the way to leave any legal grey area whatsoever. Only if there is a demonstration of a _factual_ legal risk rather than a virtual legal risk, they will get the motivation necessary to just 'stay clean' and not try to bend the license to its extremes.

So you might think "why did you (i.e. gpl-violations.org) not take it to court?" For once, I only hold copyright on certain parts of the Linux kernel, and not for large amounts of code they use. Also, a number of the particularly problematic products were not shipped into the German jurisdiction, and thus a case could not be made over here. Furthermore, many of the violations are not as clear black or white as most of the other cases that we take on. So the amount of work and resources required in such a case would probably draw away too much attention from all the other cases that we have.

But once again, I really welcome the FSF's action. It's funny how the historic cycle closes. Originally I started gpl-violations.org because I thought the FSF strategy was not aggressive/efficient enough in making Linksys/Cisco GPL compliant in the infamous WRT54G case five years ago. Now, it seems that even the tolerance and patience of the FSF has found an end.

Oh, and don't get me wrong: I never wanted to criticize the FSF for what they did back then. They had and have their own strategy of what they think about their own copyright. It's just that my strategy was different. It's up to every author or rights holder to decide which legal strategy fits best.

ALSA SoC driver working on E-TEN glofiish M800

After some hacking on this on the airplane back from India, and some finishing touches today, the audio output on the M800 is now working under Linux. The AK4641 codec driver and M800 ASoC device driver are to be found in the gnufiish git tree.

What I yet have to verify are the interconnections with the GSM Modem audio, as well as the FM radio. At least general audio playback is working, both through the earphone and ringtone speakers, as well as on the headset.

Received a Google/Android/T-Mobile G1

Due to a friendly person in Taiwan, I have now received a Google/Android/T-Mobile G1 device. Not that I'm interested in actually using it as my regular phone, but just to play a bit around with it. I've already had a chance to use the device for a bit, and I think it's surprisingly unimpressive. Mechanical quality of the swivel and keyboard is OK but definitely not as good as e.g. the HTC Kaiser/TyTN2.

What I'm much more interested in is to confirm my my earlier suspicions on the lack of openness of Android, or at least the actual devices based on Android.

As it seems, in fact it only accepts cryptographically signed kernels, and the signatures that are accepted are not signatures of the user who has bought and owns the device, but rather the signatures of Google/Android/T-Mobile/HTC.

I still think it's extremely weird that you actually buy a device, and then don't own it. I would have no problem if the device is rented from the manufacturer or the mobile network operator. Sure, then in this rented device, only they control what kind of software you use. But this is not the case. People buy it, pay money, legally own the device but technically don't.

I've seen that there are some hacks, including one one that puts the engineering bootloader on the G1. Sure, there will always people who exploit known security issues in hardware, ROM or software, just like the guys who work on Linux on the iPhone, or the now-proclaimed-dead Motorola MAGX platform. However, this doesn't address my point. Those kind of hacks will be closed at least with the next hardware release, and they can only be performed by a really small portion of the actual users (owners).

A truly open device (including mobile phone) has to give the user the freedom of choice what code he runs... Just like on the PC. You can run any OS you want, any App you want. Hell, you can even go ahead and write your own OS if you want. And the G1 is definitely not giving you that kind of freedom.

GSM hackers meeting at 25C3

There's going to be a meeting of various GSM related hackers at the 25C3. This is exciting, finally some more folks in the FOSS community who are looking at the protocol stack side of things.

We currently loosely coordinated using the wiki page at the 25C3 event wiki.

Back to Berlin

After almost one month of travels (Berlin->Paris->Bangalore->Delhi->Taipei->Delhi->Bangalore->Mumbai->Bangalore->Paris->Berlin), I'm finally back to Berlin. It always feels good to be home, and in fact I'm probably home for more than three consecutive weeks, something that doesn't happen very often.

It has been an exciting time, and I've made quite a bit of progress on both the GSM scanning side as well as on the gnufiish (Linux for E-TEN glofiish) side. Still, lots of work remains, and it's a challenge to see how much time I can spend on it.

During the next couple of weeks I'll be working on VIA related stuff. Most of it is behind-the-scenes work, but I'm also actually going to work on some actual code again. What a relief ;)

Obviously, there is also still a lot to be done on the GSM base station + GSM network front. The interested hacker might already have figured out that I'll be co-presenting with Dieter Spaar on how to run your own GSM network at the 25C3, but I'm mentioning at this blog anyway for the sake of completeness. The code will be released at the 25C3, and we'll hopefully also have some fun at the GSM hackers desk in the hack center.

With some luck, I'll be heading for Taiwan and (for the first time) Korea in January 2009. The other news about 2009 is that I'll likely spend more time than before in India.

Availability of Bollywood DVDs in Bangalore

I've been visiting Bangalore many times throughout the last five years. Every time I've spent a visit to "Planet M" on Brigade Road for buying some Bollywood DVDs.

And for some unknown reason, the size of the racks with Bollywood DVDs is shrinking from year to year. And with it, obviously the choice...

What you can get are sort of the last five major blockbusters, and tons of cheap re-releases of old movies from the seventies through nineties. But what about the last five years? What about anything that was released recently but is no longer part of the top-10? _nothing_!

Oh, and then you can get tons of Bollywood VCDs. But who wants that low quality? It's definitely no pleasure to watch a VCD. Even DVDs have way too little resolution to capture e.g. the details of costumes in a lot-of-people-dancing kind of scene.

It's really sad. Are people no longer buying those DVDs? Do Bollywood fans go to different places? Where should I go in Bangalore for a decent selection? Hints welcome, please send e-mail.

As a side note, yesterday I've also been at Planet M in the Esteem Mall. It's sort of a joke. Never seen a CD/DVD store that small. Obviously no choice at all.

Understanding the GSM Um Layer 1

More or less involuntarily I ended up spending the better part of the last couple of days understanding all the nasty details of the details about the Layer 1 of the GSM Um (MS-BTS) interface, i.e. the RF interface between your mobile phone and the BTS.

You can find a lot of secondary information about GSM both online and offline, but they all seem to address other issues, like layer 2 and layer3 protocols, even the actual logical channel multiplex (at least to some extent), network planning, etc. - But I've not found anything reasonably detailed about the actual channel coding, TDMA and synchronization, ie. what happens after demodulation and before layer 2. So I had to read the specs. Oh well...

I actually thought that all those parts are already there (in gssm and gsm-tvoid), but in reality that was just something like a proof-of-concept implementation. Restricted to only work on Timeslot 0, not demuxing the individual parts of the CCCH (PCH/AGCH/BCCH/..) and not properly dealing with frame-number counting in case of various receiver overflows or the like.

So I've now started on a new codebase specifically focussed on everything that happens between the differentially decoded GSM bursts and layer 2.

Normally, one would not assume a layer1 to be particularly complex. However, in the case of GSM, it really is. There are various different physical channel configurations, each with their own nasty little differences in the channel coding schemes... plus the synchronous nature with its necessity to know a lot of context and correctly count frames in order to correctly interpret and decode the incoming bits.

So where do we start. Most readers of this blog will know that GSM has 8 timeslots on each RF channel. Each timeslot forms one so-called physical channel, which can assume one of many physical channel configurations.

A physical channel configuration determines not only the particular logical channels residing in the physical channel, but also low-level aspects such as parity, convolutional code, training sequence, tail bits, etc.

In every timeslot on a physical channel we transmit something called a burst. Depending on the physical channel configuration, there can be different bursts:

Normal: A regular burst transmitting 142 bits of data

Frequency Correction: A burst that helps us finding the offset between sender and receiver clock rate, compensate for temperature drift, etc.

Synchronization: A burst for achieving TDMA-frame-number synchronization

Access: A specially (short) burst used in the uplink (MS->BTS) direction to request a channel allocation by the BTS.

Dummy: A burst that is transmitted in otherwise unused/empty timeslots, only on the ARFCN (radio frequency channel) that carries the CCCH/BCCH

All 8 successive timeslots form what is called a TDMA Frame. Every time the timeslot number changes from 7 to 0, the TDMA Frame Number is incremented by the receiver.

For all control channels, four such bursts need to be concatenated and go through convolutional decode and parity to form a 23-byte MAC block. On most, but not all control channels, those four bursts are sent in successive TDMA frames on one timeslot. The notable exception is the SACCH (Slow Associated Control Channel) which accommodates every TCH/F (Traffic Channel) and happens to get one burst at the 13th, 101st, 114th, 202nd, ... TDMA frame. Thus, on such TCH/F channels you need to wait for 202 TDMA frames to obtain the four bursts needed to generate one MAC block. A MAC block is what is then passed up to the layer 2.

Timeslot 0 of the primary radio channel of the BTS is called CCCH (Common Control Channel). It is the only channel about which we can at least make some assumptions about its physical configuration. However, the CCCH carries a number of different channels, such as the BCCH (Broadcast Control Channel), PCH (Paging Channel), RACH (Random Access Channel), SCH (Synchronization Channel), FCCH (Frequency Correction Channel) and possibly a NCH and maybe even a SDCCH/8 multiplexed into it. The "problem" here is that the actual configuration of the logical channels is determined by a layer2 System Information Type 3 message. So you have to work with the minimal guarantees (that there will be a FCCH burst, followed by a SCH burst, followed by four BCCH bursts which give one MAC block, in which you will at some point find the SI Type 3 message telling you how all the other bursts of the CCCH are mapped onto the various other logical channels.

From the System Information messages you can also learn on which timeslot the CBCH (Cell Broadcast Channel) is located. Typically, it is part of a SDCCH/8+SACCH/8C physical configuration. On all the BTS's I've seen protocol traces of (which are not yet that many), this is on Timeslot 1.

A SDCCH/8+SACCH/8C configuration is another weird but more logical multiplex. It consists out of 32 consecutive bursts, four for each of the 8 SDCCH instances that it carries. The following 16 bursts are divided to four, and they alternately serve SACCH0..3 or SACCH4..7. So you basically end up with two 51 multiframes , i.e. 102 bursts, out of which 8 bursts go to each of the SDCCH/8 instances, and four go to each SACCH/8C instance. (102-06 = 6, i.e. 3 bursts are dummy in each 51 multiframe.

For the TCH/F (full-rate traffic channel), the entire viterbi decode and parity is different than the control channels... and which is probably going to be part of another blog post.

Oh, in case you're interested: you can find the unfinished demultiplex code snippets at this git tree

Luckily, with a few days more work, we can actually properly demultiplex and decode all incoming frames, learn about the [dynamic] channel assignments and configurations that the BTS does, and reconstruct at least the MAC blocks for all control channels, if not even the actual speech codec data of the TCH's (on those unencrpted BTS that exist in India). However, actually following a conversation is not possible (and not of interest to me anyway) due to the frequency hopping.

FOSS.out 2008

FOSS.in 2008 is over. The grand finale was Kalyan Varma's closing keynote on how he thinks fundamental FOSS principles are present in all aspects of his work and life, even in areas completely unrelated to FOSS such as photography and wildlife conversation.

I could not agree more to what he said. Fundamentally it is about being curious, learning how things work, cooperating with other people with mutual benefit, etc. - as I have to some extent outlined in one of my previous blog posts about reverse engineering.

One particular spin was also on Security. Having an IT security background like him, with a pretty similar FOSS culture background, I can perfectly understand and support his point of view.

As for FOSS.in, I think it could also not have been much better. Biggest constraints were probably the conference venue itself. Its lecture halls inevitably create a big divide between a small number of entertainers on the stage and a big auditorium. There also was a constant and severe lack of power outlets at any given time or place - to some extent again a problem with the venue.

Thanks to the Organizers, Team FOSS.in and the Volunteers. Well Done.

Update from FOSS.in

First of all, many people have asked for the slides of my presentations. You can get the keynote slides and the glofiish reverse engineering slides from the FOSS.in website now.

Giving the latter talk, I was really surprised that nobody in the audience raised their hands when I was asking who had ever done reverse engineering of any sort. I cannot really imagine any of my work, both in the FOSS community as well as professionally without using whatever means to discover how things (devices, drivers, software) work. Isn't it a most natural human trait? You discover something new, and you want to learn how it works. So you take it apart, learn about its components and understand how the individual parts play together.

I've been doing this with about everything I ever got, even as a kid. Stereo system, reel-to-reel tape recorder, my first 286 based PC, my first motorbike, car, etc. It's simply not acceptable to be in possession of some technical device without understanding how _exactly_ it works.

So anyway, I hope the talk was at least a bit inspirational and makes some people try. It is not so much important that you actually fully manage to reach the goal (like in my case getting a full-blown Linux implementation of all the drivers done, etc.). The importance is the process, and what you learn while doing it.

So today I was mostly busy preparing and holding that talk, later at night I was back to working on gsm-tvoid. I'll cover this in a separate post.

The first two days of FOSS.in over

I've been having the pleasure of holding the opening keynote at FOSS.in, where I've been (again) using the opportunity to point out the sad situation of Linux in the Embedded space. I think it was good to get this message not only to the CE Linux Conference Europe attendees, but also to the various FOSS interested Indian developers. Many of those work for companies involved in chipsets for Embedded devices, Embedded Systems development or even BSP development.

Despite that very sad/depressing conference opener, the feedback was overall very positive. Some people mentioned "it was like if you were talking to me personally". So let's see if this kind of grass-roots FOSS lobbying can help to make a bit of a change in those Embedded Linux companies.

After the keynote I was more or less immediately starting my WorkOut on improving Free Software based GSM protocol analysis. Basically we're looking at GSM-tvoid, gssm, gsmdecode, the wireshark patch of gssm, etc. and coming up with a much improved solution.

So far we've added the tun-device support from gssm to gsm-tvoid, but that's only a kludge and a temporary solution. Adding fake Ethernet headers to a GSM Um frame and using a non-registered Ethernet protocol type is not really the kind of "implementation quality" that I'd like to see.

So now I've come up with a 'gsmtap header' similar to what 802.11 solves by the radiotap header. gsm frames including radiotap header can be stored directly as a new linktype in PCAP files, or they can be sent via UDP packets through the regular IP and networking stack, where wireshark can just grab them using the normal network devices.

We've continued to work on those issues on the second day of FOSS.in, and we'll also continue to work on it today. Tomorrow I'll be presenting on my gnufiish project, i.e. the reverse engineering and Linux port plus driver development for the E-TEN glofiish X800/M800 devices.

I personally can't really say yet how well the concept of WorkOuts has worked-out in practise. I really need to learn more about the progress that the other workouts have been making. I think at least for the GSM workout, there were not many people who had the skills or knowledge about the protocols and/or the tools involved - which is not a big surprise. But I'd hope that some of the attendees at least got interested in the subject and will contribute to the respective projects. There are many things to be done, including the somewhat tedious exercise of adding dozens and dozens of new dissector code to wireshark. If anyone else (preferably with some generic understanding about network protocols and wireshark dissectors) wants to help with that, please contact me.

From FreedomHEC Taipei to FOSS.in / Linux and the Taiwanese Hardware Industry

I'm on my way from Taipei to Bangalore, from FreedomHEC Taipei to FOSS.in. Two very different events in two very different countries with a quite different IT industry.

I was really happy about FreedomHEC. It is really about time that the Linux world and the Taiwan-based chipset vendors and system integrators start much more interaction. It is a simple economic fact that A lot of hardware development, both in the PC mainboard, Laptop as well as the embedded device space happens in Taiwan. It is also very true, that for whatever reason the gradual Linux revolution in the server and desktop market in the EU, the US and other markets such as Southern America has not really reached Taiwan. At least from all the various contacts that I've made in Taiwan, there are almost no Linux users, and particularly not in a corporate environment.

My experience in Germany shows that many small and medium sized companies, as well as a noteworthy part of public administration is using Linux, at least on the server side, and to an increasing amount on the desktop side. Many end users have dual-booting machines. Plus, the universities and particularly the computer science departments have a long UNIX-related tradition - and most SunOS and Solaris workstations have since been replaced by Linux based systems, or at least systems with dual-boot configurations.

If my completely non-representative assessment of the Situation in Taiwan is true, then we just don't see this level of adoption there. And this has a quite big impact:

• Managers and Engineers underestimate the amount of Linux adoptions in their target markets, since they don't see that much adoption in their domestic market
• Even if there is a [customer] demand for Linux, the Taiwanese hardware industry has a hard time to properly respond to this demand due to the lack of know-how about Linux and FOSS - both technology-wise, but also regarding the development model
• There are very few system administrators or software developers with a profound Linux user experience. How are you supposed to administrate or develop for a system that you haven't at least used for a couple of years?

So as a result of this, I argue that Linux hardware support world wide suffers from the lack of recognition of Linux in Taiwan.

This needs to change. Recent developments like the Asus eeePC or Linux-based Netbooks in general are not a solution either. They don't mean that Asus suddenly cares about how well e.g. the Linux ACPI implementation interacts with the ACPI BIOS of their non-eeePC Laptops.

I think any system integrator who understands those facts will likely gain a lot of trust and customer satisfaction. We yet have to see _any_ laptop or mainboard manufacturer who goes public and says "we will test our systems with Linux like we test them with Windows".

Non-Taiwanese system integrators like Dell or HP have a competitive advantage here. They do understand much better what Linux is, and how to work with it - even though mostly still on the Server side. You will find Linux-based BIOS update tools. You will see ACPI BIOSes that actually work properly and don't just contain random bytes in those parts that Windows doesn't currently use.

Why not Acer? Why not Asus? Why not MSI? Why not Foxconn? How much of a R&D investment is it really to do even the most minimal testing like booting some Linux Live Distribution from CD and checking if the major features are working? I would assume in the total Laptop R&D cost, it's less than 1%. So if only 1% of the customers will install Linux, it should already be justified.

Especially right now, nobody has really made the first step. Anyone who starts with the right strategy can be the first one on the market. The opportunity is there. Don't wait until the competition uses it.

VIA and Openchrome; Graphics Programming Manuals

Coinciding with FreedomHEC in Taipei, VIA has announced its cooperation with OpenChrome and releases Graphics Programming Manuals.

This definitely marks a big milestone in VIA's new, much more FOSS friendly Linux support. Not only releasing the source code to VIA's own graphics driver, but actually interoperating with OpenChrome to help to create one future driver base and fight against the fragmentation of the developer and user base.

After all, there's probably no other family of GPU's where there are so many different Linux/Xorg drivers like VIA's. What a terrible waste of R&D resources to reinvent the wheel over and over again. One reason for doing that (VIA's driver being closed source) has disappeared when it was made open source a couple of months ago.

So let's hope that this cooperation will be as successful as possible, and we can have one unified driver codebase with the cumulative features of both individual drivers right now. Once that has been done, we can start to think about helping the result to get into mainline X.org and put the entire history to rest.

I also appreciate and welcome the release of the graphics programming manuals for the two most recent generations of integrated graphics chips. Sure, they are by no means as exhaustive as documentation of major competitors in the GPU market - but then, VIA is a small company and they cannot release documentation which never even existed in the first place. So please accept that VIA is working on releasing the documentation it has, but is unlikely to be able to work on creating additional documentation that doesn't even exist.

There are still some things to be done, though. We still cannot include MPEG/H.263/H.264 hardware acceleration support in the driver due to unresolved legal issues (working on that, don't worry) and there is still no open source 3D support for the Chrome9 core (VX800 chipset). But then, life would be simple if all of those problems would disappear overnight. In any case, I think VIA can now legitimately claim that it is moving in the right direction, that it is not only trying to become a much better 'Free and Open Source Citizen'.

There will be more manuals and code up for release at some point, but please excuse that I simply don't want to speak about the tentative schedule of things that haven't happened yet.

E-TEN glofiish M800 Linux tree now has public git tree and a name

You can find the git tree here and clone it from git://git.gnufiish.org/gnufiish.git. Thanks to Stefan for setting up the tree and doing the initial push (ssh+git from Taipei is so slow that it cannot finish the initial commit of a kernel Tree before the DSL modem reconnects 12 hours later).

I've called the project "gnufiish" just for the fun of it. It's quite close to the original name, and therefore a 'language hack'. Though it's obvious that there is no real official connection to the GNU project, since Linux is not part of that.

Digging into the internals of WinCE / WinMobile

My E-TEN glofiish Linux porting efforts have made me investigate a lot of internals of the E-TEN ROM file format, WinMobile ROM files in general, XIP, Microsoft flash partition tables, imagefs and other bits and pieces.

I'm basically able to fully 'decompose' a ROM image into all its individual bits, including the pre-installed CAB's, the pre-linked DLLs in the XIP and the contents of the imagefs. And all of that on Linux, if it wasn't for the weird XPRS / SRPX compression in CE5.x imagefs. Allegedly it's the same Xpress algorithm as used e.g. in hibernation files and certain M$ network protocols, but I was trying that and didn't get anywhere. Luckily, the tools at least ran inside wine.

It's surprising how little information there is about those internals of the operating system. You can find bits and pieces in the 'ROM cooking' scene, but those are mostly HTC specific and don't always apply to E-TEN. And most of the tools that people tend to create in this community are not FOSS either :(

Anyway, once I find some time I'll probably pack/publish the stuff that I've done now. Obviously the coolest thing would be to do a GPL'd implementation of e.g. imagefs and get that into Linux. Would be fun (I've never ventured into filesystem land!), but then, it's not like I have any spare time at hands.

Last night I was trying to make sense of some of the M800 hardware drivers (sergsm.dll, keypad.dll, keybddr.dll, etc.) but it's actually quite a bit harder than I thought.

I also wrote some perl script that uses haret TRACE capability to reconstruct the I2C command/response stream. so you can basically perform any action on the device, like pushing one of the capacitive touch buttons, and see what kind of I2C communication the CPU initiates as a result. The problem with this, though: The I2C bus runs too fast, so it loses some bytes. I tried to work around it by increasing the I2C clock divider, but it seems the driver actually re-sets the divider with every transfer (rather than just once when bringing the I2C host controller up).

I'm trying to find other options (I could clock the entire system down, but then this affects things like the LCM refresh and other important clocks), since I believe a clean I2C tracer is the right thing to do.

I've also spent a bit of time on the Marvell 8686 driver, as there is already some (not entirely polished and thus not mainline yet) GSPI transport code for the libertas driver. However, I didn't finish this since it is not the biggest priority right now. Also, interestingly, the GPIO and other related bits regarding the wifi chip are all present in the winCE registry. Marvell apparently made the driver in a way that E-TEN and others don't need any access to its source code but can fully parameterize it through the registry.

So as a summary: I was spending basically every awake minute during the last days on this project, but there's no real visible progress yet. I've just learned a lot, and hope to use that information soon to further improve the Linux port.

Oh, and by the way: It seems like I'll be talking about some of this work (and actually showing how it was done) at FOSS.in 2008 next week. Stay tuned for some good old fun ;)

As with actual progress on the device itself: I've spent quite a bit today again with reverse engineering some drivers, thereby discovering two GPIO's that seem to be related to GSM modem power management. Maybe that's the reason why my own humble attempt at a Linux GSM driver has so far been unsuccessful. I also seem to find an awful lot of indication that UART0 is actually connected to the GSM modem, too. This might be some strange copy+paste artefact from older glofiish devices' linux driver, or actually they might have two independent communications channel to the modem - wouldn't be the first time to see this.

Some other bits have hinted at an externally-provided UART clock, but that is apparently just a workaround of a S3C2442 serial controller bug.

I', still having fun wading through tons of ARM disassembly. It's been a long time since I last had any good reason to use IDA (Interactive Dis-Assembler) that much. It's the only proprietary software that I've been willing to license (and thus pay for) in something like a decade.

FreedomHEC Taipei 2008

As I think I've mentioned before elsewhere in this blog, in a few days there is the FreedomHEC Taipei 2008. If you're in Taiwan and are doing some Linux kernel/driver related development, you should come and meet up at this event.

Looking forward to meeting lots of [new?] Taiwanese Linux developers :)

TXL-CDG-BLR-DLH-TPE

This was the route that I was taking to Taipei this time: Berlin, Paris, Bangalore, Delhi, Taipei... with 7 hours in Bangalore and 4 hours in Delhi, resulting in a total travel time of about 38 hours.

Everything went surprisingly well and I did a lot of work. However, my day/night rhythm is basically completely gone by now. Need to try to synchronize with local time.

Oh, and if you're asking yourself "why"? Because airline ticket pricing is the most ridiculous thing on this planet, even worse than stock exchange. Any more 'direct' asymmetric Germany->Taiwan->India->Germany flight would have been about three times as expensive as both a Germany->India->Germany and a India->Taiwan->India round trip ticket together.

Glofiish M800 GSM/UMTS Modem interface reverse engineered

During my seven hour stopover in Bangalore, I decided not to sleep and rather have a look about what I could do to find out more about the yet-unknown interface between the S3C2442B application processor and the 3.5G Modem in the E-TEN Glofiish M800.

Some initial poking in the WM6.1 registry led me to the (wrong) conclusion that UART0 might be used. It would have been a lot of data for a UART anyway...

So as it seems, they're using a SPI based interface. Not a bad choice, considering the various suboptimal alternatives. USB is way too heavyweight and power-consuming, and leads to inevitable problems when you want to resume the application processor from suspend (e.g. on incoming call). You just simply cannot afford the time to enumerate the USB, etc. Some shared memory / dual ported RAM interface like it is found in more integrated chipsets requires quite a bit of software work (synchronization of a shared memory region between two processors that have no common resources!) and requires a quite deep interface into the modem side. Something that E-TEN would unlikely get from Ericsson, I would say.

So SPI it is. Interestingly, the SPI master is in the modem, the S3C2442 acts as SPI slave. This adds the need for some kind of mechanism how the application processor can tell the modem that it actually wants to transmit an AT command. A simple GPIO line does that trick. The Modem responds by asserting the slave select line.

Interestingly, they even use DMA accelerated data transfers. So receiving data from the modem is less CPU intensive than reading data from NAND. What a crazy world.

Some more bits are found in the wiki.

I've already started to hack up a Linux driver. The SPI side is really simple. What is much harder is the fact that the Linux SPI core has no support for slave mode, and thus neither the in-kernel s3c24xx SPI driver. Furthermore, many of the traditional serial line analogies (baud rate, modem control lines, handshake, break, ...) no longer apply.

On top of the SPI, they seem to be running pretty standard AT commands. Nothing fancy at all. Thus, I'm optimistic that once the kernel driver is there, FSO or other userland can make use of it quite easily.

Running Linux on E-TEN glofiish M800

Ever since my blog post about certain E-TEN glofiish devices in late August, it might have been obvious that I've been up to something.

In fact, I didn't have much time, as usual. Finally, after something like about two full days of work, I can present some preliminary results:

root@glofiish-m800:/proc# cat /proc/cpuinfo 
Processor       : ARM920T rev 0 (v4l)
BogoMIPS        : 176.53

[...]

Hardware        : Glofiish M800
Revision        : 0000
Serial          : 0000000000000000
root@glofiish-m800:/proc# 

You can also find a preliminary wiki page about the current status of hardware reverse engineering in the OpenEZX wiki. It doesn't really related to EZX or OpenEZX at all, but it somehow is related to the same thing: Bringing kernel+rootfs based 100% on open source to phones without vendor support. It also doesn't really fit into the Openmoko wiki, since as you can assume, this is by no means a project of Openmoko, Inc.

So far, it was pretty easy. I was taking the 'stable' branch of the Openmoko kernel git tree, adding minimal platform support to it (to get framebuffer, microSD and USB device working), and using haret to boot into a fso-terminal-image located on a microSD card.

Of course the really hard work now starts, getting all the hardware properly supported, especially the communication with the GSM Modem, as well as the power management related bits. Nonetheless, a foundation is laid, and I expect it to be not too hard to continue from here.

So maybe, if I can find sufficient time, we will see FSO on a 3G phone at some not-too-distant point in the future.

Now some of you might be asking: Why am I not working on improving the code for the Openmoko, Inc. handsets GTA01 and GTA02? Isn't it bad to support a non-open hardware manufacturer, plus pay the Windows Mobile license tax on a device, ...? After all, Openmoko, Inc. current business model is centered around the sales of their own hardware to support for the software development!

I don't think that this is much of a competition to Openmoko. Obviously, everyone wants truly open hardware, such as what Openmoko, Inc. is trying to do. Nonetheless, people (especially geeks/nerds/hackers) want devices with 3.5G or at least 3G, they want devices with real keyboards, higher capacity batteries, better mechanical design, camera, etc. This is just something that Openmoko Inc. has not been able to provide so far. There's probably not many people on this planet who feel as sad about this fact as I do.

Next generation of OpenPICC in the works

Yesterday at a brief visit to the Chaos Computer Club Berlin, Henryk introduced me to the prototype to the next-generation OpenPICC. After co-initiating the project with Milosch and Brita some years ago, I unfortunately had to drop out of it due to time constraints. I've heard rumours about plans for a next generation OpenPICC, but now it seems like Milosch actually found some time to get it done.

The result is really the über-OpenPICC. No shortage of anything. I don't want to reveal any information that's not out in the public already. Nonetheless, I can say: Stay tuned, stay excited. It rocks!

Open source SIM card emulation, SIM card proxying: BLADOX

I've been extremely positively surprised as I recently discovered bladox, a company specializing in providing development tools and custom hardware to simulate, proxy and extend SIM cards. And not only that, they are completely based on gcc + binutils as well as their own open source software. There couldn't be any better playground to play with the SIM interface of any mobile phone.

The general idea is to put an ATMega128 in between your real SIM card and the actual SIM card slot of the GSM mobile phone. On that ATMega128, you can then do whatever you want, e.g. forward only certain commands, such as "perform GSM algorithm" to the actual SIM, and implement the rest in your microcontroller. You can obviously also implement STK applications yourself for demonstration, or you can even block all STK commands and suppress the phone from ever knowing that the SIM actually supports STK.

This is an excellent playground. And it's even sold at a very affordable price. Now if I only had more time to look into all of its exciting possibilities while not forgetting about my other tasks (and paid work) :)

Maybe there are some readers of this blog who are just as interested but didn't even know that such products (and all the example code) did actually exist. Now you know :)

German Post paper form shows HTML font tag

Something fun for a change: This morning I had one of those "you were not present when we tried to deliver something to you, please come to the post office to pick it up" cards in my mailbox.

However, as the scan of this very card shows (check for the red arrow), they inadvertently show half of a HTML FONT tag for the font "HELVETICA" on the actual printed card. I wonder how nobody could notice ;)

Hearing of German Constitutional Court on voting machines

Today was a public hearing of the German Constitutional Court (Bundesverfassungsgericht) on the subject of the use of voting machines in elections of the German parliament.

I've been anticipating this for quite some time. The plaintiff, Dr. Ulrich Wiesner, has been investigating the subject for a long time, just like the CCC has been doing a lot of theoretical analysis as well as practical hands-on hacking of the respective voting machines (actually, rather, Voting computers).

As most readers of my blog will be well aware, voting using electronic devices, or even more so computers driven by actual software, raises an almost unlimited number of concerns. Both software and hardware manipulations could have tremendous effects on the final result, no regular citizen or even most IT security experts can actually observe the counting of votes and guarantee the correctness of the results.

The hearing of the constitutional court was for clarification of further questions of the judges to both the plaintiff, the defendant (the German parliament and Ministry of Interior) as well as three independent expert witnesses. While the CCC has earlier been asked by the court to provide an expert study, it was not officially invited to be questioned at this hearing.

Nonetheless, three senior members of the Berlin CCC (me included) were present in the audience and following the hearing with great anticipation. It was my first 'live' experience at the constitutional court, and I have to say I am no less than impressed. Intellectual discourse on a very high level. The judges were asking very thoughtful and precise questions, were asking for explanations without mercy ;)

I think the legal representation of the plaintiffs (including a senior legal scholar) was excellent. Good arguments, very eloquent. The various defendants (ranging from representatives of parliament, ministry of interior, the government agency in charge of certifying the voting machines (PTB), as well as the senior election official of the state of Hessen) were making much less impressive performance.

And at the end of the day, I still cannot get why about every consumer electronics device, from mobile phone to digital TV receiver to game console has about one lightyear more security architecture than the machines that are used to count the votes. No hardware-crypto engine, no encrypted JTAG, no signed bootloader and software (plus automatic mask-rom based signature verification). Plus officials in the public administration who think the trade secrets of the vendor of the machine is more important than the public interest..

I think the judges very well got that point. You could literally see their disbelief in situations like when it was outlined to them that only the vote-counting machine has to get type approval, but not the PC + software that is used to program the particular election into the vote-counting machine, neither the software used to read out the memory modules and summarize the votes of multiple voting machines. So not even those insufficient small amount of testing and certification that exists does extend to the entire system, rather just to the input unit.

We'll probably have to wait for some more months (at least weeks) to see the result. I definitely remain very optimistic that the constitutional court will prevent the worst problems of the current situation. I don't think they will completely close the door for voting machines, but at least raise the bar for any such future system very high in order to achieve a level of transparency and trustworthiness similar to that of the traditional paper ballot vote.

To me, for a long time, the constitutional court is the single remaining still functional and trustworthy entity in the Federal Republic of Germany. It is the last bit of hope against the constant battle of the government administration[s] against civil liberties, post-9-11-security, surveillance/intelligence particular in 'new' technology.

Some more S3C24xx NAND speed observations

I've now moved on to other topics, but I still want to mention some of my thoughts on the still quite poor NAND performance on the GTA02 (and generally, the S3C24xx).

It seems like we are down to a point where the CPU is 100% busy reading from NAND, which is odd. Why would reading from a mass storage device make the CPU so busy? Well, because Samsung "forgot" to add DMA support to all of their integrated NAND controllers, from the old 2410 through the 2440, 2442, 2443 and up to the shiny new 6410, all the NAND controllers don't support DMA. In fact, they don't even have a FIFO or some kind of internal buffer for the received data. This is really weird, considering the facts that

• every other peripheral (SD/MMC, SPI, UART, ...) can use DMA
• Samsung as provider of both NAND flash and SoC should be experts in providing good flash performance
• I cannot see any strong architectural limitation. The data is read into a register. The register should be replaced with a FIFO, and a DMA can regularly read from that register or FIFO and put it somewhere else into memory. It's not any different from e.g. SPI or UART DMA.

In the current mainline Linux driver for S3C2440 NAND, we busy-wait (poll) for completion of the read request. This is of course sub-optimal. I implemented a version that uses the Read/Busy line IRQ and a 'struct complation' based mechanism and to my big surprise the CPU usage and throughput was identical. It seems like that NAND flash in the GTA02 is fast enough to max out the CPU.

So probably all that can be done is to optimize the actual code that is executed during the NAND read. It might be worth implementing some small hand-optimized assembly implementation as standalone code (not using the existing driver) to see how far the hardware can actually go.

Isn't it sad that you use Samsungs SoC and Samsungs NAND (packaged together in one component as multi-chip-package by Samsung) and still get less than 50% of the performance of the NAND chip, according to the data sheets :(

Some more GSM Abis experiments

It's been quite some time since I last mentioned Abis in this blog. Recently, I've again found some time to experiment with Abis. The last two days I was working on porting some proof-of-concept code of a fellow hacker from windows to Linux.

I now also have manufactured all the cables and adapters I need, plus installed a Windows 98 box in order to operate the Wandel+Goltermann MA-10 protocol analyzer that somehow made his way to my lab. The MA-10 can act both a a high-impedance passive sniffer on top of the E1 link (using the Abis Monitor software), or it can actually emulate the BSC by using a terminated E1 Rx+Tx interface and the AbisSim software.

I don't want to talk too much about things that haven't been implemented yet. But in the next weeks, I'll be diving all the way into mISDN and see what needs to be done to make it talk the specific Q.921 dialect that Abis uses.

Stay tuned. I'm working towards a first release at the 25C3 congress in late December.

Android and its perceived 'openness' :(

As many other people have been blogging and news sites have been reporting: The Android source code has been released. This is definitely good news. However, freedom-loving people already discover in blog posts that there's a remote kill switch by which Google can disable an already installed application and that some features are reserved to vendor-signed applications.

To me, those things are not a big surprise. As soon as you try to get in bed with the big operators, they will require this level of control. Android is not set out to be a truly open source mobile phone platform, but it's set out to be a sandbox environment for applications.

And even with all the android code out there, I bet almost (if not all) actual devices shipping with Android and manufactured by the big handset makers will have some kind of DRM scheme for the actual code: A bootloader that verifies that you did not modify the kernel, a kernel that ensures you do not run your own native applications.

Thus, Android so far was little more to me than yet-another-J2ME. Some sandbox virtual machine environment where people can write UI apps for. In other words: Nothing that gets me excited at all. I want a openness where I can touch and twist the bootloader, kernel, drivers, system-level software - and among other things, UI applications.

I actually think it's a bit of an insult if people think of Motorola's EZX or MAGX (and now Android) phones as "Linux phones". Because all the freedoms of Linux (writing native applications against native Linux APIs that Linux developers know and love, being able to do Linux [kernel] development) are stripped.

In the end, to what good is Linux in those devices? Definitely not to any benefit of the user. It's to the benefit of the handset maker, who can skip a pretty expensive Windows Mobile licensing fee. Oh and, yes, they get better memory management than on Symbian ;)

That's the brave new world. It makes me sick.

Luckily, it's 50 B.C. and the Romans occupy all of Gaul, except for one small village that has been able to avoid the invaders.

Openmoko GTA02 NAND performance improvements

On Sunday night, after returning from a weekend trip to Hamburg, I sat down and looked at the NAND and S3C2442B data sheet to figure out the actual timing performance. Interestingly, the NAND timings were much more verbose and detailed (and had different names) than the timings described in the NAND controller section of the S3C24xx manual - and both are from Samsung ;)

Anyway, it seems like the current timing settings for the various stages (reading u-boot by the stepping stone mechanism, reading the kernel by u-boot as well as actual mtd-based access inside the Linux kernels) were extremely suboptimal. They're basically standard timings designed to work with most NAND flashes out there, ignoring the fact that GTA02 uses one specific flash with very good (fast) timings, at least according to the data sheet. There should also be no PCB / routing related issues such as capacitive overload preventing higher speeds, since the NAND flash die is stacked onto the CPU die in one package, and the NAND controller signals are not routed on the PCB anywhere.

Some initial experiments based on the calculations show that the performance can be easily improved by 41% over the stock GTA02 NAND performance. However, the actual speed (6.59MBytes/sec) is still much lower than the theoretical maximum read performance of 15.64MBytes/sec. It seems there is more room for improvement inside the MTD layer of the Linux kernel.

It's again quite amazing how much room there is for improvement in GTA02 performance, both power consumption wise (see my recent post about framebuffer blanking), as well as actual data throughput. Those are really low-hanging fruits, and it's very surprising that nobody working for Openmoko or in the Openmoko community has been able to spend some time to look into those...

About the new format / structure of FOSS.in

There has been quite some discussion on various places on the net about the recently-announced change of the FOSS.in conference format. Instead of lots of talks/presentations, there is an emphasis on workshops and similar more interactive and collaborative types of events.

I have been speaking to a number of developers who have been to FOSS.in before and who have been putting in proposals for FOSS.in/2008, too. They all think it is a very courageous step: going from a successful, working 'traditional conference' scheme with presentations, sufficient sponsors to cover travel expenses of foreign speakers, etc. to a very different, much more developer-community oriented event.

I also think it is a courageous experiment. I have not yet heard of any event similar to this before. Sure, there are project days and developer meetings or miniconfs or whatever you might call them. But not to the extent as, at least to my perception, FOSS.in is planning right now.

In any case, it depends on what your target is. 'typical' Linux conferences are basically focussing on either one (or multiple) of the following:

• Spread the word about Linux/FOSS, to generate more adoption
• Provide updates on development progress to various people in the community as well both individual and professional users

However, if you emphasize on the actual FOSS development, then I think it is quite legitimate to go for a event format that FOSS.in is heading to right now.

It is exactly FOSS.in who can try such a change, since it is a true community event without any commercial interest and without affiliation to particular companies.

And after all, who wants to see the same kind of event happening each and every year, with the same kind of people talking? Wouldn't that be boring after some time? Especially if there are a number of other events doing more or less the same?

In any case, personally I'm planning to do a FOSS.in WorkOut on a USRP+gnuradio based GSM scanner project. India is the perfect place on earth to get this done, since the government mandates A5/0 (no encryption) and thus all the packets can be captured and each and every bit implemented as wireshark plugin.

FOSS.in 2008 CfP is out

I have just received news that the FOSS.in 2008 Call for Participation has been released. This is good news, although I think it is quite late, as every year...

I'm definitely looking forward to FOSS.in, like every year. There's such a huge potential in India, so many software developers. If only some more could be convinced to _effectively_ work on FOSS and contribute their work back to the community, it would be a great gain.

All details about mifare crypto1 algorithm and protocol disclosed

Henryk Ploetz has released his thesis on mifare protocol and cryptographic weaknesses, which is to the best of my knowledge the most complete publicly available documentation about the mifare CRYPTO1 system.

Congratulation to him and his peers (starbug, Karsten Nohl and others) on this great work. I still hope I could have played a more active role in the security research on mifare. But it's good to see that as imperfect as they are, OpenPCD and OpenPICC fulfill their duty as toolkit to enable security research on RFID.

Significant power savings during framebuffer blanking

As I've posted today to openmoko-kernel, there have been some quite significant power savings during the "backlight off but still not suspended yet" operational mode of the GTA02. The power savings are in the order of 49%, which is really massive, particularly for applications that run in the background while the screen is blanked, like typical mp3/ogg player applications.

It is sad to me that something like this is found long after the GTA02 has actually shipped. It seems like there are still fairly low-hanging fruit around to do some significant power saving.

Since all the measurements can be done on the device itself, using the built-in high precision coulomb counter of the battery, everyone is able to do the measurements without any special equipment. It also means that power management related issues can be tested automatically.

I would love to see somebody working on software that switches certain hardware on (and off) again or cycles through various differnent power states of every hardware unit an then reads the power consumption. The resulting readings can then be manually checked if they're consistent with expectations based on the hardware design. Furthermore, this program could be used for regression testing against new uboot/kernel/OS releases in order to ensure we don't get into power consumption regressions.

Actually working on Openmoko again

It's an interesting feeling to spend some days working full-time on Openmoko again. Swisscom was stating a number of high-priority bugs (for them) which I tried to resolve.

The first two are u-boot related, namely: get GSM passthrough working again, and fix USB DFU Upload on GTA02. Those two should be doing quite fine now.

I've also been investigating possible ways to optimize CPU usage of frameworkd, although it is not yet clear which of the possible solutions should be implemented in the end

Right now I'm working on some power management related issues, mostly glamo/backlight/LCM related, as well as re-investigating the hardware-ECC work by Zecke.

However, after a significant break from _using_ the Openmoko devices and the software available for them for a number of months, I have to say that the overall experience was really disappointing.

• Whatever Openmoko builds as their daily builds available on downloads.openmoko.org is the most unintuitive UI that I've ever seen (is that ASU?). After some attempts, I gave up. unusable for me.
• FSO images can be installed, but are incredibly slow
• Documentation in either openmoko wiki or FSO wiki is horribly outdated
• It's _really_ hard to get devirginator running since lowlevel_foo and others are not available on downloads.openmoko.org, but devirginator insists on downloading them from a website rather than copying them from a local directory
• there's a neverending fragmentation
• core aspects of the system level have not been addressed, like replacing sysvinit with something like upstart, some serious boot speed optimizations and various power management related bits
• Nobody has yet had the time and resources to investigate a thorough, flexible and performant storage and API subsystem for contact + related data

All this makes me really sad and gets me back to the point where I feel like when I left OpenMoko, Inc. last year: Too many insurmountable problems, and very few that can be addressed in a way that they are solved once and forever. Everyone runs their own personal little pet system, magic scripts, revision control system, overlay files, images, etc. Still too many people think OE is a tool to develop+crosscompile application programs.

In Switzerland again. Feeling like in a Bollywood movie

I'm back to Switzerland for some Swisscom related work. Right now I'm sitting in the Intercity train between Zurich and Bern. And believe it or not: Half of the car is occupied by (loud) Hindi speaking Indian tourists ;)

It really feels like I'm in a Bollywood movie. Indians in Switzerland. And not only in Switzerland, but in the Train. Couldn't be any more cliche ;)

Drona - what a disappointment

In Berlin there are not many chances to watch a Bollywood movie in an actual cinema. Those few movies that they show, I usually try to watch, at least if I'm in town. So far they've always made a great selection and picked only blockbuster movies that actually were any good.

Since I haven't been staying up-to-date with the latest Bollywood releases (mostly due to time constraints and lack of access to Indian DVD's in Taiwan), I didn't even check about the background of the latest movie they've started to show here: Drona.

After watching the first five to ten minutes of the film, it became already clear to me that I should have done better and check beforehand. Never seen such a trashy movie before. What a disappointment.

Blinkenlights is back (stereoscope)

Some of you might remember the famous blinkenlights installations of the CCC in Berlin at Alexanderplatz some years back. Basically they used a matrix of windows on a building for a low-resolution display to play pong and display all kinds of animations and text.

After a long break, they're back, even bigger with blinkenlights stereoscope, a massive installation spanning 960 windows of Toronto City Hall. The entire backend technology has been re-implemented based on OpenBeacon , specifically the WMCU and the WDIM units.

Netfilter Developer Workshop 2008 in Paris

I'm currently at the netfilter workshop 2008 in Paris, France.

It's always sort-of a mixed experience for me. Obviously it's great to spend some time with all the great hackers who work on various aspects of netfilter/iptables (and now finally also its successor that is so-far called nftables). On the other hand, it's been about three years since I last actively contributed code to netfilter, which makes me sad. I'm still excited about it and have many ideas that I'd love to implement. But where to find the time for it?

NLUUG autumn conference / Embedded Linux Conference Europe

I've been invited to be the keynote speaker of the joint NLUUG autumn conference and Embedded Linux Conference Europe.

It is a great honor to me to be the keynote speaker, and I will certainly use this chance to provide some of my insights into Embedded Linux. I feel confident to have a thorough understanding about the market (and it's many problems) due to

• having a strong, 14 year FOSS community developer background
• knowing how hard it is to do FOSS-only embedded hardware development (for OpenPCD, OpenBeacon, Openmoko, ...) in todays secretive hardware industry
• having seen a wider range of embedded Linux products than most other people by reverse engineering hundreds of devices for gpl-violations.org
• and now even knowing the chip maker perspective, after becoming VIA's Open Source Liaison

So I'm trying to point out the various problems I see in the Embedded Linux world, and how they can be addressed.

If I know you and you're planning to attend the conference: Please drop me an e-mail in advance so we can meet up, chat, have drinks, meet for dinner or the like.

Extending range of GSM cells by using only 4 channels

Today, while reading IT mainstream magazine "c't", I stumbled across an article about GSM deployments (and popularity) all over Africa.

One of the interesting things in that article was that one Operator had modified their network in a way to only use four timeslots (out of the eight available timeslots) per frequency in order to extend the range of a single cell to something like 70 kilometers.

For those who are not as familiar with the GSM Um air interface: It uses TDMA (multiple devices each get one timeslot on a given frequency). So let's assume we have eight timeslots on one frequency, all the transmitters (handsets) need to be synchronized with regard to that timeslot. Radio travels at speed of light and not with infinite speed. Therefore, since the handsets can be at a lot of distance to the receiver (base station), they might send in the correct timeslot, but the signal arrives out of the timeslot. GSM uses what's called "timing advance" in order to compensate for that effect. The base station tells the handset how much time earlier than the actual timeslot it needs to transmit to ensure arrival within the timeslot.

Now in that African GSM network in question, it seems like even the maximum timing advance is not sufficient. The frame still arrives late, i.e. in the next timeslot. By allocating only every second timeslot, there cannot be any clash and thus the range of a single cell can be extended. This is actually a very cool idea, I would almost call it a "hack", and it is possible within the GSM spec without requiring any change to existing mobile phones!

I only wonder how much of such cool hacks we would see if GSM base stations were more open and available. If there was a full FOSS stack that many people could use on off-the-shelf hardware, it would lead to a lot more innovative experiments and thus innovation. There would suddenly be more than a handful of GSM experts with access to proprietary technology looking at what kind of good, useful, cool and/or creative things one can do...

A Free software 3G protocol implementation: Wireless3G4Free

For quite some time there has been a project called Wireless3G4Free. I suspect it is little known outside a certain academic community. So what is it all about? Creating a FOSS based test platform for wireless 3G systems. Yes, this is the so-called baseband side. The parts that are usually very carefully locked away in the proprietary stack of cellular handsets and other equipments

Even though the project, funded by the European union and implemented at EURECOM in France, is 'finished', it is not as easy as to just use that software and get UMTS connectivity.

First of all, it implements the 3.84MChip/s TDD variant of the physical layer (layer 1), whereas most commercially deployed UMTS systems for cellular access use the FDD variant. For those not as familiar with 3G technology: There's three different layer 1 options: the 3.84MChip/s TDD, the low-chip-rate Chinese TDD variant, and the FDD variant. The layer 1 is separated in two parts, one that is TDD/FDD independent, and the other part that is shared.

Secondly, the Wireless3G4Free project uses IP on the layer 3, as opposed to the actual layer 3 protocol of UMTS (which borrows a lot from the layer 3 protocol for GSM, which in turn borrows a lot from Q.931 / Euro-ISDN).

So if one was to make that code interoperate with UMTS cellular networks, the lower half of layer 1 need to be rewritten for FDD, and layer 3 needs to be implemented.

What is exciting about 3G compared to GSM: GSM uses proprietary ciphers (A5/1, A5/2) for the actual air interface. Those ciphers have leaked quite some time ago, and they're no longer secret (and thus the GSM security is no longer existing), but still people are not supposed to know how it works.

In the 3G world, the corresponding cipher is public. This means that in theory, it should be possible to implement everything in Free Software based on publicly known information. Yes, it is a lot of work. But it definitely can be done.

Before actually using this on any official network, it would obviously need to be certified. Certification for this kind of protocol is a time-consuming and expensive process. It requires development cycles of going to a certified test lab, obtaining test results, going back to actually fixing the problems, re-running the test lab tests, and so on. Nevertheless, Free Software has already proven that this can be done. The isdn4linux project did a full EDSS1 certification some 10 years ago. ELSA, a maker of passive ISDN cards, sponsored that effort. And if you used an unmodified code version, then you were certified. As soon as the source code was changed, you were running an uncertified version. I don't see any big problem why the same scheme should not work for a 3G baseband software stack.

One important question though, is the question of hardware. None of the existing commercial vendors of 3G chipsets will ever provide you with the hardware documentation that you would need or want to run that kind of code on their hardware. It is their business to sell their proprietary 3G stack along with their chip, so they would only loose money if there was any FOSS implementation in competition.

Sure, you can use something like the USRP or USRP2 or any other software defined radio platform. But while that would be ok for a proof-of-concept, it is too large, expensive and power-consuming to be used or 'ported' to any actual handset-type product.

So any possible real-world plan of making this happen would probably go as far as to implement everything based on the USRP, then have a proof-of-concept prototype and then do a modem design based on existing, openly documented RF components and ADC as well as DSP+Processor combination that is suitable for low-power operation.

Sure, I'm just daydreaming. But sometimes you have to dare to dream in order to make things happen. Anyone wanting to turn this idea into a business, let me know ;)

Swisscom Research is evaluating Openmoko

At OpenExpo, Swisscom Research had it's own small stand (wouldn't call it a booth) to demonstrate thei research and evaluation work based on Openmoko. This is definitely exciting news, first of all since it is the research department of an established carrier, i.e. Openmoko is considered seriously even by them.

Secondly, they have many interesting ideas, some of which they have implemented. They have created a much more simplified UI, as well as an interesting input method based on gesture recognition. They've also been working on some crypto and security related bits.

I can now also disclose the fact that both Rasterman and myself have been (and stilll are) providing a bit of consulting and R&D services for Swisscom.

Hackcontest at OpenExpo 2008

I've had the honor to join other experienced FOSS hackers on the Jury for the Hackontest. The idea was to let the community collect a number of work-items for teams (of 3 developers) working on a particular project, then pick some of those work items and see how far each team gets within 24 hours.

I think it was a very interesting concept. Something that at least I have not yet seen anywhere else before. The organizers did a great job with the preparation. Setting up the website for project proposals, collecting community votes on the individual tasks, putting together the jury.

The participants of the contest then were placed into a container (yes, the kind of containers used for international shipping) with a fridge, beer, snacks, Internet, power, a projector and some other gear. They had vnc running on all of their systems, to enable a large public screen at the trade show where people would be able to follow whatever happens on-screen right now on a system of a random developer participating in the context. 'reality-tv for hackers' ;)

The results and the progress were quite different between the individual projects. I don't want to reveal the internal discussions we had in the jury, but one thing that basically everyone agreed to was the improper use of revision control systems. None of the teams was setting a good example on how to use them. Either the granularity of the commits, or the changelog texts, or the time when they committed was wrong. You shouldn't commit unrelated changes, never do cosmetic and functional changes in one commit, etc. This is what makes your work reproducible, readable and understandable to others, like the jury and particularly your own user and developer community. It is one aspect that affects a lot how easy it is for others to contribute to your project or to contribute to it.

Things I learned about GSM, STK revisited.

During the least couple of days I've had some pretty intense conversations with a number of people on various aspects of GSM, leading me to [re]reading some of the interesting bits of its specification.

There are a number of observations that I don't want to talk about right now, and which will likely be part of my work during the next couple of months.

One thing that ever so often gives me the creeps is STK (Sim Toolkit). To those people involved with GSM, it is no news that with STK an operator can basically remote-control your phone. He can, among other things

• make your phone send SMS
• initiate outgoing calls without your interaction
• initiate outgoing calls and terminate any existing call
• open data connections (GPRS/EDGE)
• launch a browser to any URL
• play tones on your speaker
• access and modify any information (contact, SMS, dial history, even IMSI) stored on the SIM

And the worst thing of it all: You don't even know which of those features your phone implements (most likely all of them). I'm happy to still use a SIM that predates the GSM11.14 (STK) specification.

Now in the advent of projects like OpenBTS, where we can emulate a GSM network side, and in combination with either supplying your own SIM card (or emulating it using a PC), we will finally see a faint possibility of actually testing (and demoing) the never-ending security nightmares caused by this evil monstrosity.

Just arrived in Winterthur for OpenExpo Zurich 2008

I've just arrived in Winterthur (Switzerland) for OpenExpo where I will present on the various reasons and implications of the fact that 99.9% of the makers of commercial embedded Linux products have not understood the slightest bit about Embedded Linux or rather, embedded FOSS in general.

Those people who've ever tried to exercise their freedom to create and run modified versions of an embedded product with pre-installed Linux will definitely know what I'm talking about.

Adding support for SD/MMC cards to parted

Today I've posted some patches that add SD/MMC card support to GNU parted, including libparted. It's actually just support for auto-detecting the /dev/mmcblk* devices, since the actual partitioning and block layer access of SD storage cards is exactly the same like on any other disk.

This has been fun, as I always like to read source code of programs that I've only been using so far ;). Luckily, the architecture is nice and abstract so the feature was easy to implement.

After the copyright assignment to the FSF has been done, the code will get merged. Once libparted has support for this, debian-installer should more or less automatically offer those devices as installation targets.

Now I just have to find out what the other distributions use for this purpose, with some luck they also rely on libparted and I don't have to implement this feature 5 times.

Installing Linux on systems that boot from SD card

It seems like boot-from-SD is about to become as standard in the x86 world as boot-from-USB currently is. This is generally good news. Also, the need for OS integration is minimal, as it just uses the usual BIOS ABI on doing disk reads.

However, the initrd's shipped by all distributions don't contain the SDHCI driver, and all the installers that I've seen don't support installation on /dev/mmcblk*

I've now filed bugs for all the major distributions about this issue, and you can find more information at this wiki page on installing Linux on a bootable SD card. Let's hope that the distro's consider this feature important enough to add support to it to their next releases to make sure at the time the users buy this kind of hardware they can install the then-existing versions of those distributions.

Updates to VIA HDA Codec driver

The last two days I was busy preparing a patchset with various updates against the linux-2.6/sound/pci/hda/patch_via.c driver for HDA Codecs.

The resulting patchset has now been posted at alsa-devel and I'm waiting for the fallout from that.

The other bit that I'm currently playing is boot-from-SDcard support, apparently a feature that major BIOS vendors have in their new releases and which will become more common with upcoming mainboards and laptop devices, just like boot-from-USB in the past.

FAQs to the VIA open source driver

There have been numerous questions regarding the recent open source release of VIA's 2D Xorg driver.

Why did VIA publish yet another driver, rather than improving any of the existing Xorg/openchrome/unichrome drivers?
Because this driver is all but new! It was the base for all the binary-only driver releases that VIA has made (and is still making) for select Linux distributions. So rather than having written a new driver, this is just the disclosure of an existing driver.

One of the commonly asked questions is _why_ not the complete source, including codec acceleration, TV out and 3D was published. I cannot disclose the particular reasons for VIA, sorry. But I can comment on the general reasons on why companies cannot disclose certain source code. As you may have noticed, the situation with regard to the ATI driver e.g. shows certain similarities.... Usually there are some parts of the code, particularly for the 3D driver, which cannot be disclosed due to either

• parts of the source code are under a proprietary license from a 3rd party
• parts of the source code refer to technologies (e.g. macrovision) which are subject to very strong NDA's by the licensor, which in turn prohibit the open documentation or distribution in source code form

Will VIA learn to build a community around that new driver? Will there be mailing lists and a public revision control system?
As of now, this is unlikely. Not because VIA doesn't believe in the community, but rather because the disclose of VIA's source now enables everyone involved to look at all the available drivers. Some consensus has to be found on which driver is best to be used as a base for a future Xorg mainline driver, and then the community and VIA can work together on merging bits from other drivers into that base. Creating VIA's own mailing lists (and community) would lead to more fragmentation, rather than unification.

Photographs of disassembly and PCB of a e-ten glofiish X800

Heh. You could say I'm now among other things a professional hardware reverse engineer. This mostly started as a kid, where I always had to take everything apart. In more recent years, I've mostly been doing hardware reverse engineering as part of the gpl-violations.org effort, or projects like openezx.org.

Now, I've actually been asked by a company to buy a device on their expense to disassemble and photograph it, to find out about the components it uses, etc. And no, before you start to wonder, I don't work for Openmoko anymore. So they are not that company ;)

The device in question is the E-TEN glofiish X800, a full-vga 3.5G Windows Mobile PDA-Phone with AGPS, Wifi and bluetooth. You can find the pictures of the disassembly process and PCB photographs here.

As you can see, the device employs the following major components / chipsets:

• Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)
• CSR4 based Bluetooth (same like Openmoko and many other devices)
• microSD slot, must be connected to S3C2442 SD/MMC controller
• WiFi Module using a Marvell 8686 chipset (you actually can't see that, I had to peel open the shielding of the module and the angle didn't allow any good photographs)
• TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02
• AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal
• Two cameras of unknown type, must be using the S3C2442 camera interface
• Ericsson based quad-band GSM and tri-band 3.5G chipset centered around the DB3150, which is used in many Sony-Ericcson 3G/3.5G phones. Sony-Ericsson has excellent public documentation on their AT-commandset for their phones. Since they are likely to use the same firmware base, the AT commandset should thus be known.
• A Xilinx CPLD

So now what does all this mean? Setting aside the CPLD and the unknown camera modules, this device (and its keyboard-enabled brother the M800) should be a very attractive target for porting Linux to it. Known SoC, wifi with driver already in mainline, GSM/3.5G modem with documented AT commands, etc.

Big question is the power management. It looks like they're using a lot of discrete regulators rather than an integrated PMU. Also, the CPLD is likely to cause a lot of trouble since neither the external connection nor the internal logic is known...

VIA releases open source Xorg driver

VIA has just released a open source Xorg driver for their integrated graphics chips on their linux.via.com.tw portal. Here's the actual download link for the source code tarball.

I am very happy to see this! It's one more step that VIA has been working on to improve and show their support for Free Software and Linux.

Please notice that this driver (as opposed to VIA's proprietary binary-only Xorg driver) has no support for 3D, hardware video codec or TV encoder support. Nevertheless, it is a big step ahead.

Of course everyone involved understands that this simple "code drop" is not enough and that it is just the first step for actual 'Free Software integration'. There is a lot to be done to harmonize the current FOSS driver landscape for VIA's graphics products, from the old via driver in the Xorg git tree, over the unichrome and openchrome and now this new driver. Stay tuned!

Back to Taipei: More work with VIA.

I've just arrived in Taipei two days ago. I'm looking forward to an exciting four weeks of close work with VIA, talking with various different groups in management as well as actual software engineers.

I can only repeat my earlier statements: It still feels great to be able to play such a substantial role in improving the Free Software interaction of a large chip maker and key player in the PC industry.

Of course being in Taipei also enables me to meet again with former colleagues at OpenMoko. I just returned from a very nice dinner conversation with jserv.

gpl-violations.org report in Financial Times Deutschland

The German business newspaper Financial Times Deutschland has published an article about my GPL enforcement work. To the best of my knowledge, it is the first such article in a general newspaper. All previous coverage was in publications or magazines tailored to the IT industry.

However, the content is of very low quality, and the actual facts are wrong in a number of cases. First of all, why go to a personal level and describe myself as having a 'Harry Potter hairstyle', and then calling me "a mixture between bill gates and a heavy-metal fan". I hereby deny any similarity with Bill Gates. I had my hair style like this even in the nineties (before growing it long around 1997-2000 and then cutting it again in 2001). And I listen to a lot of weird music, though heavy metal is generally not on my playlist. Anyway, what is the point of all of that? How does this help people to evaluate the risk of GPL violations?

Further down, the article has claims like "the driver software of the router also contained some lines of code that were originally written by Welte". First of all, it is the firmware, not the driver. Secondly, it is more than a couple of lines (since a couple of lines would probably not constitute a copyrightable work).

The article also explicitly states that I am not fighting for money, but "out of principle". Despite that, it also claims "The first couple of companies are shivering expecting the destruction of their book value". That's illogical.

Furthermore, there are claims that I have focused on companies that only used small amount of open source. To the contrary: The majority of the products that I've enforced so far contain 75% or more open source software. Only small portions were added by the respective vendors.

To the contrary, there was a recent article in the Berliner Morgenpost paper one of the CCC Leaders which was really well-researched and of high quality. Even that one gets some minor facts wrong, but still portrays a realistic picture.

1654 THE CAVE

Today I found out about this years schedule for 1654 THE CAVE.
Today it will happen.
And I'm even going to be in the right part of Germany.

The best coincidence of this year.

Small update on my VIA related work

I know there are many curious readers about what is happening at VIA with regard to Free Software. There are many things that I cannot talk about, but I can still state how excited I am by my new role, and how many (some big, some mall) steps I have managed to make during the short time that I'm working with VIA now.

The last week was mainly talking to various FOSS developers that have written or are maintaining existing Linux drivers for VIA hardware, like Ethernet, I2C, SATA/RAID, AGP, DRM/DRI and others. I have been able to provide hardware reference manuals that some of them have been trying to get their hands on for a long time (even willing to sing and NDA). VIA has also starting to offer reference hardware to selected Linux developers.

I'll be back to Taipei in roughly three weeks (August 21st) and am looking forward to the many interactions with Product Managers and Developers. Meanwhile, I'll continue to have conf calls at weird times and sending tons of emails back and forth, trying to establish the right contacts, getting the right people to talk to each other, etc.

So far I have resisted the temptation to touch a lot of the code. But I think I will not be able to resist very long ;) Right now I just don't want to step onto anyones toes (and/or duplicate work), no matter whether in the community or inside VIA.

OLS 2008 is over

Yesterday was the last day of OLS 2008. In fact, the last day of OLS in general, since from next year on, it will no longer be in Ottawa, but Montreal.

2008 marked the 10-year anniversary for OLS. Impressive. I have missed at least the first one (1999). I'm not sure if I started with the 2000 or the 2001 incarnation. Most likely 2000, since that was about the time I got heavily involved with netfilter.

I had the honor to be mentioned in the 10-year-anniversary talk in a reference to my fashion style (wearing skirts/kilts at earlier OLS's). If I only had known, I might have brought and worn it again ;)

As for the conference itself: I don't want to follow all the various people who have been voicing their discontempt with recent incarnations of OLS. Sure, due to the advent of the kernel summit, the UKUUG linux developer conference, linux.conf.au, the Linux plumbers conference and other events there now is more 'competition' to attract the Linux celebrities. However, most people should not be attending a conference like it was some kind of fan club. There are still quite many people at OLS who actually _do_ a lot of die-hard Linux development work. And those poeple have interesting things to say, and it's interesting to share ideas with them. OLS is pretty much a conference where mainline developers can talk to other mainline developers. It's not an event directed at users, and not an event directed at non-participatory 'consumers' of Linux like many commercial embedded vendors.

So after all, I have to say that the conference was a success and I'd be happy to attend it's future incarnations. Hopefully with my own paper and presentation.

There is one thing, though, that upset me a lot: At the closing ceremony, there was something like a lottery for a handful of Linux-based devices. Among those devices was the Motorola ROKR2 V8. For those of you who don't know: This is a device where the vendor chose to remove your freedom to 'run modified versions of the program'. It will not boot any non-signed bootloader, kernel or executables. And the user is locked out of his own device by means of SELinux. I think it is a grave insult to the Linxu developer community that something like that was chosen by both organizers and sponsors.

Becoming VIA Open Source Liaison

Today, VIA made public what I've already been doing behind the scenes for some time: I've been contracted and appointed to be VIA's Open Source Liaison. As first part of the process, they've released the Padlock programming guide and the CX700/VX700 integrated north+southbridge manuals on linux.via.com.tw.

This basically means that I'll be helping VIA with improving their strategy for Open Source support, such as Open Source driver support, merging those drivers into the respective mainline projects as well as working on publicly available reference documentation for their hardware.

This is an incredible chance to contribute my part to help a major manufacturer of CPU, Chipset, Ethernet, WiFi, Card Reader and PC Graphics components understand what it takes to interact properly with the Free Software community. This is a big learning experience for VIA, and a teaching experience on my part, of course. I feel very happy to be able to work in such a key position, and to be able to put all my knowledge about Linux driver development, the development process, the FOSS community values/ethics/practises as well as licensing related knowledge at work.

VIA is truly interested to learn, and they're already doing a lot internally which you might not have been aware about. I am well aware of many of the historic problems between VIA and the community, related to binary only drivers, not cooperating with mainline development, suboptimal press announcements with little action, etc.

I'm very confident that together we can move beyond this and take a fresh start for much better FOSS support of VIA products. Of course the change will not come overnight. It's a process, and it involves many groups in a large company, each group with their own management, R&D and so on. So please bear with us, and don't expect all drivers to be finished in mainline quality tomorrow.

If you are a Free Software developer and you have some comment/feedback/demand to via, please feel free to contact me (preferably at HaraldWelte@viatech.com. I will try my best to follow-up with all those comments. If you are missing some piece of documentation for hardware or have some other issue, please let me know. I do care, and I will take up the issue with VIA's management.

Receiving the 2008 Open Source Award

According to reports here and here I had the honor of being the recipient of one of the the 2008 Google+O'Reilly Open Source Awards entitled Defender of Rights", presented by Google and O'Reilly.

I'm obviously very happy to see that my work has been recognized this way. Following the FSF Award in March, this is definitely a big honor. Did anyone else receive both awards in the same year so far? ;)

Thanks to the committee for the trust they put in my work. I'd also like to use this opportunity to thank again my lawyer Dr. Till Jaeger and his law firm JBB, as well as Armijn Hemel, who has been running the day-to-day gpl-violations.org operations for quite some time now.

Arrived in Canada for OLS again

I've just arrived in Canada for Ottawa Linux Symposium 2008. After my last visit to OLS in 2005, there were two years of intensive work that prevented me from attending the event. Last year I actually had to cancel an already accepted paper submission :(

In Year 01 post OpenMoko, I have time to visit OLS again. Unfortunately no company to pay for my travel expenses this time, but well, what can you do. Due to scheduling issues with a family celebration, I didn't know until very recently that I would be able to make it this year. Thus I happily forwarded the invitation to talk about OpenMoko to Werner. I was surprised that it's now actually one of the keynotes. Looking forward to it :)

There have been many rumors that OLS is not like what it used to be. Maybe I'm now in a good position to make up my mind about it, since I've missed two years and will be able to directly compare my memories from before with the current event.

UPDATE: Astaro has retroactively offered sponsoring my travel expenses, which is very nice of them - especially considering that I haven't been doing any netfilter/iptables related work for years.

Judge determines NXP has no right to prevent researchers from publicizing about MIFARE insecurity

As reported here and here, NXP has apparently not been able to convince a Judge that the researchers at the University of Nijmegen should be restrained from publicizing about weaknesses in their MIFARE RFID products.

This is really good news. And it came so quick! Sometimes, I can still believe that there is some good left in this world. Almost too good to be true.

NXP sues security researchers studying Mifare classic

In the last couple of days multiple reports stated that NXP has filed a lawsuit against security researchers from a Dutch university who were looking at security flaws of their proprietary MIFARE Classic products.

This is so ridiculous. I'm surprised that this still happens! We live in the 21st century, and IT security has become a well-established field within computer science. Furthermore, systems based on security by obscurity should be long gone.

So we have a company that in 1994 first ships a allegedly secure RFID technology. They developed a proprietary algorithm that did not receive public peer review in the cryptographic community, and used weak random number generation as well as made some mistakes in the protocol/system design. They ship this even back then questionable product without any fix/update for 14 years, irrespective the advances in technology and cryptographic research. During all that time, NXP marketing material claimed the product was fit for 'high security applications'.

Any reasonably skilled person in IT security could determine that the public statements "proprietary cipher" and "48 bit key length" did certainly not sound like high security at all. Thus, it's not surprising that in the last two years, some people, mostly friends of mine, started to look closer at what MIFARE classic is and what it does.

They should be honored and rewarded for their public service in demonstrating the irresponsible behavior of mostly NXP's customers (system integrators) and NXP itself. And exactly those companies are the ones that should be sued for continuing to milk a known-insecure cash cow for more than a decade.

I'd be more than happy to see somebody actually standing on their feet and demanding damages from those vendors. Imagine a small system integrator for a vertical market who wants to look for a secure/safe electronic wallet system and believes in the vendor promises. Now he gets defrauded because some criminal energy - not the ethical researchers at universities - exploit some weakness.

The only reason why large technology companies rarely get sued over the massive security problems they cause in their proprietary products is the fact that almost nobody (even the system integrators and developers) really understand that very technology enough. I sincerely hope that this changes at some point, and we see all those lame promises about alleged (but completely unverified) security go away.

If people would just use publicly disclosed, well-known, well-studied and well-analyzed cryptographic algorithms and implementations thereof, this world would be a much more secure place.

A trip to Fulong beach in the northeast of Taiwan

On Saturday I went to Fulong beach. Believe it or not, my first bathing-at-a-beach trip in Taiwan, despite the long time that I spent on this tropical island.

The venue of the beach is really nice (photos will follow later). The water temperature of the pacific ocean felt surprisingly cold to me - but keep in mind that I'm still spoiled by the 28 centigrade warm Atlantic ocean in Pernambuco/Brazil ;)

However, it wouldn't have been a Taiwanese experience if there weren't some strange observations. First of all, I obviously appreciate that there are a number of life guards. But then I found out that they had a rope in the water, which you were not supposed to pass. The problem with that rope, though: It was at a water depth of about 1 meter to 1.10 meter!

So imagine a huge beach, of which there is a small portion separated by this rope floating on the water, and all the people are crammed into the small confinements between the actual waterline and that rope. The sea was incredibly calm, I could not even detect the remotest hint of any underwater currents, the slope of the ground is _very_ flat, but you can't actually get into the water to swim.

The other peculiarity was that the beach closes at 5.30pm. WTF? Especially during those incredibly hot days, why not just stay in the water into the evening or even at night?

So as a summary, I have to say, Brazilian beaches rule in comparison! Nobody to tell you that you cannot go into water deeper 1.10 meters, beaches are always open (there are no private beaches, they're all public), and most part of the day you will get served beverages, alcoholic drinks and fresh food.

So this trip to Fulong beach was certainly an experience I wouldn't want to miss. But not one that I'm likely wanting to repeat again. I now know what it's like :)

Submitting pcc_acpi for mainline inclusion

The last couple of days I've once again updated my kernel to current linux-2.6.git and I had to do the manual merge of the apparently abandoned original out-of-tree pcc_acpi.ko driver in order to get brightness control of the LCM on my Panasonic CF-R5 laptop.

I've tried to contact the original author multiple times during the recent years asking about his mainline inclusion plans, with no response so far. So this time finally I decided to submit the driver even without explicit wish by the original author. It was already GPL licensed, so no problems here.

However, the driver didn't yet support the backlight class device API, neither did it support user-configurable keymaps on the input device for the hotkeys. It furthermore added tons of new files to /proc with all the ugliness of writable proc files, and it didn't conform to the coding style at all.

Matthew Garrett was extremely helpful with his fast review, and I have just sent the 0.94 version to linux-acpi, hopefully the last one before kernel inclusion. I should have done this a long time ago, but it just didn't feel right to go ahead without the original author's opinion. However, the driver now doesn't really look like the old driver anymore, very little code left. So I feel like I have more moral right to go ahead with it now...

Of course I've only tested it on the CF-R5. Anyone with different Let's note models and versions: Please feel welcome to test it and send bug and success reports.

Electrical installations in Taiwan

I haven't noted this here yet, but I'm in Taiwan again since two weeks ago. I also have two more weeks of Taiwan ahead, since I decided to stay a full month and go to a Chinese language school. Now don't expect too much, this is basically just to find out whether I really want to seriously learn about the language or not. Four weeks will not get me anywhere, at least not beyond pronunciation drills and very basic sentences + vocabulary.

Anyway let's get to the subject of my posting: During the last couple of days I actually spent a significant amount of time trying to find something that to me is the most normal thing: A 60W 220V light bulb with an E14 socket. But that would apparently only be normal in Europe. Here in Taiwan, the voltage typically is 110V at 60Hz, with US-style power sockets. Basically just like the US or Japan.

However, for some really strange and unknown reason, the particular apartment has both 3 phase 110V and 3 phase 220V. The power sockets are all 110V, whereas the fixed ceiling lights are all 220V.

So apparently sometimes people have 220V lights here, and you can get a limited selection of usual bulbs in 220V type, even though 90% of the light bulbs in the store would be 110V.

I've been to Carrefour, B&Q and Tsan-Kuen (all large super-stores in NeiHu). 220V was really rare, and neither of them had any E14 bulbs (independent of shape) for 220V. So after a lot of wasted time, I then decided that I'm just going to replace the entire lamp socket with an E27 type in order to accommodate a different lamp. My other option would have been to add another E14 socket in series and then use two 110V bulbs attached to 220V mains.

Now the really big question is: Why would anyone have the lighting at 220V whereas the power outlets are running1 at 110? This means you need separate infrastructure, separate lines, transformers, metering devices, circuit breakers, etc. And three simply is no point. I could understand 3-phase 220 is better than 3-phase 110 in case you want to use extremely high-power consumers.

DVB-T transmit in pure PC software

I recently discovered this paper about Soft-DVB, a full PC-software DVB-T transmitter, it apparently is now possible on a 1.8GHz Celeron M based system to do a full software encode/modulation of a MPEG2 transport stream onto a DVB-T compliant carrier that can be received by off-the-shelf consumer DVB-T receivers. And all this on Linux, using gnuradio and the USRP.

This is really great news, and an incredible achievement by the authors of the software, particularly Vincenzo Pellegrini.

There is one (at this time still) moot point, though: The code has not been released yet. It has been demoed at SDR related conferences, so it really exists. Vincenzo has announced on the gnuradio-discuss mailinglist that eventually it will be public - without stating some kind of date, though.

I suppose he probably has to wait until his master thesis has been finalized and approved. That should be in the order of months, not years...

Nokia, FOSS, SIM Locks, DRM and the universe + Motorola's failure

As Bruce Perens points out at this blog entry, it is very much possible to design a product, particularly an embedded Linux device such as a mobile handset with all the usual bits and pieces (DRM for mobile media content, SIM locks, etc.) while preserving the freedom of Free Software.

I'm really pissed off by the kind of FUD that big vendors try to spread about it. There are so many claims that the user has to be locked down, that he cannot be allowed to modify/replace the Linux kernel or other bits of the software stack, etc.

I can only agree full-heartedly with Bruce's article. Such claims are all bullshit. I've worked for a long enough time with Free Software, the Licenses involved, the legal framework of those licenses (Copyright Law), the Hardware Industry, lately even a mobile handset manufacturer. I've seen the software and hardware architecture of a number of phones myself by reverse engineering. Never have I found any reason why the bright-line philosophy (see Bruce's article) should not result in a perfectly working, all-interests-satisfied solution.

Let me use this opportunity to point out my disappointment at the failure of Motorola to solve this problem properly. Instead of designing their MotoMAGX family of handsets in a way that preserves the freedom of the Free Software [community, users] and protects their valid business interests, they chose to go the easy shortcut of walking borderline on what they think the GPL permits them: They use cryptographically signed kernel images, a bootloader that only accepts binaries signed by them, plus a kernel that only accepts signed modules, plus a SELinux locked-down userspace that is very restrictive on what userspace programs can still do.

This would all be nice and good _if_ they were to provide the user with a way to either sign his own kernel images with their key, or (better) to store his own signature in the bootloader. So the hardware would accept Motorola-signed kernels and kernels signed by the user (actual owner!) of the device.

The further proprietary bits of the software stack required for DRM protection can simply refuse to operate if not run under a Motorola-signed kernel. Especially with TPM's and similar technologies becoming more widespread in the mobile world, there is a very straight-forward solution to this problem. The bootloader can store the hash of the kernel image in some TPM protected register, and the proprietary DRM system can refuse to operate if the hash is not the original one.

With regard to SIM-Lock, Operator-Lock and all the other locks: As Bruce points out, those are restrictions of the GSM/3G modem. All implemented in the firmware of this device. It doesn't matter if you run Windows Mobile, Symbian, Motorola's own locked-down Linux kernel or a custom user-built Linux kernel on the application processor. The various GSM/3G related locks are never implemented on that processor, but on the baseband side.

I hereby challenge the mobile industry to come up with hard, technical fact about what particular problem they have in designing open, FOSS-compatible devices, where every user can modify and/or replace the FOSS programs, while ensuring the integrity of their DRM, IPR, SIM lock and other business model related technologies. I will sit down and look at any such issue brought forward and I'm extremely confident that for all of such problems there's a straight-forward technical solution (bright-line in Bruce's terminology) which will not require the proprietary or FOSS side to make any sort of moot compromise.

If not only for the reason of legal safety and security, such solutions should always preferred to going borderline with FOSS licenses or against the FOSS developers and users community!

Persistent Google recruiters suck

I think I've read this before by one or the other Linux/FOSS developers blog: Googles persistent recruitment sucks. At least I've spoken with a number of well-known developers in the community, and they all have been contacted before.

What makes the situation even more difficult is that there are apparently different recruitment teams, so sometimes they want to hire you in Australia, sometimes somewhere else. I've heard rumors that they now have a company-wide blacklist, and I've asked a number of times to not receive further recruitment mail, so I should be on that list by now.

The worst message arrived today. The particular recruiter actually _knew_ that the same department had last contacted me six months ago, and that I was completely not interested. But she was hoping that by now my mind or my job situation had changed, and that she would want to talk to me about employment options at Google.

I'm now really running out of options. I've tried to state it politely a number of times over many years that I am not interested and do not want to receive further emails. As if this wouldn't occur to me automatically, given their omnipresence in the Internet world, and their numerous previous recruitment mails, even in the case I actually was seeking employment now.

I guess I will have to try to be rude now, maybe then they think my personality wouldn't fit the company spirit. I don't know.

Just let me say that this kind of aggressive recruiting is in itself alone reason enough for me to not want to work for this company :(

Last minute: Presenting at LinuxTag

As apparently there was a last-minute drop-out in the Security track of LinuxTag 2008, I have been invited to present. It is great that I could convince them to do a talk about my current favorite subject: Enabling more security research in communications protocols outside the TCP/IP/Ethernet based Internet.

I don't want to spoil it by providing too much information upfront. I'm sure there will be recordings available afterwards. For now, you can get the main points from the abstract

Bought another motorbike: Yamaha FZ6 Fazer

During the last week or so, I spent a lot of time test riding a number of various motorbikes. Both real sports / supersports bikes, as well as 'sportive touring bikes'. I wasn't really sure if I should go for a true/real sports bike like the Suzuki GSX-R (750/1000) or start with something less 'extreme' first. One thing I learned, though, is if I went for a sports/supersports bike, I'd definitely have to keep my BMW F650ST around. Those racing bikes are just not useful for casual riding in city traffic. But I want both, fun at the motorway, as well as a useful bike for local travel inside Berlin.

Then I got a really irresistible offer for a two-year-old FZ6 Fazer (with ABS), and I had to buy it. So for now, it is this. It's probably reasonable to first go from the familiar 48bhp to 98bhp before reaching to the 160bhp range of the Suzuki GSX-R. So in the end, I can even claim that I'm being rational and reasonable here, going "only" to an (already-ridiculous) amount of power, than a beyond-ridiculous amount ;)

And please don't worry too much. I'm not suicidal, and I've been riding quite safely for more than 11 years now ;) This is not going to change!

Chaosradio on Software Defined Radio

I've had the pleasure of being invited to Chaosradio Express maker Tim Pritlove to talk about Software Defined Radio in general, and gnuradio plus USRP specifically. You can listen to the resulting 2+ hours of podcast (in German).

It's been a great experience, and I have a good feeling that it was possible for us to explain this fairly detailed subject to our already at least moderately technical audience.

SDR is really hard since it combines aspects of traditional radio, i.e. physics of electric waves, electrical engineering both analog and digital, digital signal processing and software. The biggest part is really advanced mathematics, and at least from all the subjects that I've seen, it's probably the most direct and close-to-theory incarnation of applied math.

Luckily, a fairly high-level understanding of the algorithms and principles involved are already sufficient to do a lot, since most of the deep-down mathematical details of many algorithms have already been implemented as building blocks for gnuradio. Still, I assume the number of developers who are actually able to use gnuradio is far too low. If you're looking for an interesting field of software right now, I suggest going for digital signal processing. It's in every area of communications, ranging from analog modems over ISDN, DSL, WiFi, USB2, Bluetooth, GSM, UMTS, DECT, ZigBee, Ethernet, VoIP and probably any other communication technology that we use today.

Motorbike troubles again

It seems like I lost all my luck. Only a three weeks ago, the Yamaha TW-225 in Taipei had problems after my arrival. Now that I'm back to Berlin, my BMW F-650 had some serious trouble, too.

Starting the engine turned out to be really hard (started only on something like the 10th attempt, even though usually the first one is sufficient). Furthermore, pulling the gas handle only the tiniest little bit kills off the engine completely, independent of how far the choke is asserted.

So today I spent some five hours in disassembling almost the entire bike, removing the twin-carburetor, disassembling and cleaning it and putting the entire bike back together again. The engine is running fine again. I just wonder why I have this kind of carburetor problem already the second time in the last couple of years.

There's almost no visible dirt inside the carburetor, and all the fittings are fine, no signs of any leakage, no signs of any significant wear of any of the involved parts. Still, cleaning and re-assembling it clearly removes the problem.

Back from WGT

There are two fixed dates every year that I never miss: The annual Chaos Communication Congress in Berlin between Christmas and new years eve, and the Wave Gotik Treffen music festival in Leipzig.

This year I was camping at the event campsite again, following two lazy years in a hotel. I enjoyed it a lot, especially since the weather was perfect. Only sunshine, not a single drop of rain for the entire four days.

The festival itself was like always. Great. :) I think my personal favorites this year was the industrial (probably better: rhythmic noise) act NULLVEKTOR as well as INADE.

Victory: Skype withdraws appeals case, judgement from lower court accepted

The court hearing in the "Welte vs. Skype Technologies SA" case went pretty well. Initially the court again suggested that the two parties might reach some form of amicable agreement. We indicated that this has been discussed before and we're not interested in settling for anything less than full GPL compliance.

The various arguments by Skype supporting their claim that the GPL is violating German anti-trust legislation as well as further claims aiming at the GPL being invalid or incompatible with German legislation were not further analyzed by the court. The court stated that there was not enough arguments and material brought forward by Skype to support such a claim. And even if there was some truth to that, then Skype would not be able to still claim usage rights under that very same license.

The lawyer representing Skype still continued to argue for a bit into that direction, which resulted one of the judges making up an interesting analogy of something like: "If a publisher wants to publish a book of an author that wants his book only to be published in a green envelope, then that might seem odd to you, but still you will have to do it as long as you want to publish the book and have no other agreement in place".

In the end, the court hinted twice that if it was to judge about the case, Skype would not have very high chances. After a short break, Skype decided to revoke their appeals case and accept the previous judgement of the lower court (Landgericht Muenchen I, the decision was in my favor) as the final judgement. This means that the previous court decision is legally binding to Skype, and we have successfully won what has probably been the most lengthy and time consuming case so far.

Tomorrow: Court hearing in Welte vs. Skype GPL case

Tomorrow at 10:30am at the Oberlandesgericht Muenchen (higher regional court of Munich) there will be an oral hearing in the "Welte vs. Skype Technologies SA" case. The hearing is to be held in room E.06.

This case is about a GPL violation of Skype, related to their sales of Wifi Skype phones based on the Linux operating system kernel.

I'm fighting as part of the gpl-violations.org project in enforcing the GPL against Skype since February 2007. Initially Skype didn't respond, we then applied for a preliminary injunction. That injunction was granted by the court in June 2007, but Skype chose to file an appeals case against it.

The court hearing tomorrow is exactly to debate about this appeal.

Interestingly, Skype is arguing against the validity of the GPL as a whole, asserting that it is violating anti-trust regulation and similarly strange claims.

Back from the trip to Taiwan

It's been some time since my last blog post, mainly because I've been quite busy in Taiwan. First there was the conference, then there were a number of meetings with various companies to educate them about GPL licensing and how to interoperate with the FOSS community for better hardware/driver support.

The other part was actual spare time. I spent many months in Taipei during my work for OpenMoko, but I never really had much time to explore the city, or even other parts of the country.

This time I explored quite a bit of the Taipei nightlife, visiting places like Luxy, Lava, Room18, Barcode, ageha, and even the so-called "meat market" of Carnegies and Tavern.

I've also had time to try one of the many hot spa's of Taipei in Beitou, as well as a really great motorbike trip to the national forest in the Wulai mountain region.

Unfortunately the weather wasn't that great, so I had to postpone my plans to visit the northeastern and the eastern coast to some future trip.

And the most interesting part is: I actually made contact to Taiwanese people who are not at all in any way related to work :)

Further Taipei exploration brought me to the Wufenpu fashion wholesale area, as well as Ximending. Most impressive is also the "Taipei underworld", i.e. the various underground shopping malls near Taipei Main Station, such as the Taipei City Mall, Station Front Mall and ZhongShen Mall I and II. You can literally walk for many kilometers underground...

Now I am one day in Frankfurt, and tomorrow one day in Munich, Friday one half day at home, and then there will be four days of music festival at WGT 2008.

First ASUS day of OpenTechSummit Taipei

As I might have indicated before, I have the pleasure of being invited to the OpenTechSummit 2008 in Taiwan. Two days ago, I was at the opening dinner. The problem of that dinner was the lack of attendees. There were loads of delicious (free, sponsored) food, but not even remotely enough people to eat it.

Today I had a bit of a problem finding the ASUS venue, since it was said to be at "exit 2" of the MRT station. Unfortunately it had two exits of that name, one on each side of the station :)

One presentation there I found particularly embarrassing was the one about the eePC SDK. First of all, I will ignore my thoughts about why you actually need such an SDK if it really is nothing more than a customized Debian Linux with Eclipse. But even then, why fly in a foreing speaker to do a click-by-click walk-thhrough on how to create a 'hell world' Qt program using eclipse?

My favourite of the day was definitely the presentation on the OpenPattern router board.

Back to Taipei

After a break of almost six months, I'm back to Taipei. Obviously I now see everything from a quite different angle: I no longer work for OpenMoko, Inc., thus I actually have spare time here and can explore both the capital city as well as the country much better than before with that ever-growing OpenMoko workload.

However, the first day wasn't quite as relaxing as it should have been. First, the apartment key that was supposed to be with the guard of the apartment building accidentally was mixed up with some other key and got sent to the landlord.

A couple of hours later I discover that my Yamaha TW225 motorbike doesn't work anymore. First diagnosis: Battery is empty (not surprisingly). I try for like 15minutes to kickstart it, to no avail. Not even a single explosion in the engine. Then I tried to push it, and got it to a couple of explosions after which it died again. Further push-starting was prevented by the way-too-smooth floor of the parking garage, where the wheel just slides as soon as you release the clutch :(

Some disassembly revealed where the battery is (I don't know this bike at all, much opposed to my F650ST in Germany). The battery was severely short of acid/fluid, maybe somebody pushed the bike over and it leaked. Obtaining battery additive and refilling results in only 800mA charge current. I think it's dead. Now I'm in the process of ordering a new battery.

Let's hope the next couple of days are better than the start of this trip...

Review of DORS/CLUC 2008 in Zagreb, Croatia

I've spent the last five days in beautiful Croatia - most of the time in its capital Zagreb. The local conference DORS/CLUC has been around for a couple of years, and in fact I've been at a previous incarnation three years ago.

It's a nice, small but great event. And in fact, for the invited speakers as myself it feels more like an all-inclusive holiday than a conference. The organizers went out of their way to make us feel at home, including a trip to the waterfalls of Plitvice national park (photos will be available shortly at my public photo album.

It was also great to spend some time with Alan Cox again, who to my surprise was also attending the event with two lectures. Hope his luggage didn't get lost again on his way home...

Report from FSFE FTF Licensing and Legal workshop

I'm on seven-hour train ride back from Amsterdam, where I've been attending the first Licensing and Legal workshop of the Freedom Task Force (FTF) of the Free Software Foundation Europe (FSFE).

While having a somewhat lengthy name, the FTF has been doing great work on bringing together a large group of legal and technical experts in the field of Free Software licensing. So far this was all 'virtual', happening on mailing lists.` The meeting in Amsterdam was the first of its kind, and was a huge success.

By the nature of the FSFE, most of the people were from Europe, though there were attendees from the US and even Australia, too.

There were many interesting and surprisingly interactive workshops. It was also a good opportunity to meet Armijn (the second half of gpl-violations.org) and Shane (full-time manager of the FSFE FTF), as well as many lawyers, both corporate legal counsel and from law firms.

The interest in Armijns presentation about gpl-violations.org and Till Jaeger's overview about the legal cases we've handled over the years in Germany were very well received and there was more interest and questions than the short time permitted.

What was really good for me to see is that large consumer electronics companies in Europe and the US are now implementing internal business processes to ensure GPL and other FOSS license compliance. They're also increasingly using very clear contractual language throughout their supply chain to minimize the potential risk of any "hidden" GPL surprises in products they source from OEM/ODM companies.

Further studying of Abis protocols, moving towards implementation

The first quarter of 2008 is already gone, and I still haven't found all the time that I wanted to find to play with my BS11 base station[s].

However, I've spent quite a bit of time over the last couple of days further studying the GSM/3GPP 08.5x documents, as well as a thorough read through the mISDN source code.

GSM/3GPP 08.5x describe the layer1, 2 and 3 protocols of the Abis link between BSC (Base Station Controller) and BTS (Base Transceiver Station) in a GSM network. It's modelled on top of a E1 link in PCM30C configuration, i.e. TS0 is for CRC4 and synchronization, TS16 is used for the layer2+layer3 protocols, whereas the other time slots are used for transfer of the actual voice call data.

After looking at the various different driver options on Linux, I have determined that mISDN is the most promising and flexible architecture available. mISDN also has a layer0 + layer1 driver for the NT mode of the HFC-E1 card that I'm using. mISDN is great in a way that every layer is strictly separated from the other layer, and that at any layer parts of the stack can be implemented in userspace using library API.

Thus, I've started to write some mISDNuser based code to attach to the kernel-side hardware and lower-layer drivers. I'm not yet sure if the Q.921 (ISDN Layer2, also called LAPD) of the mISDN kernel side can be reused for Abis or not. The differences between standard Q.921 used on European ISDN and the Abis Layer2 are fairly small, so I hope to get it working with the existing LAPD code.

Unfortunately, I have paid work to take care of, so I will once again be distracted from this most interesting of my toy projects.

We don't do Advertisement on the netfilter.org homepage

For some reason, the amount of inquiries about companies who want to put ads on netfilter.org has significantly increased. Since the content of that site has not really changed much in the last (at least) four years, this sudden interest is somewhat surprising to me.

However, we are absolutely not interested in advertisements. I personally hate any form of advertisement, whether in print media, radio, TV, WWW or on billboards. In fact, advertisements are the reason for me to not watch any privately owned TV or radio stations for at least eight years.

So to all the advertising companies out there: Only over my dead body will there be any kind of banner ads on any of the websites of the projects in which I have anything to say.

Schiphol airport uses active millimeter wave screening

I was quite surprised that Amsterdam airport is beginning to introduce active millimeter wave screening instead of the good old metal detectors. The specific device seen in operation at one of the queues between the international and the Schengen area of the airport was L3 Communications ProVision(TM).

While doing some research about this subject on the net, I discovered cargo X-ray solutions such as those described in this article. You can mount a mobile unit onto a track and then go as deep as 200mm of steel to x-ray through the metal plating of a cargo container. This is really scary stuff...

KLM also using Linux in their Entertainment System

The intercontinental KLM flight from Sao Paulo to Amsterdam was using a fairly new (05/2007) Boeing 777-300, and it was equipped with something like an 8" wide screen entertainment system, not unlike the one that I saw some months back in a Shanghai Airlines flight.

This time I had the luck to see the Linux based system boot twice. The boot time is horrible (on the order of 4 minutes) and you can see many hardware details. It's using a Geode type CPU and a realmagic GPU, has a natsemi Ethernet chip and the credit card reader is actually a USB HID device.

All over the place they have fairly low-level debug code spit out to the console, this really looks like "it worked on one developer board, ship it to the airline" product. You can see mistakes in shell scripts ("ls: no such file or directory" and similar stuff from init scripts, as well as debug code from their UI applications.

It would really be interesting to get my hands onto an Ethernet link in that in-plane network. Guess one could have quite a bit of fun with that :)

I've taken a series of snapshots throughout the boot process. Will post them once I'm back home and find time to wade through the holiday pics.

I don't work for Google - no matter what the rumors say

A number of people have recently independently approached me about rumours that I'm now working for Google/Android, after having left OpenMoko, Inc. in November 2007.

According to one source, some friend who visited Android was told by Android that I would be now working for them. There is no truth to this.

Please put an end to those rumours. I'm not working with or for either Google or Android. There also are no plans to do so, and there have never been any negotiations, aside from the usual Google headhunters that approach anyone visible in the FOSS world every so often - which I always decline, indicating that I am not interested in a dependent employment position, no matter for which company.

I will continue to be doing freelance contract work on projects that are interesting to me and within my fields of expertise. Should anyone chose to approach me with an interesting technical Android system-level and/or hardware related project, that would certainly potentially be interesting. But I'd look at it like any other inquiry.

Back from holidays

I'm currently sitting at Amsterdam Schiphol Airport, waiting for the last connection in my Recife - Sao Paulo - Amsterdam - Berlin return trip.

I'll be wading through the several thousand emails over much of the next couple of days, so please give me some time to get back to you.

Receiving the 2007 FSF Award for Advancement of Free Software

The news has already made it to the net during my (offline) holidays, so this entry in my journal will come hardly as a surprise to you: The Free Software Foundation Award for the Advancement of Free Software 2007 has been granted to me :)

I am deeply honored to be the recipient of the award, joining the list of (much more distinguished) recipients of the award. At the same time I'm sorry to not having been able to personally attend the awards ceremony. I've outlined the three key reasons for this in the statement that I prepared to be read at the ceremony.

Update from first week of holidays

For those of you who're curious: The first week of holidays went just fine, spending something three days in Sao Paulo and three days in Curitiba In Curitiba, I had a rental car and went to Vila Velha, as well as driving the serpentines of the Rua Graciosa through Morretes to the Beach. Oh, and obviously in Curitiba I had to go to Homem Pizza and Happy Burger, the two restaurants that I frequented the most while working at Conectiva 7 years ago.

The biggest problem so far was the malfunction of the in-room Save of the Hotel in Curitiba, resulting in not being able to access any of my cash reserves, credit/debit cards, passport or laptop for two days. They actually had to physically break the safe open since the lock mechanism was stalled/clogged in a way that it did no longer move.

Now I've just arrived in Recife, where after two days, the journey will continue towards Porto de Galinhas.

Almost offline for holidays

I'm hereby announcing that I'll be offline most of the time between March 3rd and March 26. This is the longest time that I've been offline for quite some time - and it's a much deserved holiday after the intense work of the last year.

I'll be doing quite a bit of travel in Brazil through those more than 3 weeks, meeting some old friends and ex-colleagues from my time in 2001 at Conectiva. I'll also be spending some time at the beach, plus exploring a bit of Parana and Pernambuco by [rental] car.

This also means that I'll likely end up being forced to use my horrible Brazilian Portuguese again. But well, at least for me, unless forced to speak a certain language, I won't speak it at all. So this must be a good thing, then.

Please don't expect any reaction to e-mails, snail mail, phone calls, faxes or any of the like during that period of time. I won't even have my German GSM phone online to avoid roaming charges killing me.

Thoughts on FOSDEM 2008

I really have been disappointed quite a bit with my visit to FOSDEM this year. In fact, many of my observations might actually apply to Brussels as a whole, I really don't know.

It all started with arriving at Bruxelles Central station on friday, where the entire station was so crowded it took me ages to fight my way through the crowds. Then something like only the fourth idle cab driver was willing to actually take us to the hotel. The others for whatever reason didn't want to earn those 15 EUR. Aren't there some regulations forcing them to transport paying passengers?

Then, let's talk about the social event on friday. How can you hold such an event in a place that's about one third of the required size, and which has a music volume level that effectively prevents any form of communication. I left after about 10 minutes there, since there just was no point at all. One wonders what happens if there is a fire. Aren't there some kind of regulations of the max number of people you are allowed to cram into tiny places like that pub?

At the conference venue the problem seemed to re-occur. All the rooms are significantly too small. Combined with the lack of ventilation and the lack of a PA system it was not possible to stand more than a single talk in the X.org devroom, before I had to get out to get fresh air.

Getting in and out of the DevRooms is also a challenge by itself, since the hallways are over-crowded and full of noisy and loud conversations. Opening the door for even a small amount of time is barely impossible, since that would expose the talk on the inside to the enormous noise levels on the hallway. Especially since the DevRooms don't have any PA system, it's already quite a challenge to understand the speaker inside the room. Somebody opening the door just completely kills the communication flow

The entire idea of putting up all the projects with tables in the hallways seems questionable to me. They do nothing but block the path for other people (also blocking emergency escape paths). Furthermore, cold air gets in all the time since many people have to use the doors in order to walk between the different buildings. It would make much more sense to keep the hallways for what they are: Ways where people walk between rooms. The project tables should be inside rooms. Those rooms would self-contain the noise generated by the tables, be more comfortable (warm, no wind) and keep the hallways free for people to walk on.

The same problem exists for the "BAR" where you get food and drinks. It's too small, too crowded, and absolutely not comfortable at all (cold wind coming in through the permanently open doors, ...)

And then consider the public transport "performance" on weekends. It took me regularly more than an hour for something that was a 2.6km distance between hotel and venue. That's quite ridiculous. Given how crammed those few trams are that actually run, it doesn't seem to be a shortage of passengers that makes them operate so few trains per hour.

All in all, I could not do anything else but to attribute FOSDEM 2008 as something like "the most inefficient event", i.e. where I wasted a lot of time for reasons stated above, rather than actually attending lectures.

Flying from Berlin to Brussels without showing any ID

It was really surprising to see that there was absolutely zero control of any ID on the flight between Berlin and Brussels. I'm well aware of the marvels (and data protection nightmares) associated with the Schengen agreement. However, zero form of identification on air travel was really a big surprise to me. Not even my flights inside Germany had this 'feature'

How did this work? First of all, I booked the tickets through a travel agent quite some time in advance. No form of ID required (though he has my banking details). Next, I did a Lufthansa online check-in from my home, printed the boarding pass. On the airport, used the self-service luggage drop-off counter. Then directly went to the security check, and then to the gate. During the entire time, nobody asked for any form of ID.

So if I did buy the tickets on cash rather than with bank transfer, it would actually still be possible to travel under false name and thus anynomously. Amazing. Am I missing something?

flu provides opportunity to watch linux.conf.au video recordings

A quite serious flu hit me four days ago. While this prevented me from getting any serious work done (my doctor actually explicitly asked me to refrain even from mental work), it provided me with ample opportunity to watch through all the exciting video recordings of linux.conf.au 2008.

The various technical X.org driver side related talks were really good to hear, and I'm happy that there is so much innovation and development happening there now.

The most hilarious talk according to my scale of humor was Matthew Garrett's presentation on suspend to disk. I had to watch it twice, just because it's so entertaining. Rusty: Even you'll have a hard time competing against that level of entertainment :)

Something is wrong if your mail client is using 13.0GB of memory

On my fairly new quad-core 4GB RAM system I noticed that suddenly closing tabs in the web browser resulted in tons of disk accesses, which I [correctly] attributed to swap usage. This is quite a big surprise, since I don't use any integrated desktop and generally only run lots of uxterms in ion3 (over two 1600x1200 heads with 8 virtual desktops on each head) plus firefox.

As it turns out, earlier today I started thunderbird (Debian calls it icedove) in order to do some cleanup (moving folders around) on my IMAP server. After about half a day, I was looking at the following line in top:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                               
 3474 laforge   20   0 13.1g 3.1g  10m D    1 81.7  47:49.91 icedove-bin                                                            

This is ridiculous. 13GB virtual, 3.1GB resident set size. And all that with something like roughly 3 million e-mails spread over about 200 IMAP folders.

Who is supposed to use those programs? What do they use for testing? People with 10 mails in their inbox? Also, if you actually download the headers of a new folder, or headers of new mails in a folder, it takes _ages_. It looks actually like they individually request the headers of each email, without using the tagged command features of IMAP, thereby removing all the pipelining effects and being bound to one complete thunderbird-through-kernel-through-network-through-imap-server roundtrip per message. I haven't actually looked at the code, but just from observing the application, this seems to be the case. Also, every time I use the 'search messages' feature for any header that the IMAP server does not have an index for, thunderbird refuses to wait long enough until the server responds.

So far I always thought mutt's memory usage of 40-80MB is already excessive, considering all it does is displaying a bit of plain-text emails. Well, for once I've been happy again that I'm not a regular user of those kind of bloated GUI programs. firefox somehow being the sole exception to that. It's barely useable on my 1.06GHz / 512MB laptop, where you already notice quite considerable lag in the responsiveness of the UI. :/

Guess next time I have to move folders, I'll probably revert to something like cyradm (that's a minimalistic imap client with command shell, not unlike the old 'ftp' command for FTP).

Working on ISO15693 support for librfid

It's really been bugging me for a long time that librfid was lacking support for the ISO15693 protocol. The supported reader hardware ASIC can do it, but librfid always was lacking the respective code. It has been on my agenda even three years ago, but there were always higher priority items to pre-empt it.

In December 2007, Bjoern Riemer submitted a long patch to add partial ISO15693 support to librfid. The size of the patch reflected the huge amount of work that must have went in that code. So I couldn't really afford to let all that work bit-rot. I went through several iterations of code cleanup, starting with cosmetic issues, and digging deeper and deeper. I think it now doesn't really look all that similar to what Bjoern originally did, but at least now we have a working and fairly well-organized ISO15693 anti-collision implementation in librfid.

However, ISO15693 has many different options with regard to speed, modulation, coding, etc. All those combinations have to be carefully tested. What's also missing is a way how to iteratively cycle through all available ISO15693 tags within range, similar to what we do with ISO14443A and B.

Once that work has been finished, the actual higher-level standard commands, as well as the nxp I*Code2 and TI Tag-it vendor-specific extensions can be implemented on top. This can probably be done on one or two more days of additional work. Stay tuned...

Meeting between gpl-violations.org and FSFE FTF

The last two days, I enjoyed a meeting between gpl-violations.org and the FSF Europe Freedom Task Force.

Participating were Armijn Hemel (whom I have to thank to assure gpl-violations.org doesn't die while I was in Taiwan for OpenMoko), Shane Coughland (who is doing an excellent job coordinating the FTF) and myself. For a couple of hours we've also been joined by Till Jaeger, who has handled all the legal cases of gpl-violations.org so far.

This meeting has been over-due, mostly because I basically dropped off the planet for way too long time. We've discussed all the current matters regarding strategies for license enforcement, current cases, progress of the FTF legal and technical networks, as well as future plans for incorporating the gpl-violations.org project.

Yes, you have read correctly. I've been planning to do this for quite some time, and I'm confident that 2008 will finally be the year in which this happens. It's too early to talk about any details, but this is the logical step to assure both financial and legal independence of the project from my person, as well as scalability. As you might know, we have a couple of hundred reported violations and can only cherry-pick those we consider particularly important.

In any case, it was a very productive meeting. I seriously believe it has helped to make all of us work together in a coherent manner, i.e. increased productivity and effectiveness for a long-term strategy to increase the amount of free software license compliance in the industry.

Disrespect for election observers in Hessen

My fellow friends from the CCC have tried their best to observer the elections in Hessen (Germany) yesterday. The amount of resistance they've met is more than shocking. If you want to read more about this (in German), I'd suggest reading Frank's blog entry, Holger's blog entry and the official CCC release on this subject.

In fact, in some of the municipalities the election supervisors have received official statements warning them about the CCC's intention to disturb the elections. What nonsense is this ?!?

Having been part of a CCC election observer team in the past, I can only state that this is beyond anything that we've seen before. Why would there be any resistance against quiet and peaceful observation of the elections?

The CCC election observers have absolutely zero history of ever having disturbed an election in any possible way. I'm sure you can ask about any municipality that has had first-hand contact about this. We know the laws and regulations very well, and want to do nothing else but to _observe_ the

Securitization

As a friend of mine (who has studied political science) recently told me about the process of securitization. Finally I know a word for the process that seems so commonplace in todays politics: Framing something that is actually a minor problem with some criminals into a question of essential survival, thus eliminating any rational debate about it.

Learning about NAS chipsets

For gpl-violations.org, I've been analyzing a number of NAS devices recently. While most of them are based on some kind of more or less general purpose CPU (Intel StrongARM based IOP or e.g. VIA's embedded x86) plus standard peripherals, there appear to be more and more special purpose SoC's for this purpose.

To some extent, this is only a logical development. NAS appliances seem to be a growing market, and the desire to achieve higher integration by e.g. moving the SATA/IDE controllers into the SoC make development easier and reduce BOM cost.

It's quite amazing how much effort some companies actually go through. One series of chips that particularly caught my attention is the Stormlink Gemini series of NAS CPU's, e.g. the SL-3516. Looking at the public data sheets is particularly boring since they only have two pages. Instead of that, I'd recommend looking through the kernel sources that their downstream appliance vendors publish. They actually have hardware crypto, hardware IPsec acceleration, TSO (TCP segmentation offloading), hardware NAT, ...

As if that wasn't enough already, they also now have a dual core variant, which has two ARM920 cores next to the hardware crypto and pimped-up Ethernet controller!

While reading through the code, I made a slightly cleaned up diff against vanilla 2.6.15. It reveals a number of things that I'd like to point out:

• They have actually managed to implement a arch/arm/mach-sl2312 directory (instead of just editing some existing machine), though there seems no distinction between 2312/3516/3518/...
• They have GPL licensed drivers for their entire hardware functionality, not a single bit of proprietary stuff. It even comes with proper license headers and MODULE_LICENSE tags. This is really remarkable, especially for stuff coming from Taiwanese hardware companies. Congratulations!
• They integrate DMA capable RAID5 hardware generation, integrated with the Linux raid code
• They have two OTG capable EHCI USB controllers
• The ARM core they use is a FA526. It seems to originate from (another Taiwanese) ASIC/IP vendor called Faraday. Apparently an independent implementation of the ARMv4 instruction set, allegedly 100% compatible, even including a replica of the ARM ICE/JTAG. Could Faraday be to ARM what VIA is to Intel? In any case, definitely exciting.
• While the vendor-released GPL licensed sources contain support for this FA526 in a fairly decent way, it has not been merged into the mainline kernel. That's a pity. Does anyone know more about this? I think this should definitely be cleaned up and merged mainline.
• they re-use an entry from the mach-types registry for the sl2312. Not only do they use that machine type for all Stormlink SoC, but also the downstream hardware vendors use the same for all their products. not good. Did anyone tell them that registering new machine types is free?
• They're doing some obscure I/O pin sharing between IDE and the flash controller resulting in lots of ugly code. Probably a hardware workaround :)
• They have very invasive code all across the Linux crypto code, probably because they need async crypto support, which the crypto framework of 2.6.15 doesn't yet provide
• They seem to integrate their crypto with cryptoloop, but not dm-crypt
• They seem to be able to store their OS image in NOR, NAND or serial SPI(!) flash
• They have four hardware queues per Ethernet MAC
• They have done some serious hacks to the network stack in order to integrate their TCP offloading engines and hardware NAT. This code is obviously not the most beautiful you have seen. But what surprises me is that they actually have it working, and went all they way to get it developed. And all that for some obscure NAS chipset. I would be interested to learn how many man-years of engineering time they have in that code... Oh, and they do actually have code for TCP-over-IPv6 offloading
• Hardware-accelerated recvfile support

As a summary: Kudos to those who have designed the product, and actually implemented all its features, in purely GPL licensed code. It's just such a pity that none of the code, not even the most generic and clean bits have been merged mainline.

Repairing VIA EPIA-ME6000 busted capacitors

Just before Christmas, my vdr powered diskless Linux-based digital video recorder went bust. A bit of testing revealed that the VIA EPIA-ME6000 main board itself must be dead.

I immediately ordered a replacement mini-ITX board without further investigating the broken one, expecting that the replacement might actually arrive before the Christmas holidays. Unfortunately this didn't happen. While replacing the board, I discovered that six of the 1000uF electrolytic capacitors went bust.

So today I finally found a bit of time (it's great to be able to find time to do things again) to try and replace the broken capacitors. Despite the new ones being slightly larger, the board now works again like a charm. And that at a total cost of 1.62 EUR.

So now I have two working mini-ITX boards. Guess I have to either find some use for it, or sell the new one again...

My personal favourite from 24C3: Xbox 360 hacking

I've seen quite a number of presentations live at 24C3 as well as recorded ones in the days following the event. While many of them cover important subjects, there is one lecture that is outstanding: "Deconstructing Xbox 360 Security".

The level of technicality of this presentation was just right. Finally something that went deep down into the technical details. Explaining what kind of flaws they found in the disassembled power PC object code.

I definitely want to see more lectures/presentations like this. Don't be afraid to overload the audience with technical details. Just go ahead with it :)

Also, this presentation has shown how far advanced the game console hacking is compared to mobile phone hacking (at least from what I've seen in the ETC (Ada-developers) and and Motorola hacker communities). The problems are similar: Completely undocumented hardware, cryptographic authentication of code by the boot loader (sometimes down to mask ROM), ...

So I hope that the mobile phone hacker community will grow and more people with this skillet, attitude and time will join. Free your phones!