The Linux-Kongress 2010 CfP is about to close

The Linux-Kongress 2010 Call for Proposals is about to close.

So if you have anything interesting related to Linux that you would like to talk about at the 2010 incarnation of one of the most traditional Linux conferences, this is your last chance. There is no excuse, do it right now!

UPS sends me an invoice over 1 Euro-cent

Yesterday I received this letter from the local UPS subsidiary in Germany.

This is nothing uncommon, as I often import some electronics parts or other equipment from outside the EU, on which I need to pay customs duties and/or import VAT. In such cases, they typically collect an estimated amount as COD (cash on delivery) and then send an invoice about the difference (if any).

The funny part in this case now is: The grand total after subtracting my COD payment is EUR 0.01 - in words: One Euro-cent. They really want me to do a bank transfoer or write them a cheque over 1 cent !?!

One wonders to what grand total the expenses for the paper, printing, postage, banking transfer fees and accounting fees on the UPS side will amount to for processing something like this.

I wonder what would happen if I didn't pay that 1 cent. Would they actually try to sue me? Probably simply stop delivering packets to me, which I cannot afford and thus rather pay that single cent...

OpenGGSN Version 0.90 released

Only three weeks ago I blogged about OpenGGSN, a seemingly-abandoned Free Software implementation of the GGSN node of the GPRS core network.

Things have developed quite a bit ever since. As the original author didn't respond to any of my mails and sourceforge.net was not able to reach him either, they have approved my the 'abandoned project takeover' (APT) request.

I've now switched the project from CVS to git, removed links to the non-existing openggsn.org homepage and released version 0.90, containing nothing less than a fix for remote DoS vulnerability that was pending for more than 5 years.

So far I'm only exercising the PDP context activation/deactivation parts of OpenGGSN from OsmoSGSN (the SGSN I write as sister-project to OpenBSC), but I hope we can use OpenGGSN in a production GPRS network soon...

dfu-util release 0.1 has been announced

Back in the early days of my work at Openmoko, I had come up with the idea to use the standardized USB Device Firmware Upgrade (DFU) protocol for flashing firmware to the Neo1973 and later FreeRunner phones. This encompassed a DFU device implementation that is part of the Openmoko u-boot variant (and has meanwhile been merged in one of the u-boot successor projects) as well as a tool for the host PC called dfu-util.

Since DFU is meant to be device and vendor-agnostic, I tried to code closely to the spec. This meant that it in fact was compatible to other devices, and some folks e.g. used it to flash firmware into their USB-Bluetooth controllers from CSR.

However, there never was any official information how to use dfu-util outside the context of Openmoko, and even more specifically: There never were any official releases.

Stefan Schmidt has stepped up to change this and maintain dfu-util as well as make official releases. The first such release has now been made at the new dfu-util project homepage.

I'll be presenting at COSCUP 2010 in Taiwan

I have just received the great news that my attendance of the COSCUP 2010 conference in Taiwan is now confirmed. Thanks to COSCUP for inviting me!

I'll be participating in the legal track and presenting on GPL license compliance. The exact title and abstract is not yet decided.

As usual, I'm really looking forward at any chance to visit Taiwan, and the trip this August is definitely no exception. Now I only need to decide how long I'm going to stay before/after the conference...

Heading off to Europe's largest Goth festival

Despite lots of very exciting work at this time, and a distinct lack for progress on my various 'just for fun' software/hacking projects, I'll be visiting Wave-Gotik-Treffen from tomorrow on. This means that I'll be listening to some fine music and will hopefully have a most enjoyable time offline.

Don't expect me to read or answer e-mails or get any work (paid or unpaid) until at some point Tuesday next week.

Doing even more encapsulations than the GPRS Gb interface already has

Back in October 2009, I blogged about the incredibly deep protocol stack on the GPRS Gb interface between a BSS and the SGSN.

Today I had the pleasure of implementing an even more odd variant of the Gb interface, where NS does not get encapsulated in UDP/IP/Ethernet, but in FrameRelay/GRE/IP/Ethernet. The total protocol stack thus then looks like: HTTP/TCP/IP/SNDCP/LLC/BSSGP/NS/FR/GRE/IP/Ethernet, with an optional PPP between IP and SNDCP. If anyone does the math to calculate the total protocol overhead, please let me know[...

The reason for that oddity is apparently that there are Cisco and other routers that can encapsulate Frame Relay in GRE. So using a old circuit-switched SGSN with E1 interfaces and such a router, you can convert from Frame Relay on E1 to Frame Relay on GRE/IP/Ethernet.

Both the Gb Proxy as well as the upcoming OsmoSGSN use the same NS implementation, i.e. they can now both talk NS/FR/GRE and the NS/UDP variants - even at the same time, as the encapsulation is a property of each individual NS-VC.

Back from a week of GSM/GPRS protocol coding/testing in Iceland

With only 16 hours delay (which isn't all that much considering the volcanic ash situation) I arrived back in Berlin from one week of OpenBSC software hacking, particularly on the GPRS side of things.

It was really nice to see to what extent OpenBSC software is already used at On-Waves, providing GSM and now also GPRS services to thousands of users.

My work was mostly focused on the Gb-Proxy, a multiplexer/proxy for GPRS Gb links running the NSIP (NS-over-IP) protocol. It combines elements of the idea of a network address translator with that of a proxy, combined with a little bit of packet-based routing. This really makes me feel like I'm back to packet-switched networking, which is great. Especially the fact that we use the VTY code from quagga and its interactive command line sometimes lets you forget that you're not working with classic TCP/IP routing daemons or the like ;)

Aside from that, I continued my work on the upcoming OsmoSGSN, using which we will be able to run an autonomous GPRS network with no dependency on external proprietary components. In this setup, the PCU in the BTS connects over Gb/IP to OsmoSGSN, which then talks over GTPv1 to the OpenGGSN.

Also, work was spent on an abstract rate_counter implementation (now part of libosmocore). The idea is to have a counter that will count certain events (like number of packets/bytes, number of link failures, etc), but also keep a small history about how many of those events happened in the last second, last minute, last hour and last day. There is also common code to store those counters in the database, as well as to print them on the VTY. The new counters are so far only used in the GB-Proxy, but they will soon likely be added to OpenBSC (bsc_hack) and other programs of our Free Software GSM network portfolio.

Heading for 4 days of Iceland to work on OpenBSC GPRS

Having just returned from Croatia the day before yesterday, I'm about to head on a four-day trip to Iceland, where I'll be doing some testing and bug fixing of the current OpenBSC GPRS support at On-Waves.

Zecke is also going to be there, working on other aspects of OpenBSC. This will make the trip even more fun!

CECT C3100: Not a phone, but a flashlight with integrated phone

I've seen many [mobile] phones in my life, but nothing like the CECT C3100 so far. It's made of the cheapest hard plastic, like cheap kids toys. In addition to the phone keyboard, it has a mechanical switch on its side. If you slide that switch, five powerful bright white LEDs at the top of the phone will turn the entire device into a flashlight.

However, it is one of the most basic phones with one of the older/simpler MTK baseband chips inside (MT6223). Also, as we have determined by a PCB delamination analysis, the test pads next to the MT6223 really are its ARM JTAG pins.

JTAG is something not commonly found in MTK phone designs, but it is definitely a big win for bootstrapping any system-level software such as drivers on the unit.

Right now I don't have the time to work on MT6223, we still have many issues to fix in the current Ti Calypso code. But I can't wait to find time to see if we can extend our hardware support to MTK GSM chipsets...

GPRS progress in OpenBSC

In recent weeks, I have been able to pick up my work at GPRS support for OpenBSC again. What has been done is:

• Add OML support to configure nanoBTS for EDGE
• Add RR (System Information) support to indicate EDGE support
• Make a OpenBSC + nanoBTS setup inter-operate with an existing SGSN
• Develop a proxy that can aggregate the Gb-interfaces of multiple BTS into one Gb link to a real SGSN. This way the SGSN has only one Gb link for all the cells under the control of a BSC, as opposed to one Gb link for each and every BTS

What I'm working on now is the actual SGSN implementation. The SGSN is mainly responsible for GPRS mobility management (GMM) and for terminating the Layer2 (LLC) protocol from the MS. This is very different from circuit-switched GSM, where Layer2 (LAPDm) already terminates at the BTS.

The layering stack of GPRS is a real nightmare, I am sure I have indicated this in this blog before. The Current OsmoSGSN code (available from the regular openbsc.git repository) implements the NS, BSSGP and LLC layers, as well as the basic GSM 04.08 GPRS Mobility Management messages like GPRS ATTACH/DETACH and ROUTEING AREA UPDATE. The LLC code is still somewhat limited, but for the time being it is sufficient.

What drove me crazy for a couple of days is the number of parameters that are exchanged at PDP CONTEXT ATTACH time. There are no less than 26 different quality of service (QoS) parameters negotiated (see struct gsm48_qos at the bottom of this link), each of them from a wide range of values. It's almost impossible to imagine more than 1% of all the possible combinations have ever been used in production networks. The QoS parameter negotiation works by the phone sending a list of requested parameters, to which the SGSN responds with its selected parameters. My first thought was: Lets be smart and simply echo back the QoS parameters - the phone must accept what it has requested. That didn't work either: While the QoS structure is the same in both ways, the actual values in uplink and downlink directions are encoded differently. Who on earth defines such an encoding?

Next item was the XID exchange which is at the boundary between LLC and the SNDCP (Sub-Network Dependent Convergence Protocol). It works like this: The phone proposes an endless list of parameters, which the SGSN can evaluate, and then depending on the parameter type either negotiate up or down. According to the spec, sending an empty XID response should mean "I agree with all your parameters". However, at least those phones that I tested were not happy with that. So I decided to simply send back the entire XID block to the phone. And believe it or not, as opposed to the QoS parameters, this time it even worked

So now I'm facing the implementation of the actual SNDCP-to-GTP interworking, which is nothing less but the guts of the SGSN. GTP is the protocol used on the GGSN side. At least this time, GTP is sent directly over TCP or UDP, i.e. the stacking inside the SGSN is only one layer deep, while on the Gb-interface it is four (NS,BSSGP,LLC,SNDCP).

SNDCP interacts with the GPRS Mobility Management, GPRS Session Management (both GSM 04.08 over LLC), the GTP interface to the GGSN, as well as other parts. I expect many pitfalls on the way to getting it working, and given the complexity involved I have already decided to stick much closer to the specification than I usually did with the OpenBSC work. This means properly implementing all the state machines with all their transitions, exceptions and timers. I'm sure it's going to be "fun". The good part of it is: Most of the SGSN will be re-used once we finally get around adding support for 3G/UMTS/WCDMA cells.

OpenGGSN - An open source GGSN implementation

As a friend pointed out to me at exactly the right point in time: there already is an Free implementation of a GGSN. In case you don't know what a GGSN is: It is one of the two core components of a GPRS network. So, in order to extend a OpenBSC GSM network with GPRS support, there are two components required: The SGSN (on which I'm working currently, project name OsmoSGSN), and the GGSN. Due to the good news about OpenGGSN, I'm quite confident that I will not need to implement the latter part.

OpenGGSN is not only a Free Software implementation of the GGSN, but it is also licensed under GPLv2, making it compatible with the OpenBSC codebase (which is GPLv2 or later). This means I will be able to link the OpenGGSN-provided libgtp library (implementing both sides of the GTP protocol between SGSN and GGSN) from OsmoSGSN, further reducing the amount of work required to get this working.

However, despite seeming like a fairly advanced/complete implementation of the GGSN specification: OpenGGSN seems like a project that was abandoned many years ago. The latest CVS commit is from 2005, and all of the bug fixes that people have submitted to the bug tracker have not been merged. The homepage is defunct, and the openggsn.org domain name seems to have been expired (and grabbed).

I've tried to contact the author by e-mail about his intentions for the project, let's see if there is any response. Meanwhile, I have generated a git repository from the OpenGGSN CVS repository at sourceforge and applied all the pending fixes to a local branch. See my related mailing list post for more information.

Security product technical details need to be disclosed while importing to China

According to this report at The Register, there are some new government regulations about the import of certain security products into China, including Smartcards, firewalls and routers. While importing the goods, the importer needs to submit the technical details to a government panel in order to get the import license.

However, the article claims there are no further details on what exactly needs to be disclosed. Anyone who knows more details: I'd be more than interesting to hear about them - maybe there's even an English translation of the respective law or regulation?

I think it is a most reasonable policy that a country can adopt. Security products whose operation relies on its secrecy are useless anyway. The concept of security-by-obscurity has never worked and has been proven wrong many times, e.g. in the NXP Mifare Classic, DECT cipher/authentication, GSM A5 cipher and many other proprietary encryption schemes.

The only thing the Chinese regulators are doing wrong: According to their rules, the information must be disclosed to a closed government panel. Instead, they should require such information to be published publicly, or at least to be released in full detail to all customers of the respective product.