First two days of 23C3

I'm currently at the 23rd annual Chaos Communication Congress in my home town Berlin, Germany.

After having dropped out of my usual volunteer work in the Audio/Video recording team, I thought that this year would be slightly more relaxing. Then came the Sputnik system, which suddenly started to eat some of my time weeks and months before the congress, as well as the last couple days before the congress, during the build-up. In fact, given my many other projects, I was close to going crazy and thus dropped out of the project and disappeared completely from the congress for about one day. Sorry about that, but I just needed to relax and calm down.

After a very stressful 26th of December, the team actually managed to set the whole back-end and middleware system up on the first day of the event, and the 3D visualization was running by 4am of the second day.

Now I'm back to normal mode, present at the event almost all day, which I intend to do for the next two days, too.

bugzilla.netfilter.org up+running again

Only two months after the involuntary absence of bugzilla.netfilter.org (due to database corruption while doing a gentoo mysql update), I have finally found some time (and a way) to fix the problem. Therefore, as of today, bugzilla.netfilter.org is now up and running again.

This was possible due to the fact that the bugzilla tables were still present in myISAM format. The mysql tables of patchwork.netfilter.org were not that lucky. They were stored in exactly that InnoDB file that got corrupted. However, the loss of archived (and lots of unmaintained) information on patches that had been submitted on netfilter-devel is not really all that important anyway.

However, let this be a lesson: Do daily dumps of all mysql tables in a cronjob before doing backups ;)

SMC WSKP100 - A Linux-running WLAN Skype phone

As I have just discovered today, the SMC WSKP100 is actually running a 2.6.9 Linux kernel (from the H3 sources made available by TI) running on a TI OMAP1701.

I managed to sniff the serial console and thus obtain a boot log. It runs u-boot, linux-2.6.9 and busybox. This basically makes this the ideal target device for a Linux-based open WiFi phone. Who the hell is interested in all this proprietary skype? I want a WiFi phone that is open. One that can run clients for SIP, or even H.323. Oh and by the way, it should support WPA-EAP as well as transport-level encryption of the actual voice data...

Due to the 1.8V nature of the serial port, I could only receive but not transmit (my transmitter outputs some 3V and is therefore not suitable. Which brings me to another point: Could somebody please design an universal serial adaptor, with a comparator at the input, where the user can adjust the voltage level for low/high distinction? And with a small DAC or variable voltage source for the Tx side?

OpenPICC RFID transponder emulator progress

As I've indicated before, the OpenPCD team is working on a free 13.56MHz RFID emulator, mainly for ISO 14443 A+B, but also ISO 15693. This project has been dragged on for quite a lot of time, both because of its complexity, and of my unavailability due to my involvement in OpenMoko and other projects.

Anyway, our latest generation of prototypes has now arrived, and we're proceeding nicely (but slowly) again. With some luck, the ISO 14443A anti-collision could work at the end of this day :)

Voting Machines: Complaint against last German Bundestag elections turned down

As several sources have reported, the German Bundestag just decided that the formal complaints of voters against the use of insecure voting machines in the last Bundestag elections are void.

The Bundestag decided to reject those complaints by using pre-worded statements from the Ministry of Interior, some of which can be technically proven to be wrong. It is a real pity - but what do you expect if you ask those people who got elected, whether they accept that election ;) It's also quite embarrassing to see such complaints to be dragged on for more than one year. We're talking about complaints about the Elections on September 18, 2005. I think this says a lot about the state of democracy in this country, and the carelessness of those in power towards a fair and equal election process.

This is why the original plaintiffs now are preparing a lawsuit in front of the federal constitutional court. In order to be filed, some 100 signatures of German voters in support of this lawsuit are required. This shouldn't be a problem, since a petition against the use of voting machines has drawn some 48,000 supporters without any trouble. You can find more information about how to support this complaint of unconstitutionality on the Homepage of Dr. Ulrich Wiesner.

RFIDiot - a python-based RFID tool

By accident, I've discovered RFIDiot, a RFID exploration library and tool written in python. There is quite a bit of overlap with what librfid tries to achieve, from a functional point of view (written in C, of course).

So on the one hand, there's a lot of functional overlap on the high-level like mifare reading/writing, ePassport reading, ... - but on the other hand, all the lower levels seem to be missing in RFIDiot. I guess that's the price you have to pay for vendor-lock-in with a proprietary serial protocol like the ACG readers.

Once I find some time again (next year, feb/march), I'd definitely like to see whether there can be some kind of integration/cooperation between RFIDiot and librfid/libmrtd.

Seen "Kabhi Alvida Naa Kehna" in the cinema

Just by coincidence I noticed that yesterday was the only show of "Kabhi Alvida Naa Kehna" anywhere near Berlin _at all_. So no matter that it was some 60km away, and I had to drive all the way to Potsdam, I had to go. And that decision was right. It definitely has become of my personal "all-time top ten" Hindi movies. It could have been a bit more serious, according to my taste. But apart from that: Great music, fabulous choreography, camera, costumes, acting, .... - everything!

So as soon as it becomes available here, I have to buy the DVD. Oh, and yes, I still have to buy that LCD projector for my home cinema, the one I intended to buy for several months now...

I need a break: Debugging a driver for non-existent hardware

For the development of the OpenMoko system on the Neo1973 phone, we have two different development platforms, one is the phone prototype - the other being a generic S3C2410 development board. Obviously that generic board doesn't have all the phone specific bits on it - but it can interconnect to a GSM modem via DB9 serial port, providing a very close match to the actual product hardware.

For the better part of yesterday, I apparently forgot that this is not true for all the hardware devices. For hours and hours I tried to debug a problem with the power management unit (PMU) driver. The I2C core just didn't want to talk to it.

It is only today morning that I realize: The development board doesn't have this PMU. Doh! Obviously only the phone prototype has that PMU! For god's sake, it looks like I need a break (but can't afford one, time-line wise).

Now why am I 'broadcasting' this embarrassing notice in a blog? To demonstrate: We're all human beings, we all make - apparently stupid - mistakes from time to time.

Secure Linux Administration Conference

Just one day after returning from India, I'll be one of the first speakers on the first day of Secure Linux Administration Conference (SLAC), where I'll be talking about hardware selection and low-level tuning for achieving best Linux networking performance.

Some details about the GSM infrastructure on the Neo1973 / OpenMoko

I've posted this publicly to some mailing lists in mid-November, but thought it was good to have this information in the blog, too:

First of all, there is a ts0710 multiplex layer, architecture-wise similar to what Motorola uses in their 2.4.x kernels. This ts0710 (de)multiplex takes care of handling GSM TS 07.10 "advanced mode" (the HDLC framing). It will be easy to add "basic mode" for chips that doesn't support advanced mode, and I'm also planning to add support for the Motorola proprietary 07.10 extensions (see OpenEZX wiki) once Neo1973 has been released.

This demultiplex is implemented as a line discipline. Therefore some userspace program (in our case the GSM daemon) attaches as a line discipline to the underlying physical UART.

devices that don't have a physical UART (such as the Motorola phones) will provide a small glue layer that provides a virtual UART on top of e.g. USB as underlying layer.

The GSM mux layer then provides itself one virtual serial port per DLC of the multiplex.

On top of those virtual serial ports, there is a GPRS line discipline, or a PPP line discipline for implementing full in-kernel data connection support, with no need for sending data packets for network traffic from/to userspace.

Both the GPRS line discipline and the ts0710 multiplex are written according to the style and requirements ("good taste") of kernel code, and will be submitted to the mainline kernel as soon as the Neo1973 goes public. I really hope to make this a standard component of the mainline kernel, supporting as many GSM modems as possible over time.

On top of the virtual serial ports, we have a GSM daemon. This daemon takes care of almost all communication with the GSM modem. The daemon initializes AT+CMUX and then attaches the kernel line discipline. It also attaches GPRS line discipline to a virtual serial port afterwards.

The daemon provides a Unix domain socket based protocol for other applications (at some later point this might become a network-enabled protocol by running it over TCP). The "other applications" (such as the contact manager, the dialer program, etc.) link against a library called "libgsmd" which wraps the protocol into a C language API.

This means that programs have a high-level API for initiating and receiving voice calls, for receiving and sending SMS, obtaining list of operators, reading/storing contacts from/to SIM card, etc.

The daemon will be GPL licensed, for the library we're not sure whether to GPL or LGPL it (probably LGPL). All applications shipped on the Neo1973 linking to the library are GPL licensed, so there will be enough example code for people to understand how that API works.

The gsmd/libgsmd code will be run (just like any other program on the Neo1973) as any other free software / open source program. Please understand that while FIC sponsors the OpenMoko project, they don't really exert control over it. So as soon as the device and code is released, I'm happy for any input and discussions the community has on improving such a system, including support for more devices, etc.

Oh, and yes, the daemon has a plug-in interface for vendor-specific extensions, since every GSM modem vendor has commands beyond the GSM07.07 specification. Also, the C API and the Unix domain protocol provide for transparent pass-through of AT commends from application to daemon. This is not meant to be a single-vendor-single-product code, but is at least designed to make it easy to add support for other devices.

Anyway, even without gsmd/libgsmd, I think the kernel-level serial multiplexer (which is not a very complicated thing) is a valuable feature to anyone doing GSM/GPRS on Linux - be it on a PC with GSM modem, or a smartphone.

The reason for doing this (de)multiplex in the kernel:

1. the individual virtual serial ports have all the features of real serial ports. hardware/software flow control, modem status lines, etc. - and the kernel has a standard API, well known in Unix over decades, to work with serial ports from a userspace program
2. especially when it comes to data sessions (packet data or circuit switched data), then you don't want to push all data to userspace and back in the kernel. you want to have a fast path for that, both from a CPU consumption (battery!) point of life, but also from a latency point of view. mobile data latencies are already high enough, we don't want to have additional unneccesary latencies in the handset

Please understand that at this time I have to focus on OpenMoko development, and cannot engage in lengthy discussions. This is about all the information I wanted to add about what's actually happening in our project, and this is the architecture the OpenMoko software on the Neo1973 phone has. Please bear with me until January. Once the code is out, I'm happy for any kind of discussion, modification, contribution, etc.

Petition against obnoxious WEEE implementation in Germany

There is now an official Petition to re-work the obnoxious WEEE implementation in Germany (see my detailed posting earlier in this blog. This is good, and definitely a step forward in getting regulations in place which are supportive of small and medium-sized companies, rather them getting them out of business. I've spoken to lawyers about the current regulations, and they e.g. have severe doubt that they are even constitutional.

If you are German, and/or operate a business in Germany, please consider signing the above-mentioned petition!

btw: I'm planning to start a petition against hosting petitions of the German Bundestag at a University in the UK, anybody interested in joining it?

My reason for being away from OpenEZX

This post should have been posted months ago, but only since very recently I'm allowed to talk about the real reason. You might have read about it, if you read my full blog, but I'm posting this again in the 'a780' category to make it appear on planet.openezx.org

I've been hired to be key element in the design and implementation of the OpenMoko platform and the first device it supports: The Neo1973 phone. While there is no provision in the contract preventing me from working on the OpenEZX project at all, this assignment has just sucked up all available time like a vacuum cleaner.

To OpenEZX developers, users and supporters: Please be assured that most of the work done on OpenMoko will eventually benefit OpenEZX quite a lot. So please stay tuned, and concentrate on the low-leve device-specific issues that need to be resolved with the Motorola EZX hardware :)