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 SIMPhone 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.