Older blog entries for LaForge (starting at number 161)

Linux Beer, anyone?

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

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

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

Syndicated 2011-04-04 02:00:00 from Harald Welte's blog

Deutsche Telekom tried to register a trademark on netfilter

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

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

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

Syndicated 2011-04-04 02:00:00 from Harald Welte's blog

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

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

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

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

Syndicated 2011-03-27 01:00:00 from Harald Welte's blog

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

Yes, I'm not kidding!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Syndicated 2011-03-26 01:00:00 from Harald Welte's blog

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

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

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

Syndicated 2011-03-11 01:00:00 from Harald Welte's blog

Starting to experiment with Anritsu MD8470A signalling generator

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

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

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

Syndicated 2011-02-18 01:00:00 from Harald Welte's blog

Struggling with adding Ericsson RBS support to OpenBSC

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

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

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

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

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

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

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

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

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

Syndicated 2011-02-13 01:00:00 from Harald Welte's blog

Heading for a business trip to Nairobi/Kenya

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

Syndicated 2011-01-22 01:00:00 from Harald Welte's blog

Public release of Osmocom TETRA code

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

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

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

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

Syndicated 2011-01-22 01:00:00 from Harald Welte's blog

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

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

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

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

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

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

Syndicated 2011-01-15 01:00:00 from Harald Welte's blog

152 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!