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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello Harald and thanks for your email.

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

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

Please let us know if you have any further questions.

All the best,
Palm Open Source Team

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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