LaForge is currently certified at Master level.

Name: Harald Welte
Member since: 2000-08-20 17:12:09
Last Login: 2016-06-25 11:24:42

FOAF RDF Share This



Please also have a look at


Recent blog entries by LaForge

Syndication: RSS 2.0

34C3 and its Osmocom GSM/UMTS network

At the 34th annual Chaos Communication Congress, a team of Osmocom folks continued the many years old tradition of operating an experimental Osmocom based GSM network at the event. Though I've originally started that tradition, I'm not involved in installation and/or operation of that network, all the credits go to Lynxis, neels, tsaitgaist and the larger team of volunteers surrounding them. My involvement was only to answer the occasional technical question and to look at bugs that show up in the software during operation, and if possible fix them on-site.

34C3 marks two significant changes in terms of its cellular network:

  • the new post-nitb Osmocom stack was used, with OsmoBSC, OsmoMSC and OsmoHLR
  • both an GSM/GPRS network (on 1800 MHz) was operated ,as well as (for the first time) an UMTS network (in the 850 MHz band)

The good news is: The team did great work building this network from scratch, in a new venue, and without relying on people that have significant experience in network operation. Definitely, the team was considerably larger and more distributed than at the time when I was still running that network.

The bad news is: There was a seemingly endless number of bugs that were discovered while operating this network. Some shortcomings were known before, but the extent and number of bugs uncovered all across the stack was quite devastating to me. Sure, at some point from day 2 onwards we had a network that provided [some level of] service, and as far as I've heard, some ~ 23k calls were switched over it. But that was after more than two days of debugging + bug fixing, and we still saw unexplained behavior and crashes later on.

This is such a big surprise as we have put a lot of effort into testing over the last years. This starts from the osmo-gsm-tester software and continuously running test setup, and continues with the osmo-ttcn3-hacks integration tests that mainly I wrote during the last few months. Both us and some of our users have also (successfully!) performed interoperability testing with other vendors' implementations such as MSCs. And last, but not least, the individual Osmocom developers had been using the new post-NITB stack on their personal machines.

So what does this mean?

  • I'm sorry about the sub-standard state of the software and the resulting problems we've experienced in the 34C3 network. The extent of problems surprised me (and I presume everyone else involved)
  • I'm grateful that we've had the opportunity to discover all those bugs, thanks to the GSM team at 34C3, as well as Deutsche Telekom for donating 3 ARFCNs from their spectrum, as well as the German regulatory authority Bundesnetzagentur for providing the experimental license in the 850 MHz spectrum.
  • We need to have even more focus on automatic testing than we had so far. None of the components should be without exhaustive test coverage on at least the most common transactions, including all their failure modes (such as timeouts, rejects, ...)

My preferred method of integration testing has been by using TTCN-3 and Eclipse TITAN to emulate all the interfaces surrounding a single of the Osmocom programs (like OsmoBSC) and then test both valid and invalid transactions. For the BSC, this means emulating MS+BTS on Abis; emulating MSC on A; emulating the MGW, as well as the CTRL and VTY interfaces.

I currently see the following areas in biggest need of integration testing:

  • OsmoHLR (which needs a GSUP implementation in TTCN-3, which I've created on the spot at 34C3) where we e.g. discovered that updates to the subscriber via VTY/CTRL would surprisingly not result in an InsertSubscriberData to VLR+SGSN
  • OsmoMSC, particularly when used with external MNCC handlers, which was so far blocked by the lack of a MNCC implementation in TTCN-3, which I've been working on both on-site and after returning back home.
  • user plane testing for OsmoMGW and other components. We currently only test the control plane (MGCP), but not the actual user plane e.g. on the RTP side between the elements
  • UMTS related testing on OsmoHNBGW, OsmoMSC and OsmoSGSN. We currently have no automatic testing at all in these areas.

Even before 34C3 and the above-mentioned experiences, I concluded that for 2018 we will pursue a test-driven development approach for all new features added by the sysmocom team to the Osmocom code base. The experience with the many issues at 34C3 has just confirmed that approach. In parallel, we will have to improve test coverage on the existing code base, as outlined above. The biggest challenge will of course be to convince our paying customers of this approach, but I see very little alternative if we want to ensure production quality of our cellular stack.

So here we come: 2018, The year of testing.

Syndicated 2017-12-31 23:00:00 from LaForge's home page

Osmocom Review 2017

As 2017 has just concluded, let's have a look at the major events and improvements in the Osmocom Cellular Infrastructure projects (i.e. those projects dealing with building protocol stacks and network elements for mobile network infrastructure.

I've prepared a detailed year 2017 summary at the website, but let me write a bit about the most note-worthy topics here.

NITB Split

Once upon a time, we implemented everything needed to operate a GSM network inside a single process called OsmoNITB. Those days are now gone, and we have separate OsmoBSC, OsmoMSC, OsmoHLR, OsmoSTP processes, which use interfaces that are interoperable with non-Osmocom implementations (which is what some of our users require).

This change is certainly the most significant change in the close-to-10-year history of the project. However, we have tried to make it as non-intrusive as possible, by using default point codes and IP addresses which will make the individual processes magically talk to each other if installed on a single machine.

We've also released a OsmoNITB Migration Guide, as well as our usual set of user manuals in order to help our users.

We'll continue to improve the user experience, to re-introduce some of the features lost in the split, such as the ability to attach names to the subscribers.


We have osmo-gsm-tester together with the two physical setups at the sysmocom office, which continuously run the latest Osmocom components and test an entire matrix of different BTSs, software configurations and modems. However, this tests at super low load, and it tests only signalling so far, not user plane yet. Hence, coverage is limited.

We also have unit tests as part of the 'make check' process, Jenkins based build verification before merging any patches, as well as integration tests for some of the network elements in TTCN-3. This is much more than we had until 2016, but still by far not enough, as we had just seen at the fall-out from the sub-optimal 34C3 event network.


2017 also marks the year where we've for the first time organized a user-oriented event. It was a huge success, and we will for sure have another OsmoCon incarnation in 2018 (most likely in May or June). It will not be back-to-back with the developer conference OsmoDevCon this time.


We have a new SIGTRAN stakc with SUA, M3UA and SCCP as well as OsmoSTP. This has been lacking a long time.


We have converted OpenGGSN into a true member of the Osmocom family, thereby deprecating OpenGGSN which we had earlier adopted and maintained.

Syndicated 2017-12-31 23:00:00 from LaForge's home page

On the Linux Kernel Enforcement Statement

I'm late with covering this here, but work overload is having its toll on my ability to blog.

On October 16th, key Linux Kernel developers have released and anounced the Linux Kernel Community Enforcement Statemnt.

In its actual text, those key kernel developers cover

  • compliance with the reciprocal sharing obligations of GPLv2 is critical and mandatory
  • acknowledgement to the right to enforce
  • expression of interest to ensure that enforcement actions are conducted in a manner beneficial to the larger community
  • a method to provide reinstatement of rights after ceasing a license violation (see below)
  • that legal action is a last resort
  • that after resolving any non-compliance, the formerly incompliant user is welcome to the community

I wholeheartedly agree with those. This should be no surprise as I've been one of the initiators and signatories of the earlier statement of the netfilter project on GPL enforcement.

On the reinstatement of rights

The enforcement statement then specifically expresses the view of the signatories on the specific aspect of the license termination. Particularly in the US, among legal scholars there is a strong opinion that if the rights under the GPLv2 are terminated due to non-compliance, the infringing entity needs an explicit reinstatement of rights from the copyright holder. The enforcement statement now basically states that the signatories believe the rights should automatically be re-instated if the license violation ceases within 30 days of being notified of the license violation

To people like me living in the European (and particularly German) legal framework, this has very little to no implications. It has been the major legal position that any user, even an infringing user can automatically obtain a new license as soon as he no longer violates. He just (really or imaginary) obtains a new copy of the source code, at which time he again gets a new license from the copyright holders, as long as he fulfills the license conditions.

So my personal opinion as a non-legal person active in GPL compliance on the reinstatement statement is that it changes little to nothing regarding the jurisdiction that I operate in. It merely expresses that other developers express their intent and interest to a similar approach in other jurisdictions.

Syndicated 2017-11-06 23:00:00 from LaForge's home page

SFLC sues SFC over trademark infringement

As the Software Freedom Conservancy (SFC) has publicly disclosed on their website, it appears that Software Freedom Law Center (SFLC) has filed for a trademark infringement lawsuit against SFC.

SFLC has launched SFC in 2006, and SFLC has helped and endorsed SFC in the past.

This lawsuit is hard to believe. What has this community come to, if its various members - who used all to be respected equally - start filing law suits against each other?

It's of course not known what kind of negotiations might have happened out-of-court before an actual lawsuit has been filed. Nevertheless, one would have hoped that people are able to talk to each other, and that the mutual respect for working at different aspects and with possibly slightly different strategies would have resulted in a less confrontational approach to resolving any dispute.

To me, this story just looks like there can only be losers on all sides, by far not just limited to the two entities in question.

On some people, including high-ranking members of the FOSS community have started to spread conspiracy theories as to whether there's any secret scheming behind the scenes, particularly from the Linux Foundation towards SFLC to cause trouble towards the SFC and their possibly-not-overly-enjoyed-by-everyone enforcement activities.

I think this is complete rubbish. Neither have I ever had the impression that the LF is completely opposed to license enforcement to begin with, nor do I have remotely enough phantasy to see them engage in such malicious scheming.

What motivates SFLC and/or Eben to attack their former offspring is however unexplainable to the bystander. One hopes there is no connection to his departure from FSF about one year ago, where he served as general counsel for more than two decades.

Syndicated 2017-11-06 23:00:00 from LaForge's home page

Obtaining the local IP address of an unbound UDP socket

Sometimes one is finding an interesting problem and is surprised that there is not a multitude of blog post, stackoverflow answers or the like about it.

A (I think) not so uncommon problem when working with datagram sockets is that you may want to know the local IP address that the OS/kernel chooses when sending a packet to a given destination.

In an unbound UDP socket, you basically send and receive packets with any number of peers from a single socket. When sending a packet to destination Y, you simply pass the destination address/port into the sendto() socket function, and the OS/kernel will figure out which of its local IP addresses will be used for reaching this particular destination.

If you're a dumb host with a single default router, then the answer to that question is simple. But in any reasonably non-trivial use case, your host will have a variety of physical and/or virtual network devices with any number of addresses on them.

Why would you want to know that address? Because maybe you need to encode that address as part of a packet payload. In the current use case that we have, it is the OsmoMGW, implementing the IETF MGCP Media Gateway Control Protocol.

So what can you do? You can actually create a new "trial" socket, not bind it to any specific local address/port, but connect() it to the destination of your IP packets. Then you do a getsockname(), which will give you the local address/port the kernel has selected for this socket. And that's exactly the answer to your question. You can now close the "trial" socket and have learned which local IP address the kernel would use if you were to send a packet to that destination.

At least on Linux, this works. While getsockname() is standard BSD sockets API, I'm not sure how portable it is to use it on a socket that has not been explicitly bound by a prior call to bind().

Syndicated 2017-10-19 22:00:00 from LaForge's home page

322 older entries...


LaForge certified others as follows:

  • LaForge certified Marcus as Master
  • LaForge certified mobius as Journeyer
  • LaForge certified nixnut as Apprentice
  • LaForge certified dria as Master
  • LaForge certified riel as Master
  • LaForge certified alexr as Apprentice
  • LaForge certified rms as Master
  • LaForge certified Fefe as Master
  • LaForge certified andreas as Master
  • LaForge certified manu as Journeyer
  • LaForge certified rgb as Master
  • LaForge certified miguel as Master
  • LaForge certified werner as Master
  • LaForge certified alan as Master
  • LaForge certified Telsa as Journeyer
  • LaForge certified Fleedwood as Journeyer
  • LaForge certified Fyodor as Master
  • LaForge certified jgarzik as Master
  • LaForge certified Nietzsche as Apprentice
  • LaForge certified jes as Master
  • LaForge certified prumpf as Journeyer
  • LaForge certified acme as Journeyer
  • LaForge certified davej as Journeyer
  • LaForge certified marcelo as Master
  • LaForge certified daniels as Apprentice
  • LaForge certified kojima as Master
  • LaForge certified olive as Journeyer
  • LaForge certified lclaudio as Journeyer
  • LaForge certified Ankh as Master
  • LaForge certified claudio as Journeyer
  • LaForge certified niemeyer as Journeyer
  • LaForge certified epx as Journeyer
  • LaForge certified clausen as Journeyer
  • LaForge certified eckes as Journeyer
  • LaForge certified skh as Apprentice
  • LaForge certified etbe as Master
  • LaForge certified jserv as Master

Others have certified LaForge as follows:

  • nixnut certified LaForge as Master
  • Marcus certified LaForge as Master
  • manu certified LaForge as Master
  • rw2 certified LaForge as Journeyer
  • jbowman certified LaForge as Journeyer
  • ErikLevy certified LaForge as Journeyer
  • alexr certified LaForge as Journeyer
  • davej certified LaForge as Journeyer
  • acme certified LaForge as Journeyer
  • andika certified LaForge as Journeyer
  • riel certified LaForge as Master
  • daniels certified LaForge as Master
  • jLoki certified LaForge as Journeyer
  • Fefe certified LaForge as Master
  • claudio certified LaForge as Master
  • adulau certified LaForge as Master
  • morcego certified LaForge as Master
  • maragato certified LaForge as Master
  • alan certified LaForge as Journeyer
  • bruder certified LaForge as Master
  • baretta certified LaForge as Master
  • rmk certified LaForge as Journeyer
  • webseeker certified LaForge as Master
  • olive certified LaForge as Master
  • eliphas certified LaForge as Master
  • Senra certified LaForge as Master
  • minami certified LaForge as Master
  • fbl certified LaForge as Master
  • niemeyer certified LaForge as Master
  • skh certified LaForge as Master
  • hubertf certified LaForge as Master
  • dwmw2 certified LaForge as Master
  • ruda certified LaForge as Master
  • sqlguru certified LaForge as Master
  • jnewbigin certified LaForge as Master
  • rainer certified LaForge as Master
  • ittner certified LaForge as Master
  • lmvaz certified LaForge as Master
  • ld certified LaForge as Master
  • chalst certified LaForge as Master
  • redi certified LaForge as Master
  • faw certified LaForge as Master
  • dangermaus certified LaForge as Master

[ Certification disabled because you're not logged in. ]

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!

Share this page