Harald Welte's blog

Kevin Redon starts collaborative Osmocom project to collect terminal profile

As Kevin Redon writes in his blog, he has created some tools and a project for collaboratively gathering a database on the TERMINAL PROFILE capabilities of mobile phones.

The terminal profile describes which particular features regarding proactive sim or sim application toolkit a given phone supports.

This is not only important for SIM application / SIM toolkit developers, but it is also an important factor when trying to analyze the potential threat that can originate from a malicious SIM card attack.

I personally see no reason why my phone should ever report its GPS position to the SIM card, or why the SIM card should be able to re-write the nubers I'm dialling. Yes, there are cases where such features are useful, but then they should be explicitly enabled by the user, and the default should be that they are all switched off.

Who knows, after all, with some attention to this problem we might still see a SIM firewall / proxy, that you can put between the SIM and the phone to prevent any of those features from being (mis)used.

So all you need to do to contribute to the database is some way how you can read out the terminal profile from your mobile phone(s), and use Kevin's tool to upload it to the public website. And hwo do you read out the terminal profile? For example by using Osmocom SIMtrace to sniff the communication between SIM card and phone.

Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the community

As it has been quite some time since Openmoko, Inc. (the company) has released any hardware, I have obtained the permission to "donate" the Openmoko-assigned USB Product ID and IEEE OUI (MAC Address) allocations to the community.

As the actual allocations cannot be transferred unless the registrant (Openmoko. Inc.) is sold, the official registration will remain with Openmoko Inc. while the various Free / Open Source Software and hardware communities can make use of the range.

Registering a USB Vendor ID is expensive (USD 2000), and even if it wasn't for the money, many companies (let even aside community projects) will never require the 65535 product IDs allocated within that one USB Vendor ID.

As for Ethernet/Wifi/Bluetooth MAC addresses, they are allocated from the IEE OUI number ranges, which are also quite expensive (USD 1600) - but at least you get 16.7 million (24bit) and not just 16bit like USB ;)

So if you are running a small homebrew or community built project that implements a USB device or Ethernet ports, and either the software or the hardware of it is available under a free software / open source license, you can follow the instructions given at the pages in the Openmoko wiki that I linked above and request an allocation.

I'd like to thank Openmoko Inc. and especially Sean Moss-Pultz for making this donation.

osmo-lea6t-gps timing module DIY kits available

Due to lots of other work, it took quite some time between my initial blog post about the omso-lea6t-gps board and the point where we are able to offically sell kits in the sysmocom webshop. The primary reason is: The people for whom we primarily built the board (i.e. the Osmocom developers) all have one and are happy with it ;)

But repeated inquiries by e-mail and otherwise have shown there is more interest. However, for a hand ful of boards we cannot make an automated production run in a SMT assembly line. So for the time being, we are only selling DYI kits, consisting of a digikey-packaged component kit including all components, plus the PCB, as well as the LEA-6T module.

Anyone who is interested in such a timing module DIY kit can now order from the sysmocom webshop.

More information on the project, including design materials like schematics can be found at the Osmocom wiki.

Announcing the low-power, light-weight sysmoBTS

It hasn't been a secret that when I co-started a company called sysmocom more than a year ago, it was not about opening a webshop that sells cheap phones and DYI electronics kits to the larger community. Rather, it was to develop and sell exciting products surrounding Free Software and mobile communications.

There are of course the more or less obvious things to do, like system integration of OpenBSC and the related software on embedded systems, selling them as appliances including training, support and maintenance service.

However, we of course also want to more than that. Today it is my pleasure to say that the availability of our first BTS product called sysmoBTS has been officially announced.

See the news item, the product page and the data sheet for more information.

To make it very clear in the beginning: sysmoBTS is not an open hardware project. The schematics and layout files are proprietary and not disclosed publicly. Such is the FPGA bitstream and the layer1 inside the DSP.

However, any code running on the integrated ARM processor is available as free software. This includes a yocto/poky-built Embedded Linux distribution featuring u-boot, the Linux kernel (including all kernel modules!), the osmo-bts and OpenBSC software as well as many other Free Software packages.

We think this is a reasonable compromise between espanding a bit from our previous "BSC and above in Free Software" down to a "BTS Layer2 and above" divide. After all, if you use OpenBSC with a BTS from Siemens, Ericsson, Nokia or ip.access, you don't have access to the source code of anything running inside the BTS at all.

sysmoBTS offers some great new capabilities, such as integrating the BSC or even the entire osmo-nitb onto the ARM/Linux processor inside the BTS hardware itself, creating a less than 500gram, 10W power consuming autonomous GSM network.

I'm going to stop marketing here, but I thought it is one of the major milestones for sysmoocm and thus for what I've spent way too much time on in recent months - and thus deserves to be mentioned here on this personal blog.

OsmoSDR boards available for interested developers

I've posted about this on the OsmoSDR blog, so there's no point in copy+pasting it here.

There are still boards available, so feel free to order if you are interested in yet another exciting Osmocom embedded hardware/firmware/driver/software project!

Some follow-up on the Osmocom Berlin meetings

We've now had the first two incarnations of the Osmocom Berlin User Group Meeting. The start was great, and we had probably something around 10 attendees. Some were the usual suspects like the various Osmocom developers living in Berlin. But we also had a number of new people attending each of both of the meetings, which is good.

To my big surprise people are even flying in from other parts of Europe in order to be able to attend. Last time from Sweden, and for the next meeting some folks from the Netherlands have announced themselves.

To an even bigger surprise, the attendee from Sweden announced that he is working for an Ericsson research lab, and apparently they are using OsmocomBB quite a bit inside that lab. They think it's a great tool, and apparently nothing else with the same flexibility (i.e. full source code) is at their hands that can compete.

On the one hand it is surprising to see such a large traditional Telco supplier to start to use such amateur tools like OsmocomBB, which definitely have not had even a fraction of the testing (particularly with various operators in various countries) like the commercial protocol stacks.

On the other hand, if you think more about it, Ericsson is entirely a network equipment supplier today. They have spun off their baseband processor business to become part of ST-Ericsson, they have pulled out of Sony-Ericsson, sold their TEMS product line to Ascom and other bits and pieces to Tieto. So right now, if they need a MS-side protocol stack or engineering phones, they probably have to obtain what is available on the market. And that's unfortunately not all that great, as the products are either

Measurement devices aimed at mostly L1 testing / QA (Racal, Agilent, Rohde-Schwarz)
Trace mobiles primarily aimed at field testing (TEMS, Sagem OT) and while they provide traces they don't permit you to send arbitrary data or behave spec-incompliant
Mobile Phone development platforms (Qualcomm, MTK, Infinenon, ...) which don't necessarily give you the full source code to the stack, and are only available if you actually intend to build a handset

So all in all, the more I think about it, it is actually not too surprising that they ended up with OsmocomBB. It's free (as in free beer) and they get the full source code with it. You need a lot of skills and time to get it running and find your way around how to use it, but I guess if you're working in cellular protocols and embedded systems, it's not that hard.

Prototype smart card chips in DIL-40 case have arrived

Finally, the first samples of the smart card chip (for the Osmocom CardOS project) have arrived. As opposed to the final smart cards, this one has been packaged in a DIL case instead of the usual thin credit-card sized plastic. The reason for this is quite simple: This way lots of I/O pins for debugging as well as JTAG can be accessible during COS development.

Here you can see the first incarnation of a veroboard connected to an adapter pcb inside an Omnikey smart card reader:

After confirming it worked, I soldered the wires directly to the adapter PCB, as can be seen here:

There is already a real PCB design that is currently manufactured, i.e. in a week or so there will be a picture of a clean, professionally-produced/etched PCB with all of the prototype pins exported.

In terms of the COS, I haven't done much more work than compared to the last posting, mainly due to a large number of other projects. But we will get there...

Name that UART: April 2012

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: I'm going to post one picture every month about a UART that I found on embedded hardware. Unfortunately I don't have much to offer in terms of a reward for whoever finds the true solution ;)

In any case, every month there are devices that I'm looking into either out of my own interest, or because the work at gpl-violations.org requires it. In most of them, you can find a UART to get to the u-boot / Linux serial console.

So here is the device that I just took apart earlier today:

The location of the UART pads was obvious, after looking at the PCB for a very short time. The entire unpopulated U1 footprint appeared suspiciously like a UART level shifter for true RS232 voltage levels:

You can see two signals going directly to a small unpopualted3-pin header
There are two other signals coming from somewhere under the main SoC
There are capacitors (C440, C441) directly connected to the U1 for the charge pump

h-online article covering OpenBTS and OpenBSC

You can find a 3-page article about OpenBTS, OpenBSC and related projects available from the h-online web site.

OsmoDevCon 2012 is over...

We just finished the 4th and final day of the OsmoDevCon 2012. It contained four days of in-depth presentations and discussions related to Free Software communications systems, most notably OsmocomBB, OpenBSC, OpenBTS, OsmoNITB, SIMtrace, OsmoGMR, OsmoSDR, rtl-sdr and many more.

I think it was a great chance to make sure the key developers involved with those projects are up-to-date with what everyone else is hacking on. I was especially happy with the presentations of Holger's smalltalk implementation of certain GSM protocols/interfaces, and it seems my small informal Erlang intro has raised some interest.

If anything, the 4-day conference has shown that there is a massive amount of work going on in the various different projects, and that it has clearly grown beyond anything that a single person could still be involved in all the sub-projects.

Personally, I'm happy to see what has grown out of this "we have a BS-11, let's see what we can do with it" that Dieter and I started in 2008. Now we're no longer talking about BTS/A-bis/BSC, but about SS7, MSC, TCAP/MAP, SCCP, HLR, Erlang, smalltalk, DECT, SIM/USIM, COS, SDR, GMR/Thuraya, TETRA and more recently also femtocells as well as NodeBs.

In the spirit of that 2008 presentation Running your own GSM network using the BS-11, Dieter Spaar has now demonstrated his talk on Running your own UMTS network, using NSN or Ericsson NodeBs. I'm really excited to see where that will take us - despite the fact that due to the 5 MHz wide channels, it's pretty close to impossible to get the experimental spectrum licenses that most of us have been able to get in recent years for our work.

As an outlook, over the remaining year 2012, I see progress in the following areas:

osmo-nitb will get a VLR/HLR split (async database access)
we will build a stand-alone osmo-msc with A interface
the signerl TCAP/MAP implementations will be used in production
OsmoSDR firmware will be completed, the hardware will start shipping
a new card operating system (OsmoCOS) will emerge
a UMA gateway will be implemented
a Free Software GPRS/EDGE PCU and RLC/MAC implementation will appear
last but not least, sysmoBTS will start commercial shipment really soon now

I'd like to thank our host c-base for having us block their conference room for 4 days, as well as all attendees who have travelled from all parts of Europe, but even the United States and Russia to participate. There definitely will be another OsmoDevCon, though we don't know yet at which point in time.

Using a cheap (USD 20) DVB-T USB stick as SDR receiver for (not only) gnuradio

Fellow Osmocom hacker Steve Markgraf has been working on what now seems to be the cheapest way to receive real-world radio signals for PC-based SDR like gnuradio: rtl-sdr. RTL refers to the RTL2832U chipset frequently used in such devices. It can be used to obtain 2.8 Ms/s of 8-bit I+Q samples.

Below is a picture (courtesy of Steve) how the hardware looks like:

Osmocom GPS timing source with u-blox LEA6-T

Recently we have been looking for an inexpensive way to generate a high-accuracy clock source for E1 lines, as it is required by a number of classic BTSs that don't have a sufficiently accurate OCXO built-in.

Luckily, the Digium E1 cards like TE-410P have a timing connector, to which an 8.192 MHz signal can be injected. Unfortunately, there don't seem to be any OCXOs around for that frequency. That's where the u-blox LEA-6T comes into play: It has a configurable TIMEPULSE2 output that can generate any frequency up to 10 MHz. We use this in our board to generate 8.192 Mhz and want to feed that into the Digium card.

So all we had to do is build a small board that contains the module and connector for antenna input, clock output and the obligatory 2.5mm stereo jack for the OsmocomBB-style UART:

Thanks to Sylvain for doing the schematics/PCB design, and thanks to Pablo for writing the code to configurea and activate the 8.192MHz output.

Once the design is verified, the schematics + gerber will be available, as well as board from the sysmocom webshop.

Alcatel MTK phone UART pinout

The Alcatel OT-890D is a MT6573 based smartphone. It seems one of the UARTs is available on test pads as seen in this picture:

The voltage level is still 3.3V, so no fancy 1.8V gear is required.

During boot, the UART is first used at 19200 bps, where it prints the strings "MW01" and "MW02". I then switches to 115200 bps where it prints "READY", and finally switches to 921600 bps, where it seems to output some mixed binary/text messages containing AT commands and responses between AP and BP, as well as some debug information:

�Ue� � � T+CREG=2
�Ue�!�!�!T+CSQSQ=1
�Ue�!�!�!AT+CREG=2
�Uew�"w�"w�"SQSQ=1
'Ue"""      AT+EFUN=1
      SML: Load!_Ue""""""
                         SML: Load!hU("("("

I haven't yet investigated if the binary between the text is some standard HDLC framing or a TS 07.10 multiplex.

If anyone knows more about the boot process (MW01/MW02/READY) or the binary protocol, please let me know.

The next project on the horizon: A Free Software CardOS

Now that we have a 100% free software GSM protocol stack and baseband firmware for the network and mobile phone side, the only remaining proprietary part is the SIM card. And what is a SIM card? It's a small embedded computer / SoC with integrated flash + RAM.

Once again, like in many other areas of the telecommunications industry, development of Free Software has been hampered by lack of available register-level hardware documentation. Without such information, how should you be able to program? Hardware without such documentation is an insult to every software developer.

The next problem is that typically, the Card Operating System (COS) is written into mask ROM of the smartcard SoC. Making such a mask is quite expensive, and it means that for every software version, different silicon will have to be produced. So unless you are going to have millions of units in quantity, it is unlikely that it would make economic sense.

However, in recent years, purely flash based smartcard chips have been available and getting less and less expensive. However, none of them (like the Atmel AT90SC7272 or similar devices) have freely available documentation. Furthermore, availability on the open market is somewhat of a problem, mainly because they have been used extensively by people cracking encrypted satellite TV channels. In recent years, the smartcard industry is trying hard to cut any kind of supply to that group of users.

However, luckily, we now see small/independent chip design houses in China picking up and producing their own smartcard chips. They are not only cheaper, but they simply hand out the documentation to anyone who asks them. No questions asked, no NDA required. Welcome to the promised land! That's what Free Software developers like:

Free access to documentation without any confidentiality agreements
development samples available at the same price as quantity pricing later on
inexpensive development hardware with JTAG access
reference source code provided without NDA
they are happy that somebody wants to develop for their hardware

As you can see, I am quite enthusiastic about this. I like this no-bullshit approach. No stupid marketing and sales droids who charge ridiculous fees for proprietary development tools that are inflexible and force developers to use one particular OS/IDE/toolchain.

I'm not sure how much time there will be, given the multitude of other projects that are all asking for attention. However, I think this is a chance that the Free Software community doesn't get every day. Let's hope some other people like bare iron programming in small embedded systems can get excited and we can create a FOSS COS. It doesn't have to be something serious. Something quite simple would be sufficient for the beginning. I'm not thinking of EAL4+ certification, multiple channels and public key crypto. SIM/USIM cards are simple, they just require a bit of filesystem read/write operations plus authentication. And luckily, SIM toolkit development doesn't have to be done in Java this way, either ;)

OsmoSDR status update

It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at that time, there was no FPGA code yet, and some hardware bugs still had to be resolved. Nonetheless, the e4k tuner driver could already be implemented and tuning was confirmed by looking at the analog i/q spectrum.

Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL code written by maintech.de. Ever since that, they dropped the ball again with me as I had been careless enough to volunteer for writing the firmware.

And that's what I did or at least tried to do for quite some time during the last two weeks. The main problem was that I didn't have much time. The second problem was that I never was able to get the SSC (synchronous serial controller) receive DMA working.

This was a really odd experience, as I've worked a lot with that very same SSC peripheral before, while writing firmware for the OpenPICC some 6 years ago. However, this was in an at91sam7s, where the SSC is interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller, capable of scatter-gather DMA and other fancy stuff.

Atmel has provided reference code that uses the SSC DMA in transmit mode (for a USB audio device playing back music via the Wolfson codec on the SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I set out to write code for DMA-based SSC receiver. And it never worked.

I actually wrote two independent implementations, one from scratch and the other based on Atmel reference code. Neither of them worked. It seemed to be a problem with the hardware hand-shaking between SSC and DMAC. The SSC was successfully receiving data, and that data could be read out from the CPU using a polling or IRQ based driver. But if you're running at something like 32 Mbps and don't have a FIFO, you desperately want to use DMA. When the DMA handshaking was turned off, the DMA code worked, but of course it read the same received word several thousand times before the next data arrived on the SSC.

In the end, I was actually convinced it must be a silicon bug. Until I thought well, maybe they just connected the flow controller to a different ID in Rx and Tx direction. Since there are only 16 such identifiers, it was relatively easy to brute-force all of them and see if it worked. And voila - using the identifier 4, it worked!

So what had happened? The Atmel-provided reference code contained a

 #define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3

and that was wrong. 3 is valid for SSC TX but not for SSC RX. Unfortunately I never found any of those magic numbers in the SAM3U manual either. They are not documented in the chapter of the SSC, and they are not documented in the chapter about HDMA/DMAC either. And they are not identical with the Peripheral Identifiers that are used all over the chip for the built-in peripherals.

In case anyone else is interested, a patch can be found at my at91lib git repository.

I filed a ticket with Atmel support, and they pointed out in fact there was a table with those identifiers somewhere in the early introductory chapters where you can see a brief summary of the features of each integrated peripheral. Unfortunately they use slightly different naming in that chapter and in the DMAC, so a full-text search also didn't find them. Neither is that table visible in the PDF index.

So about four man-days later it was finally working. Another day was spent on integrating it with the USB DMA for sending high-speed isochronous transfers over the bus into the PC. And ever since I'm happily receiving something like 500,000 or 1,000,000 samples / second from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or Windows, the Linux audio drivers don't make arbitrary restrictions in the sample rate. According to the USB Audio spec, the sample rate can be any 24bit number. So audio devices with 16.7 Ms/s are very much within the spec. I hope some of the other OS driver writers would take that to their heart.

One of the first captures can be found at this link, containing a bzip2ed wave file in S16LE format Stereo (I/Q). It contains a FM audio signal transmitted using a small pocket-sized FM transmitter.

There is no I/Q DC offset calibration yet, but once that is done we're probably able to finally put the design into production.

More research into the Motorola Horizon macro and Mo-bis

Once upon a time there was an Americans company called Motorola, and they decided to implement GSM. Unfortunately they decided to deviate significantly from the specification and implement their own proprietary back-haul protocol between BTS and BSC, called Mo-bis. It replaces the standardized A-bis interface.

Today, There are plenty of phased-out Motorola Horizon / Horizon II macro BTSs that have been phased out. Basically you can get them for scrap value, which makes them an ideal target for GSM enthusiasts willing to run a single-cell network with little investment. So while there are actually people who are interested in operating a power-consuming device roughly the size of a washing machine in their home/office - they are normally not interested in running a 19" rack sized Motorola BSC with it. Also, the BSCs are much less frequently to be found compared to the BTS.

So it would be great to support Mo-bis from within OpenBSC. A couple of brave young men have set out to try the seemingly impossible. There's absolutely zero documentation available on that protocol, and no wireshark support either. However, the University of Brno (Czech) has a functional Motorola BTS + BSC setup, and I was able to obtain protocol traces from them and actually experiment with the equipment in their lab.

The entire Motorola GSM architecture seems to be over-engineered without end. Basically you are looking at a distributed computer from the early 1990ies. Lots of processor cards (m68k, ppc) interconnected by HDLC links on top of synchronous 2Mbps links with 64k timeslots. Those links are available e.g. on the backplane of the BTS as a TDM highway. So basically even inside the BTS, the individual processors talk over E1 to each other. In the BSC, there is a token ring based LAN between some of the cards instead. And the MCUF in the BTS even supports to transport those proprietary inter-cpu links via fiber optic (!).

Each processor has a 16bit identifier by which it can be addressed in form of physical addresses. Individual processes on the processors have fixed process identifiers, and they allocate a variety of mailboxes in which they can receive messages from remote processors. There are routing functions at intermediate notes.

So any process on any processor card can send messages to any mailbox of any other process on any other processor, independent of its physical location (locally at the BTS, or at the remote BSC, or even at remote BTSs).

Besides physical addresses, there are also functional addresses. Thos addresses are used particularly to support fail-over. Every board in a BTS and BSC can be fully redundant, and if you use physical addresses, you would address one of the two redundant boards. Using functional addresses, you address the function they both can perform, and some routing magic will make sure it ends up at the current active node in the pair.

There are multiple processors in every TRX, and a couple of processors for each BTS, processors in the E1 line cards, etc. Now speaking of the actual Mo-bis interface: It seems to be a weird mixture between 08.58 (RSL) and 08.08 (BSSAP/BSSMAP). However, after staring at the messages sufficiently long, I have been able to write a more or less complete wireshark dissector for them. Radio Channel Activation (RACH/IMM.ASS) are for example handled directly inside the BTS, they don't exist as transactions on the Mo-bis like they do in A-bis.

So implementing the actual location update / MO+MT voice call and SMS related transactions is actually not all that hard. What makes things really difficult is the way the BTS is initialized at startup. Basically what resembles the OML part of standardized A-bis.

There is a lot of low-level management and bring-up of the individual processes and boards, and the download of a large 500 kByte-sized BLOB simply called database. This binary database contains literally hundreds of configuration parameters for the BTS and its neighbors. It also contains sophisticated configuration of the message routers, the switching/multiplexing of 64k timeslots on the various links, information on redundant paths within the back-haul network, etc.

Interestingly, using the password combination 3beatles and 4stooges on any of the serial consoles of the BTS or BSC, you can enter into a "god-mode" which permits you to enter the executive monitor (EMON). The executive is the operating system they run on both m68k and ppc processors. It provides access to something like a syslog of messages from the various processes, and you can manually generate messages that are to be sent to mailboxes of processes. You can inspect the object table (application programs an databases), read/write to PCMCIA flash cards, read and write to logical and physical memory, inspect CPU and I/O usage and much more. In fact, the integrated Code Object Manager (COM) even allows the processors to synchronize their code versions and remotely boot other CPUS via HDLC channels.

For a communications system geek like myself, it's extremely fascinating to see such a sophisticated and versatile system. I only wonder why on earth somebody would come up with something as complex, only to connect a couple of BTSs to a BSC. Thus, the only logical explanation is that Motorola has developed this distributed proprietary computing system way before they went into GSM, and they probably just recycled it as it already existed.

If anyone knows more about the history of this, I would be excited to hear about it. It literally feels like being an archaeologist. Analyzing ancient technology from our forefathers. But then, it only is 20 odd years old. The only time I had a similar feeling was when I briefly came in touch with IBM mainframes in 2001 and looking at IBMs SNA protocol stack.

Some comments on the heated debate on SFC / Busybox / Linux GPL enforcement

During the past week[s], there has been a heated debate on the alleged methods of GPL enforcement as it is performed by the Software Freedom Conservancy on behalf of the Busybox copyright holders.

The extent of license enforcement on Busybox has apparently triggered the proposal to create a non-GPL replacement for it, which in turn has received quite harsh responses e.g. from Matthew Garrett.

It's been relatively difficult for me to figure out what is really going on here. It is well-known that the Free Software Conservancy has been actively enforcing the GPL on Busybox. But then, at the same time gpl-violations.org has been (and still is!) similarly active in enforcing the GPL on the Linux kernel. Still, I haven't yet seen calls to write a non-GPL Linux kernel replacement. Of course, the complexity is on an entirely different scale, so this point is moot.

However, for quite some time there have been rumors about the intensity (some would say aggressiveness) of the enforcement. I don't want to accuse anybody of anything, so I'm going to write speculatively about it.

This post is to summarize my thoughts on all of this:

It is well within the right of each author / copyright holder to decide on the enforcement strategy and license interpretation. As such, I respect the decision of the authors. It is their work, they should decide what to do.
In any kind of GPL enforcement, you of course not only want the complete corresponding source code to one program, but to all of the GPL/LGPL/AGPL or otherwise copyleft licensed programs contained in the product. We at gpl-violations.org have always been requesting the complete corresponding source code to all GPL licensed software during our communication with the infringing companies. This request was typically honored by everyone, without the need to apply any pressure onto it. After all, releasing only one bit of code causes the risk to get sued by somebody else who owns the other not-yet-compliant part of the code.
Now there have been rumors that SFC was not only requesting non-Busybox source code, but also making it a condition for the explicit re-instatement of the license on Busybox. Whether or not there was such a hard condition is subject to debate and there are different opinions on it. For those in the field of FOSS licensing, it has always known that there are different lines of thought with regard to the requirement to explicit reinstatement. We in Germany generally think that it is not required at all, and the existing preliminary injunctions at least implicitly acknowledge that as they enjoin companies from distributing a product as long as it is not in compliance with the license. In other (particularly the U.S.), it is generally assumed that explicit reinstatement is required. In such a case, it may very well be legally possible to use it as a lever to obtain source code for other programs like the Linux kernel. However, I am personally not sure if that really is the right strategy. Not everything that is possible legally is ethically the right thing to do. But then, ethics and legal customs differ widely in the FOSS communities, as they do in society in general. Some countries and communities believe in the death penalty, others don't. Some countries allow abortion, others don't. Some allow prostitution, others don't. So when judging about whether that "reinstatement lever" is acceptable or not, we have to accept that there may be different lines of thought. I for my part definitely think that the far superior method is, beyond doubt, to have a rights holder on those other program in order to make any demand for source code (as opposed to a mere request without implicit or explicit legal threat).
There also have been rumors about a requirement on submitting future source code releases to a compliance audit by the Conservancy. According to SFC sources, there never was any such demand, and the rumors are likely spawned by some incorrect claims of a defendant in a court case, which ended up in the public record. If there was such a requirement, I wouldn't think it is just - at least not for a first-time non-intentional infringement case. If there was repeated infringement and a clear sign that it would happen again and again, such a requirement for future audits may be justified, depending on the case.
People who claim that GPL enforcement is scaring away companies from using Linux and/or other Free Software also have to be careful in what they say. If a commercial entity enters a new market (let's say Android Tablets), then there is a certain due diligence required before entering that market. So if you don't understand Free Software and particularly GPL licensing, then you shouldn't place a Linux-based device on the market. Just think about an analogy: If you have a recycling company and enter a new market (disposal of hazardous chemicals), then you cannot simply treat those chemicals as regular waste, wait until you run into legal trouble and expect to get away with it.
I think there are still far too many GPL violations out there, and we need to see more enforcement in order to get all the major players in their respective lines of business into compliance. But come on, dealing with embedded devices in 2012 and still getting compliance outright wrong really means that there has not been the least bit of attention on this subject. And without enforcement, it is never going to change. People who want no enforcement should simply use MIT-style licenses.
Last, but not least, I also think GPL compliance is a matter of fair competition. There are some companies who really do a good job in ensuring compliance with the various Free Software licenses. If their competition doesn't invest the funds into the respective skills, procedures and business processes, they are getting an unfair competitive advantage against those who are doing it right. If there was no enforcement, the motivation would be to reduce efforts in compliance, not increase it.

Let me conclude with a clear statement to anyone who thinks that by replacing Busybox with a non-GPL licensed project they can evade GPL enforcement: It will not work. There are others out there enforcing the GPL. Last but not least gpl-violations.org. Despite the notoriously outdated webpage, we are still alive and kicking, churning down on the violation reports that we receive. Armijn Hemel, Joachim Steiger, Tim Engelhardt, Julia Gebert and Till Jaeger deserve much of the credit for all that work, while I'm mostly spending each awake minute hacking Free Software for mobile communications. Yes, we should publish more about our activities, and I hope to find the time to do so. There should at least be an annual report with the number of cases...

New OsmocomBB RSSI monitor firmware

Jolly has been hacking up a nice new RSSI monitoring firmware application for OsmocomBB.

I let the pictures speak for themselves:

I really hope this trend continues and we'll get some actual user interface in OsmocomBB at some point this year..

OP25 project joins hosting on osmocom.org

Some days ago, I noticed that the famous OP25 project (a Free Software implementation of the APCO25 system, a digital trunked radio system) was no longer reachable on-line. It seems they were running this on a desktop PC in a university. As nobody in the project still seems to be at that university, a change in the network configuration had accidentally rendered the website unreachable.

After some quick e-mails, I offered to host them within the osmocom.org family of Free Software Projects for mobile communications. This is when op25.osmocom.org was created, and a full-site backup uploaded + installed.

I'm really happy that we were able to do a small part to help to make sure this valuable project remains accessible to interested parties in the signal processing and mobile communications field.

First osmo-nvs-gps evaluation boards soldered

At the osmocom project, we recently discovered the most interesting NVS NV08C-CSM module. It not only is a superb GPS receiver, but it includes GALILEO and GLONASS receivers, too. However, it's only available as an industry module, or as an expensive (700 EUR or so) evaluation kit.

Given the cheap PCB prototyping service at seeedstudio, I thought I'd spend an afternoon creating the schematics and PCB layout for an evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style 2.5mm jacks, so they can be used with the T191 cables. I have the feeling this 2.5mm jack is becoming a new standard for low-voltage RS232 links ;)

Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch header, connects to an external antenna via a MCX socket and has an optional footprint for a CR2032 battery on the bottom side.

So far, the board seems to be working fine. If there is interest in the bare PCB itself (without components!), please send me an e-mail. Depending on the amount of interest we might add it to the sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

Having Fun with DHL Express!

This is what I got when tracking one of my inbound shipments:

It seems DHL is having fun bouncing the package back and forward between Hong Kong and Leipzig(Germany). So far, it started in HK, then arrived in Leipzig on January 8, went back to HK, back to Leipzig, back to HK, back to Leipzig and is currently allegedly again in Hong Kong _after_ succesfully passing German customs clearance on January 15.

For the TCP/IP nerds among the readers: I wonder when the TTL expires.

First assembled prototypes of osmo-e1-xcvr

I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver board, which is going to be used for experimentally interfacing such a TDM line with microcontroller and/or FPGA. The name of this board is osmo-e1-xcvr.

The first prototype PCBs have arrived yesterday, and despite lots of other more important work I couldn't resist but to actually solder some of the units. The result can be seen here:

I don't have time to do anything beyond very basic testing right now, but so far the boards seem to be doing fine. Now we need a driver for the transceiver chip, and connect its control interface over SPI to some microcontroller (likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up at the SSC peripheral of the controller.

OsmoSDR status update

It's already two weeks since my last post mentioning OsmoSDR only very briefly. By now, OsmoSDR is fully public and you can read all about it on the http://sdr.osmocom.org/ website.

Specifically, the website includes Schematics, and one of my colorful block diagrams. I am a text guy and really hate to work with graphics, but the block diagram of the Calypso has helped a lot in the context of making people understand OsmocomBB, so I tried again for OsmoSDR:

So as you can see, it is a very simple, straight-forward design with a chip tuner, direct I/Q down-conversion, ADC for differential I and Q signals as well as a small FPGA for basic filtering and serial format conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high speed USB).

And yes, it's receive only. However, it has a stacking connector for later addition of a transmit daughter-board which may eventually follow later in 2012.

So what is this OsmoSDR going to be used for? Well, for receiving any kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz, untested). We don't build it for a specific application, but we simply thought that for many applications a member of the USRP family is expensive overkill, and the FCDP has this arbitrary restriction at 96 kHz sampling frequency.

Please note that while I may be the only OsmoSDR developer that blogs about this project, it is very much a team effort and I'm only a minor part of that team. Apart from selecting the SAM3U, writing firmware and drivers for it as well as some discussions early on in the project, I didn't have any involvement in the Hardware design. Those credits go to Christian Daniel and Stefan Reimann.

So where do we stand? There are 5 prototypes of the first generation, they look like this:

There are some smaller hardware issues that were easy to work around, but one bigger problem related to the fact that the Si570 programmable oscillator output levels didn't match quite with what the FPGA clock input requires.

There will be a second generation board fixing this and other problems, and hopefully we'll see some progress in the weeks to come.

Firmware-wise, the code is currently scattered over a couple of different repositories, but I'm going to consolidate that soon. If you've worked with OpenPCD or SIMtrace, you will find some similarities: We split the flash of the controller into two partitions: One for the DFU bootloader, and one for the application code. You can then use the USB DFU (Device Firmware Upgrade) standard to quickly update the actual firmware of the device, without having to resort to jumpers or un-plugging and re-plugging of the hardware.

This also meant that I had to re-implement the old sam7dfu code for the SAM3U, which has considerable differences in the USB peripheral, cpu core, board startup code, etc. So it's really a reimplementation than a port. The good news is that I tried to make it as general as possible and integrate it with at91lib, Atmels reference code. So it should be easier to use it with other Atmel SoCs like the sam3s which I want to use e.g. in SIMtrace v2.

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 GRPS, 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.