January 31, 2016
In the recent FOSDEM 2016 SDR Devroom, the
Q&A session following a presentation on OpenAirInterface touched the topic of its
controversial licensing. As I happen to be involved deeply with Free
Software licensing and Free Software telecom topics, I thought I might
have some things to say about this topic. Unfortunately the Q&A session
was short, hence this blog post.
As a side note, the presentation was actually certainly the least
technical presentation in all of the FOSDEM SDR track, and that with a
deeply technical audience. And probably the only presentation at all at
FOSDEM talking a lot about "Strategic Industry Partners".
Let me also state that I actually have respect for what OAI/OSA has been
and still is doing. I just don't think it is attractive to the Free
Software community - and it might actually not be Free Software at all.
OpenAirInterface / History
Within EURECOM, a group around Prof.
Raymond Knopp has been working on a Free Software implementation of all
layers of the LTE (4G) system known as OpenAirInterface. It includes the physical layer
and goes through to the core network.
The OpenAirInterface code was for many years under GPL license (GPLv2,
other parts GPLv3). Initially the SVN repositories were not public
(despite the license), but after some friendly mails one (at least I)
could get access.
I've read through the code at several points in the past, it often
seemed much more like a (quick and dirty?) proof of concept
implementation to me, than anything more general-purpose. But then,
that might have been a wrong impression on my behalf, or it might be
that this was simply sufficient for the kind of research they wanted to
do. After all, scientific research and FOSS often have a complicated
relationship. Researchers naturally have their papers as primary output
of their work, and software implementations often are more like a
necessary evil than the actual goal. But then, I digress.
Now at some point in 2014, a new organization the OpenAirInterface
Software Association (OSA) was established. The idea apparently was to
get involved with the tier-1 telecom suppliers (like Alcatel, Huawei,
Ericsson, ...) and work together on an implementation of Free Software
for future mobile data, so-called 5G technologies.
The existing GPLv2/GPLv3 license of the OpenAirInterface code of course
would have meant that contributions from the patent-holding telecom
industry would have to come with appropriate royalty-free patent
licenses. After all, of what use is it if the software is free in terms
of copyright licensing, but then you still have the patents that make it
Now the big industry of course wouldn't want to do that, so the OSA
decided to re-license the code-base under a new license.
As we apparently don't yet have sufficient existing Free Software
licenses, they decided to create a new license. That new license (the
OSA Public License V1.0
not only does away with copyleft, but also does away with a normal
This is very sad in several ways:
- license proliferation is always bad. Major experts and basically all
major entities in the Free Software world (FSF, FSFE, OSI, ...) are
opposed to it and see it as a problem. Even companies like Intel and
Google have publicly raised concern about license Proliferation.
- abandoning copyleft. Many people particularly from a GNU/Linux
background would agree that copyleft is a fair deal. It ensures that
everyone modifying the software will have to share such modifications
with other users in a fair way. Nobody can create proprietary
- taking away the patent grant. Even the non-copyleft Apache 2.0
License the OSA used as template has a broad patent grant, even for
commercial applications. The OSA Public License has only a patent
grant for use in research context
In addition to this license change, the OSA also requires a copyright
assignment from all contributors.
What kind of effect does this have in case I want to contribute?
- I have to sign away my copyright. The OSA can at any given point
in time grant anyone whatever license they want to this code.
- I have to agree to a permissive license without copyleft, i.e.
everyone else can create proprietary derivatives of my work
- I do not even get a patent grant from the other contributors (like
the large Telecom companies).
So basically, I have to sign away my copyright, and I get nothing in
return. No copyleft that ensures other people's modifications will be
available under the same license, no patent grant, and I don't even keep
my own copyright to be able to veto any future license changes.
My personal opinion (and apparently those of other FOSDEM attendees) is
thus that the OAI / OSA invitation to contributions from the community
is not a very attractive one. It might all be well and fine for large
industry and research institutes. But I don't think the Free Software
community has much to gain in all of this.
Now OSA will claim that the above is not true, and that all contributors
(including the Telecom vendors) have agreed to license their patents
under FRAND conditions to all other contributors. It even seemed to me
that the speaker at FOSDEM believed this was something positive in any
way. I can only laugh at that ;)
FRAND (Fair, Reasonable and Non-Discriminatory) is a frequently invoked
buzzword for patent licensing schemes. It isn't actually defined
anywhere, and is most likely just meant to sound nice to people who
don't understand what it really means. Like, let's say, political
In practise, it is a disaster for individuals and small/medium sized
companies. I can tell you first hand from having tried to obtain patent
licenses from FRAND schemes before. While they might have reasonable
per-unit royalties and they might offer those royalties to everyone,
they typically come with ridiculous minimum annual fees.
For example let's say they state in their FRAND license conditions you
have to pay 1 USD per device, but a minimum of USD 100,000 per year. Or
a similarly large one-time fee at the time of signing the contract.
That's of course very fair to the large corporations, but it makes it
impossible for a small company who sells maybe 10 to 100 devices per
year, as the 100,000 / 10 then equals to USD 10k per device in terms of
royalties. Does that sound fair and Non-Discriminatory to you?
OAI/OSA are trying to get a non-commercial / research-oriented foot into
the design and specification process of future mobile telecom network
standardization. That's a big and difficult challenge.
However, the decisions they have taken in terms of licensing show that
they are primarily interested in aligning with the large corporate
telecom industry, and have thus created something that isn't really Free
Software (missing non-research patent grant) and might in the end only
help the large telecom vendors to uni-directionally consume
contributions from academic research, small/medium sized companies and
In the good tradition about writing a blog post on my way back from a FOSDEM (see earlier installments e.g. for 2012, 2010, 2008, and 2007), here is this year’s take.
No issues with transportation this time (I’m still in the train, but it looks good so far), other than road construction works at the venue, which itself seems to establish a tradition now
This year I stayed in the Be Manos hotel – near to Gare du Midi – which was quite nice. Since I find myself being too old for the pre-FOSDEM beer event, I did not attend it. I had my share of Leffe Bruin (my favorite belgium beer) in the hotel lobby though.
The temperature was around +8°, much better than FROZDEM 2012, where it had -20°.
I saw 5 presentations, 4 of those which were quite good. That’s a better ratio than in previous years. My favorite talk was given by Carsten ‚Rasterman‘ Heitzler, an ex-Openmoko colleague who is now working for SAMSUNG on Tizen’s graphical subsystems (EFL-based).
Most important though were the people I met, a lot of old and new friends, in particular Phil Blundell, Harald Welte, Daniel Willmann, Jan Lübbe, Marcin ‚HRW‘ J., Paul Espin, Florian Boor, and many more. Seeing all of you alive and kicking gave me a lot of positive energy!
I’m returning excited and with many mental notes of things to check out and the motivation to make a major contribution to at least one open project this year. See you all soon!
Der Beitrag Coming back from FOSDEM 2016 erschien zuerst auf Vanille.de.
January 18, 2016
Imagine you run a GSM network and you have multiple systems at the edge of your network that communicate with other systems. For debugging reasons you might want to collect traffic and then look at it to explore an issue or look at it systematically to improve your network, your roaming traffic, etc.
The first approach might be to run tcpdump on each of these systems, run it in a round-robin manner, compress the old traffic and then have a script that downloads/uploads it once a day to a central place. The issue is that each node needs to have enough disk space, you might not feel happy to keep old files on the edge or you just don't know when is a good time to copy it.
Another approach is to create an aggregation framework. A client will use libpcap to capture the traffic and then redirect it to a central server. The central server will then store the traffic and might rotate based on size or age of the file. Old files can then be compressed and removed.
I created the osmo-pcap tool many years ago and have recently fixed a 64bit PCAP header issue (the timeval in the header is 32bit), collection of jumbo frames and now updated the README.md
file of the project and created packages for Debian, Ubuntu, CentOS, OpenSUSE, SLES and I made sure that it can be compiled and use on FreeBSD10 as well.
If you are using or decided not to use this software I would be very happy to hear about it.
January 03, 2016
While I was still active in the Linux kernel development / network
security field, I was regularly attending 10 to 15 conferences per year.
Doing so is relatively easy if you earn a decent freelancer salary and
are working all by yourself. Running a company funded out of your own
pockets, with many issues requiring (or at least benefiting) from
personal physical presence in the office changes that.
Nevertheless, after some years of being less of a conference speaker,
I'm happy to see that the tide is somewhat changing in 2016.
After my talk at 32C3, I'm looking forward to attending (and sometimes
speaking) at events in the first quarter of 2016. Not sure if I can
keep up that pace in the following quarters...
FOSDEM (http://fosdem.org/2016) a classic, and I don't even remember for
how many years I've been attending it. I would say it is fair to state
it is the single largest event specifically by and for
community-oriented free software developers. Feels like home every
netdevconf (http://www.netdevconf.org/1.1/) is actually something I'm
really looking forward to. A relatively new grass-roots conference.
Deeply technical, and only oriented towards Linux networking hackers.
The part of the kernel community that I've known and loved during my old
I'm very happy to attend the event, both for its technical content, and
of course to meet old friends like Jozsef, Pablo, etc. I also read that
Kuninhiro Ishiguro will be there. I always adored his initial work on
Zebra (whose vty code we coincidentally use in almost all osmocom
projects as part of libosmovty).
It's great to again see an event that is not driven by commercial /
professional conference organizers, high registration fees, and
corporate interests. Reminds me of the good old days where Linux was
still the underdog and not mainstream... Think of Linuxtag in its early
I'll be attending Linaro Connect for the first time in many years. It's
a pity that one cannot run various open source telecom protocol stack /
network element projects and a company and at the same time still be
involved deeply in Embedded Linux kernel/system development. So I'll
use the opportunity to get some view into that field again - and of
course meet old friends.
OsmoDevCon is our annual invitation-only developer meeting of the
Osmocom developers. It's very low-profile, basically a no-frills family
meeting of the Osmocom community. But really great to meet with all of
the team and hearing about their respective experiences / special
is another invitation-only event, organized by the makers of the
TROOPERS conference. The idea is to make folks from the classic Telco
industry meet with people in IT Security who are looking at Telco related
topics. I've been there some years ago, and will finally be able to
make it again this year to talk about how the current introduction of
3G/3.5G into the Osmocom network side elements can be used for security
Some Free Software projects have already moved to Github, some probably plan it and the Python project will move soon
. I have not followed the reasons for why the Python project is moving but there is a long list of reasons to move to a platform like github.com. They seem to have a good uptime, offer checkouts through ssh, git, http (good for corporate firewalls) and a subversion interface, they have integrated wiki and ticket management, the fork feature allows an upstream to discover what is being done to the software, the pull requests and the integration with third party providers is great. The last item allows many nice things, specially integrating with a ton of Continuous Integration tools (Travis, Semaphore, Circle, who knows).
From a freedom point of view I think Gitlab is a lot worse than Github. They try to create the illusion that this is a Free Software alternative to Github.com, they offer to host your project but if you want to have the same features for self hosting you will notice that you fell for their marketing. Their website prominently states "Runs GitLab Enterprise" Edition. If you have a look at the feature comparison
between the "Community Edition" (the Free Software project) and their open core additions (Enterprise edition) you will notice that many of the extra features are essential.
So when deciding putting your project on github.com or gitlab.com the question is not between proprietary and Free Software but essentially between proprietary and proprietary and as such there is no difference.
December 30, 2015
The 32C3 GSM Network
32C3 was great from the Osmocom perspective: We could again run our own
cellular network at the event in order to perform load testing with real
users. We had 7 BTSs running, each with a single TRX. What was new
compared to previous years:
- OsmoPCU is significantly more robust and stable due to the efforts of
Jacob Erlbeck at sysmocom. This means that GPRS is now actually still
usable in severe overload situations, like 1000 subscribers sharing
only very few kilobits. Of course it will be slow, but at least data
still passes through as much as that's possible.
- We were using half-rate traffic channels from day 2 onwards, in order
to enhance capacity. Phones supporting AMR-HR would use that, but
then there are lots of old phones that only do classic HR (v1).
OsmoNITB with internal MNCC handler supports TCH/H with HR and AMR for
at least five years, but the particular combination of OsmoBTS +
OsmoNITB + lcr (all master branches) was not yet deployed at previous
CCC event networks so far.
Being forced to provide classic HR codec actually revealed several bugs
in the existing code:
- OsmoBTS (at least with the sysmoBTS hardware) is using bit ordering
that is not compliant to what the spec says on how GSM-HR frames
should be put into RTP frames. We didn't realize this so far, as
handing frames from one sysmoBTS to another sysmoBTS of course works,
as both use the same (wrong) bit ordering.
- The ETSI reference implementation of the HR codec has lots of
global/static variables, and thus doesn't really support running
multiple transcoders in parallel. This is however what lcr was trying
(and needing) to do, and it of course failed as state from one
transcoder instance was leaking into another. The problem is simple,
but the solution not so simple. If you want to avoid re-structuring
the entire code in very intrusive ways or running one thread per
transcoder instance, then the only solution was to basically memcpy()
the entire data section of the transcoding library every time you
switch the state from one transcoder instance to the other. It's
surprisingly difficult to learn the start + size of that data section
at runtime in a portable way, though.
Thanks to our resident voice codec expert Sylvain for debugging and
fixing the above two problems.
Thanks also to Daniel and Ulli for taking care of the actual logistics
of bringing + installing (+ later unmounting) all associated equipment.
Thanks furthermore to Kevin who has been patiently handling the 'Level 2
Support' cases of people with various problems ending up in the GSM
It's great that there is a team taking care of those real-world test
networks. We learn a lot more about our software under heavy load
situations this way.
osmo-iuh progress + talk
I've been focussing basically full day (and night) over the week ahead
of Christmas and during Christmas to bring the osmo-iuh code into a
state where we could do a end-to-end demo with a regular phone + hNodeB
+ osmo-hnbgw + osmo-sgsn + openggsn. Unfortunately I only got it up to
the point where we do the PDP CONTEXT ACTIVATION on the signalling
plane, with no actual user data going back and forth. And then, for
strange reasons, I couldn't even demo that at the end of the talk.
Well, in either case, the code has made much progress.
The video of the talk can be found at
The annual CCC congress is always an event where you meet old friends
and colleagues. It was great talking to Stefan, Dimitri, Kevin, Nico,
Sylvain, Jochen, Sec, Schneider, bunnie and many other hackers. After
the event is over, I wish I could continue working together with all
those folks the rest of the year, too :/
Some people have been missed dearly. Absence from the CCC congress is
not acceptable. You know who you are, if you're reading this ;)
December 28, 2015
The classic question in IT is to buy something existing or to build it from scratch. When wanting to buy an off the shelves HLR (that actually works) in most cases the customer will end up in a vendor lock-in:
- The vendor might enforce to run on a hardware sold by your vendor. This might just be a dell box with a custom front, or really custom hardware in a custom chasis or even requiring you to put an entire rack. Either way you are trapped to a single supplier.
- It might come with a yearly license (or support fee) and on top of that might be dongled so after a reboot, the service might not start as the new license key has not been copied.
- The system might not export a configuration interface for what you want. Specially small MVNOs might have specific needs for roaming steering, multi IMSI and you will be sure to pay a premium for these features (even if they are off the shelves extensions).
- There might be a design flaw in the protocol and you would like to mitigate but the vendor will try to charge a premium from you because the vendor can.
The alternative is to build a component from scratch and the initial progress will be great as the technology is more manageable than many years ago. You will test against the live SS7 network, maybe even encode messages by hand and things appear to work but only then the fun will start. How big is your test suite? Do you have tests for ITU Q787? How will you do load-balancing, database failover? How do you track failures and performance? For many engineering companies this is a bit over their head (one needs to know GSM MAP, need to know ITU SCCP, SIGTRAN, ASN1, TCAP).
But there is a third way and it is available today. Look for a Free Software HLR
and give it a try. Check which features are missing and which you want and develop them yourself or ask a company like sysmocom
to implement them for you. Once you move the system into production maybe find a support agreement that allows the company to continuously improve the software and responds to you quickly. The benefits for anyone looking for a HLR are obvious:
- You can run the component on any Linux/FreeBSD system. On physical hardware, on virtualized hardware, together with other services, not with other services. You decide.
- The software will always be yours. Once you have a running system, there will be nothing (besides time_t overflowing) that has been designed to fail (no license key expires)
- Independence of a single supplier. You can build a local team to maintain the software, you can find another supplier to maintain it.
- Built for change. Having access to the source code enables you to modify it, with a Free Software license you are allowed to run your modified versions as well.
The only danger is to make sure to not fall in the OpenCore trap surrounded by many OpenSource projects. Make sure that all you need is available in source and allows you to run modified copies.
December 27, 2015
‚Tis the season to let the year pass by and make plans for the next one. 2015 was what I’d call a „transitioning“ year. Although LaTe App-Developers had been shut down in 2014, we still had to spend most of 2015 to work on some things our clients already paid for. This is now finally done and I can move forward looking for new endeavors. Here’s a bunch of my plans for 2016:
First off, I’ll attempt to bring three iOS-apps in the AppStore. These apps will be completely new versions of those that I did while working with my colleague at LaTe, in particular it’s going to be a radio station app, a guitar songbook, and a matching game for kids:
- The radio station app will be the successor to the popular „Volksradio“ App, with a clear focus on streamlining (i.e. only a bare minimum of features, but those supersolid) and social recommendations („listeners who enjoyed ‚Space Station Soma‘ also liked ‚Chillout Radio‘).
- The guitar songbook app will be the successor to the „Chord Pro Songbook“ app, with the focus on collection ’sets‘ (a number of titles to perform at a given time) and ‚alternates‘ (variants of songs). My dream would be to incorporate a great edit function (to create new transcriptions right on your device), but I’m not sure whether this will make it.
- The matching game will be the successor to the „Match and Learn“ app. This one hasn’t been updated for ages, I have new animals and plan to add a better gameplay as well as incorporate support for new devices.
I also have started working on ‚retro player‘, an app that will be the successor to SidPlayer, Module Player, and PokeyPlayer — I have mentioned this in an earlier installment of this blog. This one is going to be huge and I plan a crowdfunding campaign later in 2016 to make it happen. Note that the campaign will not be launched until the product is in a stage where it is sure that it can be completed. I’m not going to make this mistake — something that has annoyed me this year as a contributor to some projects.
Next to this iOS-related work, over the last year I have seriously reinvested time (and money) into my music again. In 2016 I’m going to publish some new material, consisting of rearranged and enhanced versions of some of my ancient AMIGA MODs (see http://www.vanille.de/mickey/my-amiga-history/), but also completely new compositions. It looks like my writer’s block has vanished and after roughly 15 years of sucking on my thumb, I started recording new stuff. Isn’t that exciting?
Professionally, there will be some iOS work, but hopefully also architectures with a broader scope. I really want to do more Python and distributed middleware again. I’m not so sure on Vala (one of my other favorite programming languages) though. This language has flourished between 2008 and 2012 and sadly I’m afraid it’s not going anywhere anymore. There’s little activity on the mailing list, the original author has moved on, and there is not enough fresh blood. Very sad, but given that state, it looks like my half-done book on Vala will not see the light of day.
That’s about everything I think of at the moment. I wish all of you a great healthy and successful 2016, may we manage to make the world a bit more peaceful (although I have my doubts). All the best to you! Yours truly,
Der Beitrag Towards the end of 2015 erschien zuerst auf Vanille.de.
December 05, 2015
Back when Openmoko took the fall, we donated the Openmoko, Inc. USB
Vendor ID to the community and started the registry of free Product ID
allocations at http://wiki.openmoko.org/wiki/USB_Product_IDs
Given my many other involvements and constant overload, I've been doing a
poor job at maintaining it, i.e. handling incoming requests.
So I'm looking for somebody who can reliably take care of it, including
- reviewing if the project fulfills the criteria (hardware or software
already released under FOSS license)
- entering new allocations to the wiki
- informing applicants of their allocation
The amount of work is actually not that much (like one mail per week), but
it needs somebody to reliably respond to the requests in a shorter time
frame than I can currently do.
Please let me know if you'd like to volunteer.
Sylvain brought this up yesterday: Wouldn't it be nice to have some
degree of SMS interfacing from OpenBSC/OsmoNITB to the real world at
32C3? It is something that we've never tried so far, and thus
definitely worthy of testing.
Of course, full interworking is not possible without assigning public
MSISDN to all internal subscribers / 'extensions' how we call them.
But what would most certainly work is to have at least outbound SMS
working by means of an external SMPP interface.
The OsmoNITB-internal SMSC speaks SMPP already (in the SMSC role), so we
would need to implement some small amount of glue logic that behaves as
ESME (external SMS entity) towards both OsmoNITB as well as some
public SMS operator/reseller that speaks SMPP again.
Now of course, sending SMS to public operators doesn't come for free.
So in case anyone reading this has access to SMPP at public operators,
resellers, SMS hubs, it would be interesting to see if there is a chance
for some funding/sponsoring of that experiment.
Feel free to contact me if you see a way to make this happen.
December 04, 2015
Since 2012 we have support for SMPP in OsmoNITB (the network-in-the-box
version of OpenBSC). So far I've only used it from C and Erlang code.
Yesterday I gave python-smpplib from
https://github.com/podshumok/python-smpplib a try and it worked like a
charm. Of course one has to get the details right (like numbering plan
In case anyone is interested in interfacing OsmoNITB SMPP from python,
I've put a working example to send SMS at http://cgit.osmocom.org/mncc-python/tree/smpp_test.py
December 01, 2015
I've been working on a small python tool that can be used to attach to
the MNCC interface of OsmoNITB. It implements the 04.08 CC state
machine with our MNCC primitives, including support for RTP bridge mode
of the voice streams.
The immediate first use case for this was to be able to generate MT
calls to a set of known MSISDNs and load all 14 TCH/H channels of a
single-TRX BTS. It will connect the MT calls in pairs, so you end up
with 7 MS-to-MS calls.
The first working version of the tool is available from
The code is pretty hacky in some places. That's partially due to the
fact that I'm much more familiar in the C, Perl and Erlang world than in
python. Still I thought it's a good idea to do it in python to enable
more people to use/edit/contribute to it.
I'm happy for review / cleanup suggestion by people with more Python-foo
than I have.
Architecturally, I decided to do things a bit erlang-like, where we have
finite state machines in an actor models, and message passing between
the actors. This is what happens with the GsmCallFsm()'s, which are
created by the GsmCallConnector() representing both legs of a call and
the MnccActor() that wraps the MNCC socket towards OsmoNITB.
The actual encoding/decoding of MNCC messages is auto-generated from the
mncc header file #defines, enums and c-structures by means of ctypes
mncc_test.py currently drops you into a python shell where you can e.g.
start more / new calls by calling functions like connect_call("7839",
"3802") from that shell. Exiting the shell by quit() or Ctrl+C
will terminate all call FSMs and terminate.
November 29, 2015
Last year Jacob and me worked on the osmo-sgsn of OpenBSC. We have improved the stability and reliability of the system and moved it to the next level. By adding the GSUP interface we are able to connect it to our commercial grade Smalltalk MAP stack and use it in the real world production GSM network. While working and manually testing this stack we have not used our osmo-pcu software but another proprietary IP based BTS, after all we didn't want to debug the PCU issues right now.
This year Jacob has taken over as a maintainer of the osmo-pcu, he started with a frequent crash fix (which was introduced due us understanding the specification on TBF re-use better but not the code), he has spent hours and hours reading the specification, studied the log output and has fixed defect after defect and then moved to features. We have tried the software at this years Camp and fixed another round of reliability issues.
Some weeks ago I noticed that the proprietary IP based BTS has been moved from the desk into the shelf. In contrast to the proprietary BTS, issues has a real possibility to be resolved. It might take a long time, it might take one paying another entity to do it but in the end your system will run better. Free Software allows you to genuinely own and use the hardware you have bought!
November 15, 2015
Contrary to my blog post yesterday, it looks like we will have a private
GSM network at the CCC congress again, after all.
It appears that Vodafone Germany (who was awarded the former DECT guard
band in the 2015 spectrum auctions) is not yet using it in December,
and they agreed that we can use it at the 32C3.
With this approval from Vodafone Germany we can now go to the regulator
(BNetzA) and obtain the usual test license. Given that we used to get
the license in the past, and that Vodafone has agreed, this should be a
For the German language readers who appreciate the language of the
administration, it will be a Frequenzzuteilung für Versuchszwecke im
nichtöffentlichen mobilen Landfunk.
So thanks to Vodafone Germany, who enabled us at least this time to run
a network again. By end of 2016 you can be sure they will have put
their new spectrum to use, so I'm not that optimistic that this would
be possible again.
November 14, 2015
I currently don't assume that there will be a GSM network at the 32C3.
Ever since OpenBSC was created in 2008,
the annual CCC congress was a great opportunity to test OpenBSC and
related software with thousands of willing participants. In order to do
so, we obtained a test licence from the German regulatory authority.
This was never any problem, as there was a chunk of spectrum in the
1800 MHz GSM band that was not allocated to any commercial operator, the
so-called DECT guard band. It's called that way as it was kept free
in order to ensure there is no interference between 1800 MHz GSM and the
neighboring DECT cordless telephones.
Over the decades, it was determined on a EU level that this guard band
might not be necessary, or at least not if certain considerations are
taken for BTSs deployed in that band.
When the German regulatory authority re-auctioned the GSM spectrum
earlier this year, they decided to also auction the frequencies of the
former DECT guard band. The DECT guard band was awarded to Vodafone.
This is a pity, as this means that people involved with cellular
research or development of cellular technology now have it significantly
harder to actually test their systems.
In some other EU member states it is easier, like in the Netherlands or
the UK, where the DECT guard band was not treated like any other chunk
of the GSM bands, but put under special rules. Not so in Germany.
To make a long story short: Without the explicit permission of any of
the commercial mobile operators, it is not possible to run a
test/experimental network like we used to ran at the annual CCC
- the event is held in the city center (where frequencies are typically
used and re-used quite densely), and
- an operator has nothing to gain from permitting us to test our open
source GSM/GPRS implementations,
I think there is little chance that this will become a reality.
If anyone has really good contacts to the radio network planning
team of a German mobile operator and wants to prove me wrong: Feel free
to contact me by e-mail.
Thanks to everyone involved with the GSM team at the CCC events,
particularly Holger Freyther, Daniel Willmann, Stefan Schmidt, Jan
Luebbe, Peter Stuge, Sylvain Munaut, Kevin Redon, Andreas Eversberg,
Ulli (and everyone else whom I may have forgot, my apologies). It's
been a pleasure!
Thanks also to our friends at the POC (Phone Operation Center) who have
provided interfacing to the DECT, ISDN, analog and VoIP network at the
events. Thanks to roh for helping with our special patch requests.
Thanks also to those entities and people who borrowed equipment (like
BTSs) in the pre-sysmocom years.
So long, and thanks for all the fish!
November 13, 2015
- give away
- destroy it
- or exclude others from doing these things.
(Seek legal advice)
November 10, 2015
I’m absolutely relying on working with issue trackers for managing features, bugs, and releases. Although it’s always a bit cumbersome to teach (new) clients how to properly use it (it takes quite some hand holding and improving their tickets), sooner or later they all realize that it’s way better than the chaos we get by tossing Excel sheets back and forwards.
Although we shut our company LaTe App-Developers down last year, my colleague and me are still using our old redmine 2.x installation to support existing clients. For new projects, I recently started to look into the current state of issue tracker offerings. My needs are:
- Open source – I don’t believe in closed source solutions for such a critical thing in my daily routine.
- Simple & efficient – I don’t need a feature monster, I need something that I and my clients can use and that doesn’t get in our way.
- Self-hosted on debian 7.x – I know it’s quite some administrative work to get things running smoothly, but once in a while I enjoy these kind of tasks.
- Configurable task states and workflow – My status flow is usually open => reproducible => in progress => testable => closed.
- Remote GIT repository integration:
- A combined activity screen where I see not only tickets, but also change sets.
- Being able to advance the task state with commit messages.
- Fetching new data by using git hooks! No cron jobs, no pulling.
As I’ve mentioned, we previously used redmine and this is what I’m familiar with and what I love to work with. In the past (when my requirements were not developed yet), I also used trac, mantis, and bugzilla – but neither of those got me hooked.
Despite being somewhat satisfied with redmine, the last time I researched the market was five years ago, so I set out to do another survey – to see whether there is anything better than redmine meeting my requirements. I spare you the itchy details, but after looking and trying for some weeks, there were only three contenders left:
- Good ole‘ redmine, this time in version 3.1.
- OpenProject, a fork of the (now defunct) ChilliProject – hence a 2nd order fork of redmine.
- Phabricator, the new hotness introduced by Facebook, Inc.
OpenProject looked interesting to me since it basically is still redmine, but with a focus on a more streamline UI and better usability (and more frequent releases). Installation was pretty good, since finnlabs (the company that is steering its development and offering professional services around the product) provides packages. Everything worked pretty well, but at the end of the day though, it wasn’t that much of a step-up from redmine.
Phabricator is pretty impressive. Installation is painless (On most systems, PHP still has the better out-of-the-box experience than Ruby and Rails) and the web GUI looks amazing. Although the individual parts are very strong and it has a lot of features that redmine lacks, the configuration UI is pretty barebones (for custom ticket states, you have to edit JSON files) and it doesn’t felt as integrated as redmine. It has great potential though, perhaps I just need to play with it for a longer time. I left my installation intact and will use it for an internal project for a while.
For all other projects though, I have decided to come back to redmine. To spice up the look and feel, I’m using the Circle theme from RedmineCRM (who are making some great plugins for redmine) and some of their plugins.
One thing that’s always a bit of a nuisance is the git repository integration without pulling or stalling when it reads the changesets while you are, say, querying the tickets. Phabricator comes with a dedicated daemon that eases this part, I think that’s a way redmine et. al. should look into, as well. For redmine 3.1, I got it working with their new (to me) repository web service. If you don’t have the repository on the same machine as your tracker installation, the ideal system has the following parts:
- I push a new changeset to my repository. A simple post-receive hook on my gitolite installation then calls the redmine web service to trigger the next step, e.g.
curl "http://<redmine url>/sys/fetch_changesets?key=$apikey&id=$projectid" &
- The redmine webservice updates its local mirror of the repository by calling git fetch. This can easily be done with the redmine plugin gitremote.
- The redmine installation processes the new changesets, checks for special commit texts, and updates its internal databases accordingly.
The hardest part of that is debugging, when something does not work (as always…). In my case it was a custom SSH port on my machine, which made it silently fail fetching new changesets until I realized that
I still recommend redmine, if you have similar needs as me. Yes, it may not integrate the latest web technologies and look a bit rusty (which you can improve by using a theme), but it’s solid and does not get in your way.
Der Beitrag My „new“ issue tracker installation erschien zuerst auf Vanille.de.
November 09, 2015
Originally, computer programs were not protected by copyrights because they were not considered fixed, tangible works. Object code was distinguished from source code. (Object code is instructions for machines–source codes are for humans.) Object code was viewed as a utilitarian good, produced from source code rather than as a creative work in and of itself.
The U.S. Copyright Office attempted to classify computer programs by drawing an analogy: the blueprints of a bridge and the resulting bridge compared to the source code of a program and the resulting executable object code:
This analogy caused the Copyright Office to issue copyright certificates under its “Rule of Doubt“.
In 1974, the newly established U.S. Commission on New Technological Uses of Copyrighted Works (CONTU) decided that “computer programs, to the extent that they embody an author’s original creation, are proper subject matter of copyright.”
Then in 1980, the U.S. Congress added the definition of “computer program” to existing copyright laws in order to allow the owner of the program to make another copy or adaptation for use on a computer. This legislation, plus court decisions such as Apple v. Franklin, clarified that the Copyright Act gave computer programs the copyright status of literary works. To simplify: Congress said compiling code is like writing War an Peace.
As a result, software companies began to claim that they did not sell their products but rather “licensed” them to customers. Why? Because this enabled them to avoid the transfer of rights to the end-user via the first-sale doctrine. These software license agreements are now called end-user license agreements (EULAs).
For roughly 1,000 years Western Civilization has expanded property rights to democratize who can own what. In the last 30 years, since software licensing began eating the world, we’ve been screwing it all up.
True ownership is as different from licensing as owning land is to renting a house. Licensing specifically precludes ownership. Licensing is a great model for the kings of the tech industry (Google, Amazon, Apple, Facebook) but it’s less than optimal for us serfs (end-users and developers).
To understand why, one has to look back at the history of property…
November 07, 2015
It is always sad if you start to develop some project and then never get
around finishing it, as there are too many things to take care in
parallel. But then, days only have 24 hours...
Back in 2012 I started to write some generic Linux kernel GTP tunneling
code. GTP is the GPRS Tunneling Protocol, a protocol
between core network elements in GPRS networks, later extended to be
used in UMTS and even LTE networks.
GTP is split in a control plane for management and the user plane
carrying the actual user IP traffic of a mobile subscriber. So if
you're reading this blog via a cellular interent connection, your data
is carried in GTP-U within the cellular core network.
To me as a former Linux kernel networking developer, the user plane of
GTP (GTP-U) had always belonged into kernel space. It is a tunneling
protocol not too different from many other tunneling protocols that
already exist (GRE, IPIP, L2TP, PPP, ...) and for the user plane, all it
does is basically add a header in one direction and remove the header in
the other direction. User data, particularly in networks with many
subscribers and/or high bandwidth use.
Also, unlike many other telecom / cellular protocols, GTP is an IP-only
protocol with no E1, Frame Relay or ATM legacy. It also has nothing to
do with SS7, nor does it use ASN.1 syntax and/or some exotic encoding
rules. In summary, it is nothing like any other GSM/3GPP protocol, and
looks much more of what you're used from the IETF/Internet world.
Unfortunately I didn't get very far with my code back in 2012, but
luckily Pablo Neira (one of my colleagues from netfilter/iptables days)
picked it up and brought it along. However, for some time it has been
stalled until recently it was thankfully picked up by Andreas Schultz
and now receives some attention and discussion, with the clear intention
to finish + submit it for mainline inclusion.
The code is now kept in a git repository at
Thanks to Pablo and Andreas for picking this up, let's hope this is the
last coding sprint before it goes mainline and gets actually used in
Back in 2012, I started the idea of having a regular, bi-weekly meeting
of people interested in mobile communications technology, not only
strictly related to the Osmocom projects and software. This was
initially called the Osmocom User Group Berlin. The meetings were
held twice per month in the rooms of the Chaos Computer Club Berlin.
There are plenty of people that were or still are involved with Osmocom
one way or another in Berlin. Think of zecke, alphaone, 2b-as, kevin,
nion, max, prom, dexter, myself - just to name a few.
Over the years, I got "too busy" and was no longer able to attend
regularly. Some people kept it alive (thanks to dexter!), but
eventually they were discontinued in 2013.
Starting in October 2015, I started a revival of the
meetings, two have been held already, the third is coming up next week
on November 11.
I'm happy that I had the idea of re-starting the meeting. It's good to
meet old friends and new people alike. Both times there actually were
some new faces around, most of which even had a classic professional
In order to emphasize the focus is strictly not on Osmocom alone (
particularly not about its users only), I decided to rename the event to
the Osmocom Meeting Berlin.
If you're in Berlin and are interested in mobile communications
technology on the protocol and radio side of things, feel free to join us
November 02, 2015
At my company sysmocom we are operating a small
web-shop providing small tools and
accessories for people interested in mobile research. This includes
programmable SIM cards, SIM card protocol tracers, adapter cables,
duplexers for cellular systems, GPS disciplined clock units, and other
things we consider useful to people in and around the various Osmocom projects.
We of course ship domestic, inside the EU and world-wide. And that's
where the trouble starts, at least since 2014.
What are VAT-free intra-EU shipments?
As many readers of this blog (at least the European ones) know, inside
the EU there is a system by which intra-EU sales between businesses in
EU member countries are performed without charging VAT.
This is the result of different countries having different amount of
VAT, and the fact that a business can always deduct the VAT it spends on
its purchases from the VAT it has to charge on its sales. In order to
avoid having to file VAT return statements in each of the countries of
your suppliers, the suppliers simply ship their goods without charging
VAT in the first place.
In order to have checks and balances, both the supplier and the
recipient have to file declarations to their tax authorities, indicating
the sales volume and the EU VAT ID of the respective business partners.
So far so good. This concept was reasonably simple to implement and
it makes the life easier for all involved businesses, so everyone
participates in this scheme.
Of course there always have been some obstacles, particularly here in
Germany. For example, you are legally required to confirm the
EU-VAT-ID of the buyer before issuing a VAT-free invoice. This
confirmation request can be done online
However, the Germany tax authorities invented something unbelievable: A
Web-API for confirmation of EU-VAT-IDs that has opening hours. Despite
this having rightfully been at the center of ridicule by the German
internet community for many years, it still remains in place. So there
are certain times of the day where you cannot verify EU-VAT-IDs, and
thus cannot sell products VAT-free ;)
But even with that one has gotten used to live.
Now in recent years (since January 1st, 2014) , the German authorities
came up with the concept of the Gelangensbescheinigung. To the German
reader, this newly invented word already sounds ugly enough. Literal
translation is difficult, as it sounds really clumsy. Think of
something like a reaching-its-destination-certificate
So now it is no longer sufficient to simply verify the EU-VAT-ID of the
buyer, issue the invoice and ship the goods, but you also have to
produce such a Gelangensbescheinigung for each and every VAT-free
intra-EU shipment. This document needs to include
- the name and address of the recipient
- the quantity and designation of the goods sold
- the place and month when the goods were received
- the date of when the document was signed
- the signature of the recipient (not required in case of an e-mail
where the e-mail headers show that the messages was transmitted from
a server under control of the recipient)
How can you produce such a statement? Well, in the ideal / legal /
formal case, you provide a form to your buyer, which he then signs and
certifies that he has received the goods in the destination country.
First of all, I find if offensive that I have to ask my customers to
make such declarations in the first place. And then even if I accept
this and go ahead with it, it is my legal responsibility to ensure that
he actually fills this in.
What if the customer doesn't want to fill it in or forgets about it?
Then I as the seller am liable to pay 19% VAT on the purchase he made,
despite me never having charged those 19%.
So not only do I have to generate such forms and send them with my
goods, but I also need a business process of checking for their return,
reminding the customers that their form has not yet been returned, and
in the end they can simply not return it and I loose money. Great.
Track+Trace / Courier Services
Now there are some alternate ways in which a Gelangensbescheinigung
can be generated. For example by a track+trace protocol of the delivery
company. However, the requirements to this track+trace protocol are so
high, that at least when I checked in late 2013, the track and trace
protocol of UPS did not fulfill the requirements. For example, a
track+trace protocol usually doesn't show the quantity and designation
of goods. Why would it? UPS just moves a package from A to B, and
there is no customs involved that would require to know what's in the
Now let's say you'd like to send your goods by postal service. For
low-priced non-urgent goods, that's actually what you generally want to
do, as everything else is simply way too expensive compared to the value
of the goods.
However, this is only permitted, if the postal service you use produces
you with a receipt of having accepted your package, containing the
following mandatory information:
- name and address of the entity issuing the receipt
- name and address of the sender
- name and address of the recipient
- quantity and type of goods
- date of having receive the goods
Now I don't know how this works in other countries, but in Germany you
will not be able to get such a receipt form the postal office.
In fact I inquired several times with the legal department of Deutsche
Post, up to the point of sending a registered letter (by Deutsche Post)
to Deutsche Post. They have never responded to any of those letters!
So we have the German tax authorities claiming yes, of course you can
still do intra-EU shipments to other countries by postal services, you
just need to provide a receipt, but then at the same time they ask for
a receipt indicating details that no postal receipt would ever show.
Particularly a postal receipt would never confirm what kind of goods you
are sending. How would the postal service know? You hand them a
package, and they transfer it. It is - rightfully - none of their
business what its content may be. So how can you ask them to confirm
that certain goods were received for transport ?!?
So in summary:
Since January 1st, 2014, we now have German tax regulations in force
that make VAT free intra-EU shipments extremely difficult to impossible
- The type of receipt they require from postal services is not provided
by Deutsche Post, thereby making it impossible to use Deutsche Post
for VAT free intra-EU shipments
- The type of track+trace protocol issued by UPS does not fulfill the
requirements, making it impossible to use them for VAT-free intra-EU
- The only other option is to get an actual receipt from the customer.
If that customer doesn't want to provide this, the German seller is
liable to pay the 19% German VAT, despite never having charged that
to his customer
To me, the conclusion of all of this can only be one:
German tax authorities do not want German sellers to sell VAT-free
goods to businesses in other EU countries. They are actively trying to
undermine the VAT principles of the EU. And nobody seem to complain
about it or even realize there is a problem.
What a brave new world we live in.
I’ve begun to collect quite a collection of good books on the theme of Ownership. The quest started a few years ago; thinking about the birth of my son, I realized what I care most about these days is digital. And as any astute EULA reader would know, we don’t own what we buy from Apple, Google, or Amazon – we merely rent.
I started a company to enable ownership of digital things. I’m interested in how, albeit with a western bias, we have been building up properly law for 1,000+ years. But since the 1970s we have been screwing it up.
This is the first post of (hopefully) many as I try to work out what is OWNERSHIP in a more public way.
October 31, 2015
Some time ago I wrote a small Linux command line utility that can be
used to (re)program the Ethernet (MAC) address stored in the EEPROM
attached to an RTL8168 Ethernet chip.
This is for example useful if you are a system integrator that has its
own IEEE OUI range and you would like to put your own MAC address in
devices that contain the said Realtek etherent chips (already
pre-programmed with some other MAC address).
The source code can be obtaned from: