HTCs delays in releasing Linux source code are unacceptable

The Taiwanese smart phone maker HTC is widely known to be delaying its Linux kernel source code releases of their Android products. Initially, this has been described to to the requirement for source code review, and making sure that no proprietary portions are ending up in the release.

While the point is sort-of moot from the beginning (there should be no proprietary portions inside the Linux kernel for a product that wants to avoid entering any legal grey zone in the first place), I was willing to accept/tolerate it for some time.

At one point more than one year ago, gpl-violations.org actually had the opportunity to speak in person to senior HTC staff about this. I made it very clear that this delay is not acceptable, and that they should quickly fix their processes in order to make sure they reduce that delay, eventually down to zero.

Recently, I received news that the opposite is happening. HTC still has the same delays, and they are now actually claiming that even a 120 days delay is in compliance with the license.

I do think neither the paying HTC customers, nor tha Free Software community as a whole have to tolerate those delays. It is true that the GPLv2 doesn't list a deadline until when the source code has to be provided, but it is at the same also very clear what the license wants: To enable people to study the program source code. Especially in todays rapid smart phone product cycles, 120 days is a very long time.

So I hereby declare my patience has ended here. I am determined to bring those outrageous delays to an end. This will be one of my new year resolutions for 2012: Use whatever means possible to make HTC understand that this is not how you can treat Free Software, the community, its customers, the GPL and in the end, copyright itself.

More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bank

I'm currently quite excited to be doing more bare iron programming as well as actual electrical engineering work again.

There's actually not just one project I'm working on, but a variety of them:

• OsmoSDR - an upcoming small form-factor, inexpensive USB SDR. Not big and expensive like USRP or real "professional" solutions, but also not as weak as the ultra-narrow-band funcube dongle. I wasn't involved in the hardware design, but have volunteered to take care of the firmware development for the Atmel SAM3U micro-controller inside.
• osmo-e1-xcvr - a relatively simple circuit board containing the magnetics, LIU, clock generation and transceiver for E1/T1/J1 lines. The idea here is to have a solution for the analog part, as well as HDB3/B8ZS/AMI encoding, which can then be attached to any FPGA, CPLD or micro-controller development board. It exposes SPI for controlling the transceiver, and a synchronous serial bit-stream for Rx and Tx.
• unnamed sim-bank project - here the goal is to find a cheap solution to attach a large number of SIM cards to either a PC or directly to Ethernet. This can be very useful for testing, where you host your sim cards in a centralized location and can borrow them to remote users/devices over TCP/IP. There are commercial devices available for this, but they are quite expensive (like 1700 USD for 32 card device) and intended to be used with some proprietary windows software (who wants that?!?).

In the latter two projects I'm also doing the component selection, schematics design and PCB layout. One project with KiCAD, the other in EAGLE, as I really want to get first-hand experience of the usability of Free vs. proprietary EDA tools. I'd love to also evaluate Altium Designer, but they are still windows-only, and that would just make life way too difficult for me.

The projects will be duly announced soon, and they are all intended to be Open Hardware designs with Free Software. We'll probably also make all of them available at shop.sysmocom.de, too.

Back home after successful KOSS Legal Conference

The first incarnation of the KOSS Legal Conference was a big success. There were many participants from a variety of backgrounds, such as

• Independent Korean legal experts
• Legal scholars from Korean law schools
• International legal experts (e.g. Till Jaeger, Carlo Piana, etc.)
• Representatives from the major Korean IT industry
• Representatives of the community organizations like FSFE
• Independent technical experts like Armijn Hemel and myself

The discussions have been a big success, with significant participation from the floor. There are many events that I attended where it was hard to actually get any participation from the audience - but the KOSS Law conference was definitely not one of them. Some of the questions were easy to respond to, some other questions really tackled the difficult issues in Free Software License Compliance.

What was clear to see from the Industry participants: FOSS License Compliance has become an important topic in the last couple of years: One the one hand as a result of virtually no TV set / mobile phone / PMP or other device running without Linux or other FOSS. On the other hand, I'm sure that the enforcement efforts of gpl-violations.org and the SFLC also have had significant impact on that.

What I personally find important is that compliance is only considered as part of the overall FOSS picture. Complying with the license text is the minimum that companies involved with FOSS should do. Rather, they should look beyond mere compliance and consider the benefit of engaging more actively with the community, contribute code back upstream/mainline and really becoming a first-class citizen of the Free Software world.

As a big surprise to everyone, Jim Zemlin of the Linux Foundation made a surprise visit towards the end of the second day of the conference.

Many thanks to the KOSS Law center for bringing this together and organizing such an event. Thanks also to the Korean NIPA (National IT Industry Promotion Agency) and the FSFE for their support of the event.

Going to attend Korean FOSS legal conference

Recently I had been invited by the Korean Open Source Software (KOSS) Law Center to attend their 2011 KOSS conference scheduled for November 17 and 18 in Seoul, Korea.

This conference is organized by the KOSS Law Center with support by the Korean Government (National IT Industry Promotion Agency). Its primary purpose is to share best practises in terms of FOSS licensing, license compliance but also FOSS community interaction within the Korean IT industry and the public sector.

I'm happy to present on Beyond Legal Compliance - Embracing the FOSS community, where I will outline that the primary focus should not be on to-the-letter legal compliance, but to a proactive way of interacting with the FOSS community. After all, collaborative development is what FOSS is all about...

However, due to a schedule conflict with the DeepSec 2011 conference in Vienna (where I'm giving a two-day GSM security workshop), I'm only able to attend the second day of the KOSS conference.

The speaker line-up for the KOSS conference is quite impressive, and it includes Karsten Gerloff (FSFE), Till Jaeger (JBB), Carlo Piana (FSFE), Keith Bergelt (OIN), Armijn Hemel (gpl-violations.org/Tjaldur) and others.

Unfortunately there seems to be no homepage, at least none with an English language title that Google would be able to find. Carlo Piana has mentioned the event in his blog four days ago.

UPDATE: There now is a conference page, although in Korean language only ;)

Some thoughts on the Erlang User Conference 2011

It seems I'm really getting too lazy to update this blog more frequently, which is a pity. Last week I was in Stockholm attending the Erlang User Conference 2011. This was the first Erlang conference I ever went to, and it was the first conference in many, many years where I was not speaking but merely a normal attendee.

Some of the readers of this blog will already have noticed my microblogging updates on identi.ca and Twitter that I made during the conference. They were not overly excited about the conference. Let me write some more details here. I have no idea how many technical conferences I have attended, but I am typically speaking at something like 10 to 14 every year, which I believe qualifies me as a "professional conference participant" ;)

Let me start with some positive feedback: There have been excellent and technical presentations, particularly by Kostis Sagonas (PropEr), Melinda Toth (Change impact analysis) and also the talk on Hashes/Frames/Structs as new built-in Erlang data types by Kenneth Lundin.

However, apart from those, i have quite a bit of criticism:

• Some presentations ended way ahead of their schedule.
  This is a pity, as it means that some hundred-odd highly paid software developers are then sitting in a room and wasting time. If you hold a presentation at a conference, you should make sure that this time is used in the most efficient way. If you have been allocated a 45 minute slot, please don't make a 15 minute presentation + 5 minute questions session. That's not what the audience expects!
• Keynote presentation by Ulf Wiger contained lots of hot air
  If I go to a technical conference aimed at Erlang users (i.e. software developers who write programs using the Erlang language, libraries and runtime system), then I expect it to be loaded with brilliant, technical content. I want to get excited about new developments, Erlang software projects, etc. The last thing that I'd want is having a real Erlang guru on stage talking about superficial, trivial aspects of embedded computing. Of course I respect the commercial decision of Ulf and/or Erlang Solutions to try to create a market for Erlang in the embedded sphere. But what is the technical relevance of this to the Erlang community? Ulf did not talk about great new schemes of optimizing the Erlang VM for battery-powered CPUs, or how he has extended powertop to give function or line-level accuracy on which of your Erlang code lines burn most CPU cycles or cause the highest number of CPU wake-ups from low power mode. That would have been exciting.
• Erlang/OTP Road-map presentation without much technical details
  When I see a slide with "Some SCTP improvements" then I want to see what exactly are those improvements. I think there was more than enough time to go into more details, if Kenneth would have spoken faster and put more content into the available time. Once again, the audience is a room full of intelligent, highly-paid professional software engineers. If you get their attention for whatever amount of time, I believe you should pack it as full with information as possible, rather than bore them with slowly and carefully reading each line from a slide...
• No Internet available at the Tutorials
  Can you believe it? In 2011, a technical conference aimed at software developers hosts tutorials inside a facility owned by one of the largest communications equipment suppliers (Ericsson) and then there is no provision for Internet access. It's really ironic, especially since at least some of the tutorial trainers expected the attendees would be able to clone git repositories on their laptops during the workshops.

In my hallway conversations with other attendees (who also have a background outside of Erlang and are more familiar with other conferences in the FOSS community), they independently observed those very same issues and agreed with my assessment.

All in all, the conference was a good trigger for me to finally sit down and start to use dialyzer on the various Osmcoom Erlang-language projects such as osmo_ss7, osmo_sscp and signerl. I'm already adding type specifications all over the code and am looking forward to soon starting with some PropEr test cases in the next couple of days.

GSM Security Training at DeepSec

Dieter Spaar and I will be holding yet another GSM security training on November 15/16 at this years DeepSec conference in Vienna.

We have been giving a series of successful GSM Security trainings in-house at various operators, as well as at a variety of conferences during the last couple of years. If you want to beef up your knowledge on the detailed inner workings of mobile networks, with a specific focus on security related aspects, this training might be a great opportunity.

You can register here. Unfortunately the Early Bird discount has already expired, but you still have a chance to book before November 2nd, after which a late booking fee will apply.

First OsmocomGMR code release

The OsmocomGMR project. GMR is Geo Mobile Radio, the specifications for (among others) the Thuraya satellite telephone network.

For more details see the OsmocomGMR announcement.

I still remember some years ago, when Dieter and I were first working on some code to implement the GSM protocols, which later ended up becoming OpenBSC. A number of other developers joined the project ever since, and we have a wide user base, from individuals over academia up to commercial deployments. Next we did GPRS, which was another journey into a new world. While OsmoSGSN still has some bugs here and there, it has come a long way ever since.

In December 2010 at 27C3 I had this crazy idea of looking into yet another communications system (TETRA). Just one week of coding later, the first working code emerged and later became OsmocomTETRA. Again, history repeated itself and what was started by one person became a collaborative effort in very short time.

Finally, in July 2011, I thought it would be time for yet another communications system: ETSI GMR, used by Thuraya. This time I was too busy to actually write any code, but I just read specifications, found a supplier for some equipment and got some fellow Osmocom developers interested in it. For weeks, the IRC channel was flooded with daily reports about progress, new measurements/traces that had been made and about new code that had been written. About three months later, the code is capable of demodulating, decoding, de-interleaving, and it can give you a BCCH protocol trace in wirshark.

With this pace of progess, I wonder where we might be in yet another one or two years. At least on my personal agenda are the following items:

• Finish Erlang TCAP + MAP implementation, which will allow us to implement a true HLR/AUC and finally a new MSC that can interoperate with GSM/3G core networks
• Integrate OpenBSC and OpenBTS, especially now that we already have the BTS-side A-bis implementation as part of osmo-bts
• Get funding to implement a GPRS/EDGE PCU, enabling osmo-bts to talk to OsmoSGSN
• Work on some hardware+software interface that allows us to use the Motorola Horizon Macro BTS with OpenBSC, or at least their TRXs (called CTU) with osmo-bts
• Implement a UMA/GAN gateway (for UMA capable phones and femtocells)
• Support IuCS/IuPS from our MSC and SGSN for 3G Femtocells
• Complete the SIMtrace firmware/software to do full MITM and SIM card emulation
• Work on automated regression testing for osmo-bts, OpenBSC, OsmoSGSN and all other GSM related Osmocom components.
• Continue the excellent work that has been done on supporting MTK chipsets from OsmocomBB at some point

At least now you know there is never any reason to be bored. If you have time and are interested in helping with implementing any of this stuff, let me know.

FOSS.in is dead, PRODUCTISE.in lives

Team FOSS.in has announced lest year that the successful series of FOSS.in conferences has concluded. I'm still a bit sad that I was unable to make it to the grand finale.

But now, the very same team announces a new event called PRODUCTISE.in, with a different focus. It's not about Free and Open Source Software anymore, but about product developers - where the respective products of course could be FOSS based.

I remain curios to see what will happen to the event. Everyone who knows me knows that I'm probably a slightly pragmatic but otherwise orthodox Free Software fellow. As far as I can tell, the only proprietary software that I use (and license) in more than a decade is IDA Advanced.

But in any case, all the best to Team FOSS.in with their latest endeavour!

I'm still alive - short update...

In the last two months I barely found time to update this blog. I'm now back on track and will try to update the blog more frequently.

The CCC Camp 2011 has been great, and the OpenBSC based camp GSM network has been a success, despite some initial problems. Thanks again to everyone helping with the build-up and operation of it, and thanks for all our volunteer users/testers.

Most of the time since I've been buried alive in work, almost exclusively related to various sub-projects surrounding the Osmocom GSM protocol implementations. We're working on every level of the protocol stack at the same time, and on network elements from BTS, BSC up well into the core network, media gateways, etc.

Most recently I've been doing some work with openembedded (OE) again, and I've had more contact with the intrinsics of GSM AMR than I ever imagined I would.

There's lots of exciting stuff ahead, but I don't want to talk about it until the respective code is public and the stuff actually works.

The only really ugly thing that I have to deal with again and again is a lawsuit related to the GPL infringement of the German vendor of the Fritz!Box DSL routers. I'll follow-up on that shortly. One of the most ridiculous things they claim is that their products are not DSL routers :)

Ground-breaking research on APCO P25 security

While we at OsmocomTETRA have been looking only at implementing the TETRA protocols as they are (and doing a bit of sniffing on unencrypted networks), some researchers have recently published two ground-breaking papers on the (lack of) security in the APCO P25 radio system.

In case you haven't heard about APCO P25: It is a digital mobile radio system mainly used by Police in non-EU English speaking countries like the US, Australia and New Zealand.

You can find the respective papers here and here.

So apparently P25 uses either single-DES or a proprietary cipher with only 40 bit key-length. No, I'm not joking. Seems like it was developed by people who have not the slightest clue about communications security at all.

And guess what they used to receive and transmit P25 waveforms? Of course the USRP and gnuradio. This once again proves how invaluable those tools are, not just for the FOSS community, but also for the communications research community.

Ramblings on German battery law

Germany has laws for everything, including batteries (Batteriegesetz).

In order to be able to e.g. import products with batteries from outside the EU and sell them inside Germany (or the EU), you need to be registered as a battery manufacturer/importer. You also need to become member of one of the registered/accredited companies that take care of recycling the batteries (i.e. put small boxes in supermarkets where people can put their old batteries).

What's funny is that there is absolutely no lower boundary for that for small businesses. What that means for my company: I need to pay 1 Eurocent for each LiIon powered mobile phone to that recycling company.

I guess at current estimated volume, we will have to pay something like 1 to 2 EUR every year. The recycling company won't even send us an invoice if the amount is < 20 EUR total.

So all this comes down is an exercise in buerocracy. We need to send a monthly report on the quantities every month, and there's a hard deadline that needs to be followed.

Furthermore, we need to put fancy stickers on each of the battery, covering at least 3% of the battery surface. That means opening every box, removing the battery from packaging, putting the sticker on it and re-packaging the box. Modern batteries normally have the symbol printed by the manufacturer, but we're talking about Motorola C1xx phones that have been produced from 2005 to 2008 here.

I certainly don't object to manufacturers or importers having to pay for the recycling. But if recycling is actually that cheap, and we're talking about single-digit EUR amounts per year, the administrative overhead (time needed for making the monthly reports, putting stickers on the batteries, etc) costs something like 100 times the actual recycling cost. Is that really worth it? Why not have a lower threshold for small businesses?

Major bugfix release of SIMtrace firmware

At the CCC Camp 2011, the Osmocom SIMtrace project was a major success. Not only were something like 60 units out of our initial batch of 100 units sold, but the SIMtrace workshop was so successful that it had to be held three times instead of once.

During the workshop we discovered a very annoying bug which I wasn't able to solve immediately. Depending on the combination of phone/simcard used, the SIMtrace would disconnect from USB and the phone would claim there is no SIM card inserted.

The debugging went like this:

• SIMtrace was resetting very early in/after the ATR
• the reset reason was diagnosed as being a watchdog reset
• the watchdog was triggered by an IRQ storm from the USART
• the IRQ storm was caused by the firmware not clearing some parity error / overrun related bits

However, at that point I couldn't further find the cause of the bug. I assumed it was related to the PPS/PTS, but couldn't really point my finger at it. If we sniff the PPS/PTS wrong, then of course our baud rate is different from the real baud rate, which in turn would cause perceived parity errors and the like.

I'm grateful that most people still didn't loose their interest in simtrace and happily bought the unit and/or attended the workshop.

After a bit more debugging after the camp, I have now solved the bug. I simply never realized that the TCK (ATR checksum byte) is only present in cards that support T=1 as well as T=0. However, some simpler SIM cards like the ones that we issued for our test GSM network on the camp only do T=0 and thus don't transmit TCK.

The old code thus considered the first PTS/PPS byte (0xff) as the TCK, and didn't recognize the PTS/PPS correctly.

Firmware version v0.2 fixes this problem. I've released the firmware update, now also available from the wiki

Update on the GSM network at the CCC Camp 2011

During the past weeks, I've been trying very hard to get to a technical solution for the setup regarding the private GSM network that we intend to operate at the CCC Camp 2011. Unfortunately, despite puting in way too much time that I don't have, no really good solution appeared. There were times when I was wondering if it would happen at all - mainly due to the lack of properly integrated / tested RF related issues like PA, LNA, duplexer, combiner, etc.

But it seems just in time Dieter came to the rescue. So now we have pretty much figured out the equipment and settled on a configuration. We'll have 2 Nokia Metrosite BTS with a total of 5 TRX, each running at 5W using borrowed equipment.

During the next 10 days, all the parts like antennas, cabling, plugs, adapters and the BTS units themselves should arrive at my place. Let's hope there are no serious fuck-ups that cause something to not arrive in time.

So all in all, there's a 99% chance we will have a functional GSM network. The Nokia A-bis support in OpenBSC will be brand new, so there might be some glitches here and there. But then, that's part of the fun. I'm already very curious to see what kind of coverage we get. I guess if we do things right, it should reach well into Finowfurt itself, and not just barely cover the camp grounds like we had at HAR 2009.

US government closing data centers and give up their independence

Sometimes I really think I must be dreaming. Who in their right mind would propose something like closing something like 800 government-owned data centers and outsourcing all the data to the cloud?

As a government, you

• make yourself dependent from a private company to supply essential infrastructure
• introduce single points of failure (technically, administratively)
  previously, you had 800 data centers, maybe each of them not as reliable as the advertisements of the cloud provider - but it is unlikely that all of them go down at the same time
• give up control over who physically owns and has access to the data
  In fact, you will have a hard time even finding anyone at all who can tell you where your data is physically located. Maybe even out of the country?

Now you can argue that all those things can be put down in contracts as service level agreements (SLAs). That's true, but as we say around here: Paper is patient, meaning no paper is going to help you after data has been copied or was lost, and if you suddenly fail to provide basic services of the public administration.

The distributed nature of self-hosting your data and applications has key advantages in terms of security and reliability. Why would somebody give that up without a broad discussion? And we're not talking about some private company where nobody but their shareholders care if they loose data or go out of business. We're talking about the public administration here.

People seem to have lost perspective on the overall advantages of a heterogeneous, distributed setup.

On the recent THC release on the Vodafone femtocell

I am mainly posting this to prevent any more people mailing me about this release. There's nothing really spectacular here.

Starting from 2009 on, the usual suspects (aka OpenBSC developers) have been looking at various 3G femtocells, including the Vodafone one (I have 10 of them here). Aside from that Alcatel-Lucent design that Vodafone uses, we've also looked at the Cisco/AT+T/ip.access design, as well as the Ubiquisys/SFR one. With some effort you can root all of them, and you can then make sure they don't connect to the respective operator but to an IP address of your choosing.

The protocols are vendor-dependent. The Vodafone femtocell uses a version of RANAP (the protocol between RNC and MSC in UMTS) behind an 8 byte proprietary header. As RANAP is specified in the 3GPP, it was pretty easy to build a small piece of code that interacts with the unit.

Ubiquisys (used by SFR) uses the UMA protocols, and the Cisco/ip.access/AT+T design uses a proprietary ip.access protocol called URSL (sort-of a "progression" of the 2G RSL to UMTS).

Supporting them from OpenBSC is not easy. While the call control and SMS transfer protocols of 3G are identical to GSM, everything below doesn't really bear much resemblance. I would guess it would take at least a man-month to get basic signalling, call + SMS support working, if not more.

Given the fact that the femtocells all speak their vendor-proprietary dialects, and given that they often come with license terms that only permit the use of their firmware in combination with their gateway located at the operator network, we never thought it is a high priority item for us to work on.

What you also have to consider, is that their output power of 20dBm is even less than the 200mW of typical small-scale GSM BTS, and that they typically only support the operation of 4 concurrent phones. Nothing that you would be able to run e.g. a conference telephony network on.

Furthermore, due to the wide channels (5MHz), it is very likely that all available sprectrum has been auctioned off/licensed to commercial operators, so it's almost impossible to get something like a test license. In GSM with 200kHz channels, there's often still a guard band or some unallocated channel that can be used.

If you really want to have some free software + femtocell based 3G network, go ahead and do it. The option existed for years now, ever since femtocells started shipping to the market. All of them are some form of embedded Linux systems. Rooting them isn't really different from rooting a Linux based WiFi router / DSL modem. So what's that new about the THC release? That a vendor of Linux embedded devices chose a trivial password? If you're surprised by that, I guess you haven't taken apart many embedded devices then.

SIM-unlocking the Openmoko phones?

I think it's quite funny that SIM-unlicking vendors like RebelSIM actually advertise that their products are compatible with Openmoko, as you can see in this PDF file.

What's funny about this? Well, Openmoko phones have never been sold with any form of SIM or Operator locking. The entire idea was to have a phone that is under the control of the user, not the operator...

SIMtrace v1.0 prototypes are working out of the box

After the debacle with various wrong footprints in the v0.9, I'm very happy to announce that the SIMtrace v1.0 hardware is working fine. All footprints correct, schematics correct, layout/Gerber correct. All we had to do is solder the components, attach it to USB, flash the firmware and use it.

Here's a picture of the board (sorry, my soldering is not very clean):

Early next week we will be ordering a batch of 100 units from the SMT house we have chosen.

Unbelievable statements in GPL related case in the Supreme Court of Mauritius

I've recently received some documents regarding a court case at the Supreme Court of Mauritius.

The plaintiff is a company called Linux Solutions Ltd. in Mauritius. It seems to be covering an alleged breach of an NDA between a contracted freelancing developer and a company in Mauritius. That contractor (the defendant) has apparently published some of the work he had done while contracting for the plaintiff.

While none of that seems to be clearly connected with the GPL, what is extremely disturbing is the sworn affidavit / oath by one of the executives of the plaintiff. It says things like:

5. Licenses of open-source software like "Linux" and "Asterisk" have no copyright restrictions which in effect puts no restrictions on their use or distribution. As a consequence, any work which is derived from the open source software as conceptualized, created, installed and managed, by the Applicant becomes the ownership of the Applicant.

6. In the light of the above, therefore, the applications, configuration files and features so developed by the Applicant are the sole property of the Applicant, make up the knowledge base of the Applicant, make the basis of its business operations, and are highly confident in nature. The applications, configurations and features have been built and acquired by the Applicant through important capital investments and manpower over a period of time.

So let me phrase this more clearly: Somebody, under oath is stating at the Supreme Court, that GPL-Licensed software (which the Linux kernel definitely is), has no copyright restrictions? And that any derived work is the sole property of whoever created the derivative? What kind of pot are they smoking in Mauritius?

If there's anyone in the Free Software legal community interested in filing some kind of legal document to the Supreme Court of Mauritius to clarify this issue, feel free to contact me for more details on the case. No matter whether the defendant has broken some NDA, I think it's unacceptable to see such ridiculous claims being made at a Supreme Court.

In case you don't believe it, here are some scanned samples:

AVM trying to spread FUD about the Cybits case

Unsurprisingly, AVM is now trying to claim their legal action is not related to any GPL violation. This couldn't be further from the truth.

In both the court hearings (in two independent cases), AVM has repeatedly declined to make a clear statement that the modification and installation of modified version of the GPL-Licensed parts (like Linux) is acceptable to them.

We have raised this question in front of court and out of court, and AVM was not willing to make such a declaration. If they had, I don't think I would have had much reason to join the lawsuit on the side of the defendant.

I have no connection to Cybits (the defendant). There has never been any business or other relationship to them, and they have not been involved in funding my legal expenses. To be honest, I don't even care about child filtering software in general, no matter from which vendor.

But I do care about the GPL, and the freedoms it grants. The GPL is intended to allow any third party to modify, recompile, re-install and run modified versions of the respective GPL licensed program. Any court order / verdict / judgement that tries to undermine this freedom is a substantial danger to the Free Software movement - and as such I will do what I can to prevent it.

AVM has stated in front of the court that AVM releases the source code compliant with the GPL, anyone can download, compile and use it - just not on OUR hardware. There you can clearly see their attitude: They see the FritzBox as their hardware. Last time I checked, the unit is not rented by AVM, but is legally sold to the customer. It is his decision to do with it what he wants. Under the terms of the GPL, it is his decision to install whatever software on the hardware, including modified versions of the GPL licensed Linux kernel.

Just imagine a world, where you buy a Laptop from HP, with Windows pre-installed. Now further imagine that there is a third-party software vendor (e.g. Canonical with its Ubuntu). Now imagine that HP was suing Canonical for offering different software that runs on their hardware. This is the kind of analogy that you need to think about.

I don't think AVM is truly understanding the daemons they are calling here. If they actually manage to get a finally awarded judgement that deprives third parties of their rights under the GPL, AVM will have violated the GPL, specifically clause 6: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. And what would that mean? That the GPLv2 is revoked and AVM looses the right to use the GPLv2 licensed software they use in the product.

First working prototypes of Osmocom SIMtrace design

Last winter I was working on some hardware and software that can be used to trace the communication between a SIM card and a phone and called it Osmocom SIMtrace. At that time, I was simply recycling an old OLIMEX development board for the AT91SAM7S micro-controller.

But since the firmware for the micro-controller, the host software as well as the wireshark plug-in has been written now, it would be a shame if I was they only user of the project. Therefore, Kevin Redon and I have spent some time in polishing and improving the design, as well as generate some actual prototypes.

Unfortunately a number of mistakes were made (both on the design side but also wrong component pin-outs) so there was a need for significant re-working.

Nonetheless, we now have some 5 functional prototypes, a picture can be seen in the Osmocom Wiki, where you can also find the schematics

We're now having a second version of the PCB built, this time hopefully with correct footprints for all parts. Once that is verified at the end of next week, we will give "go" for the production of a small batch (100 units).

Interested developers will be able to obtain the resulting hardware from mid-August onwards. We also expect to be offering them at the Radio Village of the 2011 CCC Camp.

Tracing the SIM<->Phone protocol can be useful in a variety of cases:

• Observing the behavior of operator-issued SIM cards in terms of which SIM Application Toolkit or Proactive SIM features they use.
• Debugging aid while developing and interoperability testing of your own SIM toolkit applets
• Prototyping and development of SAT blocker or other SIM card firewalls which restrict the security or privacy threats originating from untrusted operator SIMs or potentially compromised SIM cards.

Court hearing in the AVM / Cybits / GPL case

Today was the court hearing at the Berlin district court in the case that I blogged about yesterday.

Nothing really new happened there. AVM still has a number of claims that I consider extremely dangerous to Free Software in the embedded market:

• collective/aggregate work
  They claim to have some rights on the collective work of their own proprietary components and the GPL licensed components. While that may or may not be true, they also argue that based on such rights, they can legally prevent anyone from installing modified versions of those GPL licensed components onto the device. To me, that would clearly be a further restriction under the GPL, and thus violate the terns of the License.
• using rmmod on proprietary kernel module is a modification under copyright law
  This is where it starts to get really ridiculous. Both the module unload feature inside the kernel as well as the rmmod command itself are licensed under GPL. Their sole intended purpose is to unload modules from the Linux kernel. AVM now claims that the defendant is violating AVMs copyright because he unloads a proprietary AVM kernel module. Not only is it legally extremely questionable to have binary-only kernel modules at all... but then trying to tell other people they cannot unload such code is outrageous. AVM seems to not understand that they have _sold_ the device to the user. He can stop and unload any program on the device. The device is not owned by or rented by AVM.
• copying code from NAND flash to RAM requires explicit permission from the copyright holder
  Once again, we have a situation where the user has bought the AVM product. He has obtained a license to the software programs. Under German copyright law there is even no requirement to have a license for 'normal use of the program' as long as the program was obtained lawfully. The CPU on the AVM device (like any CPU in any computer) can only execute code that's accessible to the memory/data bus. Code in NAND flash can never be executed directly, it always has to be copied into RAM before it can be executed. The claim that this operation requires separate permission by the copyright holder is wrong. The copying happens as part of the 'normal use of the program'.

AVM has filed several other claims against Cybits based on trademark and competition law. They go as far as to debating whether a certain LED on the product malfunctions after the user has installed the Cybits software on the product ;). I don't really want to go into details here, but I think it's mainly arguing for the sake of the argument. AVM wants to keep and extend its monopolistic power over those devices, even after they have been sold. That's where the real anti-competitiveness here is... If you look at popular alternative firmware projects like OpenWRT, you will find many vendors and literally hundreds of supported devices. None of them is from AVM. Isn't that striking, considering that AVM is told to have > 60% market share in Germany?

The court has heard arguments from all sides and is now adjourned. All parties are now again going to submit lengthy piles of paper to the court. Within those originating from my lawyers and myself, we will definitely once again outline our position. AVM can do whatever it wants, but it cannot use legal means to disallow the legitimate and intended modification + use of modified versions of GPL licensed code on their devices.

The implications of such a legal win for AVM go way beyond AVM or the DSL router business. They go all over the embedded market, and include NAS devices, Android smartphones, e-book readers, etc. Just think about the implications for OpenWRT, Cyanogenmod, Openinkpot and all the other firmware modification and 'homebrew' projects out there.

German dsl-router vendor AVM seeks to remove the GPLs freedoms

Today, there has been a joint press release of gpl-violations.org and the Free Software Foundation Europe on a legal battle that has been ongoing for quite some time:

The German maker of popular dsl-routers (AVM) is using legal means to try to halt a third party company (Cybits) from modifying the GPL licensed components (like the Linux kernel) of AVM-branded routers. Furthermore, it seeks to ask courts to halt Cybits from distributing software by which end users can modify that GPL licensed software.

This is outrageous! AVM does not own the copyright to that GPL-licensed software. How can they seek to prevent anyone from exercising their right to modify the code and run modified versions of it? This is one of the most fundamental freedoms that Free Software grants its users.

In the last lawsuits (preliminary proceedings) that AVM has brought about, I have intervened on behalf of Cybits. At that time, the court was impressed and has restricted a previously-granted preliminary injunction against Cybits to not include any claims regarding the Free Software portions of the product.

But meanwhile, AVM has filed for the main/regular proceedings. Tomorrow (June 21st, 11am), there will be the first hearing at the district court (Landgericht Berlin, Room 2709, Littenstr. 12-17, Berlin).

I have applied to be a side intervener in those main proceedings, too. Given that the previous court accepted this, I assume it will be accepted in the district court, too.

Normally I wouldn't care much if two companies are taking it to court. But this case is not about Cybits or AVM. This case is about the fundamental question of whether a device maker using Linux and other GPL licensed software has the right to use legal means to prevent third parties from exercising their fundamental rights granted under the GPL.

For more information about the case and background information, please check out this background page at FSFE.

Exploring the Motorola Horizon macro BTS

Some days ago, my new 100kg toys have arrived: The Motorola horizonmacro indoor cabinets, populated with 3 GSM 1800 TRX each. Pictures are at the openbsc.osmocom.org wiki

It took some time to manufacture the power cable, and specifically the E1 cable (where I had to reverse engineer the pin-out of a 37pin sub-d connector that the so-called BIB (balanced interface boards) use.

The next biggest time consumer was the fact that the command line based user interface (MMI) has three modes; MMI-ROM, MMI-RAM and emon. Figuring out which commands to use to switch modes isn't really something that you can easily find. Especially the fact that the MMI-ROM to MMI-RAM switching command has a parameter that needs to be identical with one stored on the PCMCIA flash card (number "18" in my case), didn't make things any easier.

So as an intermediate summary, I can make the following comments about the Motorola BTS and specifically A-bis architecture:

• Motorola seems more proprietary and less specification oriented than what I've seen so far (Ericsson, ip.access, Siemens, Nokia).
• They do not seem to implement a SAPI=62 OML link on A-bis at all
• Thus, there is no GSM TS 12.21 compatible OML protocol at all
• Instead of using individual OML messages and/or attributes to set things like ARFCN, BSIC and the like, the Motorola BSC seems to generate one big database blob containing all parameters. This blob is downloaded into the BTS RAM (optionally its PCMCIA Series2 flash card).

Particularly the latter part is causing quite some problems for me. As I don't have a Motorola BSC, I cannot generate those database files. My BTS units come with databases on their PCMCIA flash cards. I can view their contents on the MMI. However, their config (EGSM) doesn't match the actual radio hardware that's installed. Even after hours spent with the MMI, there seems absolutely no way how those parameters can be altered locally

I also have not found any hint / documentation at all about something like a LMT (local maintenance terminal) like other BTS vendor. Using such a software on a PC, you can typically configure the BTS via a RS232 line.

So most of my hope now lies in being able to analyze dumps of those old Series2 flash cards in order to get some hints on that database format.

If anyone has any of the following information, it would make my day:

• Motorola A-bis / Mo-bis protocol traces
• Any Motorola BTS config databases (independent of BTS model/version)
• The sample database files that come with a Racal 6113 Option 225
• Any information on the database format

But to be honest, I don't have much hope. The equipment is old (about 1999), and only very few operators have been using it, as it seems.

Why do self-respecting hackers use Gmail & Co?

Yesterday morning I was reading through the logs of my exim-based mailserver and noticed _how_ many messages were delivered to Google/Gmail. This is mostly related to the various mailing lists that I'm hosting at lists.{gnumonks,osmocom}.org.

Now if those lists were general-purpose mailing lists for let's say a group of environmentalists or a local model train club, I wouldn't be surprised. But almost all of those lists are about very technical projects, where the only subscriber base should be people from either the IT security community, or the Free Software community. The former is typically extremely security and privacy aware, whereas the latter is at least to some extent in favor of what I would describe as 'being a producer rather than just a consumer of technology.

So why is there such a high degree of Gmail usage among those groups? I really don't get it. Let me illustrate why this is a surprise:

• you give away control over your personal data

  Control over your own data means you own it, you have it on your hard disk, it is not on somebody else's storage medium. Control over your data also means that somebody needs a search warrant to your home in order to get to it. It also means that you decide when or how to shut it down, not a large corporation in a foreign country.

• you put your personal data within the U.S. jurisdiction

  Depending on where you are, this may or may not be an improvement. I don't want to start a political debate here, but you have to be aware what this means specifically, especially in terms of government authorities or private companies getting access to your mails. I myself would not even say that I understand enough about the US legal system to determine the full outcome of this. Also, in case there was a subpoena or other legal action in the US, how would I defend myself? That's so much easier in my home country, where I know the laws and regulations.

• you give Google not only the social web information who mails whom, but also the full content of that communication

  Now Google may have privacy policies and other rules that this data is not to be mined for whatever purposes they deem fit. But first of all, what guarantees do you have on it? Definitely less than if you ran your own mail server on your own hardware. Secondly, whatever Google promises is always within the scope of the US jurisdiction. In the 10-year aftermath of 9/11 there have been a number of alarming developments including wiretaps to phone lines without court review/order, etc.

Now I don't want this to be a bashing of Google. The same applies more or less to any email hosting company. I also don't want it to be a bashing about the US. The above is meant as an example only. In Europe we have our own problems with regard to data retention of e-mail related data (who is mailing whom). But those only apply to companies that offer telecommunications services. If you host your own mail server, you are not providing services to anyone else and thus are not required to retain any data.

There's also what I would call the combination effect, i.e. millions of millions of people all using the same service. This leads to a large concentration of information. Such concentrations are ideal for data mining and to get a global 'who is who'. This information is much more interesting to e.g. intelligence communities than the actual content, as it is much easier analyzed automatically. It also doesn't help to encrypt your messages, as the headers (From, To, ...) are still unencrypted.

Furthermore, this concentration leads to single points of failure. I'm not speaking physically, as Google and other web-hosters of course know how to replicate their services using a large-scale distributed system. But all is under control by the same company, maintained by the same staff, subject to the same jurisdiction/laws, etc.

There was a time when the Internet was about a heterogeneous network, de-centralized, without a single point of failure. Why are all people running to a very few number of companies? The same question goes for sites like sourceforge. All the code hosted there subject to the good will of the hosting company. Subject to their financial stability, their intentions and their admin staff. They've had security breaches, as did apparently Google. Sure, self-hosted machines also have security breaches, but only the breakage of a very small set of accounts, not the breakage of thousands, hundred thousands or millions of users simultaneously.

Now hosting your own mailserver on your own machine might be a bit too much effort in terms of money or work for some people. I understand that. But then, there are several other options:

• You team up with some friends, people you know and trust, and you share the administrative and financial effort
• You look out for NGOs, societies, cooperatives or other non-for-profit groups that offer email and other services to their members. At least in Germany we traditionally have many of these.
• You use a local, small Internet service company rather than one of the big entities.

While you still give up some control with those alternatives, you keep your data within your jurisdiction, and you still keep the spirit of de-centralization rather than those large concentrated single point of failures.

ETSI and its ridiculous fees for old archived documents

I am currently looking for some old meeting minutes in order to understand who was the driving force behind certain features in GSM.

Ever since the GSM standardization had been handed over to 3GPP, all meeting minutes are freely accessible and downloadable for everyone. But what about the 15-20 years before that? They remain in the ETSI archive.

So from April 2011, the ETSI has started to offer an archive DVD, containing all the early CEPT and ETSI documents such as draft standards and meeting minutes. What a great idea. This DVD set is titled A Technical History of GSM Standards

But then, when you look at the price tag, you can only think "Seriously? They must be kidding!!". They are selling it for 6,000 EUR. Yes, this is not 60 EUR, not 600 but 6,000!. Go and see with your own eyes at the ETSI web-shop or this flyer.

But if that hefty price was not enough, they add an additional burden: You have to be an ETSI member to even buy it. And what is the cheapest option? Well, as an individual/small business you can join for a reduced price of EUR 3,000 per year. So in order to get access to some old meeting minutes from the 1980ies or 1990ies, I have to pay a total of EUR 9,000? They must be out of their freaking minds. Sorry, but I am simply lacking any other words how I could put it.

I think ETSI and the entire telecomms industry can be happy if anyone shows an archaeological interest into ancient specification texts at all. Scaring them away with a more than ridiculous price tag is certainly not going to encourage students or researchers to understand who, how and why GSM has ended up what it is today.

Looking for documentation and/or protocol traces for Motorola Horizon BTS

It seems like I'll be getting my hands on some Motorola Horizon 1 BTS soon. Of course it would be great to add OpenBSC support for yet another vendor / model.

So if anyone out there has any information on Motorola Horizon, I would be more than happy. Information includes:

• Motorola A-bis (Mo-bis) protocol traces
• Motorola A-bis (Mo-bis) protocol specs
• Installation manuals
• Configuration manuals
• Service manuals

Thanks in advance!

Starting to investigate old Motorola Dimetra EBTS

Together with some friends, we have managed to get our hands on some ancient (1997) Motorola Dimetra TETRA equipment. Specifically, this includes the Base Radios (BR) and the TETRA Site Controller (TSC).

We haven't yet managed to put everything up in the wiki, but you can watch our progress at the Dimetra_EBTS page on http://tetra.osmocom.org/ as well as it's sub-pages.

It's going to be a big challenge to put all that equipment to some good use. Success is probably defined in terms of running your own small TETRA network with such an EBTS but without any of the Motorola Dimetra core network infrastructure (SwMI, basically the same thing we did for GSM with OpenBSC.

The big conceptual difference to GSM here is: In GSM, the internal protocols (A-bis, A, ...) are all publicly specified. There are vendor-specific dialects, but those are relatively easy to figure out. In TETRA, the ETSI only specified the air interface, but not the interfaces between the wired components of the network. This leaves pretty much everything else proprietary :(

So if anyone has any information (installation manuals, service manuals, provisioning software, protocol specifications, ...) or experience with configuring or maintaingin this equipment, I would be very happy if you could drop me a message.

Interview with German newspaper taz about gpl-violations.org work

There has been an interview for (at least) the online edition of the German newspaper taz - die tageszeitung. If you understand German, you can read it here.

By coincidence, I'm a subscriber to that very same newspaper for more than 10 years ;)

HTC announcement about no more locked-down phones

As it has been covered at various news site, HTC has apparently announced that they will not be shipping Android phones with locked-down bootloaders.

If this is really true, it would mean that more people not only have the theoretical freedom to run modified versions of Linux (granted by GPLv2), but also the practical freedom. If there is no cryptographic restriction on only booting HTC-supplied versions of the Linux kernel (and other software), this is good news!

It comes as a bit of surprise though. "Traditionally", HTC is known for behaving unfriendly towards the community. Not only due to their source code releases being constantly too late, but also due to the fact that their phones were some of the first to use cryptographic signatures to keep people from installing their own versions of Linux (and Android).

The other surprising move has come from Motorola, who probably has the longest tradition of shipping Linux-based phones (in various degrees of GPL compliance), but then using technical means to deprive their customers of the Freedoms the GPL wants to grant to them, i.e. the freedom to run modified versions of the Software (Linux in this case). They did this with the later models of the EZX range, with their MAGX phones, as well as now with their Android phones over the last couple of years. So it was very puzzling to see the same Motorola announce a 180 degree turn in policy at least for their Xoom tablet.

Also, in recent news, Sony Ericsson made a similar announcement that at least some of their Xperia models can be bootloader unlocked.

It's really striking. During the least seven years, I used to be involved in a number of projects that tried to enable the user of mobile smartphones to have the full source code for (at least) the Linux kernel, and to be able to modify, tinker and re-program it any way they want. Now some of the vendors seem to be moving in the right direction.

What's sad is that Samsung is not capitalizing on their potential here. They have always had very timely and complete source code releases for all their Linux based phones at http://opensource.samsung.com/, and they have very rarely tried to lock any of the bootloaders. I don't know if this is intentional or not. But now the other vendors are getting good PR for stopping to do something that (to my knowledge) Samsung has not done, at least not to the extent of the others.

In any case, I still think the Nexus S is the best choice for anyone who wants to have a developer friendly device. It is fully supported in the main AOSP tree, everything in the kernel is GPLv2, and those binary userspace blobs that are required are distributed independently at https://code.google.com/android/nexus/drivers.html so they can be integrated into custom builds. This is by no means perfect, but the best compromise that seems available at this point. I still don't understand why the userspace drivers for the GSM/3G modem, Wifi, Bluetooth and GPS would need to be proprietary. Or even the NFC par, it's sort-of ridiculous to have that proprietary with Free Software RFID stacks like libnfc and librfid around...

Apple not providing LGPL webkit source code for latest iOS 4.3.x

As some people may know, next to a plethora of BSD licensed code, Apple is using some LGPL licensed code in their iPhone products.

So far, it seems they have always provided the respective source code in a timely manner for each and every release they have made on a website www.opensource.apple.com.

However, in recent months it seems they have deviated from that policy for unknown reasons. As my friend and webkit developer zecke has blogged, Apple has stopped to release their webkit source code with iOS release 4.3.0. The corresponding website simply states: "coming soon".

iOS 4.3.0 was released on March 10, 4.3.1 on March 25, 4.3.2 on April 14 and 4.3.3 on May 4. For all of those releases, no source code has been published.

It cannot be a simple oversight, as multiple inquiries have been made to Apple by interested developers. However, the source code yet has to be released.

I think it is time that Apple gets their act together and becomes more straight-forward with LGPL compliance. It is not acceptable to delay the source code release for 8 weeks after shipping a LGPL licensed software. Especially not, if you have already demonstrated in the past that you are well aware of the obligations and have a process and a website to release the corresponding source code under the license conditions.

Jounrees Logiciels Libres / ENSA Tetouan, Morocco

I've been invited to Tetouan, Morocco by the organizers of the second incarnation of the Journees Logiciels Libres. Tomorrow I'll have the pleasure of presenting about Free Software projects related to GSM, including OpenBSC and OsmocomBB.

The organizers have done a great job in caring about the foreign speakers (who include Richard Stallman and myself).

I've been listening to various talks by RMS RMS over the last 16 years or so... but right now I'm listening the first time to him giving a French presentation.

Overall, this trip has done more to improving my understanding French than anything else in a long time. I once had 4 years of French from 1st to 4th grade in school, but never really continued with it. However, what I remember, combined with my knowledge of Portuguese (and even English) is sufficient to e.g. understand all of the French language slides that have been presented at this conference. However, most spoken French is too hard to understand for me.

One striking observation is the apparently much higher percentage of women taking a communications or computer engineering degree here than what I'm used to in Germany or the so-called western world. It reminds me of India where you have the feeling that almost 50% of the IT related students are female. It would still be interesting to see some scientific research why the supposedly open and anti-discriminating, women-rights-embracing 'western world' is seeing less women taking up engineering studies...

PTB kann nicht nur Wahlcomputer nicht prüfen, sondern auch Spielautomaten

To my non-german-speaking blog readers: Deep apologies, this one makes more sense in German. It will remain an exception in this blog.

Eine Gruppe von namhaften öffentlich bestellten und vereidigten Sachverständigen hat ein 25-seitiges Positionspapier herausgegeben, das erläutert, wie die Untätigkeit oder Unfähigkeit der PTB (Physikalisch-Technische Bundesanstalt) dazu führt, daß die gesetzlichen Bestimmungen zur Spielsuchtbekämpfung unterlaufen werden.

Die von der PTB herausgegebenen technischen Richtlinien entsprechen nicht dem Stand der Technik. Nicht nur das, sondern es werden auch noch Sachverständige zugelassen, die sich nicht auf dem Gebiet der Informationsverarbeitung (IT/EDV) auskennen.

Das erinnert mich 1:1 an die extrem peinliche Rolle der PTB im Bereich der Wahlcomputer. Zur Erinnerung: Eine Behörde, deren Vorschriften nicht im Entferntesten geeignet sind, die komplexen informationstechnischen Systeme in adäquater Weise zu prüfen. Eine Behörde, die ihre Prüfvorschriften nicht herausrücken wollte, und deren Prüfberichte nicht veröffentlicht wurden - schließlich wiegt das Geschäftsinteresse der Hersteller schwerer als das Interesse der Bürger an transparenten Wahlen, nicht wahr? Erfreulicherweise hat uns das BVerfG bis auf weiteres von Wahlcomputern befreit, und damit auch die Frage erübrigt, ob die PTB qualifiziert ist, Regeln in diesem Gebiet zu erlassen und/oder Geräte zu prüfen.

Man sollte einfach eine Abteilung für die Prüfung der Spielgeräte beim BSI einrichten. Man kann vom BSI halten, was man will - aber man arbeitet dort einfach auf einem ganz anderem Kompetenzniveau. Man sehe sich die umfang- und detailreichen technischen Richtlinien zur De-Mail an. Da hat jemand über Nachvollziehbarkeit und Sicherheit von IT-Systemen nachgedacht, der wirklich Ahnung hat. (ganz unabhängig davon, ob das System an sich für den Bürger nützlich ist)

Die PTB mag sich ja mit der Eichung von Messgeräten und ähnlichem auskennen - zumindest als es noch um mechanische Waagen oder so geht. Der Name sagt ja schon technisch-physikalisch, nicht etwa Soft-und Hardware von Informationssystemen. Aber genau um letzteres geht es bei den Spielgeräten heutzutage: Moderne Computer, mit komplexer Hardware und Software.

Finally: A parseable MAPv1 ASN.1 specification

After way too much work in extracting the ASN.1 text from word documents, learning about the differences in pre-1990 ASN.1 and pre-1990 TCAP with their respective current-day counterpart, some futile attempts with the incomplete ASN.1 grammar files available for ANTLR3, I have finally dedicated the entire day to manually convert the MAPv1 from ETSI TS 09.02 3.10.0 (1994) to work with present-day TCAP and present-day ASN.1 syntax.

The result not only passes the syntax and semantic checker, but it is accepted by the Erlang asn1ct. It has not been tested/validated against any test data so far. Just in case anyone else needs a 'working' version of MAPv1 some 20 years after it was created, I have published the result here: http://cgit.osmocom.org/cgit/asn1_docextract/tree/output/3.10.0

Any bugfixes/improvements/complaints are obviously welcome.

Now I just need to figure out how to properly work with the ROS/ROSE CONTRACT class and TCAP APPLICATION-CONTEXT class to formally describe the various application contexts, their respective MAP operations and associated application context versions. It's actually quite a bit surprising that the ETSI/3GPP don't specify this formally in 29.002. The information is contained in the human-readable part of the document, but not in the formal ASN.1 notation. I wonder why...

Facebook "Open Compute Project" nothing but hot air

There has been a lot of fuzz about facebook's Open Compute Project, and it seems to originate mostly from journalists without much technical skill.

Did anyone actually bother to check what they released? You can find mechanical designs and simple specification data sheets. More or less every vendor is publishing that kind of information, or at least there are common form factors that are specified (like ATX, eATX, mini-ITX, ...)

It is sad to hear that they are 'openwashing' themselves (like BP is greenwashing itself). Specifically, the following portions are not "open":

• Any type of electrical schematics (mainboards, power supply, ...)
• Any type of detailed data sheets or programming manuals on the electronic components used
• Gerber files of the PCBs

So what this really is all about is: Facebook advertising this is our new mechanical form factor, now we want all of you to adopt it, so we can buy cheaper hardware.

Go home, facebook. Come back if you have something _really_ open.

Following up on my GSM MAP archeology project

In the past weeks, I have been blogging about the work I've been doing in trying to recover the earlier versions of the GSM MAP ASN.1 files in order to support it from my own Osmocom Erlang MAP code.

After having gone through the tiresome exercise of implementing a custom MS Word for DOS file parser to extract the ASN.1 definitions from the 3GPP-published DOC files, I tried to feed them into the Erlang asn1ct code generator.

Unfortunately this didn't work, as the old MAP ASN.1 references very old ITU-T TCAP from 1988. So I went to the ITU website. There again a similar story. From their asn1 website section, you can only get the TCAPMessages from 1997. If you want an older format, like the Q.773 from 1988, you can download a PDF file. Most of that PDF file is actual text. But the ASN.1 sections are included as an image, so there is no way how you can copy+paste them.

So there I went, and manually typed in those few pages of ASN.1 source code. After I was finished, I thought I had finally done enough. Writing a word-for-DOS parser, typing in pages of ASN.1 manually. What more can there be? I should be able to finally generate Erlang code for decoding and encoding the respective messages.

But it would be too simple if it was that easy. The 1988 TCAP as well as the old MAP specifications use the ASN.1 "MACRO" construct to define the individual MAP operations. However, as it seems the MACRO construct had been deprecated in 1994 by the ISO in charge of ASN.1. Successive ISO specs for ASN.1 have completely remove the MACRO construct as similar results can be achieved with newly-introduced information objects. So of course, the Erlang asn1ct (as well as other free software ASN.1 tools) does not support such an antique feature.

So here I am in the year 2011, unable to use information available in the public ITU-T and ETSI/3GPP specifications to build a GSM MAP protocol implementation that can deal with the messages that you encounter on real-world SS7 links. I guess there are now the following different approaches to proceed:

• write a converter that translates MACRO into OBJECT
• manually convert the old MAP specs from MACRO to OBJECT
• add MACRO support to current-day ASN.1 tools
• find some old ASN.1 code generators that still support MACRO

All in all, this is a really dissatisfying situation, and I would say it is a failure of the standardization bodies to provide useful versions of their specifications. You cannot remove operations and associated message types from a specification, while in real life even 15 years later a whole number of users still use messages according to those (now removed) definitions. Meanwhile, the old specs are getting useless, because you not only deprecate but completely remove a language construct of the formal specification language used.

This renders the idea of having a formal specification useless. If I first need to write my own converters or manually convert that very same formal specification, errors can be introduced in the translation/conversion process, just as much as errors could have been introduced in manually writing encoding and decoding routines based on a non-formal-specified protocol like most of the IETF / Internet protocols.

Deutsche Telekom tried to register a trademark on netfilter

I am currently doing some trademark related research, and just for fun I queried the database of the DPMA (German trademark and patent office) for "netfilter".

To my big surprise, you can find this record, indicating that Deutsche Telekom AG has applied for a trademark on the word "NetFilter" in July 2006.

I find that quite outrageous, as the netfilter project is using the name since about 1999, i.e. 7 years earlier. To our luck, the trademark office refused the application based on the generic nature of the name, i.e. "netfilter" being too generic for anyone obtaining a trademark on it - at least in Germany, under German laws.

Linux Beer, anyone?

During my trademark research, I also discovered: A German beer brewer (St. Georgen Braeu, Buttenheim) has held a registered trademark "LINUX" from 1999 to 2009. This trademark was restricted to "beverages, beer and other alcoholic drinks".

You can find the respective entry in the DPMA trademark database here.

I am not quite certain whether I would have liked the idea of drinking a pint of Linux or not. It would certainly have been a popular gift to bring to international (Linux, Free Software) conferences.

More MS Word for DOS file parsing in the name of GSM

It seems that from TS 09.02 version 4.2.0 on, the editors have actually put markers as "hidden text" inside the Word document, which allow better automatic detection when a given ASN.1 module starts, is interrupted by plain text, continues and ends. The following screen shot (from Section 14 of the above-mentioned document) is human-readable hidden text explaining the syntax:

So now I'm adding this format as a second option to my extraction tool.

Please note: The tool I wrote yesterday (working fine with version 3.x.y of 09.02) is available from asn1_docextract.git. Later today it should also support the >= 4.2.0 annotations outlined in this blog post.

Implementing a custom MS Word for DOS file parser to properly do GSM SS7

Yes, I'm not kidding!

In recent months, I've been writing quite a bit of GSM MAP (Mobile Application Part) code. MAP is the protocol used heavily in the GSM core network and especially on the roaming interfaces between different operators. It is specified in GSM TS 09.02 and later 3GPP TS 29.002.

The protocol specification relies on ASN.1 description of the messages as well as the regular BER encoding rules. ASN.1 is this marvelous technology that allows a protocol to be specified in an abstract and formal notation, in an extensible way, removing all the problems of human-written marshalling code, full of errors and differences due to different developers interpreting a human-readable specification in different ways.

So far so good. You think it should be simple to write a parser and generator for MAP messages: Simply feed them into the ASN.1 compiler of your choice, it will generate code in the target language you require.

As long as both sides of the communication do that using exactly the same revision of the specification (and don't make implementation mistakes), this will work. The reality looks very different, though :( When I test my code against something like one million of real-world messages captured on a production SS7 roaming interface, it produces errors already on packet number six of that trace.

The problem is: The protocol designers have not specified the first versions in a really extensible way, i.e. a given operation originally only returned one atomic data field, and it was later extended to return a sequence of data fields. Thus, there is one additional level of hierarchy in the encoding.

Not only that, but in their infinite wisdom, the designers of MAP have also failed to include versioning information in each and every message header. Instead, it is part of the application context name, which is only part of the first message of every conversation.

Furthermore, different versions of the MAP specifications disagree on whether certain fields are deemed optional or not. This is further complicated by somewhat strange versioning habits. There is the Revision number of the TS 09.02 (like 3.8.10), then there is a different version number encoded in the corresponding ASN.1 files like 'version9(9)' and individual operations then have v1/v2/v3 in their application context name.

Some even more wiser decision must have been to remove the description of older messages from the later versions of the specifications. So even specifications published in the year 2000 no longer include definitions of messages that were still part 5 years earlier. Why does it matter? Because today, in 2011, you still see MAP message on the international SS7 interfaces that are encoded in some of the earliest versions of the MAP protocol!

And if all of this was not enough, the biggest bummer is: For most of the releases of the specification, the ASM.1 text files are not distributed separately, but they are interspersed with human-readable text in the actual specification documents (which can be 600 pages long, nothing you want to cut+paste).

Even worse: If you go to the ETSI homepage and download the PDF version of old 09.02 specs, they will actually provide a PDF with a scanned paper print-out, i.e. no searching and no copy+pasting.

Luckily, the 3GPP has made the history of 3.8.0 and later available on their FTP server. But they are in MS Word for DOS format, like they were written originally. This format can not be opened by OpenOffice, and as far as I know not even by any of the Windows Word versions that MS has released in the last 10 years.

So what did I do? I actually installed MS Word 5.5 for DOS (provided as Freeware from Microsoft) and ran it in DOSEMU, to convert the specs into RTF format. This way I can at least open them and look at them in a modern text processor.

But this still does not solve the copy+paste problem.

I finally found antiword, but it mainly focuses on Word for Windows files and only does rudimentary text extraction from Word for DOS files. But hey, there is an online copy of chapter 16 from the File Formats Handbook, apparently published by Dr.Dobb's (who remembers them!!) at some time in the past.

So what did I do? I wrote some custom parser for those old Word/DOS files, which parses the paragraph format descriptions and tries to identify those sections that contain the ASN.1 code. As they are almost the only part in the specification that is enclosed with a border line on all four pages, this should work pretty fine. Early results are quite promising!

My hope is now that the ETSI stylesheets did not change too much over time, i.e. that this parser will be able to extract the ASN.1 spec for all of the protocol versions that I can find. If that works, I can run them through a validator, then pretty-print them and putt them all in one git tree in chronological order. And maybe at some point in 2011, we will have the marvels of an unified diff between two different MAP versions. The strange part is: Diff was developed in the 1970ies, GSM in the late 1980ies. They should have known about it back then, and used a revision control system like SCCS to record all the changes in the specification they make.

I guess this all is a glimpse how a digital archaeologist of the 22nd century must feel when analyzing ancient artefacts and trying to understand what the heck his ancestors have been doing back then.

UPDATE: The tool can be found at http://cgit.osmocom.org/cgit/asn1_docextract/

Travelling to Belem/Brazil to talk about OpenPCD and OsmocomBB at UFPA

Tomorrow I'll be leaving for a 10-day trip to the signal processing lab of UFPA (Federal University of Para) in Belem, Brazil. I was kindly invited by Prof. Aldebaro Klautau to hold some lectures and lab exercises regarding Free Software (+Hardware) RFID projects like OpenPCD as well as Free Software GSM projects like OsmocomBB.

I would love to use that opportunity to spend some more time in Brazil for holidays, but my schedule really doesn't allow for anything like that at this time. It's always sad to have to miss such a chance. It would be exactly the right time of the year to spend some time at the beaches of Pernambuco or Alagoas... *sigh*

Starting to experiment with Anritsu MD8470A signalling generator

Earlier this week I was able to pick up some new equipment (aka toys) from the customs at Berlin TXL airport. Among other things I learned that despite filing an Internet-Zoll-Anmeldung (IZA) (Internet Customs Declaration), online via the German customs web site, you still have to print two copies of it on actual paper. I only had one copy, and the customs department does not have a copier to produce another copy. Buerocrats :/

In any case, I am now the proud owner of an Anritsu MD8470A signalling generator, which is basically a small 3G (WCDMA) network on steroids, all inside a single box. It can do mobility management, call control, voice calls, sms, packet data service, WAP, etc. It even has a legacy GSM/GPRS radio, so you can do inter-RAT hand-over between 3G and GSM.

But what is even more exciting: It includes (proprietary) APIs that allow you to send sequences hand-crafted messages on RRC and any layer above. This means it is an excellent tool for security and robustness testing of mobile phones.

Struggling with adding Ericsson RBS support to OpenBSC

I've been spending way too much time recently in understanding the low-level aspects of Ericsson RBS 2000 and the associated OM2000 protocol. The goal here is to support this family of BTS from OpenBSC.

The first big obstacle was that the A-bis Layer2 (LAPD) is quite different from what we've seen with Siemens BTS before - and also from what the GSM Specs TS 08.56 says.

In the Ericsson A-bis, there are the following key differences regarding standard A-bis:

• E1 timeslot is not configured statically. Instead, the BTS scans the entire E1 link and looks for SABM messages to TEI=62/SAPI=62
• There is no TEI manager
• LAPD sessions are initiated from BSC to BTS
• There is not only one OML connection for each BTS, but one additional OML connection for each TRX
• OML does not follow 08.59/12.21 but is proprietary

All those parts above have now been solved. We can initialize the A-bis link and talk OM2000 to the DXU/IXU of Ericsson RBS 2000, and we can use that to configure and initialize the CF (central function), as well as to configure the IS (Interface Switch) and CON (concentrator).

However, the IS configuration is already quite difficult. In that configuration you connect 1:1 mappings of various ICPs (Interface Connection Points). So you can connect any 64k or even 16k sub-slot of a TRX with any of the E1 interface(s) timeslots. However, the assignment of which TRX(TRU) is represented by which ICP is BTS specific. On a RBS 2401 for example, the first TRX (TRX0) is attached to ICP 512..523 (1x 64kbps signalling + 8x16kbps traffic).

So if we configure the IS to connect those ICPs 512..523 to the ICPs 4..15, then we will get the TRX0 routed to Timeslot 1,2 and 3 of the first E1/T1 interface. You can see some examples in page 89 (pdf page 115) of this document. This works on the RBS 2401, but it seems like the RBS 2308 has different ICP/DCP assignments than the generic RBS 2000 example that they are showing.

If anyone is more familiar with the details of the Interface Switch in RBS2000, and specifically the ICP / DCP mapping inside the RBS 2308, I would definitely want to have a chat with you.

If we cannot figure this out, it is impossible to bring up the per-TRX OML and RSL links, and thus impossible to use those BTS with OpenBSC :(

Public release of Osmocom TETRA code

Today I have publicly released the TETRA receiver code that I've started to work on earlier this year. The gnuradio-based demodulator, PHY and lower MAC code as well as some README file is available from the new http://tetra.osmocom.org/ website.

There's still a lot of work to be done, but fundamentally we are able to receive, demodulate and decode TETRA TMO downlink data. So the task of the software somewhat compares to that of gsm-tvoid or gsm-receiver (part of airprobe).

A corresponding project mailing list has also been made available. Please respect that this is a development-only discussion list right now. If you cannot make the code work and need help with it, chances are high that it doesn't do anything useful for you anyway.

There is some early code that should eventually enable us to run a base-station side transmit implementation, but it's not working yet.

Heading for a business trip to Nairobi/Kenya

I'm about to leave for a 1-week business related trip to Kenya... so please excuse any [additional] delays in reaching me. I really need to focus on my work in order to keep up productivity.

SS7 work: M2UA, MTP3 and ISUP message {de,en}coding

One of my paid contracts required me to start moving directly into the GSM core network, the SS7 domain. While so far I had a fairly good understanding of SCCP, TCAP and MAP (which are required for GSM/3G roaming interfaces), I've now had to look at the actual telephony signalling side of things.

Even in GSM networks, the gateway or inter-working MSC will translate all the GSM TS 04.08 Call Control messages into ISUP, the ISDN User Part, originally designed for call control signalling between ISDN networks.

As apparently always in SS7, there are many, many different standardized and proprietary protocol stackings that can be seen in the wild. I'm now working on a stack that looks like IP->SCTP->M2UA->MTP3->{ISUP, SCCP->TCAP->MAP}.

Luckily, for now there is no need to do any fully-fledged implementation of it, simple message parsing and encoding routines are sufficient for the task at hand.

It's been about time that I'm closing those last gaps in the knowledge of GSM core network protocols. The only part that I'm still missing so far is CAMEL. I know roughly how it works, but I've never played with it or implemented any part of it.

Supporting the HSL 2.75G femtocell from OpenBSC

The last couple of days I've been hacking away on reverse-engineering the proprietary Abis-over-IP variant of the HSL Femtocell. This is required to get this latest newcomer in the GSM femto/picocell market to work with our OpenBSC (and later OsmoSGSN) software. Progress is quite good now, apart from their custom RTP multiplexing format, everything required for signalling, SMS and Voice is working from OpenBSC.

The HSL Femto is a nice and powerful piece of hardware, containing a TI DaVinci ARM+DSP chip, 128MByte DDR2 memory, a Spartan-3A FPGA and 275Ms/s DAC as well as 65 Ms/s ADC. Much too powerful for a single-ARFCN GSM system. This really looks like the vendor wants to do multi-ARFCN software updates later. More details and some initial PCB photographs can be found in the OpenBSC wiki.

The Software side looks a bit like it is still maturing. Most bugs I have found so far are apparently fixed in the SR1.0.1 firmware. The A-bis dialect is quite different (and more simplistic) from what I've seen in any other BTS. More details can once again be found at a page in our wiki.

What's exciting is that there now is a commercially available traditional BTS product at relatively low cost. By traditional I mean it is still only a BTS and not a Um-SIP gateway like OpenBTS.

I hope this will enable more people to use and experiment with OpenBSC, as the cost and availability of the ip.access nanoBTS has always been an issue for many people without a four-digit budget available.

Working on a Free Software TETRA implementation

Those who have been following my twitter feed over the last week will already know: I've been in deep hacking mode implementing the lower levels of TETRA, specifically the PHY and lower MAC but also parts of the upper MAC level.

The primary idea here is to produce something similar to what airprobe is for GSM: An air-interface protocol analyzer that can demodulate/decode/demultiplex information received from a TETRA base station.

I'm not working on this alone, a number of known (and unknown) names from the Osmocom projects have been involved again. Progress has been surprisingly quick. The biggest gain was Dieter discovering that we didn't have to write our own pi4/DQPSK demodulator, but that somebody had already done that as a gnuradio hierarchical block originally intended for the more advanced channel types of APCO25.

So we could concentrate on the PHY and lower MAC layers, i.e. implementing stuff like

correlator for the various training sequences to achieve frame sync
• de-scrambler, de-interleaver, convolutional decoder, CRC, Reed-Muller decode
• Implementing the TDMA multiplex, reading the BSCH (like SCH in GSM)
• Decoding the MAC-layer PDUs like ACCESS-ASSIGN, SYNC, SYSINFO, RESOURCE
• Peeking into the higher layers like MM

Before writing the decoder I also wrote encoders/interleaver/scrambler etc. for the transmit side in order to do first testing/validation of the decoder. Using this encoder, we are able to generate continuous downlink SYNC bursts containing BSCH(MAC-SYNC PDU) + BNCH(SYSINFO PDU). As the SYNC bursts can be used for unallocated time-slots, a never-ending sequence of this single burst should provide a valid carrier that TETRA mobiles can lock to.

Working on all this has taught me much. My previous knowledge on convolutional codes, scrambling, interleaving, training sequence corellation, viterbi decoding, etc. has been mostly abstract and theoretical. Now I had the chance of implementing [almost] everything from scratch. Now I can understand what people like Tvoid or Piotr went through when they wrote gsm-tvoid/gsm-receiver (part of airprobe).

For the next couple of weeks I have to turn back to doing some higher priority work again, and in February I want to play with the GSM RF side of the MTK GSM chipsets again, so I don't know when I'll be able to continue with the TETRA related work. However, I hope other developers in the team will pick up where I left and bring the project further forward.

As soon as the code has moved beyond early prototyping, we'll be releasing the demodulator, libosmo-tetra-phy, libosmo-tetra-mac and associated command line tools.