shop for SIMtrace

shop for SIMtrace

The WebShop for the SIMtrace hardware can be found here. We are using a CA-Cert signed SSL certificate and your browser vendor might not like it.

Setting up, or mostly modifying the webshop was my first encounter with rails. In some ways it is a great framework, in others with a Smalltalk background there are some tears in my eyes. This is using spreecommerce because I wanted something that is not done in PHP and is not following the OpenCore business model.

The manual of spreecommerce is actually great from an engineering point of view, they describe the concepts, the models and how to modify it. But they are bit short on setting it up. There are some config options where no Graphical way to change them exists yet. So it is best to look into the app_configuration.rb of spree_core, e.g. to modify the default country.

There are still some bits that I would like to change, the code for my modification can be found on gitorious.

Going down the Sangoma rabbit hole

Going down the Sangoma rabbit hole

I ended up needing to configure FreeSWITCH to use a Sangoma ISDN card. At first we were foolish and used the setup script to install libraries into our system.

Cleaning up

It took dpkg -S and manual filtering to clean this mess. On a debian system there are files in /usr/ that do not belong to packages, these can be links to /etc/alternatives, or in case of python be bytecode files (*.pyc).

Second attempt with building packages

The next attempt was to use checkinstall -D make install but the source distribution of wanpipe is such a mess that checkinstall refuses to work, I have created a handmade debian package with some split up. The most annoying issues are the installation of .svn, .deps, .libs directories, using /etc/wanpipe for examples and firmware (they belong somewhere else), also installing the package requires to overwrite files of other packages (Linux comes with a wanrouter.ko too). There also appears to be some fishy licensing part, the source distribution is shipping with some .o files, the module claims to be GPL though.

First attempt with FreeSWITCH

FreeSWITCH allows to build debian packages out of the box, and it worked, it also built the freetdm module. But my module was missing support for wanpipe, adding the wanpipe-dev, rebuilding fixed the problem.

Second attempt with FreeSWITCH

After configuring the ISDN card using the wancfg_fs utility (and not allowing it to mess with the free switch config, as it is breaking it), I saw the cards but I was missing a library to actually use the card for Voice Calls.

ISDN libraries

I needed to get the libsng-isdn library, of course without sourcecode, also without a LICENSE file at all. Who may use this library? Under which circumstances? I started with checkinstall but this does not handle shlib providers very well, so I had to package the library myself

Third attempt with FreeSWITCH

I was able to recompile the FreeTDM module, and I could configure the ISDN trunk and use the the fs_cli to orginate a call.

Summary

FreeSWITCH and FreeTDM are quite powerful, also having support for creating debian packages is great too. The Sangoma experience is less exciting.

Playing with a MSC over the A-link

Playing with a MSC over the A-link

One of the benefits of having a dynamic language like Smalltalk is that it becomes easier to experiment. For one of my current projects I am dealing with some simple USSD message handling and want to see how much load my application and the backend system can handle. Using the Smalltalk TestPhone this becomes quite easy.

The first thing I do is to make up an Identity. This includes the IMSI and the AuKey (e.g. COMPv1 as found in libosmocore) and the next is to establish the A-link to the MSC.

> phoneConfig := PhoneConfig new.
> phoneConfig imsi: ‘XXXX…’ auKeyv1: ‘AAAAAAA’.
> (server := IPAConfig new addr: ‘A.B.C.D’ port: 5000) connect serve.

The next part is to do ‘procedures’ (SCCP connections with a specific goal). Right now there is an implementation of the LU Procedure, the beginning of Call Control (no way to hang up or such) and and sending some bits of USSD (processUnstructuredData Request). To warm up I can execute a simple USSD query. The below code will wait until the operation has completed, it could also print out if it was considered a success or a failure.

> (server doUSSD: phoneConfig nr: ‘**1234#’) execute

Now to produce load I can repeat this, or create multiple processes. In the below code I am going to create four processes that each will do the query 100 times.

> 4 timesRepeat: [:time |
[
100 timesRepeat: [:each | (server doUSSD: phoneConfig nr: ‘**1234#’) execute]
] fork.

Another thing missing is to add a timeout on each of these operations, e.g. if the MSC does not answer fast enough or such but I will blog about transactions and dealing with time-outs in another blog.

Wireshark dissector for TETRA

Wireshark dissector for TETRA

The Professional Mobile Communication Research Group of Beijing Institute of Technology (BIT) was kind enough to send us their TETRA Wireshark dissector. They went through the specification and created ASN1 files out of the tables, I helped with the integration and cleaning to get the code into wireshark and the wireshark developers were kind enough to do a fast review and the code is now merged.

The next part is to extend the GSMTAP dissector to pass on the tetra bits to the TETRA decoder, I have already written the code, now I need to get it merged into the wireshark codebase too.

My TETRA agenda includes figuring out majority logic decision decoding with syndromes which is required for the shorted Reed Muller code used in the AACH, create a proper GNU Radio block for the decoder emitting soft bits that we can feed into our viterbi decoder… maybe I will manage to do this during my vacation in Taiwan… who knows.

Cleaning up the cellmgr_ng and turning it into a MGW/STP

Cleaning up the cellmgr_ng and turning it into a MGW/STP

One year ago I was starting the on the BSC NAT application from a Hotel room in Munich, I was flying from Taiwan to Munich and was happy to see the snow from my window. Shortly after this I began to implement something we called cellmgr_ng. The job was to take MTPLevel3 coming out of a library and put the SCCP payload into the IPA protocol and send it to a MSC. As part of MTP Level3 I had to implement the link bring up and such as well (once again without having too much time to read all the specs).

The problems were as most of the times not the ones one would expect. The system behind the E1/T1 link was sending wrong SCCP messages, when a SCCP connection was not closed fast enough it would send out its own release message but was confused about the source local and destination local addresses. As a result I had to add connection tracking to the codebase, I am also rewriting/removing Point Codes to avoid crashes and make the MSC happy.

Last month and this month I had the pleasure to resume the work on this. My knowledge of MTPL3 is at least a bit bigger now, we have done the libosmocore split so I can use more features without copying code around and there was new demand.

The first big thing is to support a LinkSet with multiple Links in it. This allowed me to do a lot of cleanups, some are still to do but now the abstraction is a lot better and I will do testing and force link failures and see how the system is behaving. This will also end with VTY commands to manage links via the telnet interface, more statistics collected and reported, being able to start writing PCAP files for the linksets from the VTY command.

The second big feature is the addition of M2UA to the codebase. The code does not support fail over scenario’s yet but this should be relatively easy to add inside the structure now.

The result is that we now have something that could be used as a MediaGateway and convert MTPL2/MTPL3/{SCCP,ISUP} into SCTP/M2UA/MTPL3{SCCP,ISUP} and convert the audio to and from RTP, the other part is a Signalling Transfer Point (STP) with some basic capabilities.

Using systemtap userspace tracing…

Using systemtap userspace tracing…

At the 27C3 we were running a GSM network and during the preparation I noticed a strange performance problem coming from the database library we are using running. I filled our database with some dummy data and created a file with the queries we normally run and executed time cat queries | sqlite3 file as a mini benchmark. I also hacked this code into our main routine and ran it with time as well. For some reason the code running through the database library was five times slower.

I was a bit puzzled and I decided to use systemtap to explore this to build a hypothesis and to also have the tools to answer the hypothesis. I wanted to find out if if it is slow because our database library is doing some heavy work in the implementation, or because we execute a lot more queries behind the back. I was creating the below probe:

probe process(“/usr/lib/libsqlite3.so.0.8.6”).function(“sqlite3_get_table”)
{
a = user_string($zSql);
printf(“sqlite3_get_table called ‘%s’n”, a);
}

This probe will be executed whenever the sqlite3_get_table function of the mentioned library will be called. The $zSql is a variable passed to the sqlite3_get_table function and contains the query to be executed. I am converting the pointer to a local variable and then can print it. Using this simple probe helped me to see which queries were executed by the database library and helped me to do an easy optimisation.

In general it could be very useful to build a set of probes (I think one calls set a tapset) that check for API misusage, e.g. calling functions with certain parameters where something else might be better. E.g. in Glib use truncate instead of assigning “” to the GString, or check for calls to QString::fromUtf16 coming from Qt code itself. On second thought this might be better as a GCC plugin, or both.

GSM in Smalltalk – a GSM Toolkit

GSM in Smalltalk – a GSM Toolkit

I started to play with smalltalk somewhere in February, more specific with the GNU Smalltalk implementation. Like it is with any new language and class library it takes a while to get productive and it took me until somewhere the last month where I finally started to do GSM handling in Smalltalk and thanks to laf0rge the code is now in a public repository and hosted along the other Osmocom projects. You can see all the subprojects over here.

So far I can create and parse the ipaccess IPA protocol, SCCP, BSSAP, BSSMAP and messages for Call Control and Mobility Management of GSM48. I also have a small Web-UI to connect to a MSC and then do a Location Updating Request and a Mobile Originated Call for a configurable IMSI (you will need to know your AuKey for that). It is very easy to parse and create the whole stack of messages, adding new GSM48 messages is easy as well (i still consider writing a program to get this directly from the GSM48 PDF).

This code is probably very well suited to do load tests of a MSC, e.g. find out how many LUs it can do a second, also to play easily with various quirks with it. Thanks to the nature of smalltalk one can easily change the creation of messages at runtime without needing to reconnect to the MSC. The next thing would probably to use it for fuzzing a MSC…

One note of caution, it is my first Smalltalk project and there are probably plenty of things I do wrong, I already know some of them and will work on refactoring it to a better structure. The next stop is nice ASN1 support, I will base it on the LDAP work.

osmo-bsc in OpenBSC master

osmo-bsc in OpenBSC master

A small service announcement. The bsc_msc_ip from on-waves/bsc-master is now dead and one can use osmo-bsc from master. It has the same functionality but is implemented in a cleaner way making it more easily extandable.
The biggest benefit of a open/free BSC equipment is the flexibility. If your network is a bit different to what people have thought out 30 years ago, you are now in the position to easily change that. E.g. your BSC could have different MSC connections and send different subscribers to different MSCs.
I am going to work on some new BSC features as well. With the new internal BSC API it should be possible to have different call routing based on some criteria, implement IMSI access control on the BSC, provide CBS services…
Searching for Cell Broadcast

Searching for Cell Broadcast

Is there someone that can provide me with a trace with Cell Broadcast Services on the Abis link? I am not really figuring out what should be provided to the BTS… I assume that the nanoBTS takes care of scheduling the message and one provides one big message instead of the four separate things?

Please comment, drop me an email or such.
OpenBSC updates

OpenBSC updates

I am almost back from a trip to iceland, I was fortunate enough to focus exclusively on GSM. In the last week I have continued to build osmo-bsc (a true BSC based on code from the on-waves/bsc-master) branch, I have worked on the NAT to make the IMSI filtering more useful and to add (hardware) transcoding to the MGCP MGW. The NAT changes are already in production, the transcoding will follow soon.

IMSI filtering in the NAT/MUX. There is the use case that in certain areas IMSIs are not allowed that are normally allowed in your network (e.g. on a test cell, only allow test IMSIs). Now in general the first message (GSM0808 Complete Layer3 Information) should carry the T-MSI/IMSI and a NAT/MUX could filter based on this message (which I did). The reality is a bit different, in the case of a Location Updating Request most phones send you the TMSI of a different network, in that case the NAT/MUX will need to inspect every message until the real IMSI and TMSI (TMSI reallocation) is revealed and then apply the filter. I have added this part to the NAT and it appears to be working. While doing this we also encountered a crasher that was hiding and only happens on unreliable networks (e.g. not during unit testing).
For the last days I was working on a funny real life issue. In our case certain connections have an adaptive bandwidth. E.g. when a voice call is setup we will only slowly get the bandwidth we need. This means that on the first couple of RTP packets we will have a huge jitter. Now luckily we are using a proprietary MGW that puts out press releases of their field proven Jitter Buffer technology… which means that money was spend on PR instead of making it work and we had to run the audio through a different hardware based decoder/encoder to really handle the jitter. In the next couple of weeks we are hopefully able to replace this MGW with our own.