LaForge's home page (Posts about telecom)https://laforge.gnumonks.org/blog/tags/telecom.atom2022-09-23T09:48:04ZHarald WelteNikolaDeployment of future community TDMoIP hubhttps://laforge.gnumonks.org/blog/20220919-octoi_hub_colocation_noris/2022-09-19T00:00:00+02:002022-09-19T00:00:00+02:00Harald Welte<p>I've mentioned some of my various <em>retronetworking</em> projects in some
past blog posts. One of those projects is <a class="reference external" href="https://osmocom.org/projects/octoi/wiki">Osmocom Community TDM over
IP (OCTOI)</a>. During the
past 5 or so months, we have been using a number of GPS-synchronized
open source <a class="reference external" href="https://osmocom.org/projects/e1-t1-adapter/wiki/IcE1usb">icE1usb</a>
interconnected by a <a class="reference external" href="https://osmocom.org/projects/octoi/wiki/Proposed_efficient_TDMoIP">new, efficient but strill transparent TDMoIP protocol</a> in order to run a distributed
TDM/PDH network. This network is currently only used to provide ISDN
services to retronetworking enthusiasts, but other uses like frame relay
have also been validated.</p>
<p>So far, the central <em>hub</em> of this OCTOI network has been operating in
the basement of my home, behind a consumer-grade DOCSIS cable modem
connection. Given that TDMoIP is relatively sensitive to packet loss,
this has been sub-optimal.</p>
<p>Luckily some of my old friends at <a class="reference external" href="https://noris.net">noris.net</a> have
agreed to host a new OCTOI hub free of charge in one of their
ultra-reliable co-location data centres. I'm already hosting some other
machines there for 20+ years, and noris.net is a good fit given that
they were - in their early days as an ISP - the driving force in the
early 90s behind one of the Linux kernel ISDN stracks called <a class="reference external" href="http://matthias.urlichs.de/bio/comp/">u-isdn</a>. So after many decades, ISDN
returns to them in a very different way.</p>
<p>Side note: In case you're curious, a reconstructed partial release
history of the u-isdn code can be found <a class="reference external" href="https://gitea.osmocom.org/retronetworking/u-isdn">on gitea.osmocom.org</a></p>
<p>But I digress. So today, there was the installation of this new OCTOI
hub setup. It has been prepared for several weeks in advance, and the
hub contains two circuit boards designed entirely only for this use
case. The most difficult challenge was the fact that this data centre
has no existing GPS RF distribution, and the roof is ~ 100m of CAT5
cable (no fiber!) away from the roof. So we faced the challenge of
passing the 1PPS (1 pulse per second) signal reliably through several
steps of lightning/over-voltage protection into the icE1usb whose
internal GPS-DO serves as a grandmaster clock for the TDM network.</p>
<p>The equipment deployed in this installation currently contains:</p>
<ul class="simple">
<li><p>a rather beefy Supermicro 2U server with EPYC 7113P CPU and 4x PCIe, two of which are populated with Digium TE820 cards resulting in a total of 16 E1 ports</p></li>
<li><p>an icE1usb with RS422 interface board connected via 100m RS422 to an
Ericsson GPS03 receiver. There's two layers of of over-voltage
protection on the RS422 (each with gas discharge tubes and TVS) and
two stages of over-voltage protection in the coaxial cable between
antenna and GPS receiver.</p></li>
<li><p>a <a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3">Livingston Portmaster3</a> RAS server</p></li>
<li><p>a <a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Cisco_AS5400">Cisco AS5400</a> RAS server</p></li>
</ul>
<p>For more details, see <a class="reference external" href="https://osmocom.org/projects/octoi/wiki/Colocated_Hub">this wiki page</a> and <a class="reference external" href="https://osmocom.org/issues/5542">this ticket</a></p>
<p>Now that the physical deployment has been made, the next steps will be
to migrate all the TDMoIP links from the existing user base over to the
new hub. We hope the reliability and performance will be much better
than behind DOCSIS.</p>
<p>In any case, this new setup for sure has a lot of capacity to connect
many more more users to this network. At this point we can still only
offer E1 PRI interfaces. I expect that at some point during the coming
winter the project for remote TDMoIP BRI (S/T, S0-Bus) connectivity will
become available.</p>
<section id="acknowledgements">
<h2>Acknowledgements</h2>
<p>I'd like to thank anyone helping this effort, specifically
* Sylvain "tnt" Munaut for his work on the RS422 interface board (+ gateware/firmware)
* noris.net for sponsoring the co-location
* sysmocom for sponsoring the EPYC server hardware</p>
</section>Clock sync trouble with Digium cards and timing cableshttps://laforge.gnumonks.org/blog/20220906-digium_timing_cable_troubles/2022-09-09T00:00:00+02:002022-09-09T00:00:00+02:00Harald Welte<p>If you have ever worked with Digium (now part of Sangoma) digital
telephony interface cards such as the TE110/410/420/820 (single to octal
E1/T1/J1 PRI cards), you will probably have seen that they always have a
<em>timing connector</em>, where the timing information can be passed from one
card to another.</p>
<p>In PDH/ISDN (or even SDH) networks, it is very important to have a
synchronized clock across the network. If the clocks are drifting,
there will be underruns or overruns, with associated phase jumps that
are particularly dangerous when analog modem calls are transported.</p>
<p>In traditional ISDN use cases, the clock is always provided by the
network operator, and any customer/user side equipment is expected to
synchronize to that clock.</p>
<p>So this Digium timing cable is needed in applications where you have
more PRI lines than possible with one card, but only a subset of your
lines (spans) are connected to the public operator. The timing cable
should make sure that the clock received on one port from the public
operator should be used as transmit bit-clock on all of the other ports,
no matter on which card.</p>
<p>Unfortunately this decades-old Digium timing cable approach seems to
suffer from some problems.</p>
<section id="bursty-bit-clock-changes-until-link-is-up">
<h2>bursty bit clock changes until link is up</h2>
<p>The first problem is that downstream port transmit bit clock was jumping
around in bursts every two or so seconds. You can see an oscillogram of
the E1 master signal (yellow) received by one TE820 card and the
transmit of the slave ports on the other card at
<a class="reference external" href="https://people.osmocom.org/laforge/photos/te820_timingcable_problem.mp4">https://people.osmocom.org/laforge/photos/te820_timingcable_problem.mp4</a></p>
<p>As you can see, for some seconds the two clocks seem to be in perfect
lock/sync, but in between there are periods of immense clock drift.</p>
<p>What I'd have expected is the behavior that can be seen at <a class="reference external" href="https://people.osmocom.org/laforge/photos/te820_notimingcable_loopback.mp4">https://people.osmocom.org/laforge/photos/te820_notimingcable_loopback.mp4</a> - which shows a similar setup but without the use
of a timing cable: Both the master clock input and the clock
output were connected on the same TE820 card.</p>
<p>As I found out much later, this problem only occurs until any of the
downstream/slave ports is fully OK/GREEN.</p>
<p>This is surprising, as any other E1 equipment I've seen always transmits
at a constant bit clock irrespective whether there's any signal in the
opposite direction, and irrespective of whether any other ports are
up/aligned or not.</p>
<p>But ok, once you adjust your expectations to this Digium peculiarity,
you can actually proceed.</p>
</section>
<section id="clock-drift-between-master-and-slave-cards">
<h2>clock drift between master and slave cards</h2>
<p>Once any of the spans of a <em>slave</em> card on the timing bus are fully
aligned, the transmit bit clocks of all of its ports appear to be in
sync/lock - yay - but unfortunately only at the very first glance.</p>
<p>When looking at it for more than a few seconds, one can see a slow,
continuous drift of the <em>slave</em> bit clocks compared to the <em>master</em> :(</p>
<p>Some initial measurements show that the clock of the <em>slave</em> card of the
timing cable is drifting at about 12.5 ppb (parts per billion) when
compared against the <em>master</em> clock reference.</p>
<p>This is rather disappointing, given that the whole point of a timing cable
is to ensure you have <em>one</em> reference clock with all signals locked to
it.</p>
</section>
<section id="the-work-around">
<h2>The work-around</h2>
<p>If you are willing to sacrifice one port (span) of each card, you can
work around that slow-clock-drift issue by connecting an external
loopback cable. So the <em>master</em> card is configured to use the clock
provided by the upstream provider. Its other ports (spans) will transmit
at the <em>exact</em> recovered clock rate with no drift. You can use any of
those ports to provide the clock reference to a port on the <em>slave</em>
card using an external loopback cable.</p>
<p>In this setup, your <em>slave</em> card[s] will have perfect bit clock
sync/lock.</p>
<p>Its just rather sad that you need to sacrifice ports <em>just</em> for
achieving proper clock sync - something that the timing connectors and
cables claim to do, but in reality don't achieve, at least not in my
setup with the most modern and high-end octal-port PCIe cards (TE820).</p>
</section>Progress on the ITU-T V5 access network fronthttps://laforge.gnumonks.org/blog/20220909-wobcom-v5/2022-09-09T00:00:00+02:002022-09-09T00:00:00+02:00Harald Welte<p>Almost one year after my post <a class="reference external" href="https://laforge.gnumonks.org/blog/20170212-libosmo_sigtran/">regarding first steps towards a V5
implementation</a>, some friends
and I were finally able to visit <a class="reference external" href="https://www.wobcom.de/">Wobcom</a>, a
small German city carrier and pick up a lot of decommissioned
POTS/ISDN/PDH/SDH equipment, primarily V5 access networks.</p>
<p>This means that a number of retronetworking enthusiasts now have a
chance to play with Siemens Fastlink, Nokia EKSOS and DeTeWe ALIAN
access networks/multiplexers.</p>
<p>My primary interest is in Nokia EKSOS, which looks like an rather easy,
low-complexity target. As one of the first steps, I took PCB
photographs of the various modules/cards in the shelf, take note of the
main chip designations and started to search for the related
data sheets.</p>
<p>The results can be found in the Osmocom retronetworking wiki, with
<a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS">https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS</a> being the main entry page, and sub-pages about</p>
<ul class="simple">
<li><p><a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS_Node_Control_Unit">Node Control Unit</a></p></li>
<li><p><a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS_BRI_UK0_Line_Card">16x BRI Uk0 Line Card</a></p></li>
<li><p><a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS_POTS_Line_Card">32x POTS Line Card</a></p></li>
<li><p><a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS_Line_Measurement_Unit">Line Measurement Unit</a></p></li>
<li><p><a class="reference external" href="https://osmocom.org/projects/retronetworking/wiki/Nokia_EKSOS_Shelf">Shelf</a></p></li>
</ul>
<p>In short: Unsurprisingly, a lot of Infineon analog and digital ICs for
the POTS and ISDN ports, as well as a number of Motorola M68k based
QUICC32 microprocessors and several unknown ASICs.</p>
<p>So with V5 hardware at my disposal, I've slowly re-started my efforts to
implement the LE (local exchange) side of the V5 protocol stack, with
the goal of eventually being able to interface those V5 AN with the
<a class="reference external" href="https://osmocom.org/projects/octoi/wiki">Osmocom Community TDM over IP network</a>. Once that is in place, we
should also be able to offer real ISDN Uk0 (BRI) and POTS lines at
retrocomputing events or hacker camps in the coming years.</p>Retronetworking at VCFB 2022https://laforge.gnumonks.org/blog/20220916-vcfb_2022_and_retronetworking/2022-09-09T00:00:00+02:002022-09-09T00:00:00+02:00Harald Welte<p>I'm happy to announce active participation at the <a class="reference external" href="https://vcfb.de/2022/">Vintage Computing
Festival Berlin 2022</a> in two ways:</p>
<ul class="simple">
<li><p>Running a <a class="reference external" href="https://vcfb.de/2022/ausstellungen.html">retronetworking exhibit on Modem and ISDN dial-up</a></p></li>
<li><p>Giving a <a class="reference external" href="https://vcfb.de/2022/vortraege_workshops.html">talk on the Osmocom Community TDMoIP netwokr</a></p></li>
</ul>
<p>The exhibit will be similar to the exhibit at the retrocomputing village
of the last CCC congress (36C3): A digital telephony network with ISDN
BRI and POTS lines providing services to a number of laptops with Modems
and ISDN terminal adapters.</p>
<p>We plan to demo the following things:
* analog modem and ISDN dial-up into BBSs
** text / ANSI interfaces via Telix, Telemate, Terminate
** RIPterm graphical interfaces
* analog modem and ISDN dial-up IP/internet
* ISDN video telephony</p>
<p>The client computers will be contemporary 486/Pentium machines wit DOS,
Windows 3.11 and OS/2.</p>First steps towards an ITU-T V5.1 / V5.2 implementationhttps://laforge.gnumonks.org/blog/20211011-v52/2021-10-11T00:00:00+02:002021-10-11T00:00:00+02:00Harald Welte<p>As some of you may know, I've been starting to collect "vintage"
telecommunications equipment starting from analog modems to ISDN
adapters, but also PBXs and even SDH equipment. The goal is to keep
this equipment (and related software) alive for demonstration and
practical exploration.</p>
<p>Some [incomplete] information can be found at
<a class="reference external" href="https://osmocom.org/projects/retro-bbs/wiki/">https://osmocom.org/projects/retro-bbs/wiki/</a></p>
<p>Working with PBXs to simulate the PSTN (ISDN/POTS) network is fine to
some extent, but it's of course not the real deal. You only get
S0-buses and no actual Uk0 like actual ISDN lines of the late 80ies and
90ies. You have problems with modems not liking the PBX dialtone, etc.</p>
<p>Hence, I've always wanted to get my hand on some more real-world
central-office telephone network equipment, and I finally have a source
for so-called <a class="reference external" href="https://en.wikipedia.org/wiki/V5_interface">V5.1/V5.2</a>
access multiplexers. Those are like remote extension boxes for the
central office switch (like <a class="reference external" href="https://en.wikipedia.org/wiki/EWSD">EWSD</a>
or <a class="reference external" href="https://en.wikipedia.org/wiki/ITT_System_12">System 12</a>). They
aggregate/multiplex a number of analog or ISDN BRI subscriber lines into
E1 lines, while not implementing any of the actual call control or ISDN
signalling logic. All of that is provided by the actual telephone
switch/exchange.</p>
<p>So in order to integrate such access multiplexers in my retronetworking
setup, I will have to implement the LE (local exchange) side of the V5.1
and/or V5.2 protocols, as specified in ITU-T <a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.964-200103-I!!PDF-E&type=items">G.964</a> and
<a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.965-200103-I!!PDF-E&type=items">G.965</a>.</p>
<p>In the limited spare time I have next to my dayjob and various FOSS
projects, progress will likely be slow. Nonetheless I started with an
implementation now, and I already had a lot of fun learning about more
details of those interfaces and their related protocols.</p>
<p>One of the unresolved questions is to what kind of software I would want
to integrate once the V5.x part is resolved.</p>
<ul class="simple">
<li><p><a class="reference external" href="http://linux-call-router.de/">lcr</a> would probably be the most
ISDN-native approach, but it is mostly unused and quite EOL.</p></li>
<li><p>Asterisk or FreeSWITCH would of course be obvious candidates, but they
are all relatively alien to ISDN, and hence not very transparent once
you start to do anything but voice calls (e.g. dialup ISDN data calls
in various forms).</p></li>
<li><p><a class="reference external" href="http://yate.null.ro/">yate</a> is another potential candidate. It
already supports classic SS7 including ISUP, so it would be a good
candidate to build an actual ISDN exchange with V5.2 access
multiplexers on the customer-facing side (Q.921+Q.931 on it) and
SS7/ISUP towards other exchanges.</p></li>
</ul>
<p>For now I think yate would be the most promising approach. Time will
tell.</p>
<p>The final goal would then be to have a setup [e.g. at a future CCC
congress] where we would have SDH add/drop multiplexers in several
halls, and V5.x access multiplexers attached to that, connecting analog
and ISDN BRI lines from individual participants to a software-defined
central exchange. Ideally actually multiple exchanges, so we can show
the signaling on the V5.x side, the Q.921/Q.931 side and the SS7/ISUP
between the exchanges.</p>
<p>Given that the next CCC congress is not before December 2022, there is a
chance to actually implement this before then ;)</p>OsmoDevCon 2017 Reviewhttps://laforge.gnumonks.org/blog/20170503-osmodevcon/2017-05-03T00:00:00+02:002017-05-03T00:00:00+02:00Harald Welte<p>After the public user-oriented OsmoCon 2017, we also recently had the
6th incarnation of our annual contributors-only <a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon">Osmocom Developer Conference</a>: The <a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2017">OsmoDevCon 2017</a>.</p>
<p>This is a much smaller group, typically about 20 people, and is limited
to actual developers who have a past record of contributing to any of
the many <a class="reference external" href="https://osmocom.org/projects">Osmocom projects</a>.</p>
<p>We had a large number of presentation and discussions. In fact, so
large that the schedule of talks extended from 10am to midnight on some
days. While this is great, it also means that there was definitely too
little time for more informal conversations, chatting or even actual
work on code.</p>
<p>We also have such a wide range of topics and scope inside Osmocom, that
the traditional <em>ad-hoch scheduling</em> approach no longer seems to be
working as it used to. Not everyone is interested in (or has time for)
all the topics, so we should group them according to their topic/subject
on a given day or half-day. This will enable people to attend only
those days that are relevant to them, and spend the remaining day in an
adjacent room hacking away on code.</p>
<p>It's sad that we only have OsmoDevCon once per year. Maybe that's
actually also something to think about. Rather than having 4 days once
per year, maybe have two weekends per year.</p>
<p>Always in motion the future is.</p>Overhyped Dockerhttps://laforge.gnumonks.org/blog/20170503-docker-overhyped/2017-05-03T00:00:00+02:002017-05-03T00:00:00+02:00Harald Welte<div class="section" id="overhyped-docker-missing-the-most-basic-features">
<h2>Overhyped Docker missing the most basic features</h2>
<p>I've always been extremely skeptical of suddenly emerging over-hyped
technologies, particularly if they advertise to solve problems by adding
yet another layer to systems that are already sufficiently complex
themselves.</p>
<p>There are of course many issues with containers, ranging from replicated
system libraries and the basic underlying statement that you're giving
up on the system packet manager to properly deal with dependencies.</p>
<p>I'm also highly skeptical of FOSS projects that are primarily driven by
one (VC funded?) company. Especially if their offering includes a
so-called <em>cloud service</em> which they can stop to operate at any given
point in time, or (more realistically) first get everybody to use and
then start charging for.</p>
<p>But well, despite all the bad things I read about it over the years, on
one day in May 2017 I finally thought let's give it a try. My problem
to solve as a test balloon is fairly simple.</p>
</div>
<div class="section" id="my-basic-use-case">
<h2>My basic use case</h2>
<p>The plan is to start OsmoSTP, the m3ua-testtool and the sua-testtool,
which both connect to OsmoSTP. By running this setup inside containers
and inside an internal network, we could then execute the entire
testsuite e.g. during jenkins test without having IP address or port
number conflicts. It could even run multiple times in parallel on one
buildhost, verifying different patches as part of the continuous
integration setup.</p>
<p>This application is not so complex. All it needs is three containers,
an internal network and some connections in between. Should be a piece
of cake, right?</p>
<p>But enter the world of buzzword-fueled web-4000.0 software-defined
virtualised and orchestrated container NFW + SDN vodoo: It turns out to
be impossible, at least not with the preferred tools they advertise.</p>
</div>
<div class="section" id="dockerfiles">
<h2>Dockerfiles</h2>
<p>The part that worked relatively easily was writing a few Dockerfiles to
build the actual containers. All based on debian:jessie from the
library.</p>
<p>As m3ua-testsuite is written in guile, and needs to build some guile
plugin/extension, I had to actually include guile-2.0-dev and other
packages in the container, making it a bit bloated.</p>
<p>I couldn't immediately find a nice example Dockerfile recipe that would
allow me to build stuff from source outside of the container, and then
install the resulting binaries into the container. This seems to be a
somewhat weak spot, where more support/infrastructure would be helpful.
I guess the idea is that you simply install applications via package
feeds and apt-get. But I digress.</p>
<p>So after some tinkering, I ended up with three docker containers:</p>
<ul class="simple">
<li><p>one running OsmoSTP</p></li>
<li><p>one running m3ua-testtool</p></li>
<li><p>one running sua-testtool</p></li>
</ul>
<p>I also managed to create an internal <em>bridged</em> network between the
containers, so the containers could talk to one another.</p>
<p>However, I have to manually start each of the containers with ugly long
command line arguments, such as <code class="docutils literal">docker run <span class="pre">--network</span> sigtran <span class="pre">--ip</span>
172.18.0.200 <span class="pre">-it</span> <span class="pre">osmo-stp-master</span></code>. This is of course sub-optimal, and
what Docker Services + Stacks should resolve.</p>
</div>
<div class="section" id="services-stacks">
<h2>Services + Stacks</h2>
<p>The idea seems good: A <em>service</em> defines how a given container is run,
and a <em>stack</em> defines multiple containers and their relation to each
other. So it should be simple to define a <em>stack</em> with three
<em>services</em>, right?</p>
<p>Well, it turns out that it is not. Docker documents that you can
configure a static <code class="docutils literal">ipv4_address</code> <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id5" id="id1">1</a> for each service/container, but it
seems related configuration statements are simply silently
ignored/discarded <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id6" id="id2">2</a>, <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id7" id="id3">3</a>, <a class="footnote-reference brackets" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id8" id="id4">4</a>.</p>
<p>This seems to be related that for some strange reason <em>stacks</em> can (at
least in later versions of docker) only use <em>overlay</em> type networks,
rather than the much simpler <em>bridge</em> networks. And while bridge
networks appear to support static IP address allocations, overlay
apparently doesn't.</p>
<p>I still have a hard time grasping that something that considers itself a
serious product for production use (by a company with estimated value
over a billion USD, not by a few hobbyists) that has no support for
running containers on static IP addresses. that. How many applications
out there have I seen that require static IP address configuration? How
much simpler do setups get, if you don't have to rely on things like
dynamic DNS updates (or DNS availability at all)?</p>
<p>So I'm stuck with having to manually configure the network between my
containers, and manually starting them by clumsy shell scripts, rather
than having a proper abstraction for all of that. Well done :/</p>
</div>
<div class="section" id="exposing-ports">
<h2>Exposing Ports</h2>
<p>Unrelated to all of the above: If you run some software inside
containers, you will pretty soon want to expose some network services
from containers. This should also be the most basic task on the planet.</p>
<p>However, it seems that the creators of docker live in the early 1980ies,
where only TCP and UDP transport protocols existed. They seem to have
missed that by the late 1990ies to early 2000s, protocols like <a class="reference external" href="https://datatracker.ietf.org/doc/rfc2960">SCTP</a> or <a class="reference external" href="https://datatracker.ietf.org/doc/rfc4340/">DCCP</a> were invented.</p>
<p>But yet, in 2017, Docker chooses to</p>
<ul class="simple">
<li><p>blindly assume TCP in
<a class="reference external" href="https://docs.docker.com/engine/reference/builder/#expose">https://docs.docker.com/engine/reference/builder/#expose</a> without even
mentioning it (or designing the syntax to accept any specification of
the protocol)</p></li>
<li><p>design a syntax (<code class="docutils literal">/tcp</code>) in the command-line parsing (see
<a class="reference external" href="https://docs.docker.com/engine/reference/run/#expose-incoming-ports">https://docs.docker.com/engine/reference/run/#expose-incoming-ports</a>), but then
only parse tcp and udp, despite people requesting support for other
protocols like SCTP <a class="reference external" href="https://github.com/moby/moby/issues/9689">as early as three years ago</a></p></li>
</ul>
<p>Now some of the readers may think 'who uses SCTP anyway'. I will give
you a straight answer: Everyone who has a mobile phone uses SCTP. This
is due to the fact that pretty much all the connections inside cellular
networks (at least for 3G/4G networks, and in reality also for many 2G
networks) are using SCTP as underlying transport protocol, from the
radio access network into the core network. So every time you switch
your phone on, or do anything with it, you are using SCTP. Not on your
phone itself, but by all the systems that form the network that you're
using. And with the drive to C-RAN, NFV, SDN and all the other
buzzwords also appearing in the Cellular Telecom field, people should
actually worry about it, if they want to be a part of the software stack
that is used in future cellular telecom systems.</p>
</div>
<div class="section" id="summary">
<h2>Summary</h2>
<p>After spending the better part of a day to do something that seemed like
the most basic use case for running three networked containers using
Docker, I'm back to step one: Most likely inventing some custom
scripts based on <a class="reference external" href="http://man7.org/linux/man-pages/man2/unshare.2.html">unshare</a> to run my three
test programs in a separate network namespace for isolated execution of
test suite execution as part of a Jenkins CI setup :/</p>
<p>It's also clear that Docker apparently don't care much about playing a
role in the Cellular Telecom world, which is increasingly moving away
from proprietary and hardware-based systems (like STPs) to virtualised,
software-based systems.</p>
<dl class="footnote brackets">
<dt class="label" id="id5"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id1">1</a></span></dt>
<dd><p><a class="reference external" href="https://docs.docker.com/compose/compose-file/#ipv4address-ipv6address">https://docs.docker.com/compose/compose-file/#ipv4address-ipv6address</a></p>
</dd>
<dt class="label" id="id6"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id2">2</a></span></dt>
<dd><p><a class="reference external" href="https://forums.docker.com/t/docker-swarm-1-13-static-ips-for-containers/28060">https://forums.docker.com/t/docker-swarm-1-13-static-ips-for-containers/28060</a></p>
</dd>
<dt class="label" id="id7"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id3">3</a></span></dt>
<dd><p><a class="reference external" href="https://github.com/moby/moby/issues/31860">https://github.com/moby/moby/issues/31860</a></p>
</dd>
<dt class="label" id="id8"><span class="brackets"><a class="fn-backref" href="https://laforge.gnumonks.org/blog/20170503-docker-overhyped/#id4">4</a></span></dt>
<dd><p><a class="reference external" href="https://github.com/moby/moby/issues/24170">https://github.com/moby/moby/issues/24170</a></p>
</dd>
</dl>
</div>OsmoCon 2017 Reviewhttps://laforge.gnumonks.org/blog/20170501-osmocon/2017-05-01T00:00:00+02:002017-05-01T00:00:00+02:00Harald Welte<p>It's already one week past the event, so I really have to sit down and
write some rewview on the first public <a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon">Osmocom Conference</a> ever:
<a class="reference external" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017">OsmoCon 2017</a>.</p>
<p>The event was a huge success, by all accounts.</p>
<ul class="simple">
<li><p>We've not only been sold out, but we also had to turn down some last
minute registrations due to the venue being beyond capacity (60
seats). People traveled from Japan, India, the US, Mexico and many
other places to attend.</p></li>
<li><p>We've had an amazing audience ranging from commercial operators to
community cellular operators to professional developers doing work
relate to osmocom, academia, IT security crowds and last but not least
enthusiasts/hobbyists, with whom the project[s] started.</p></li>
<li><p>I've received exclusively positive feedback from many attendees</p></li>
<li><p>We've had a great programme. Some part of it was of introductory
nature and probably not too interesting if you've been in Osmocom for
a few years. However, the work on 3G as well as the current roadmap
was probably not as widely known yet. Also, I really loved to see
Roch's talk about <a class="reference external" href="https://media.ccc.de/v/osmocon17-4011-showcase_running_a_commercial_cellular_network_with_osmobts_osmopcu_osmobsc_co">Running a commercial cellular network with Osmocom
software</a>
as well as the talk on Facebook's <a class="reference external" href="https://media.ccc.de/v/osmocon17-4013-opencellular_open_source_wireless_access_platform">OpenCellular BTS hardware</a>
and the <a class="reference external" href="https://media.ccc.de/v/osmocon17-4014-community_cellular_manager">Community Cellular Manager</a>.</p></li>
<li><p>We have very professional live streaming + video recordings courtesy
of the <a class="reference external" href="https://c3voc.de/">C3VOC</a> team. Thanks a lot for your
support and for having the <a class="reference external" href="https://media.ccc.de/c/osmocon17">video recordings</a> of all talks online already at
the next day after the event.</p></li>
</ul>
<p>We also received some requests for improvements, many of which we will
hopefully consider before the next Osmocom Conference:</p>
<ul class="simple">
<li><p>have a multiple day event. Particularly if you're traveling
long-distance, it is a lot of overhead for a single-day event. We of
course fully understand that. On the other hand, it was the first
Osmocom Conference, and hence it was a test balloon where it was
initially unclear if we'll be able to get a reasonable number of
attendees interested at all, or not. And organizing an event with
venue and talks for multiple days if in the end only 10 people attend
would have been a lot of effort and financial risk. But now that we
know there are interested folks, we can definitely think of a multiple
day event next time</p></li>
<li><p>Signs indicating venue details on the last meters. I agree, this cold
have been better. The address of the venue was published, but we
could have had some signs/posters at the door pointing you to the
right meeting room inside the venue. Sorry for that.</p></li>
<li><p>Better internet connectivity. This is a double-edged sword. Of
course we want our audience to be primarily focused on the talks and
not distracted :P I would hope that most people are able to survive
a one day event without good connectivity, but for sure we will have
to improve in case of a multiple-day event in the future</p></li>
</ul>
<p>In terms of my requests to the attendees, I only have one</p>
<ul class="simple">
<li><p>Participate in the discussions on the schedule/programme while it is
still possible to influence it. When we started to put together the
programme, I posted about it on the openbsc mailing list and invited
feedback. Still, most people seem to have missed the time window
during which talks could have been submitted and the schedule still
influenced before finalizing it</p></li>
<li><p>Register in time. We have had almost no registrations until about two
weeks ahead of the event (and I was considering to cancel it), and
then suddenly were sold out in the week ahead of the event. We've had
people who first booked their tickets, only to learn that the tickets
were sold out. I guess we will introduce <em>early bird</em> pricing and add
a very expensive <em>last minute</em> ticket option next year in order to
increase motivation to register early and thus give us flexibility
regarding venue planning.</p></li>
</ul>
<p>Thanks again to everyone involved in OsmoCon 2017!</p>
<p>Ok, now, all of you who missed the event: Go to
<a class="reference external" href="https://media.ccc.de/c/osmocon17">https://media.ccc.de/c/osmocon17</a> and check out the recordings. Have
fun!</p>Things you find when using SCTP on Linuxhttps://laforge.gnumonks.org/blog/20170417-linux-sctp-dry-events/2017-04-17T00:00:00+02:002017-04-17T00:00:00+02:00Harald Welte<div class="section" id="observations-on-sctp-and-linux">
<h2>Observations on SCTP and Linux</h2>
<p>When I was still doing Linux kernel work with netfilter/iptables in the
early 2000's, I was somebody who actually regularly had a look at the
new RFCs that came out. So I saw the SCTP RFCs, SIGTRAN RFCs, SIP and
RTP, etc. all released during those years. I was quite happy to see
that for new protocols like SCTP and later DCCP, Linux quickly received
a mainline implementation.</p>
<p>Now most people won't have used SCTP so far, but it is a protocol used
as transport layer in a lot of telecom protocols for more than a decade
now. Virtually all protocols that have traditionally been spoken over
time-division multiplex E1/T1 links have been migrated over to SCTP
based protocol stackings.</p>
<p>Working on various Open Source telecom related projects, i of course
come into contact with SCTP every so often. Particularly some years
back when implementing the Erlang SIGTAN code in <a class="reference external" href="http://git.osmocom.org/erlang/osmo_ss7/tree/src">erlang/osmo_ss7</a> and most recently
now with the introduction of libosmo-sigtran with its OsmoSTP, both part
of the <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/">libosmo-sccp repository</a>.</p>
<p>I've also hard to work with various proprietary telecom equipment over
the years. Whether that's some eNodeB hardware from a large brand
telecom supplier, or whether it's a MSC of some other vendor. And they
all had one thing in common: Nobody seemed to use the Linux kernel SCTP
code. They all used proprietary implementations in userspace, using RAW
sockets on the kernel interface.</p>
<p>I always found this quite odd, knowing that this is the route that you
have to take on proprietary OSs without native SCTP support, such as
Windows. But on Linux? Why? Based on rumors, people find the Linux
SCTP implementation not mature enough, but hard evidence is hard to come
by.</p>
<p>As much as it pains me to say this, the kind of Linux SCTP bugs I have
seen within the scope of our work on Osmocom seem to hint that there is
at least some truth to this (see e.g.
<a class="reference external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1308360">https://bugzilla.redhat.com/show_bug.cgi?id=1308360</a> or
<a class="reference external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1308362">https://bugzilla.redhat.com/show_bug.cgi?id=1308362</a>).</p>
<p>Sure, software always has bugs and will have bugs. But we at Osmocom
are 10-15 years "late" with our implementations of higher-layer
protocols compared to what the mainstream telecom industry does. So if
we find something, and we find it even already during R&D of some
userspace code, not even under load or in production, then that seems a
bit unsettling.</p>
<p>One would have expected, with all their market power and plenty of
Linux-based devices in the telecom sphere, why did none of those large
telecom suppliers invest in improving the mainline Linux SCTP code? I
mean, they all use UDP and TCP of the kernel, so it works for most of
the other network protocols in the kernel, but why not for SCTP? I
guess it comes back to the fundamental lack of understanding how open
source development works. That it is something that the given
industry/user base must invest in jointly.</p>
</div>
<div class="section" id="the-leatest-discovered-bug">
<h2>The leatest discovered bug</h2>
<p>During the last months, I have been implementing SCCP, SUA, M3UA and
OsmoSTP (A Signal Transfer Point). They were required for an <a class="reference external" href="http://osmocom.org/versions/121">effort to
add 3GPP compliant A-over-IP to OsmoBSC and OsmoMSC</a>.</p>
<p>For quite some time I was seeing some erratic behavior when at some
point the STP would not receive/process a given message sent by one of
the clients (ASPs) connected. I tried to ignore the problem initially
until the code matured more and more, but the problems remained.</p>
<p>It became even more obvious when using <a class="reference external" href="https://github.com/nplab/m3ua-testtool">Michael Tuexen's m3ua-testtool</a>,
where sometimes even the most basic test cases consisting of sending +
receiving a single pair of messages like ASPUP -> ASPUP_ACK was failing.
And when the test case was re-tried, the problem often disappeared.</p>
<p>Also, whenever I tried to observe what was happening by meas of strace,
the problem would disappear completely and never re-appear until strace
was detached.</p>
<p>Of course, given that I've written several thousands of lines of new
code, it was clear to me that the bug must be in my code. Yesterday I
was finally prepare to accept that it might actually be a Linux SCTP
bug. Not being able to reproduce that problem on a FreeBSD VM also
pointed clearly into this direction.</p>
<p>Now I could simply have collected some information and filed a bug
report (which some kernel hackers at RedHat have thankfully invited me
to do!), but I thought my use case was too complex. You would have to
compile a dozen of different Osmocom libraries, configure the STP, run
the scheme-language m3ua-testtool in guile, etc. - I guess nobody
would have bothered to go that far.</p>
<p>So today I tried to implement a test case that reproduced the problem in
plain C, without any external dependencies. And for many hours, I
couldn't make the bug to show up. I tried to be as close as possible to
what was happening in OsmoSTP: I used non-blocking mode on client and
server, used the SCTP_NODELAY socket option, used the sctp_rcvmsg()
library wrapper to receive events, but the bug was not reproducible.</p>
<p>Some hours later, it became clear that there was one setsockopt() in
OsmoSTP (actually, libosmo-netif) which enabled all existing SCTP
events. I did this at the time to make sure OsmoSTP has the maximum
insight possible into what's happening on the SCTP transport layer, such
as address fail-overs and the like.</p>
<p>As it turned out, adding that setsockopt for SCTP_FLAGS to my test code
made the problem reproducible. After playing around which of the flags,
it seems that enabling the SENDER_DRY_EVENT flag makes the bug appear.</p>
<p>You can find my detailed report about this issue in
<a class="reference external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1442784">https://bugzilla.redhat.com/show_bug.cgi?id=1442784</a> and a program to
reproduce the issue at
<a class="reference external" href="http://people.osmocom.org/laforge/sctp-nonblock/sctp-dry-event.c">http://people.osmocom.org/laforge/sctp-nonblock/sctp-dry-event.c</a></p>
<p>Inside the Osmocom world, luckily we can live without the
SENDER_DRY_EVENT and a corresponding work-around has been submitted and
merged as <a class="reference external" href="https://gerrit.osmocom.org/#/c/2386/">https://gerrit.osmocom.org/#/c/2386/</a></p>
<p>With that work-around in place, suddenly all the <a class="reference external" href="https://github.com/nplab/m3ua-testtool">m3ua-testtool</a> and <a class="reference external" href="https://github.com/nplab/m3ua-testtool">sua-testtool</a> test cases are reliably green
(PASSED) and OsmoSTP works more smoothly, too.</p>
</div>
<div class="section" id="what-do-we-learn-from-this">
<h2>What do we learn from this?</h2>
<p>Free Software in the Telecom sphere is getting too little attention.
This is true even those small portions of telecom relevant protocols
that ended up in the kernel like SCTP or more recently the GTP module I
co-authored. They are getting too little attention in development, even
more lack of attention in maintenance, and people seem to focus more on
not using it, rather than fixing and maintaining what is there.</p>
<p>It makes me really sad to see this. Telecoms is such a massive
industry, with billions upon billions of revenue for the classic telecom
equipment vendors. Surely, they would be able to co-invest in some
basic infrastructure like proper and reliable testing / continuous
integration for SCTP. More recently, we see millions and more millions
of VC cash burned by buzzword-flinging companies doing "NFV" and
"SDN". But then rather reimplement network stacks in userspace than to
fix, complete and test those little telecom infrastructure components
which we have so far, like the SCTP protocol :(</p>
<p>Where are the contributions to open source telecom parts from Ericsson,
Nokia (former NSN), Huawei and the like? I'm not even dreaming about
the actual applications / network elements, but merely the maintenance
of something as basic as SCTP. To be fair, Motorola was involved early
on in the Linux SCTP code, and Huawei contributed a long series of fixes
in 2013/2014. But that's not the kind of long-term maintenance
contribution that one would normally expect from the primary interest
group in SCTP.</p>
<p>Finally, let me thank to the Linux SCTP maintainers. I'm not
complaining about them! They're doing a great job, given the arcane code
base and the fact that they are not working for a company that has
SCTP based products as their core business. I'm sure the would love
more support and contributions from the Telecom world, too.</p>
</div>SIGTRAN/SS7 stack in libosmo-sigtran merged to masterhttps://laforge.gnumonks.org/blog/20170410-libosmo-sigtran/2017-04-10T00:00:00+02:002017-04-10T00:00:00+02:00Harald Welte<p>As I blogged in <a class="reference external" href="https://laforge.gnumonks.org/blog/20170212-libosmo_sigtran/">my blog post in Fabruary</a>, I was working towards a more
fully-featured SIGTRAN stack in the Osmocom (C-language) universe.</p>
<p>The trigger for this is the support of 3GPP compliant AoIP (with a
BSSAP/SCCP/M3UA/SCTP protocol stacking), but it is of much more general
nature.</p>
<p>The code has finally matured in my development branch(es) and is now
ready for mainline inclusion. It's a series of <a class="reference external" href="https://gerrit.osmocom.org/#/q/project:libosmo-sccp+branch:master+topic:sigtran">about 77 (!) patches</a>,
some of which already are the squashed results of many more incremental
development steps.</p>
<p>The result is as follows:</p>
<ul class="simple">
<li><p>General SS7 core functions maintaining links, linksets and routes</p></li>
<li><p>xUA functionality for the various User Adaptations (currently <a class="reference external" href="https://www.ietf.org/rfc/rfc3868.txt">SUA</a> and <a class="reference external" href="https://tools.ietf.org/html/rfc4666">M3UA</a> supported)</p>
<ul>
<li><p>MTP User SAP according to <a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.701-199303-I!!PDF-E&type=items">ITU-T Q.701</a> (using osmo_prim)</p></li>
<li><p>management of application servers (AS)</p></li>
<li><p>management of application server processes (ASP)</p></li>
<li><p>ASP-SM and ASP-TM state machine for ASP, AS-State Machine (using osmo_fsm)</p></li>
<li><p>server (SG) and client (ASP) side implementation</p></li>
<li><p>validated against ETSI TS 102 381 (by means of Michael Tuexen's <a class="reference external" href="https://github.com/nplab/m3ua-testtool">m3ua-testtool</a>)</p></li>
<li><p>support for dynamic registration via RKM (routing key management)</p></li>
<li><p><code class="docutils literal"><span class="pre">osmo-stp</span></code> binary that can be used as Signal Transfer Point, with
the usual "Cisco-style" command-line interface that all Osmocom
telecom software has.</p></li>
</ul>
</li>
<li><p>SCCP implementation, with strong focus on Connection Oriented SCCP (as
that's what the A interface uses).</p>
<ul>
<li><p>osmo_fsm based state machine for SCCP connection, both incoming and
outgoing</p></li>
<li><p>SCCP User SAP according to <a class="reference external" href="https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Q.711-200103-I!!PDF-E&type=items">ITU-T Q.711</a> (osmo_prim based)</p></li>
<li><p>Interfaces with underlying SS7 stack via MTP User SAP (osmo_prim based)</p></li>
<li><p>Support for SCCP Class 0 (unit data) and Class 2 (connection oriented)</p></li>
<li><p>All SCCP + SUA Address formats (Global Title, SSN, PC, IPv4 Address)</p></li>
<li><p>SCCP and SUA share one implementation, where SCCP messages are
transcoded into SUA before processing, and re-encoded into SCCP after
processing, as needed.</p></li>
</ul>
</li>
</ul>
<p>I have already done experimental <a class="reference external" href="http://osmocom.org/projects/osmomsc/wiki">OsmoMSC</a> and <a class="reference external" href="http://osmocom.org/projects/osmohnbgw/wiki">OsmoHNB-GW</a> over to libosmo-sigtran.
They're now all just M3UA clients (ASPs) which connect to <code class="docutils literal"><span class="pre">osmo-stp</span></code>
to exchange SCCP messages back and for the between them.</p>
<p>What's next on the agenda is to</p>
<ul class="simple">
<li><p>finish my incomplete hacks to introduce IPA/SCCPlite as an alternative
to SUA and M3UA (for backwards compatibility)</p></li>
<li><p>port over OsmoBSC to the SCCP User SAP of libosmo-sigtran</p>
<ul>
<li><p>validate with SSCPlite lower layer against existing SCCPlite MSCs</p></li>
</ul>
</li>
<li><p>implement BSSAP / A-interface procedures in OsmoMSC, on top of the
SCCP-User SAP.</p></li>
</ul>
<p>If those steps are complete, we will have a single OsmoMSC that can talk
both IuCS to the HNB-GW (or RNCs) for 3G/3.5G as well as AoIP towards
OsmoBSC. We will then have fully SIGTRAN-enabled the full Osmocom
stack, and are all on track to bury the OsmoNITB that was devoid of such
interfaces.</p>
<p>If any reader is interested in interoperability testing with other
implementations, either on M3UA or on SCCP or even on A or Iu interface
level, please contact me by e-mail.</p>Returning from TelcoSecDay 2017 / General Musingshttps://laforge.gnumonks.org/blog/20170321-telcosecday-2017/2017-03-21T18:00:00+01:002017-03-21T18:00:00+01:00Harald Welte<p>I'm just on my way back from the <cite>Telecom Security Day 2017
<https://www.troopers.de/troopers17/telco-sec-day/></cite>, which is an
invitation-only event about telecom security issues hosted by ERNW
back-to-back with their <cite>Troopers 2017 <https://www.troopers.de/troopers17/></cite>
conference.</p>
<p>I've been presenting at TelcoSecDay in previous years and hence was
again invited to join (as attendee). The event has really gained quite
some traction. Where early on you could find lots of IT security /
hacker crowds, the number of participants from the operator (and to
smaller extent also equipment maker) industry has been growing.</p>
<p>The quality of talks was great, and I enjoyed meeting various familiar
faces. It's just a pity that it's only a single day - plus I had to
head back to Berlin still today so I had to skip the dinner + social
event.</p>
<p>When attending events like this, and seeing the interesting hacks that
people are working on, it pains me a bit that I haven't really been
doing much security work in recent years. netfilter/iptables was at
least somewhat security related. My work on OpenPCD / librfid was
clearly RFID security oriented, as was the work on airprobe,
OsmocomTETRA, or even the <a class="reference external" href="https://media.ccc.de/v/27c3-4036-en-reverse_engineering_a_real_word_rfid_payment_system">EasyCard payment system hack</a></p>
<p>I have the same feeling when attending Linux kernel development related
events. I have very fond memories of working in both fields, and it was
a lot of fun. Also, to be honest, I believe that the work in Linux
kernel land and the general IT security research was/is appreciated much
more than the endless months and years I'm now spending my time with
improving and extending the Osmocom cellular infrastructure stack.</p>
<p>Beyond the appreciation, it's also the fact that both the IT security
and the Linux kernel communities are much larger. There are more
people to learn from and learn with, to engage in discussions and
ping-pong ideas. In Osmocom, the community is too small (and I have the
feeling, it's actually shrinking), and in many areas it rather seems
like I am the "ultimate resource" to ask, whether about 3GPP specs or
about Osmocom code structure. What I'm missing is the feeling of being
part of a bigger community. So in essence, my current role in the "Open
Source Cellular" corner can be a very lonely one.</p>
<p>But hey, I don't want to sound more depressed than I am, this was
supposed to be a post about TelcoSecDay. It just happens that attending
IT Security and/or Linux Kernel events makes me somewhat gloomy for the
above-mentioned reasons.</p>
<p>Meanwhile, if you have some interesting projcets/ideas at the border
between cellular protocols/systems and security, I'd of course love to
hear if there's some way to get my hands dirty in that area again :)</p>Towards a real SIGTRAN/SS7 stack in libosmo-sigtranhttps://laforge.gnumonks.org/blog/20170212-libosmo_sigtran/2017-02-13T00:00:00+01:002017-02-13T00:00:00+01:00Harald Welte<p>In the good old days ever since the late 1980ies - and a surprising
amount even still today - telecom signaling traffic is still carried
over circuit-switched SS7 with its TDM lines as physical layer, and not
an IP/Ethernet based transport.</p>
<p>When Holger first created OsmoBSC, the BSC-only version of OpenBSC some
7-8 years ago, he needed to implement a minimal subset of SCCP wrapped
in TCP called <em>SCCP Lite</em>. This was due to the simple fact that the MSC
to which it should operate implemented this non-standard protocol
stacking that was developed + deployed before the IETF SIGTRAN WG
specified M3UA or SUA came around. But even after those were specified
in 2004, the 3GPP didn't specify how to carry A over IP in a standard
way until the end of 2008, when a first <a class="reference external" href="http://www.etsi.org/deliver/etsi_tr/143900_143999/143903/08.03.00_60/tr_143903v080300p.pdf">A interface over IP study</a>
was released.</p>
<p>As time passese, more modern MSCs of course still implement classic
circuit-switched SS7, but appear to have dropped SCCPlite in favor of
real AoIP as specified by 3GPP meanwhile. So it's time to add this to
the osmocom universe and OsmoBSC.</p>
<p>A couple of years ago (2010-2013) implemented both classic SS7
(MTP2/MTP3/SCCP) as well as SIGTRAN stackings (M2PA/M2UA/M3UA/SUA in
Erlang. The result has been used in some production deployments, but
only with a relatively limited feature set. Unfortunately, this code
has nto received any contributions in the time since, and I have to say
that as an open source community project, it has failed. Also, while
Erlang might be fine for core network equipment, running it on a BSC
really is overkill. Keep in miond that we often run OpenBSC on
really small ARM926EJS based embedded systems, much more resource
constrained than any single smartphone during the late decade.</p>
<p>In the meantime (2015/2016) we also implemented some minimal SUA support
for interfacing with UMTS femto/small cells via Iuh (see <a class="reference external" href="https://osmocom.org/projects/osmohnbgw/wiki">OsmoHNBGW</a>).</p>
<p>So in order to proceed to implement the required
SCCP-over-M3UA-over-SCTP stacking, I originally thought well, take
Holgers old SCCP code, remove it from the IPA multiplex below, stack it
on top of a new M3UA codebase that is copied partially from SUA.</p>
<p>However, this falls short of the goals in several ways:</p>
<ul class="simple">
<li><p>The application shouldn't care whether it runs on top of SUA or SCCP,
it should use a unified interface towards the SCCP Provider.
OsmoHNBGW and the SUA code already introduce such an interface baed on
the SCCP-User-SAP implemented using <a class="reference external" href="http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__prim.html">Osmocom primitives (osmo_prim)</a>.
However, the old OsmoBSC/SCCPlite code doesn't have such abstraction.</p></li>
<li><p>The code should be modular and reusable for other SIGTRAN stackings
as required in the future</p></li>
</ul>
<p>So I found myself sketching out what needs to be done and I ended up
pretty much with a re-implementation of large parts. Not quite fun, but
definitely worth it.</p>
<p>The strategy is:</p>
<ul class="simple">
<li><p>Implement the SCCP SCOC state machines for connection-oriented SCCP
(of which Iu and A interface are probably the only users) using
<a class="reference external" href="http://ftp.osmocom.org/api/latest/libosmocore/core/html/group__fsm.html">Osmcoom Finite State Machines (osmo_fsm)</a>.</p></li>
<li><p>Migrate the existing SUA code on top of that, maintaining the existing
osmo_prim based <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/tree/include/osmocom/sigtran/sccp_sap.h">SCCP User SAP</a></p></li>
<li><p>Implement <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/commit/?h=laforge/sigtran&id=dc923e49cd3b623dab05f6016a3e935d7c652cb3">SCCP to SUA and vice-versa message transcoding</a>
to makes sure the bulk of the code has to deal only with one message
format (parsed SUA).</p></li>
<li><p>Introduce a <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/commit/?h=laforge/sigtran&id=21c8a1bcc8f853f3da05d71c4b4fbea6faf53b24">MTP SAP</a>
at the lower boundary of the SCCP code</p></li>
<li><p>Implement <a class="reference external" href="http://git.osmocom.org/libosmo-sccp/commit/?h=laforge/sigtran&id=50e931338dfa1ad570734b80cce065ab611929aa">xUA ASP and AS statemachines using osmo_fsm</a>
and add ASPTM/ASPSM support to SUA (was missing so far) * Implement</p></li>
<li><p>Implement M3UA using the xUA ASP and AS FSMs as well as the general
<a class="reference external" href="http://git.osmocom.org/libosmo-sccp/tree/src/xua_msg.c">xUA message encoder/decoder</a>,
offering the MTP SAP toward SCCP</p></li>
</ul>
<p>And then finally stack all those bits on top of each other, rendering a
fairly clean and modern implementation that can be used with the IuCS of
the virtually unmodified OsmmoHNBGW, OsmoCSCN and OsmoSGSN for testing.</p>
<p>Next steps in the direction of the AoIP are:</p>
<ul class="simple">
<li><p>Implementation of the MTP-SAP based on the IPA transport</p></li>
<li><p>Binding the new SCCP code on top of that</p></li>
<li><p>Converting OsmoBSC code base to use the SCCP-User-SAP for its
signaling connection</p></li>
</ul>
<p>From that point onwards, OsmoBSC doesn't care anymore whether it
transports the BSSAP/BSSMAP messages of the A interface over
SCCP/IPA/TCP/IP (SCCPlite) SCCP/M3UA/SCTP/IP (3GPP AoIP), or even
something like SUA/SCTP/IP.</p>
<p>However, the 3GPP AoIP specs (unlike SCCPlite) actually modify the
BSSAP/BSSMAP payload. Rather than using Circuit Identifier Codes and
then mapping the CICs to UDP ports based on some secret conventions,
they actually encapsulate the IP address and UDP port information for
the RTP streams. This is of course the cleaner and more flexible
approach, but it means we'll have to do some further changes inside the
actual BSC code to accommodate this.</p>Testing (not only) telecom protocolshttps://laforge.gnumonks.org/blog/20170212-telecom-testing-ttcn/2017-02-12T00:00:00+01:002017-02-12T00:00:00+01:00Harald Welte<p>When implementing any kind of communication protocol, one always dreams
of some existing test suite that one can simply run against the
implementation to check if it performs correct in at least those use
cases that matter to the given application.</p>
<p>Of course in the real world, there rarely are protocols where this is
true. If test specifications exist at all, they are often just very
abstract texts for human consumption that you as the reader should
implement yourself.</p>
<p>For some (by far not all) of the protocols found in cellular networks,
every so often I have seen some formal/abstract machine-parseable test
specifications. Sometimes it was TTCN-2, and sometimes TTCN-3.</p>
<p>If you haven't heard about TTCN-3, it is basically a way to create
functional tests in an abstract description (textual + graphical), and
then compile that into an actual executable tests suite that you can run
against the implementation under test.</p>
<p>However, when I last did some research into this several years ago, I
couldn't find any Free / Open Source tools to actually use those
formally specified test suites. This is not a big surprise, as even
much more fundamental tools for many telecom protocols are missing, such
as good/complete ASN.1 compilers, or even CSN.1 compilers.</p>
<p>To my big surprise I now discovered that Ericsson had released their
(formerly internal) <a class="reference external" href="https://projects.eclipse.org/projects/tools.titan">TITAN TTCN3 Toolset</a>
as Free / Open Source Software under EPL 1.0. The project is even part
of the Eclipse Foundation. Now I'm certainly not a friend of Java or
Eclipse by all means, but well, for running tests I'd certainly not
complain.</p>
<p>The project also doesn't seem like it was a one-time code-drop but seems
very active with many repositories on gitub. For example for the core
module, <a class="reference external" href="https://github.com/eclipse/titan.core">titan.core</a> shows
plenty of activity on an almost daily basis. Also, <a class="reference external" href="https://projects.eclipse.org/projects/tools.titan/downloads">binary releases for
a variety of distributions are made available</a>. They
even have a <a class="reference external" href="https://www.youtube.com/watch?v=T__msvMhhHQ&feature=youtu.be">video showing the installation</a> ;)</p>
<p>If you're curious about TTCN-3 and TITAN, Ericsson also have made
available a great <a class="reference external" href="https://www.eclipse.org/downloads/download.php?file=/titan/TITAN_User_P.pdf">200+ pages slide set about TTCN-3 and TITAN</a>.</p>
<p>I haven't yet had time to play with it, but it definitely is rather high
on my TODO list to try.</p>
<p>ETSI provides a couple of test suites in TTCN-3 for protocols like
DIAMETER, GTP2-C, DMR, IPv6, S1AP, LTE-NAS, 6LoWPAN, SIP, and others at
<a class="reference external" href="http://forge.etsi.org/websvn/">http://forge.etsi.org/websvn/</a> (It's also the first time I've seen that
ETSI has a SVN server. Everyone else is using git these days, but yes,
revision control systems rather than periodic ZIP files is definitely a
big progress. They should do that for their reference codecs and ASN.1
files, too.</p>
<p>I'm not sure once I'll get around to it. Sadly, there is no TTCN-3 for
SCCP, SUA, M3UA or any SIGTRAN related stuff, otherwise I would want to
try it right away. But it definitely seems like a very interesting
technology (and tool).</p>