Osmocom Planet Osmocom
Open Source Mobile Communications

December 27, 2020

Osmocom.org News: E1/T1 Hardware Interface (including icE1usb) - Development of DAHDI driver for icE1usb

So far, the icE1usb reuired a custom user-space driver (osmo-e1d) in order to operate. While this has the advantage that no kerne/operating system level code is required, it has a few disadvantages such as the increased overhead of frequent context switches, the increased propability of overruns/underruns and the lack of interoperability with other software outside the Osmocom universe.

A first version of a DAHDI hardware driver for icE1usb is now available for public beta-testing, for details see redmine issue #4923

Using this DAHDI driver, it should be possible to use icE1usb with any DAHDI-using application, such as Asterisk, FreeSWITCH and others.

Osmocom.org News: E1/T1 Hardware Interface (including icE1usb) - Osmocom icE1usb USB E1 adapter available from sysm...

Fully assembled and tested icE1usb adapters are now available via the sysmocom webshop for purchase.

As a fully Open Source Hardware (OSHW) design, anyone can of course assemble their own hardware units based on the design files within the git repository.

December 04, 2020

Dieter Spaar: Modern TPMS Sensors: Let's try a DoS attack

TPMS (Tire-pressure monitoring system) sensors have been researched extensively many years ago, they periodically transmit the tire pressure, temperature and a unique ID which can be misused for tracking a vehicle. But there is another aspect: modern TMPS sensors also have a receiver which is typically used to trigger the data transmission when a new TPMS sensor is presented to the vehicle ("learning procedure").

Here in Europe TPMS sensors usually transmit on the 433 MHz ISM band. The receiver operates on 125 kHz, very similar to LF RFID. A simple way to make use of the receiver is just to look for the presence of the 125 kHz carrier and then trigger data transmission. Current sensors are usually more evolved and use a modulated carrier which contains command packets and only if the correct command is received data transmission is triggered.

If you already have a receiver you can do of course more than just trigger data transmission: For example there might be support for different commands, some sensors even allow firmware updates this way.

One such command which is typically supported is switching the sensor into "Shipping" mode. Why would you need that? When the sensor is operating normally it waits for motion (there is an acceleration/shock sensor inside) and only starts periodic data transmission when the wheel is rotating. This is used to safe battery life. When the TPMS sensor is not yet mounted in the tire it should not react on motion, that’s why there is this "Shipping" mode. In this mode the sensor only wakes up every few seconds and looks if there is a 125 kHz signal, if yes it checks for a valid command, for example the command to trigger data transmission which usually also leaves "Shipping" mode and switches the sensor into normal operation.

This "Shipping" mode can be misused: If you can switch a TPMS sensor of a vehicle’s wheel into "Shipping" mode the sensor will no longer transmit data and the vehicle's tire pressure control light will go on after a while. Just to make it clear: This warning light is annoying to the driver, it does not affect safety of the car because the deactivated TMPS sensor has not affected the actual tire pressure.

I have looked at a few TPMS sensors for different cars if this really works, I choose sensors for BMW and Ford cars. Please note that most certainly other car manufactures are affected too, mainly because there are only a few manufactures of TPMS sensors which deliver their sensors to various car manufactures. My choice for BMW and Ford came from the fact that I found lots of cheap, used sensor for those cars.

Also I only looked at "OEM" sensors for BMW and Ford, which means that those sensors are mounted by the car manufacturer. There are also so called "Universal" sensors which are typically mounted by tire dealers, there are some notes about them at the end of this text.

It is quite easy to build a tool for transmitting data on 125 kHz: There is this cheap EL-50448 TMPS sensor activation tool which only transmits a carrier without modulation. However the hardware can easily be modified to modulate the carrier: Most of the time OOK (On-Off Keying) is used for communication, which means that the carrier is just turned on and off. The EL-50448 uses a power driver with an unused "enable" pin to generate the carrier, you can use this "enable" pin to modulate the carrier. The data rate is slow, a frequently used rate is 3900 baud. Most of the time Manchester encoding of the data bits is used, which means that the carrier changes twice as much (7800 changes per second). This is nothing special and can be done with probably any microcontroller you prefer to use. The hardware costs for such a setup are below EUR 20, the transmission range is about 20 centimeters.

How can you find the command to switch to Shipping" mode? Brute force by trying all possible commands is only an option if the command is short. The reason is that the sensor only looks for the LF 125 kHz signal every few seconds. If the command is not longer than two bytes brute force is possible (it takes a few days), for longer commands it is impractical. Please note that you also have to find a way to detect if the command you send causes a reaction of the TPMS sensor, e.g. by monitoring the power consumption of the sensor or receiving the 433 MHz data signal (which of course only works if the command you send causes a data transmission).

Another option is looking at those TPMS tools which tire dealers and car repair workshops use to check TPMS sensors. Some of those tools might support switching a TPMS sensor into "Shipping" mode.

Those are the results I found (I won't go into the details to avoid misuse):

  • BMW: A certain sensor used in several car models from TPMS Sensor manufacturer "A" can be switched into "Shipping" mode. The deactivated TPMS sensor can be activated again with a different command. Also if the sensor detects a fast pressure change (e.g. by inflating the tire) the sensor leaves "Shipping" mode. The command length is four bytes so brute force is no option.
  • Ford: A certain sensor used in several car models from TPMS Sensor manufacturer "A" (the same manufacture as above for the BMW sensor) can be switched into "Shipping" mode, it is the same command as used by the BMW sensor from above. The deactivated TPMS sensor can be activated again with a different command.

    A certain sensor used in several car models from TPMS Sensor manufacturer "B" can be switched into "Shipping" mode. The deactivated TPMS sensor can be activated again with a different command. The command in this case is only two bytes and I tried all combinations which resulted in several more "interesting" commands, a few examples:

    • It is possible to completely turn off the TPMS sensor. In this case it will no longer react on anything, you have to break open the sensor case and apply a hardware reset or disconnect the battery to reactivate it again.
    • It is possible to switch the sensor into continuous "carrier transmit" mode on 433 MHz. In this mode the sensor will continuously transmit the 433 MHz carrier until the battery is empty or you apply a hardware reset (see above), it will not react on anything else. There are two other similar commands which transmit on the upper and lower shifted frequency (the sensor uses FSK modulation, Frequency Shift Keying, when transmitting data).

    Those examples show that it is basically possible to destroy this specific sensor by transmitting the appropriate command. Also if the sensor is in "carrier transmit" mode it probably disturbs the remote control car key fob which usually uses the same frequency as the TPMS sensor.

You have to be close to the sensor to send those LF 125 kHz signals but it only takes a few seconds to send the signal. Using a larger antenna (which is basically a coil) for the transmitter, e.g. large enough to fit in a suitcase, might extend the transmission range to more than a meter.

How can those problems be avoided? This is actually quite easy, the command to switch into "Shipping" mode should not be allowed if the measured tire pressure is above a certain limit, which means that the sensor is mounted in the tire of a vehicle. This also applies to those other commands of the sensor from manufacturer "B" which are probably some kind of factory test or developer commands. Please note that during my tests the commands I described were possible even when the measured tire pressure was in the range of a typical vehicle wheel.

I contacted the car manufactures (BMW and Ford) before I published this article, this is the experience I made:

  • BMW: The contact information for reporting security issues can be found on the BMW website. I had a phone call with the responsible person within a few days after reporting the issue. BMW already knew the problem, they found it during an internal review. Their latest TPMS sensors have fixed the issue by blocking certain commands if the tire pressure is above a certain limit.
  • Ford: I wasn't able to find a security contact on the website of Ford Germany so I contacted the person responsible for "Public Relation". He promised to look for someone who takes care of the issue I reported, after several days I got a reply that it is possible to disturb the TPMS system due to the nature of radio transmission and that this is a known problem. I wasn't able to communicate directly with the responsible person and I then replied that the reported issue is not about disturbance but a "Denial of Service" and that it is even possible to destroy a certain TPMS sensor used in Ford cars. I didn't receive any further information about the security issue, I notified them again after several weeks that I am now going to publish the issue which was acknowledged.

Some notes about those "Universal" sensors tire dealers normally use: Those sensors are "Universal" because they can be programmed for different car models. The main benefit for the tire dealer is that only a few different kind of "Universal" sensors have to be on stock, it’s not necessary to have lots of different "OEM" TPMS sensors for every possible car model lying around. The programming of those "Universal" sensors most of time uses the LF 125 kHz signal to transfer the programming data to the sensor. Many of those "Universal" sensors can be reprogrammed regardless of the measured tire pressure so an obvious "Denial of Service" attack on those sensors is to simply reprogram them for a different car model.

October 03, 2020

Osmocom.org News: Osmocom.org Servers - gerrit and jenkins upgrades

Our gerrit instance at https://gerrit.osmocom.org has been upgraded from 2.16.x to the latest release 3.2.3. This migrates us away from an (since June) unsupported 2.16.x release.

For https://jenkins.osmocom.org/ we just did a minor LTS upgrade from 2.235.2 to 2.249.1

If there are any problems, please report them in the bug tracker associated with this "Osmocom.org Servers" project in redmine.

July 20, 2020

Osmocom.org News: Osmocom.org Servers - scheduled Osmocom outage on *2020-07-21 7:30am CEST*

There will be another scheduled outage of most public Osmocom services (redmine, jenkins, gerrit) on 2020-07-21 7:30am CEST with an expected maximum duration of 45 minutes.

July 17, 2020

Osmocom.org News: Osmocom.org Servers - scheduled Osmocom outage on *2020-07-19 9am CEST*

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on Sunday, July 19 2020, starting about 9am CEST.

The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit.

In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law.

Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate.

In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github.

Regards, laforge

May 08, 2020

Osmocom.org News: Distributed GSM - Distributed GSM: Merged to OsmoHLR

The D-GSM implementation developed under a Mozilla MOSS grant is now complete and merged to the OsmoHLR master branch. It is hence featured in OsmoHLR's Nightly Builds, and will be included in the next OsmoHLR release (upcoming OsmoHLR v1.21).

Distributed GSM is a unique feature set tailored to non-centralized collaboration of communal mobile network sites, as explained in this news post from a few months ago: Distributed GSM / Multicast MS Lookup. Compared to traditional (centralized, highly available) core networks, the most novel aspects of D-GSM are that it allows mobile network sites to roam its subscribers and connect calls without any central entity, and that it minimizes disruption that may be caused by unstable links between sites.

Find full documentation in the OsmoHLR User Manual: there is a new section called "Distributed GSM / Multicast MS Lookup", explaining how to configure and run D-GSM in all detail. Find the latest manuals here.

Please go ahead and give D-GSM a spin, and let us know of any feedback!

January 08, 2020

Osmocom.org News: Cellular Network Infrastructure - January 2020 Osmocom CNI releases

The Osmocom project has released new version 202001 of the CNI (Cellular Network Infrastructure) software, including OsmoTRX, OsmoBTS, OsmoPCU, OsmoBSC, OsmoMGW, OsmoMSC, OsmoHLR, OsmoSGSN, OsmoGGSN, OsmoSTP, OsmoSIPConnector, and others.

Those new tagged/released versions contain five months of work since the previous versions released during August 2019. The primary focus was on bug-fixing and stabilization as well as some major new features, such as inter-MSC-handover support in osmo-msc.

You can find pre-compiled binary packages of our latest release for a variety of Debian and Ubuntu GNU/Linux versions at Latest_Builds.

List of tagged versions and link to related ChangeLog

Project Version Changelog
libosmocore 1.3.0 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.3.0
libosmo-abis 0.8.0 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=0.8.0
libosmo-netif 0.7.0 http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=0.7.0
libosmo-sccp (+ OsmoSTP) 1.2.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.2.0
osmo-iuh (+ OsmoHNBGW) 0.6.0 http://git.osmocom.org/osmo-iuh/plain/debian/changelog?h=0.6.0
OsmoTRX 1.2.0 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.2.0
OsmoBTS 1.2.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.2.0
OsmoPCU 0.8.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=0.8.0
OsmoBSC 1.6.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.6.0
OsmoMSC 1.6.1 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.6.1
OsmoHLR 1.2.0 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.2.0
OsmoMGW 1.7.0 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.7.0
OsmoSIPConnector 1.4.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.4.0
OsmoSTP 1.1.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.1.0
OsmoSGSN 1.5.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.5.0
OsmoGGSN 1.5.0 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.5.0
OsmoPCAP 0.1.2 http://git.osmocom.org/osmo-pcap/plain/debian/changelog?h=0.1.2
osmo-gsm-manuals 0.3.0 http://git.osmocom.org/osmo-gsm-manuals/plain/debian/changelog?h=0.3.0

Noteworthy Changes

Misc / Common

  • libosmocore: logging (and other subsystem) improvements for multi-thread processes (like osmo-trx)
  • libosmocore, libosmo-netif, libosmo-sccp: multi-address (multi-homing) support (multi-homing) and configure flags for libsctp (--enable-libsctp)
  • libosmocore: integration of libusb in libosmocore's main loop (--enable-libusb)
  • libosmocodec: new generic Error Concealment Unit abstraction
  • libosmovty: Several crash fixes and improvements regarding command parsing, node tracking, etc.
  • libosmogsm: add support for XOR authentication
  • libosmo-abis: DAHDI support fixes and improvements. It is now enabled by default (--enable-dahdi)
  • osmo-iuh: First version of libosmo-sabp now available, containing SABP ASN.1 from 3GPP TS 25.419 V11.1.0
  • osmo-iuh: First version of OsmoHNBGW User Manual now available.
  • Add code coverage support
  • port most python scripts to use python3 (python2 will become deprecated soon)
  • Improve reproducibility, fix sporadic failures of some tests


  • Improved robustness all along the code, fixing several crashes and regressions, avoiding unnoticed underrun events, etc.
  • Lots of logging improvements (use libosmocore multi-thread lock API, print channel, new log categories, support libuhd's >=3.11 logging system, etc.)
  • Several fixes in TRXDv1 and TRXC (avoid dropping ul idle indications, wrong responses on some CMDs, etc.)
  • Improved performance in some specific cases (Enable EDGE detection only on PDCH timeslots)
  • Multi-arfcn improvements: ARFCN setup verficiation (RXTUNE/TXTUNE), code cleanup
  • vty: Simplify filler burst settings and improve help and readability


  • Increased robustness and small fixes and improvements all over the code
  • Several fixes and improvements in PCU interface: fix endian-swapped CellID, forward ETWS Primary Notification, set correct ARFCN, etc.
  • New improved generic MS Power Control Loop available for all BTS variants ("ms-power-control osmo")
  • Migrate to use new libosmocore's generic ECU abstraction
  • Several fixes and improvements for measurement reports.
  • vty: add "logging filter l1-sapi"
  • bts-trx: Fix several inconsistencies in TRX setup and lifecycle management of each TRX, clock availability, etc.
  • bts-trx: Improvements thanks to information available from TRX using TRXDv1 (C/I, ToA, etc.)
  • bts-trx: Improvements handling PDCH: fix handling of PTCCH/U and PTCCH/D logical channels, detect TSC for Access Burstsm etc.


  • Improve User Manual documentation
  • Forward ETWS Primary Notification to MS
  • Several crash, assertion fixes and robustness improvements
  • GSMTAP support improved, with more categories and fixes on existing ones
  • Move some of the existing timer infrastructure to use osmo_tdef
  • PTCCH support added
  • bssgp: do not reject SUSPEND ACK / NACK messages
  • vty: fix command 'show tbf all': properly filter TBFs


  • Cell Broadcast: CBSP and CBCH scheduling support
  • SMSCB: Send ETWS primary Notification/Warning
  • Fix RSL connection timeout for TRX other than first one
  • Send IE MS Power Param during CHAN ACT (to osmo-bts only, to enable Autonomous MS Power Control Loop in BTS)
  • Decode classmark of MS and infer its the maximum MS Power Control level, then tell the BTS through MS PWR CTRL message
  • Support SCTP multi-homing in AoIP, lots of sigtran improvements (thanks to new libosmo-sccp)
  • Several crashes fixes, robustness and logging improved


  • Improvements in SGs interface and CSBF
  • Several crash fixes, memory leak fixes, robustness and logging improved, specially during Call Control
  • MNCC v6: add optional SDP to the socket protocol. Now SDP can be passed SIP<->MSC<->MGW.
  • Improved counter documentation
  • Fix SM-RP-OA encoding for MO SMS over GSUP
  • Implement a VTY global switch on the network to disable call waiting ("[no] call-waiting")
  • Support SCTP multi-homing in AoIP, lots of sigtran improvements (thanks to new libosmo-sccp)

OsmoHLR (and libosmo-gsup-client)

  • Add --db-check program option
  • Update tb dv schema v4 (and lots of infra added to test schema update)
  • AUC: Add support for setting the AMF separation bit to '1' for EUTRAN
  • Make tests more robust: return codes on mipsel and alpha archs, test_nodez.vty expectancies, etc.
  • Several crash fixes and increased robustness

OsmoMGW (and libosmo-mgcp-client)

  • Improvements in codec parsing and management
  • Several crash fixes, memleak fixes and increased robustness


  • MNCC v6: add optional SDP to the socket protocol
  • logging from sofia: add missing newline
  • Fixes in systemd's osmo-sip-connector.service dependencies
  • Several robustness improvements

OsmoSTP (and libosmo-sigtran)

  • Introduce SCTP multi-homing (multi address socket) support
  • Support for all SS7 traffic modes: override, load-share, broadcast
  • Dynamic ASP creation in AS for IPA connetions (identified by IPA unit id)
  • Configure freely IPA/SCTP links as client or server, and M3UA link role as SGW or ASP
  • osmo_sccp_simple_client(): use sccp instance index 0 instead of 1
  • A lot more other SS7 protocol stack fixes and improvements


  • File/directory structure cleanup
  • Initial OsmoGbPROXY user manual
  • Fix of some long standing bugs and crashes
  • LLC: Don't use hard-coded N201-U / N201-I values in XID
  • Improved Iu/RANAP support and related fixes
  • Logging improvements
  • Migrate timers to osmo_tdef
  • gtp: Drop related pdp contexts on echo timeout against GGSN
  • Lots of improvements in (P)MM state FSMs: related timers, actions, etc.
  • Gb: implement PS Paging when MS is MM_STANDBY

OsmoGGSN (and libgtp)

  • Implement echo req/resp and recovery
  • libgtp: Manage queue timers internally
  • libgtp: Remove packets in tx queue belonging pdp being freed
  • Improvedd logging
  • Some IPv6 related fixed
  • Several crash fixes and improved robustness

January 04, 2020

Harald "LaForge" Welte: 36C3 Talks on SIM card technology / Mitel DECT

At 36C3 in December 2019 I had the pleasure of presenting: One full talk about SIM card technology from A to Z and another talk where I presented together with eventphone team members about Security issues in the Mitel SIP-DECT system.

The SIM card talk was surprisingly successful, both in terms of a full audience on-site, as well as in terms of the number of viewers of the recordings on media.ccc.de. SIM cards are a rather niche topic in the wider IT industry, and my talk was not covering any vulnerabilities or the like. Also, there was nothing novel in the talk: SIM cards have been around for decades, and not much has changed (except maybe eSIM and TLS) in recent years.

In any case, I'm of course happy that it was well received. So far I've received lots of positive feedback.

As I'm working [more than] full time in cellular technology for almost 15 years now, it's sometimes hard to imagine what kind of topics people might be interested in. If you have some kind of suggestion on what kind of subject within my area of expertise you'd like me to talk about, please don't hesitate to reach out.

The Mitel DECT talk also went quite well. I covered about 10 minutes of technical details regarding the reverse engineering of the firmware and the communication protocols of the device. Thanks again to Dieter Spaar for helping with that. He is and remains the best reverse engineer I have met, and it's always a privilege to collaborate on any project. It was of course also nice to see what kind of useful (and/or fun) things the eventphone team have built on top of the knowledge that was gained by protocol-level reverse engineering.

If you want to know more low-level technical detail than the 36C3 talk, I recommend my earlier talk at the OsmoDevCon 2019 about Aastra/Mitel DET base station dissection.

If only I had more time, I would love to work on improving the lack of Free / Open Source Software realted to the DECT protocol family. There's the abandoned deDECTed.org, and the equally abandoned dect.osmocom.org project. The former only deals with the loewst levels of DECT (PHY/MAC). The latter is to a large extent implemented as part of an ancient version of the Linux kernel (I would say this should all run in userspace, like we run all of GSM/UMTS/LTE in userspace today).

If anyone wants to help out, I still think working on the DECT DLC and NWK dissectors for wireshark is the best way to start. It will create a tool that's important for anyone working with the DECT protocols, and it will be more or less a requirement for development and debugging should anyone ever go further in terms of implementing those protocols on either the PP or FP side. You can find my humble beginnings of the related dissectors in the laforge/dect branch of osmocom.org/wireshark.git.

Harald "LaForge" Welte: Retronetworking / BBS-Revival setup at #36C3

After many years of being involved in various projects at the annual Chaos Communication Congress (starting from the audio/vidoe recording team at 15C3), I've finally also departed the GSM team, i.e. the people who operate (Osmocom based) cellular networks at CCC events.

The CCC Camp in August 2019 was slightly different: Instead of helping an Osmocom based 2G/3G network, I decided to put up a nextepc-based LTE network and make that use the 2G/3G HLR (osmo-hlr) via a newly-written DIAMETER-to-GSUP proxy. After lots of hacking on that proxy and fixing various bugs in nextepc (see my laforge/cccamp2019 branch here) this was working rather fine.

For 36C3 in December 2019 I had something different in mind: It was supposed to be the first actual demo of the retronetworking / bbs-revival setup I've been working on during past months. This setup in turn is sort-of a continuation of my talk at 34C3 two years ago: BBSs and early Intenet access in the 1990ies.

Rather than just talking about it, I wanted to be able to show people the real thing: Actual client PCs running (mainly) DOS, dialling over analog modems and phone lines as well as ISDN-TAs and ISDN lines into BBSs, together with early Interent access using SLIP and PPP over the same dial-up lines.

The actual setup can be seen at the Dialup Network In A Box wiki page, together with the 36C3 specific wiki page.

What took most of the time was - interestingly - mainly two topics:

  1. A 1U rack-mount system with four E1 ports. I had lots of old Sangoma Quad-E1 cards in PCI form-factor available, but wanted to use a PC with a more modern/faster CPU than those old first-generation Atom boxes that still had actual PCI slots. Those new mainboards don't have PCI but PCIe. There are plenty of PCIe to PCI bridges and associated products on the market, which worked fine with virtually any PCI card I could find, but not with the Sangoma AFT PCI cards I wanted to use. Seconds to minutes after boot, the PCI-PCIe bridges would always forget their secondary bus number. I suspected excessive power consumption or glitches, but couldn't find anything wrong when looking at the power rails with a scope. Adding additional capacitors on every rail also didn't change it. The !RESET line is also clean. It remains a mystery. I then finally decided to but a new (expensive) DAHDI 4-port E1 PCIe card to move ahead. What a waste of money if you have tons of other E1 cards around.

  2. Various trouble with FreeSWITCH. All I wanted/needed was some simple emulation of a PSTN/ISDN switch, operating in NT mode towards both the Livingston Portmaster 3 RAS and the Auerswald PBX. I would have used lcr, but it supports neither DAHDI nor Sangoma, but only mISDN - and there are no mISDN cards with four E1 ports :( So I decided to go for FreeSWITCH, knowing it has had a long history of ISDN/PRI/E1 support. However, it was a big disappointment. First, there were some segfaults due to a classic pointer deref before NULL-check. Next, libpri and FreeSWITCH have a different idea how channel (timeslot) numbers are structured, rendering any call attempt to fail. Finally, FreeSWITCH decided to blindly overwrite any bearer capabilities IE with 'speech', even if an ISDN dialup call (unrestricted digital information) was being handled. The FreeSWITCH documentation contains tons of references on channel input/output variables related to that - but it turns out their libpri integration doesn't set any of those, nor use any of them on the outbound side.

Anyway, after a lot more time than expected the setup was operational, and we could establish modem calls as well as ISDN dialup calls between the clients and the Portmaster3. The PM3 in turn then was configured to forward the dialup sessions via telnet to a variety of BBSs around the internet. Some exist still (or again) on the public internet. Some others were explicitly (re)created by 36C3 participants for this very BBS-Revival setup.

My personal favorite was finding ACiD Underworld 2.0, one of the few BBSs out there today who support RIPscrip, a protocol used to render vector graphics, text and even mouse-clickable UI via modem connection to a DOS/EGA client program called RIPterm. So we had one RIPterm installation on Novell DOS7 that was just used for dialling into ACiD Underworld 2.0.

Among other things we also tested interoperability between the 1980ies CCC DIY accoustic coupler "Datenklo" and the Portmaster, and confirmed that Windows 2000 could establish multilink-PPP not only over two B-channels (128 kbps) but also over 3 B-Channels (192).

Running this setup for four days meant 36C3 was a quite different experience than many previous CCC congresses:

  • I was less stressed as I wasn't involved in operating a service that many people would want to use (GSM).

  • I got engaged with many more people with whom I would normally not have entered a conversation, as they were watching the exhibits/demos and we got to chat about the technology involved and the 'good old days'.

So all in all, despite the last minute FreeSWITCH-patching, it was a much more relaxing and rewarding experience for me.

Special thanks to

  • Sylvain "tnt" Munaut for spending a lot of time with me at the retronetworking assembly. The fact that I had an E1 interface around was a good way for him to continue development on his ICE40 based bi-directional E1 wiretap. He also helped with setup and teardown.

  • miaoski and evanslify for reviving two of their old BBSs from Taiwan so we could use them at this event

The retronetworking setup is intended to operate at many other future events, whether CCC related, Vintage Computing or otherwise. It's relatively small and portable.

I'm very much looking forward to the next incarnations. Until then, I will hopefully have more software configured and operational, including a variety of local BBSs (running in VMs/containers), together with the respective networking (FTN, ZConnect, ...) and point software like CrossPoint.

If you are interested in helping out with this project: I'm very much looking for help. It doesn't matter if you're old and have had BBS experience back in the day, or if you're a younger person who wants to learn about communications history. Any help is appreciated. Please reach out to the bbs-revival@lists.osmocom.org mailing list, or directly to me via e-mail.

January 02, 2020

Osmocom.org News: SIM card related Projects - Video: SIM Card Technology from A to Z

Osmocom founder LaF0rge has presented a talk titled SIM Card Technology from A to Z at the 36th annual Chaos Communication Congress

The talk tries to be an in-depth technical introduction into various aspects of SIM cards, ranging from relevant standards, electrical aspects, protocols, command set, operating systems all the way up to SIM toolkit, proactive SIM and also slightly touch eSIM.

If you're interested, you can find the following related resources:

Osmocom.org News: Retro-Networking / BBS-Revival - Successful setup at #36C3

The Osmocom Retro-Networking / BBS-Revival project has successfully been operating at the 36th annual Chaos Communication Congress where it was known as the Retronetworking / BBS-Revival Assembly.

At this assembly, we operated our Dialup_Network_In_A_Box setup, providing both analog telephone lines as well as ISDN BRI (S0) interfaces for dial-up. We could verify that the physical layer (telephony) was working as expected, and had a variety of demonstrations:
  • dial-up to a variety of (ANSI) BBSs from TELIX on MS-DOS 6.22
  • dial-up to a RIPscrip BBS (ACiD Underworld 2 from RIPterm on Novell DOS 7
  • dial-up to a BBS from a Datenklo (DIY accoustic coupler with 300 bps)
  • dial-up internet access using PPP over analog modem (Interfax at 28.8 kbps) lines
    • tested from Windows 95
  • dial-up internet access using PPP over ISDN lines
    • tested from Windows 2000 with 1 B-channel but also bundling up to 3 B-channels resulting in blazingly-fast 192 kbps

Many people were interested in the setup - both those remembering the good old BBS days, as well as those who didn't witness it back then. Clearly, the modem connect sounds from the USR Sportster (set to highest volume) were drawing most attention. ISDN is boring in comparison ;)

We also had several visitors who would either bring their own computer + modem (for example Aminga 500 or x86 PC with Windows 2000) and connect to the system. Equally, several others have borrowed some modems from our pool to connect with their own machines. One supporter even brought their own DOS BBS, ran it in a VM on Linux and set up actual modem dial-in to that BBS on the venue itself.

All in all, it was a successful first event for the project to participate. As the core setup is running now, future events will likely have more emphasis on the software side of things, i.e. showcasing a variety of different protocols and systems, such as FTN networks, QWK readers, Zerberus/ZConnect/CrossPoint, etc.

If you're interested in working on any of this, your contribution is more than welcome. Feel free to reach out at the bbs-revival mailing list

December 19, 2019

Harald "LaForge" Welte: Software Freedom Podcast #3 about Free Software mobile phone communication

Recently I had the pleasure of being part of the 3rd incarnation of a new podcast series by the Free Software Foundation Europe: The Software Freedom Podcast.

In episode 3, Matthias and Bonnie of the FSFE are interviewing me about various high-level topics related to [the lack of] Free Software in cellular telephony, as well as some of the projects that I was involved in (Openmoko, Osmocom).

We've also touched the current mainstream / political debate about Huawei and 5G networks, where my position can only be summarized as: It doesn't matter much in which country the related proprietary software is being developed. What we need is Free / Open Source software that can be publicly audited, and we need a method by which the operator can ensure that a given version of that FOSS software is actually executing on his equipment.

Thanks to the FSFE for covering such underdeveloped areas of Free Software, and to use their podcast to distribute related information and ideas.

November 27, 2019

Osmocom.org News: Distributed GSM - Distributed GSM / Multicast MS Lookup

When building communal mobile telephony networks, traditional core network infrastructure poses a fundamental challenge: it is built on a centralised paradigm and requires highly available network links at all times. Osmocom is currently implementing Distributed GSM (D-GSM), a concept that is a far better match for a decentralised cooperation of independent communal mobile networks, who don't have the luxury of ultra-reliable networking infrastructure.

When several communities, who have each built their own independent mobile network infrastructure, would like to join their services to allow calling, messaging and roaming across sites, the usual answer would be a centralised gateway entity to locate subscribers, and, naturally, a central authority governing all participating communities. That is a challenge, not only socially and administratively, but is also quite impractical when the network links between communities tend to be unstable or expensive.

For example, when a phone has just moved to a different coverage area, but weather conditions impair the hypothetical wireless link to a central subscriber database, the phone becomes unreachable, even for callers in the local vicinity where connecting a voice call would not have posed any problem.

A solution that comes to mind is a series of mirrors of that central database, one for each site. However, that requires database synchronisation, which can lead to a considerable delay. After a subscriber has moved to a different coverage area, practice shows that it can take something like half an hour until a site notices that a given subscriber has lost reception to its network, and until it has synchronised that fact with other sites. For that duration, callers are unable to get the accurate current position of the person they are trying to reach. Imagine a subscriber located just between two coverage areas, often switching back and forth between them at random -- service would be disrupted probably for most of the day.

To solve these challenges, we are implementing D-GSM as part of the Osmocom CNI stack. D-GSM is a close cooperation with/for Rhizomatica [1], an organization of community owned operators providing mobile telephony service in numerous rural communities in Oaxaca, Mexico. We are aiming to overcome common practical problems that their current mobile networks are experiencing, improving availability and stability. The results of this work are naturally contributed to the Osmocom project and are freely available for anyone to use, under terms of the GNU AGPL. The implementation of D-GSM is mostly funded by the Mozilla MOSS grant [2], and carried out by sysmocom-employed [3] Osmocom contributors. Thank you for making this possible!

The solution we are implementing is inspired by the actual social and physical structure that we aim to service: each village in Oaxaca has their own fully independent core network stack, and each community is fully in charge of their own infrastructure. There is no central authority governing across communities, by deliberate choice. Because the infrastructure is operated in remote rural areas, often from a pole on a hill crest running on solar panels, and with directional wifi over large distances, network links between villages can be unstable.

D-GSM is a relatively simple, low impact addition to an Osmocom CNI, which is designed to match Rhizomatica's situation:

  • it de-centrally resolves the current location of a subscriber (by MSISDN or IMSI),
  • provides service addresses to directly reach the subscriber (so far SIP, SMPP and GSUP; freely extendable), and
  • it proxies HLR services to provide roaming across villages.

The key technology that enables D-GSM in Osmocom is called mslookup, which is built on multicast DNS -- quite similar to the concept of service discovery in zeroconf networking [4].

Whenever calling or messaging a particular phone number (MSISDN), a multicast request is dispatched to all connected sites. Each site where that subscriber has recently been attached replies with the age of the local record, and the youngest aged response wins.

Figure 1: mslookup for connecting subscribers: Alice is visiting village C; a phone call gets routed directly to her current location independently from her resident village infrastructure

Error executing the graphviz_link macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :rsb]}. Searched in: * "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views" * "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views" * "/usr/src/redmine/plugins/redmine_tags/app/views" * "/usr/src/redmine/plugins/redmine_openid_provider/app/views" * "/usr/src/redmine/plugins/redmine_mentions/app/views" * "/usr/src/redmine/plugins/redmine_lightbox2/app/views" * "/usr/src/redmine/plugins/redmine_checklists/app/views" * "/usr/src/redmine/plugins/redmine_banner/app/views" * "/usr/src/redmine/plugins/event_notifications/app/views" * "/usr/src/redmine/plugins/clipboard_image_paste/app/views" * "/usr/src/redmine/app/views" )

Furthermore, when a subscriber visits a site where its IMSI is not known, mslookup can find the IMSI's home HLR location, and OsmoHLR can provide roaming service by transparently proxying to the remote site's HLR.

Figure 2: mslookup for roaming: Alice visits village B; she can attach to the local mobile network, which proxies HLR administration to her home village.

Error executing the graphviz_link macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:atom], :variants=>[], :handlers=>[:erb, :builder, :raw, :ruby, :rsb]}. Searched in: * "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views" * "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views" * "/usr/src/redmine/plugins/redmine_tags/app/views" * "/usr/src/redmine/plugins/redmine_openid_provider/app/views" * "/usr/src/redmine/plugins/redmine_mentions/app/views" * "/usr/src/redmine/plugins/redmine_lightbox2/app/views" * "/usr/src/redmine/plugins/redmine_checklists/app/views" * "/usr/src/redmine/plugins/redmine_banner/app/views" * "/usr/src/redmine/plugins/event_notifications/app/views" * "/usr/src/redmine/plugins/clipboard_image_paste/app/views" * "/usr/src/redmine/app/views" )

By nature of multicast lookups, D-GSM is highly resilient against single sites or links becoming temporarily unavailable. Service between still reachable sites simply continues; Service to a disconnected site resumes as soon as it becomes reachable again. Even adding a new site to the communal network is basically done by setting up a network link with multicast routing, and by choosing distinct naming for the local GSUP services.

OsmoHLR is the workhorse for our D-GSM implementation. In fact, no other Osmocom CNI program's code base besides OsmoHLR itself needs to be touched for implementing D-GSM:

  • OsmoHLR answers all service endpoint requests for locally attached subscribers, as configured in osmo-hlr.cfg;
  • For IMSIs it doesn't find in the local db (outbound roaming), OsmoHLR takes care of requesting the home HLR of the IMSI and of proxy-routing HLR operations there; and
  • OsmoHLR answers requests for all IMSIs it finds in the local db (inbound roaming).

A D-GSM enabled OsmoHLR will soon be available on the osmo-hlr.git master branch -- the implementation is currently undergoing peer review to be merged to the master branch.

The elements that request cross-site service for voice and SMS (currently) are:

  • a custom dialplan implementation for a PBX connected to OsmoMSC via OsmoSIPConnector (we're using FreeSWITCH [5] in the lab), and
  • a custom SMPP handler connected to OsmoMSC,

both of which are available as example implementations in osmo-hlr.git/contrib/dgsm [6] / [6].

This list is likely to be enhanced with further example integrations, like more FLOSS PBX integrations, or SMS-over-GSUP transport instead of SMPP. That's up to the Osmocom community to implement and contribute. If you need more information, take a look at OsmoHLR's user manual [7] / [7].

All of the above technology is fully functional in our lab setup right now: we are routing Location Updating requests, calls, and SMS to the right site, entirely without the need for centralised administrative infrastructure.

A further aim of D-GSM is providing roaming service even though the link to the respective home HLR is unstable or altogether down. The solution is adding a persistent local cache to the HLR proxy, which we are going to implement next.

D-GSM is, technologically, a relatively trivial enhancement of the Osmocom CNI. Yet it brings an entirely new paradigm to mobile core network infrastructure: It allows independent mobile core network stacks to provide voice, SMS and roaming services cooperatively, without the need for centralised infrastructure or administration authority, and is resilient against unstable network links between sites. It elegantly provides ad-hoc service for subscribers, who are free to move across all coverage areas, and it allows sites to dynamically join or leave the cooperative network without the need for configuration changes nor administrative decisions at other sites.

It also has been and is great fun to implement a versatile enhancement that, for a change, completely surpasses 3GPP specifications, and has the potential to change the fundamental shape of communal mobile coverage. We're looking forward to see D-GSM in action in Oaxaca, soon.


November 16, 2019

Osmocom.org News: OsmoPCU - September/October OsmoPCU code sprint

This is a (late) update about the September/October 2019 activities regarding improvement of OsmoPCU and OsmoSGSN functionality and reliability.

Work has been done, among others, on #4111, #3828, #4228, #3827, #4247, #4102, #3995, #3969, #4029, #1977, #4024, #2406, #4204, #2857, #3922, #4048, #4173, #3727, #43, #4058, #2408, #2955

Unfortunately, OsmoPCU is still one of the least loved projects in the Osmocom universe. Not many people contribute to it, and there are very few commercial users wanting to contribute either financially or by helping with closing some more of the open issues :/

Osmocom.org News: OsmoSTP - OsmoSTP features added (traffic-mode load-share, ...)

OsmoSTP has received a variety of new features over the last few weeks.

This includes:
  • operation of STP in M3UA ASP role (normally a STP operates in SG role): #2005
  • operation as STP in STCP client/connect role (normally a STP operates in SCTP server/bind): #2005
  • support for SCTP multi-homing with configurable IPs on local and remote end: #3608
  • make point-code insertion into SCCP optional at for IPA ASPs: #4219
  • dynamic creation of ASPs within an IPA/SCCPlite AS: #4218
  • support traffic-mode load-share (in M3UA and IPA): #4220

We also discovered a number of drive-by bugs which were encountered while working on the implementation of the above, see #4247, #4236, #4238, #4234, #4239, #4233, #4235, #4232 - most of which are already fixed.

We furthermore have created a TTCN-3 test suite for OsmoSTP covering those parts that the existing nplab m3ua and sua test suites don't cover. Test results of all STP related test suites can be seen (as usual) in our jenkins:

Related developments have been funded by a commercial user of OsmoSTP and implemented by pespin and laforge at sysmocom. We rely on funding for maintenance, feature development and bug fixing.

Osmocom.org News: M.2 (NGFF) WWAN modem USB breakout board - Second prototype of m.2/NGFF modem breakout functional

We had recently received the prototype v2 of the m.2/NGFF WWAN modem breakout board and are happy to report that it immediately worked for both USB 3.0 super-speed as well as for PCIe. All debug results and reworks from v1 have been incorporated in this v2.

Design validation has completed, which means a first manufacturing batch is in up in the pipelnie, and we expect boards to become available from the sysmocom webshop in some 4-6 weeks (maybe a bit later due to christmas holidays).

As usual, as the project is an Open Source Hardware, and anyone can go ahead and build their own boards, see http://git.osmocom.org/osmo-small-hardware/tree/ngff-breakout for the design files.

fun fact: The part most difficult to source is the M2x3 wide-flat-head screw that holds the M.2 card in place.

November 14, 2019

Osmocom.org News: Cellular Network Infrastructure - Binary packages for Raspbian 10 and Ubuntu 19.10

Thanks to the great support of the OpenSuSE Build Service, Osmocom is now offering binary package feeds for Raspbian 10 and Ubuntu 19.10.

October 14, 2019

Osmocom.org News: Retro-Networking / BBS-Revival - Retro-BBS plans for #36C3

At 36C3, the Osmocom Retro-bBS project will be running a PBX with analog lines and ISDN S0 ports as well as a RAS Server in order to host multiple BBSs and enable attendees to connect modems/ISDN-TA to their computers and dial in to the local BBSs

Current status and plans are summarised at http://lists.osmocom.org/pipermail/bbs-revival/2019-October/000014.html - please do join us if you'd also like to revive the good old BBS days!

October 01, 2019

Osmocom.org News: SIMtrace 2 - Card Emulation with SIMtrace2 boards

The SIMtrace project has from beginning on been designed to not only monitor the communication between a card and the reader (e.g. a SIM and a phone), but also to emulate cards. This card emulation functionality has never been implemented, at least not by the osmocom community, and the project has been hibernating for quite some time. A year ago, the SIMtrace project has been revived. The now old and deprecated micro-controller has been replaced with ARM Cortex-M, but the initial design remains. This change forced us to rewrite the code from scratch, and this is now the SIMtrace 2 project. Monitoring the communication is still available, even with increased stability, but this fresh start was to opportunity the also implement the other long awaited features.

Card emulation is finally there. Is it currently in it's beta phase, but has already been successfully tested. It can even be used in combination with the recent osmo-remsim project, allowing to use multiple cards at remote locations. While it is not completely emulating a card since it only forwards the traffic to a card present in another reader, we are currently working on also providing this functionality. So, feel free to try it out yourself, and let us know using the SIMtrace mailing list if you find any issues. The card emulation wiki article will be updated as we continue on our journey to make SIMtrace the tool it was intended for from beginning on.

September 28, 2019

Harald "LaForge" Welte: Sometimes software development is a struggle

I'm currently working on the firmware for a new project, an 8-slot smart card reader. I will share more about the architecture and design ideas behind this project soon, but today I'll simply write about how hard it sometimes is to actually get software development done. Seemingly trivial things suddenly take ages. I guess everyone writing code knows this, but today I felt like I had to share this story.

Chapter 1 - Introduction

As I'm quite convinced of test-driven development these days, I don't want to simply write firmware code that can only execute in the target, but I'm actually working on a USB CCID (USb Class for Smart Card readers) stack which is hardware-independent, and which can also run entirely in userspace on a Linux device with USB gadget (device) controller. This way it's much easier to instrument, trace, introspect and test the code base, and tests with actual target board hardware are limited to those functions provided by the board.

So the current architecture for development of the CCID implementation looks like this:

  • Implement the USB CCID device using FunctionFS (I did this some months ago, and in fact developing this was a similarly much more time consuming task than expected, maybe I find time to expand on that)

  • Attach this USB gadget to a virtual USB bus + host controller using the Linux kernel dummy_hcd module

  • Talk to a dumb phoenix style serial SIM card reader attached to a USB UART, which is connected to an actual SIM card (or any smart card, for that matter)

By using a "stupid" UART based smart card reader, I am very close to the target environment on a Cortex-M microcntroller, where I also have to talk to a UART and hence implement all the beauty of ISO 7816-3. Hence, the test / mock / development environment is as close as possible to the target environment.

So I implemented the various bits and pieces and ended up at a point where I wanted to test. And I'm not getting any response from the UART / SIM card at all. I check all my code, add lots of debugging, play around with various RTS / DTR / ... handshake settings (which sometimes control power) - no avail.

In the end, after many hours of trial + error I actually inserted a different SIM card and finally, I got an ATR from the card. In more than 20 years of working with smart cards and SIM cards, this is the first time I've actually seen a SIM card die in front of me, with no response whatsoever from the card.

Chapter 2 - Linux is broken

Anyway, the next step was to get the T=0 protocol of ISO 7816-3 going. Since there is only one I/O line between SIM card and reader for both directions, the protocol is a half-duplex protocol. This is unlike "normal" RS232-style UART communication, where you have a separate Rx and Tx line.

On the hardware side, this is most often implemented by simply connecting both the Rx and Tx line of the UART to the SIM I/O pin. This in turn means that you're always getting an echo back for every byte you write.

One could discard such bytes, but then I'm targeting a microcontroller, which should be running eight cards in parallel, at preferably baud-rates up to ~1 megabit speeds, so having to read and discard all those bytes seems like a big waste of resources.

The obvious solution around that is to disable the receiver inside the UART before you start transmitting, and re-enable it after you're done transmitting. This is typically done rather easily, as most UART registers in hardware provide some way to selectively enable transmitter and/or receiver independently.

But since I'm working in Linux userspace in my development environment: How do I approximate this kind of behavior? At least the older readers of this blog will remember something called the CREAD flag of termios. Clearing that flag will disable the receiver. Back in the 1990ies, I did tons of work with serial ports, and I remembered there was such a flag.

So I implement my userspace UART backend and somehow it simply doesn't want to work. Again of course I assume I must be doing something wrong. I'm using strace, I'm single-stepping through code - no avail.

In the end, it turns out that I've just found a bug in the Linux kernel, one that appears to be there at least ever since the git history of linux-2.6.git started. Almost all USB serial device drivers do not implement CREAD, and there is no sotware fall-back implemented in the core serial (or usb-serial) handling that would discard any received bytes inside the kernel if CREAD is cleared. Interestingly, the non-USB serial drivers for classic UARTs attached to local bus, PCI, ... seem to support it.

The problem would be half as much of a problem if the syscall to clear CREAD would actually fail with an error. But no, it simply returns success but bytes continue to be received from the UART/tty :/

So that's the second big surprise of this weekend...

Chapter 3 - Again a broken card?

So I settle for implementing the 'receive as many characters as you wrote' work-around. Once that is done, I continue to test the code. And what happens? Somehow my state machine (implemented using osmo-fsm, of course) for reading the ATR (code found here) somehow never wants to complete. The last byte of the ATR always is missing. How can that be?

Well, guess what, the second SIM card I used is sending a broken, non-spec compliant ATR where the header indicates 9 historical bytes are present, but then in reality only 8 bytes are sent by the card.

Of course every reader has a timeout at that point, but that timeout was not yet implemented in my code, and I also wasn't expecting to hit that timeout.

So after using yet another SIM card (now a sysmoUSIM-SJS1, not sure why I didn't even start with that one), it suddenly works.

After a weekend of detours, each of which I would not have assumed at all before, I finally have code that can obtain the ATR and exchange T=0 TPDUs with cards. Of course I could have had that very easily if I wanted (we do have code in pySim for this, e.g.) but not in the architecture that is as close as it gets to the firmware environment of the microcontroller of my target board.

Osmocom.org News: Cellular Network Infrastructure - August 2019 Osmocom CNI releases

It seems we forgot the release announcement in early August:

The Osmocom project has released new version of the CNI (Cellular Network Infrastructure) software, including OsmoTRX, OsmoBTS, OsmoBSC, OsmoMGW, OsmoMSC, OsmoHLR, OsmoSGSN, OsmoGGSN.

Those new tagged/released versions contain four months of work since the previous versions released during April 2019. The primary focus was on bug-fixing and stabilization as well as some major new features, such as inter-MSC-handover support in osmo-msc.

You can find pre-compiled binary packages of our latest release for a variety of Debian and Ubuntu GNU/Linux versions at Latest_Builds.

List of tagged versions and link to related ChangeLog

Project Version Changelog
libosmocore 1.2.0 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.2.0
libosmo-abis 0.7.0 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=0.7.0
libosmo-netif 0.6.0 http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=0.6.0
libosmo-sccp 1.1.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.1.0
OsmoTRX 1.1.1 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.1.1
OsmoBTS 1.1.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.1.0
OsmoBSC 1.5.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.5.0
OsmoMSC 1.5.0 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.5.0
OsmoHLR 1.1.0 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.1.0
osmo-mgw 1.6.0 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.6.0
osmo-sip-connector 1.3.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.3.0
OsmoSTP 1.1.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.1.0
OsmoSGSN 1.5.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.5.0
OsmoGGSN 1.4.0 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.4.0

Noteworthy Changes

Misc / Common

  • debian packages now have -doc sub-packages containing the corresponding user and VTY reference manuals of each program.
  • various robustness fixes
  • support LAPDm payloads with more than 200 bytes
  • fsm: Allow millisecond granularity in osmo_fsm built-in timer
  • CBSP (Cell Broadcast Service Protocol) implementatin in libosmogsm
  • vty parser fixes: don't pass incomplete arguments to vty funcs
  • work around gcc bug with gcc < 7.3.0 on ARM related to thread-local storage
  • shared IPA keep-alive FSM in libosmocore; use it wherever possible
  • libosmo-netif Stream client: fix disconnection logic


  • new protocol (TRXDv1) support, mainly for passing C/I value from TRX->BTS->PCU for rate adaptation
  • proper counting of under/overruns
  • LimeSuite stability improvements (recovery / re-synchronization after drop-outs)
  • various internal refactoring / code de-duplication
  • fix ARM VFP4 convolution
  • LimeSuite: automatic detection of device type and device specific gains


  • Various Abis OML protocol conformance fixes
  • handling of GPRS SUSPEND (from DCCH -> PCU)
  • Full CBCH (Cell Broadcast Channel) support, both basic and extended
  • RSL CBCH LOAD INDICATION for CBCH flow control
  • Fix RACH load percentage computation
  • clear GPRS indicator form SI3 when PCU is not connected
  • fix (so far ignored) MS power control in RSL CHANNEL ACTIVATION
  • osmo-bts-oc2g specificx
    • systemd service file + example config installation
    • status LED fixes
    • nominal transmit power fix
    • generate failure event report if calibration data missing
  • osmo-bts-trx specifics
    • TRXDv1 protocol support
    • 11-bit RACH support


  • Various AMR rate handling related fixes between AoIP and Abis
  • AMR: Signal usage of octet-aligned or bandwith-efficient mode to MSC
  • various inter-BSC hand-over related fixes for AoIP
  • various manual updates, including documentation for 3G/4G neighbor cells, OSMUX, ...
  • always default to octet-aligned AMR mode
  • keep per-BTS statistics about RACH utilization
  • re-introduce support for IPA-encapsulated MGCP (used with osmo-bsc_nat)
  • OSMUX support with AoIP (we only supported it with SCCPlite so far)
  • support assigning TCH/x in signaling mode


  • Add SGs interface for CSFB (circuit switched fall-back) and SMS-over-SGs
  • various SMS and USSD handling related fixes
  • include libsmpp34 memory allocations in talloc reports
  • Fix SMS transmission over Iu (use SAPI3)
  • allow user to disable retrieval of IMEISV early
  • allow transmission of IMEI to HLR (for subscriber-create-on-demand)
  • support inter-BSC hand-over
  • support inter-MSC hand-over
  • do not force encryption on UTRAN/Iu
  • OSMUX support with AoIP


  • document --db-upgrade command line argument
  • optionally store IMEI in subscriber table (for non-standard subscriber-create-on-demand)
  • support routing of GSUP messages between clients (MSCs) for inter-MSC hand-over

OsmoMGW (and libosmo-mgcp-client)

  • Add config option to use RFC5593 for GSM HR frames (we normally use ETSI TS 101318 format)
  • SDP parsing related fixes
  • Support OSMUX configuration via MGCP (activated via BSC and MSC)


  • support international Caller-ID
  • support emergency calling
  • handle SIP re-invite

OsmoSTP (and libosmo-sigtran)

  • enable statsd export
  • fix bug when saving config file (pointcode+mask of route)
  • enable memory usage debugging via talloc introspection


  • various parser correctness imporvements for LLC
  • send Iu Release Command upon Attach Complete
  • send Service Reject when no PDP contexts available
  • fix GTP echo behavior
  • require GMM authentication by default

OsmoGGSN (and libgtp)

  • various PCO handling related improvements/fixes
  • minimalistic PAP support during PDP context activation
  • fix missing GTP-C re-transmission
  • Introduce new pdp APIs (and deprecate old ones) to support multiple GSN

Osmocom.org News: gr-osmosdr - gr-osmosdr maintainer needed

The original author and maintainer of gr-osmosdr (Dimitri horiz0n Stolnikov) has lost time and/or interest in maintaining gr-osmosdr. That's very sad, but it is a fact that people have a limited amount of time, and priorities change. We'd like to thank Dimitri and all other gr-osmosdr developers/contributors for what they have done so far.

We're publicly calling for some other community member[s] to step up and become maintainer[s] of gr-osmosdr.

Who is interested in gr-osmosdr and willing to maintain it, possibly in a team with other interested folks?

The original related mailing list post can be found at http://lists.osmocom.org/pipermail/osmocom-sdr/2019-September/001983.html - it is best to follow-up there in case you are interested and/or have comments.

September 11, 2019

Osmocom.org News: Ericsson RBS 6xxx - Presentation on commercial cellular base station technology

On September 10, 2019 Osmocom founder Harald "LaF0rge" Welte gave a presentation as part of the Datengarten series of lectures at the Chaos Computer Club Berlin.

The abstract of the talk is:

In today’s hyper-connected society, everyone constantly uses their smartphone, which in turn uses the commercial cellular networks (from 2G/GSM to 4G/LTE) in order to achieve connectivity. However, contrary to WiFi technology, even most technology-minded people don’t have much of an idea how the infrastructure behind those cellular networks looks like. This talk does not cover the architecture and protocols of underlying cellular systems, but focuses on the physical side of things: what are the typical components of cellular base stations? what are their key functionalities? how did cellular base station technology evolve during the past 20 years? how do we expect cellular base stations to change in the [near] future? We will not cover DIY or hobbyist projects here, but the actual technology deployed in the field by real-world commercial operators.

If you're interested in the presentation, feel free to check out:

May 24, 2019

Osmocom.org News: Cellular Network Infrastructure - Binary packages for Debian unstable + testing, Ubuntu 19.04

Thanks to the great support of the OpenSuSE Build Service, Osmocom is now offering binary package feeds for Debian unstable, Debian testing and Ubuntu 19.04.

May 14, 2019

Osmocom.org News: rtl-sdr - Weekly windows binary packages for rtl-sdr and osmo-fl2k

While Osmocom in general is a very much Linux-centric development community, we are now finally publishing automatic weekly Windows binary builds for the most widely used Osmocom SDR related projects: rtl-sdr and osmo-fl2k.

You can find the binaries at The actual builds are done by roox who is building them using MinGW on OBS, see

The status of the osmocom binary publish job, executed once per week from now on, can be found at https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/Osmocom-OBS_MinGW_weekly_publish/

May 09, 2019

Osmocom.org News: UmTRX - XTRX SDR workshop on May 12, 2019 in Berlin

XTRX SDR workshop Berlin

  • Speaker: Sergey Kostanbaev, Founder and Head of Engineering, Fairwaves
  • Duration: 2h+
  • When: Sunday, May 12 from 3pm onwards
  • Where: IN-Berlin e.V., Lehrter Str. 53, 10557 Berlin
  • Admission: Free + Open to anyone

Preliminary agenda:

  • Why XTRX. What's different in XTRX SDR? * XTRX hardware capabilities * XTRX carrier board (USB3 / PCIex2) * Understanding XTRX software layers * Building XTRX driver & host libraries * PCIe Driver specifics, ARM specifics, porting to other platforms * Native API overview, Spoapy wrapper * GNURadio plugins, building simple applications * Q&A

XTRX homepage: https://xtrx.io/

Previous talks, e.g. OsmoDevCon 2018 one year ago: https://media.ccc.de/v/MNL3YJ

Osmocom.org News: OsmoMSC - Handover support merged to OsmoMSC master

We are happy to announce that OsmoMSC handover support for 2G has been merged to the master branch yesterday.
See this talk: https://media.ccc.de/v/osmodevcon2019-103-inter-msc-handover-how-it-works-and-how-we-implement-it
and sensational images of the new code launched to the OsmoMSC master orbit: http://people.osmocom.org/neels/oeZeich5/msc_launch.jpg ;)

OsmoMSC master can now do both inter-BSC as well as inter-MSC handover for 2G (GERAN).
Until now, only OsmoBSC supported handover, i.e. an ongoing phone call moving to another cell within the same BSC.
OsmoBSC since not so long ago can also handover to another BSC, but you needed a third-party MSC for this.

Now, you can use our stock OsmoMSC for inter-BSC handover. Notably OsmoBSC has also received crucial fixes for handover on AoIP.
We also support inter-MSC handover now, i.e. you can handover a 2G call to another OsmoMSC.
To handover to/from a third-party MSC, a separate GSUP-to-MAP compatibility layer will have to be added.

A rather large refactoring effort was necessary to allow handling more than one RAN connection per subscriber.
Though handover to/from 3G is not yet supported, the new code base is a necessary preparation for adding that.
It is not yet clear when or by whom handover on 3G might be taken on, so join us if you are interested.

OsmoMSC v1.4.0 was released to mark a stable version before the new changes.
After due testing by the extended Osmocom community, we will (likely soon) tag a new "latest" release.
Until then, handover support is available in the nightly images and when built from current master.

May 01, 2019

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCon 2019 videos released

Thanks to c3voc, the video recordings of OsmoDevCon2019 have been released.

For a list of videos available, please see https://media.ccc.de/c/osmodevcon2019

The recorded presentations include:

Links from the conference schedule to the videos will be added later on.

We thank c3voc and the respective speakers for agreeing to make their video recordings public.

January 27, 2019

Osmocom.org News: Cellular Network Infrastructure - Binary packages for Raspbian 9

Thanks to the great support of the OpenSuSE Build Service, Osmocom is now offering binary package feeds for the popular Raspbian distribution, Version 9.

As a result, running Osmocom CNI (Cellular Network Infrastructure) on Raspbery Pi embedded computers is easier than ever: Just add the Latest_Builds
or Nightly_Builds feed to /etc/apt/sources.list[.d] and run your Osmocom based 2G and/or 3G cellular network.

The feeds are available from

January 24, 2019

Osmocom.org News: Cellular Network Infrastructure - New Osmocom Cellular software versions released!

The Osmocom project has released new version of the CNI (Cellular Network Infrastructure) software, including OsmoTRX, OsmoBTS, OsmoBSC, OsmoMGW, OsmoMSC, OsmoHLR, OsmoSGSN, OsmoGGSN.

Those new tagged/released versions contain half a year of work since the previous versions released during summer 2018. The primary focus was on bug-fixing and stabilization as well as some major new features, such as inter-BSC-handover support in osmo-bsc.

You can find pre-compiled binary packages of our latest release for a variety of Debian and Ubuntu GNU/Linux versions at Latest_Builds.

List of tagged versions and link to related ChangeLog

Project Version Changelog
libosmocore 1.0.1 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.0.1
libosmo-abis 0.6.0 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=0.6.0
libosmo-netif 0.4.0 http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=0.4.0
libosmo-sccp 1.0.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.0.0
OsmoTRX 1.0.0 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.0.0
OsmoBTS 1.0.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.0.0
OsmoBSC 1.4.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.4.0
OsmoMSC 1.3.1 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.3.1
OsmoHLR 1.0.0 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.0.0
osmo-mgw 1.5.0 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.5.0
osmo-sip-connector 1.2.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.2.0
OsmoSTP 1.0.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.0.0
OsmoSGSN 1.4.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.4.0
OsmoGGSN 1.3.0 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.3.0

Noteworthy Changes


  • the asciidoc source of the user manuals + VTY reference manuals is now always kept inside the respective repository: osmo-bts.git contains the osmo-bts manual. Before this, we used to have all manuals in osmo-gsm-manuals.git.
  • logging vty: deprecate the 'everything' keyword
  • various logging related improvements
  • various improvements of osmo_fsm
  • new osmo-config-merge utility
  • SGsAP protocol encoding/decoding (SGsAP not yet part of osmo-msc!)
  • GSMTAP definitions for LTE RRC and NAS sub-types
  • introduce osmo_timerfd support as part of libosmocore (recurring timers)


  • Introduce OsmoTRX user manual
  • Direct support of LimeSuite as osmo-trx-lms without the detour of uhd+soapy-uhd+soapysdr
  • split device-specific parts into their own classes + binaries: osmo-trx-{uhd,lms,usrp1}
  • make better use of diferent logging sub-systems / log levels


  • various correctness fixes related to advanced SACCH FILL scenarios with different SI5/SI6 per channel/subscriber
  • various fixes to bit-rotten CBCH support; related generalization
  • CBCH support for osmo-bts-trx
  • extend precision of TOA mesaurement reports to 1/256 symbol duration
  • make RTP port range configurable
  • extensive fixes on correctness of computed + reported measurement reports
  • Fix build against gpsd >= 3.18
  • Allocate TRX for BTS dynamically, deprecate "-t" command line option
  • Initial support for OpenCellular OC-2G BTS model/PHY


  • inter-BSC hand-over support (AoIP and SCCPlite)
  • large refactoring: use FSMs for lchans; timeslots; MGCP endpoints; ...
  • Implement RR Classmark Enquiry in case
  • various LCLS related fixes
  • various codec / channel type related fixes during ASSIGNMENT
  • interop tested against 3rd party MSCs for both AoIP and SCCPlite


  • Implementation of MSC-originated CLASSMARK inquiry procedure for MS/UE without early classmark sending to allow A5/3 encryption
  • mncc: fix byte ordering of IP-Address in mncc
  • various improvements on state introspection via VTY
  • forward SS / USSD messages via GSUP to HLR rather than processing it in MSC
  • optional forward of SMS via GSUP to/from HLR rather than using internal SMSC
  • fix Classmark Update without VLR subscriber
  • vty: add SCCP related vty commands
  • GSUP client: send CN domain IE on LU request
  • vty: add command to show all known BSC


  • Add GSUP message router
  • Add concept of Internal (IUSE) and external (EUSE) USSD handlers
  • Implement handling of USSD received from OsmoMSC via GSUP
  • Introduce shared libosmo-gsup-client library for client programs connecting to OsmoHLR (like OsmoMSC, OsmoSGSN).

OsmoMGW (and libosmo-mgcp-client)

  • Remove libosmo-legacy-mgcp and osmo-bsc-mgcp (they live in deprecated openbsc.git)
  • various OSMUX related fixes
  • use IETF-allocated port number for call-agent side as default
  • introduce the concept of payload type maps
  • rewrite/translate payload type numbers as per the ptmap
  • make MGCP parser more tolerant (and interoperable)
  • add extensive statistics / counters and improve VTY introspection


  • various logging improvements (more strings, less numbers)
  • better SIP/MNCC cause mapping

OsmoSTP (and libosmo-sigtran)

  • make SCCP timers configurable (required for some SCCPlite peers)
  • osmo-stp: add SCCP related VTY commands
  • allow less characters for SCCP address book entries
  • skip simple-client default as/asp when saving VTY config
  • fix ipa_asp_fsm down state transition


  • gprs_gmm: introduce a GMM Attach Request FSM
  • sgsn_ggsn_ctx_drop_pdp: protect against nullpointer when MM is gone
  • gprs_gmm: dont answer unknown IMSI/TMSI on Service Requests NET_FAIL
  • gprs_gmm: Fix missing Security Command for 3G when attaching
  • sgsn_libgtp: fix a potential memleak when the GGSN is not reachable
  • gb_proxy: Add ctrl interface and nsvc-state, gbproxy-state commands
  • osmo-sgsn: ping GGSN periodically and check for restart counter
  • Disarm T3395 when dettaching mmctx from pdpctx
  • sgsn: cdr: Fix uninitialized string access if ggsn is detached
  • gbproxy: Add VTY parameter: link stored-msgs-max-length
  • gbproxy: Add new VTY-managed timer: link-list clean-stale-timer
  • Remove local libgsupclient; Use libosmo-gsup-client from osmo-hlr

OsmoGGSN (and libgtp)

  • ggsn: ctrl iface: listen on IP configured by VTY
  • gtp: Allow recv DEL CTX REQ in sgsn and DEL CTX RSP in ggsn
  • gtp: Log ignore CTX DEL REQ due to no teardown and only 1 ctx active
  • gtp: Add new API to avoid freeing pdp contexts during DEL CTX REQ
  • fix support for multiple IPCP in PDP protocol configuration options

October 19, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon 2018 videos day one released

Thanks to c3voc, the video recordings of the first day of OsmoCon2018 have been released on the very same day.

For a list of videos available, please see https://media.ccc.de/c/osmocon2018

The recorded presentations include:

As the videos of the second day (today) become available, they will be added to the above list.

Links from the conference schedule to he videos will be added later on.

October 10, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon 2018 happening in one week from now

Only one week left until OsmoCon 2018 takes place in Berlin, Germany.

We're looking forward to an exciting schedule of technical presentations covering most of the exciting work that has been happening in the Osmocom universe throughout the last 12-18 months.

Tickets are still available from our ticket shop, see https://pretix.sysmocom.de/sysmocom/osmocon2018/, and community discount vouchers are also still availble.

See you at OsmoCon 2018 on October 18+19, 2018!

October 03, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon 2018 happening in two weeks from now

Only two weeks left until OsmoCon 2018 takes place in Berlin, Germany.

We're looking forward to an exciting schedule of technical presentations covering most of the exciting work that has been happening in the Osmocom universe throughout the last 12-18 months.

Tickets are still available from our ticket shop, see https://pretix.sysmocom.de/sysmocom/osmocon2018/, and community discount vouchers are also still availble.

See you at OsmoCon 2018 on October 18+19, 2018!

September 28, 2018

Harald "LaForge" Welte: Fernvale Kits - Lack of Interest - Discount

Back in December 2014 at 31C3, bunnie and xobs presented about their exciting Fernvale project, how they reverse engineered parts of the MT6260 ARM SoC, which also happens to contain a Mediatek GSM baseband.

Thousands (at least hundreds) of people have seen that talk live. To date, 2506 people (or AIs?) have watched the recordings on youtube, 4859 more people on media.ccc.de.

Given that Fernvale was the closest you could get to having a hackable baseband processor / phone chip, I expected at least as much interest into this project as we received four years earlier with OsmocomBB.

As a result, in early 2015, sysmocom decided to order 50 units of Fernvale DVT2 evaluation kits from bunnie, and to offer them in the sysmocom webshop to ensure the wider community would be able to get the boards they need for research into widely available, inexpensive 2G baseband chips.

This decision was made purely for the perceived benefit of the community: Make an exciting project available for anyone. With that kind of complexity and component density, it's unlikely anyone would ever solder a board themselves. So somebody has to build some and make it available. The mark-up sysmocom put on top of bunnie's manufacturing cost was super minimal, only covering customs/import/shipping fees to Germany, as well as minimal overhead for packing/picking and accounting.

Now it's almost four years after bunnie + xobs' presentation, and of those 50 Fernvale boards, we still have 34 (!) units in stock. That means, only 16 people on this planet ever had an interest in playing with what at the time I thought was one of the most exciting pieces of equipment to play with.

So we lost somewhere on the order of close to 3600 EUR in dead inventory, for something that never was supposed to be a business anyway. That sucks, but I still think it was worth it.

In order to minimize the losses, sysmocom has now discounted the boards and reduced the price from EUR 110 to to EUR 58.82 (excluding VAT). I have very limited hope that this will increase the amount of interest in this project, but well, you got to try :)

In case you're thinking "oh, let's wait some more time, until they hand them out for free", let me tell you: If money is the issue that prevents you from playing with a Fernvale, then please contact me with the details about what you'd want to do with it, and we can see about providing them for free or at substantially reduced cost.

In the worst case, it was ~ 3600 EUR we could have invested in implementing more Osmocom software, which is sad. But would I do it again if I saw a very exciting project? Definitely!

The lesson learned here is probably that even a technically very exciting project backed by world-renowned hackers like bunnie doesn't mean that anyone will actually ever do anything with it, unless they get everything handed on a silver plate, i.e. all the software/reversing work is already done for them by others. And that actually makes me much more sad than the loss of those ~ 3600 EUR in sysmocom's balance sheet.

I also feel even more sorry for bunnie + xobs. They've invested time, money and passion into a project that nobody really seemed to want to get involved and/or take further. ("nobody" is meant figuratively. I know there were/are some enthusiasts who did pick up. I'm talking about the big picture). My condolences to bunnie + xobs!

September 18, 2018

Harald "LaForge" Welte: Wireshark dissector for 3GPP CBSP - traces wanted!

I recently was reading 3GPP TS 48.049, the specification for the CBSP (Cell Broadcast Service Protocol), which is the protocol between the BSC (Base Station Controller) and the CBC (Cell Broadcast Centre). It is how the CBC according to spec is instructing the BSCs to broadcast the various cell broadcast messages to their respective geographic scope.

While OsmoBTS and OsmoBSC do have support for SMSCB on the CBCH, there is no real interface in OsmoBSC yet on how any external application would instruct it tot send cell broadcasts. The only existing interface is a VTY command, which is nice for testing and development, but hardly a scalable solution.

So I was reading up on the specs, discovered CBSP and thought one good way to get familiar with it is to write a wireshark dissector for it. You can find the result at https://code.wireshark.org/review/#/c/29745/

Now my main problem is that as usual there appear to be no open source implementations of this protocol, so I cannot generate any traces myself. More surprising is that it's not even possible to find any real-world CBSP traces out there. So I'm facing a chicken-and-egg problem. I can only test / verify my wireshark dissector if I find some traces.

So if you happen to have done any work on cell broadcast in 2G network and have a CBSP trace around (or can generate one): Please send it to me, thanks!

Alternatively, you can of course also use the patch linked above, build your own wireshark from scratch, test it and provide feedback. Thanks in either case!

September 14, 2018

Osmocom.org News: OsmocomBB SDR PHY - SDR PHY summer status update!

During this summer we have been working on the project, and despite the lack of time (daily job, traveling, etc.), some important features were introduced, so we are happy to highlight them.

First of all, the project has it's own wiki now, as well as a separate bug/feature tracker. For a long time, there was only a single page with brief description within the OsmocomBB project wiki. Having a dedicated project in Redmine, we are able to provide well structured description and documentation for our milestones. Kudos to Harald Welte!

A few weeks ago, the first milestone has been completed - "Ability to run GSM network on any frequency"! We have managed to run a GSM network in 2.4 GHz WiFi band, connect an SDR-based phone and successfully tested the regular subscriber's activity, such as SMS messaging and voice calls. More details about this feature will be shared soon.

There was a lot of work at the front of audio integration (see https://osmocom.org/versions/133). TCH/H channel coding implementation (see https://osmocom.org/issues/3419) in trxcon has been sent for review. In addition to Full Rate (GSM FR codec) speech, both HR (Half Rate) and EFR (Enhanced Full Rate) codecs are supported as well now! At the moment, all changes related to audio support in OsmocomBB can be found in a separate branch: https://git.osmocom.org/osmocom-bb/log/?h=fixeria/audio

Work on frequency hopping is also ongoing. Up to this point we used OsmoTRX for the purpose of testing of new features in the real world. As OsmoTRX currently doesn't support frequency hopping, we needed to find something else to test this functionality. For this purpose we hooked our mobile station to a Racal 6103E tester (kudos to Sylvain Munaut) that has support for frequency hopping, and currently it is possible to perform location registration and assignment of a traffic channel with it.

September 09, 2018

Dieter Spaar: A Pico Base Station from Ericsson

The RBS6401 is a small indoor base station from Ericsson for WCDMA or LTE. The device is about two times the size of an ip.access nanoBTS. It is based on a KeyStone I SoC from TI and runs Linux (in fact there are two KeyStone I SoCs inside, but it seems that only one of them is used, at least for WCDMA).

Compared to the other commercial base stations I have seen so far the RBS6401 makes it quite hard to get access to the operating system. It tries to setup a VPN to a Security Gateway for Autointegration into the operator's network and there is only a simple Web Interface to set the network parameters of the device.

Unfortunately I have only found the WCDMA software on the three devices I have access to. It would really be nice to use the RBS6401 with LTE, WCDMA is not that interesting (I am not aware of any Open Source RNC). If anyone has the LTE software for the RBS6401, please let me know.

August 26, 2018

Harald "LaForge" Welte: Still alive, just not blogging

It's been months without any update to this blog, and I feel sad about that. Nothing particular has happened to me, everything is proceeding as usual.

At the Osmocom project we've been making great progress on a variety of fronts, including

  • 3GPP LCLS (Local Call, Local Switch)

  • Inter-BSC hand-over in osmo-bsc

  • load Based hand-over in osmo-bsc

  • reintroducing SCCPlite compatibility to the new BSC code in osmo-bsc / libosmo-sigtran

  • finishing the first release of the SIMtrace2 firmware

  • extending test coverage on all fronts, particularly in our TTCN-3 test suites

  • tons of fixes to the osmo-bts measurement processing / reporting

  • higher precision time of arrival reporting in osmo-bts

  • migrating osmocom.org services to new, faster servers

At sysmocom, next to the Osmocom topics above, we've

  • made the sysmoQMOD remote SIM firmware much more robust and reliable

  • after months of delays, finally SIMtrace2 hardware kits are available again

  • created autoamtic testing of pySim-prog and sysmo-usim-util

  • extended our osmo-gsm-tester based automatic testing setup to include multi-TRX nanoBTS setups

In terms of other topic,

  • my wife and I have been to a three week motorbike tour all over the Alps in July

  • I've done tons of servicing (brake piston fittings, brake tubes, fuel line, fixing rust/paint, replacing clutch cable, choke cable, transmission chain, replacing several rusted/worn-out needle bearings, and much more) on my 22year old BMW F650ST to prepare it for many more yers to come. As some type-specific spare parts (mostly plastic parts) are becoming rarer, it was best to take care of replacements sooner than later

  • some servicing/repairs to my 19 year old Audi A4 car (which passed German mandatory inspection without any deficiency at the first attempt!)

  • some servicing of my Yamaha FZ6

  • repaired my Fairphone 2 by swapping the microphone module (mike was mute)

  • I've re-vamped a lot of the physical/hardware infrastructure for gnumonks.org and other sites I run, which was triggered by having to move racks

August 16, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon 2018: Draft Schedule Released

At https://pretalx.sysmocom.de/osmocon2018/schedule/, the first draft schedule for OsmoCon 2018. the annual Open Source Mobile Communications Conference has been released!

It includes many exciting talks from key Osmocom developers and users. Among the key highlights are:

Use the opportunity until August 31st to get your discounted early bird ticket at https://pretix.sysmocom.de/sysmocom/osmocon2018/

We do have a number of community discount ticket vouchers available.

Stay tuned for further schedule updates, and see you in two months at OsmoCon 2018!

June 08, 2018

Harald "LaForge" Welte: Re-launching openmoko USB Product ID and Ethernet OUI registry

Some time after Openmoko went out of business, they made available their USB Vendor IDs and IEEE OUI (Ethernet MAC address prefix) available to Open Source Hardware / FOSS projects.

After maintaining that for some years myself, I was unable to find time to continue the work and I had handed it over some time ago to two volunteers. However, as things go, those volunteers also stopped to respond to PID / OUI requests, and we're now launching the third attempt of continuing this service.

As the openmoko.org wiki will soon be moved into an archive of static web pages only, we're also moving the list of allocated PID and OUIs into a git repository.

Since git.openmoko.org is also about to be decommissioned, the repository is now at https://github.com/openmoko/openmoko-usb-oui, next to all the archived openmoko.org repository mirrors.

This also means that in addition to sending an e-mail application for getting an allocation in those ranges, you can now send a pull-request via github.

Thanks to cuvoodoo for volunteering to maintain the Openmoko USB PID and IEEE OUI allocations from now on!

June 06, 2018

Osmocom.org News: Miscellaneous Projects - Osmocom now accepts financial contributions

The Osmocom project (if you count its predecessor OpenBSC) have been running for close to 10 years, creating a large number of Open Source projects related to mobile communications. We have never needed nor wanted any legal entity for it. It's a pure/classic FOSS project, open to contributions from anyone.

Until today, you could only contribute in one of the following forms:

  • by writing code (bug fixes, new features, etc) and submitting it (which means you need to be a developer)
  • by writing documentation / improving the wiki
  • helping other users on the mailing lists, IRC, or in other forums
  • donating cellular equipment (which many don't have)
  • hiring a freelancer or a company to write code and contribute to Osmocom on your behalf
  • buying products or services from companies who dedicate lots of work to Osmocom

However, we've repeatedly getting requests from some individuals who wanted to contribute to the project in an easy way, even if they are not a developer, and/or don't have time, and/or don't have the size of a budget to fund development of entire new features or sub-systems.

Today, Osmocom announces that we have joined Open Collective in order to enable you to make financial contributions, either one-off or recurring.

We'll be using the funds (if we get any!) according to our funding policy outlined at https://opencollective.com/osmocom/expenses/new# in order to pay for expenses such as hosting costs for our servers / IT infrastructure, travel funding for the annual developer conferences, etc. Any and all expenses paid from those funds will be visible on the OpenCollective website. You cannot ask for more transparency than that :)

Thanks in advance for your kind assistance!

May 30, 2018

Osmocom.org News: Osmocom.org Servers - osmocom.org upgraded to redmine 3.4

We've upgraded our redmine project management software from 3.2 to 3.4, which gets us a number of interesting new features and fixes.

This opportunity was also used to install a number of interesting redmine plugins.

Among the intresting new features are:

  • ability to attach tags to issues and wiki pages
  • projects overview page now with multiple columns and no side-pane
  • preview of image attachments at bottom of issues / wiki pages
  • PDF attachment preview in lightbox
  • uploading/attaching of images from clipboard, including browser-based image cropping
  • links to individual users/developers using the "@" notation like "@laforge" leading to laforge
  • ability to add [temporary] banners and/or footers to the site

Let us know if anything was broken during the upgrade. *

May 28, 2018

Dieter Spaar: A personal remark about security research

In the last few years I have done a lot of automotive security research, one of my findings about cars from BMW, which was the result of working on contract for the ADAC, was published in February 2015: the original German version and the translated English version.

A few days ago Tencent Keen Security Lab published their findings about BMW cars in this paper.

While in general I find it great that there is more public research in the area of automotive security, I really don't like it if previous work isn't respected. The report of Tencent Keen Security Lab does not contain any reference to previous work besides their own. I would at least have expected references to previous QNX research (QNX is the OS used in the BMW infotainment ECU) and my work when it comes to the TCB (Telematic Communication Box, the name of the BMW telematic ECU). For example regarding the TCB, the description of the communication protocol with the backend and how encrypted SMS is used, with identical encryption keys in all cars, was already contained in my report. To find out why there are no references to others work I contacted them, but I didn't receive any reply.

Could it be that they really aren't aware of previous work? If you start researching the BMW telematic ECU, you would very soon become aware of NGTP (Next Generation Telematics Protocol), the protocol used to communicate with the BMW backend. Searching on Google for "TCB" and "NGTP" will give you the link to the German article on the first place. OK, it's just the German article and you would have to open it to find the link to the English translation, which requires an additional step.

What if they don't use Google but Baidu? Searching for "TCB" and "NGTP" on Baidu gave this link on the fourth place. I can't read the page, but this seems to be the Chinese translation of the article from Heise, even the text in the diagrams is translated. Interestingly when I tried to reproduce my search from last week on Baidu today, this page no longer appears in the search results, although the page itself still exists.

So for me its looks like this: Tencent Keen Security Lab either simply doesn't give reference to previous work and follows the old Chinese tradition of "Clone and Copy" or they don't have any clue about Information Gathering, which is one the first steps when starting to research a target. In my opinion neither of the two possibilities is what you really want.

May 25, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon 2018: Make your Submission Now!

one of the difficulties with OsmoCon2017 last year was that almost nobody submitted talks / discussions within the deadline, early enough to allow for proper planning.

This lead to the situation where the sysmocom team had to come up with a schedule/agenda on their own. Later on much after the CfP deadline,people then squeezed in talks, making the overall schedule too full.

It is up to you to avoid this situation again in 2018 at OsmoCon2018 by submitting your talk RIGHT NOW. We will be very strict regarding late submissions. So if you would like to shape the Agenda of OsmoCon 2018, this is your chance. Please use it.

We will have to create a schedule soon, as [almost] nobody will register to a conference unless the schedule is known. If there's not sufficient contribution in terms of CfP response from the wider community, don't complain later that 90% of the talks are from sysmocom team members and only about the Cellular Network Infrastructure topics.

You have been warned. Please make your CfP submission in time at https://pretalx.sysmocom.de/osmocon2018/cfp before the CfP deadline on 2018-05-30 23:59 (Europe/Berlin)

Thanks for your kind attention.

May 24, 2018

Harald "LaForge" Welte: OsmoCon 2018 CfP closes on 2018-05-30

One of the difficulties with OsmoCon2017 last year was that almost nobody submitted talks / discussions within the deadline, early enough to allow for proper planning.

This lad to the situation where the sysmocom team had to come up with a schedule/agenda on their own. Later on much after the CfP deadline,people then squeezed in talks, making the overall schedule too full.

It is up to you to avoid this situation again in 2018 at OsmoCon2018 by submitting your talk RIGHT NOW. We will be very strict regarding late submissions. So if you would like to shape the Agenda of OsmoCon 2018, this is your chance. Please use it.

We will have to create a schedule soon, as [almost] nobody will register to a conference unless the schedule is known. If there's not sufficient contribution in terms of CfP response from the wider community, don't complain later that 90% of the talks are from sysmocom team members and only about the Cellular Network Infrastructure topics.

You have been warned. Please make your CfP submission in time at https://pretalx.sysmocom.de/osmocon2018/cfp before the CfP deadline on 2018-05-30 23:59 (Europe/Berlin)

Harald "LaForge" Welte: openmoko.org archive down due to datacenter issues

Unfortunately, since about 11:30 am CEST on MAy 24, openmoko.org is down due to some power outage related issues at Hetzner, the hosting company at which openmoko.org has been hosting for more than a decade now.

The problem seems to have caused quite a lot of fall-out tom many servers (Hetzner is hosting some 200k machines, not sure how many affected, though), and Hetzner is anything but verbose when it comes to actually explaining what the issue is.

All they have published is https://www.hetzner-status.de/en.html#8842 - which is rather tight lipped about some power grid issues. But then, what do you have UPSs for if not for "a strong voltage reduction in the local power grid"?

The openmoko.org archive machine is running in Hetzner DC10, by the way. This is where they've had the largest number of tickets.

In any case, we'll have to wait for them to resolve their tickets. They appear to be working day and night on that.

I have a number of machines hosted at Hetzner, and I'm actually rather happy that none of the more important systems were affected that long. Some machines simply lost their uplink connectivity for some minutes, while some others were rebooted (power outage). The openmoko.org archive is the only machine that didn't automatically boot after the outage, maybe the power supply needs replacement.

In any case, I hope the service will be back up again soon.

btw: Guess who's been paying for hosting costs ever since Openmoko, Inc. has shut down? Yes, yours truly. It was OK for something like 9 years, but I want to recursively pull the dynamic content through some cache, which can then be made permanent. The resulting static archive can then be moved to some VM somewhere, without requiring a dedicated root server. That should reduce the costs down to almost nothing.

May 23, 2018

Harald "LaForge" Welte: Mailing List hosting for FOSS Projects

Recently I've encountered several occasions in which a FOSS project would have been interested in some reliable, independent mailing list hosting for their project communication.

I was surprised how difficult it was to find anyone running such a service.

From the user / FOSS project point of view, the criteria that I would have are:

  • operated by some respected entity that is unlikely to turn hostile, discontinue the service or go out of business altogether

  • free of any type of advertisements (we all know how annoying those are)

  • cares about privacy, i.e. doesn't sell the subscriber lists or non-public archives

  • use FOSS to run the service itself, such as GNU mailman, listserv, ezmlm, ...

  • an easy path to migrate away to another service (or self-hosting) as they grow or their requirements change. A simple mail forward to that new address for the related addresses is typically sufficient for that

If you think mailing lists serve no purpose these days anyways, and everyone is on github: Please have a look at the many thousands of FOSS project mailing lists out there still in use. Not everyone wants to introduce a dependency to the whim of a proprietary software-as-a-service provider.

I never had this problem as I always hosted my own mailman instance on lists.gnumonks.org anyway, and all the entities that I've been involved in (whether non-profit or businesses) had their own mailing list hosts. From franken.de in the 1990ies to netfilter.org, openmoko.org and now osmocom.org, we all pride oursevles in self-hosting.

But then there are plenty of smaller projects that neither have the skills nor the funding available. So they go to yahoo groups or some other service that will then hold them hostage without a way to switch their list archives from private to public, without downloadable archives or forwarding in the case they want to move away :(

Of course the larger FOSS projects also have their own list servers, starting from vger.kernel.org to Linux distributions like Debian GNU/Linux. But what if your FOSS project is not specifically Linux related?

The sort-of obvious candidates that I found all don't really fit:

Now don't get me wrong, I'm of course not expecting that there are commercial entities operating free-of charge list hosting services where you neither pay with money, nor your data, nor by becoming a spam receiver.

But still, in the wider context of the Free Software community, I'm seriously surprised that none of the various non-for-profit / non-commercial foundations or associations are offering a public mailing list hosting service for FOSS projects.

One can of course always ask any from the above list and ask for a mailing list even though it's strictly speaking off-topic to them. But who will do that, if he has to ask uninvited for a favor?

I think there's something missing. I don't have the time to set up a related service, but I would certainly want to contribute in terms of funding in case any existing FOSS related legal entity wanted to expand. If you already have a legal entity, abuse contacts, a team of sysadmins, then it's only half the required effort.

May 14, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon 2018 CfP deadline extended

The deadline of the Call for Participation (CfP) to the OsmoCon2018 has been extended by two weeks.

This means you still have time until May 30, 2018 to submit your proposal and meet us in October 2018 to talk about your experience, or to share your ideas about Open Source Mobile Communications.

You can find our CfP at https://pretalx.sysmocom.de/osmocon2018/cfp

May 10, 2018

Osmocom.org News: Cellular Network Infrastructure - New Osmocom Cellular software versions released!

The Osmocom project has released new version of the CNI (Cellular Network Infrastructure) software, including OsmoBTS, OsmoBSC, OsmoMGW, OsmoMSC, OsmoHLR, OsmoSGSN, OsmoGGSN.

Thosw new tagged/released versions contain half a year of work since the previous versions released in early November 2017. The primary focus was on bug-fixing and stabilization. Many bugs were introduced during the split of the NITB into individual network elements during 2017, and even more bugs exposed by our ever-growing test coverage, particularly in the Osmocom TTCN-3 test suites.

All-in-all, the post-NITB stack has gained a lot in terms of spec compliance, robustness, stability and features during this period.

You can find pew-compiled binary packages of our latest release for a variety of Debian and Ubuntu GNU/Linux versions at

The developer performing the release related work was Pau Espin. Thanks!

List of tagged versions and link to related ChangeLog

Project Version Changelog
libosmocore 0.11.0 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=0.11.0
libosmo-abis 0.5.0 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=0.5.0
libosmo-netif 0.2.0 http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=0.2.0
OsmoTRX 0.4.0 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=0.4.0
OsmoBTS 0.8.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=0.8.0
OsmoBSC 1.2.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.2.0
OsmoMSC 1.2.0 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.2.0
OsmoHLR 0.2.1 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=0.2.1
osmo-mgw 1.3.0 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.3.0
osmo-sip-connector 1.1.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.1.0
OsmoSTP 0.9.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=0.9.0
OsmoSGSN 1.3.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.3.0
OsmoGGSN 1.2.1 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.2.1

Notworthy Changes


  • GnuTLS fall-back for obtaining randomness
  • support for three-digit MNC throguhout the code-base
  • add talloc introspection via VTY
  • tighter CRTL input parsing
  • stricter VTY config file parsing
  • allow to print only basename of source code file in logging
  • print log level with color-keying of the level name


  • OsmoTRX has now a VTY interface and uses Osmocom-style logging + config file
  • use GNU autotest, like other osmocom projects
  • re-introduce support for USRP1 devices
  • build multiple binaries rather than selecting UHD / USRP1 at compile time
  • EFR decoding fixes
  • fix dynamic detection/use of CPU optimization (SSE3 vs SSSE3)
  • various parsing/encoding fixes for trx-control interface
  • add example config file for USRP B200


  • higher accuracy reporting of time of arrival
  • fix LAPDm UA memory leak
  • put useful information into RTCP SDES packets
  • fix AMR DTX FSM related crash
  • many fixes related to measurement processing + reporting
  • more robust RSL message parsing + error reporting
  • implement DELETE INDICATION on AGCH overflow
  • fix crashes in IPA DLCX processing
  • fix operation without System Information Type 1


  • support all types of Cell Identifier Lists in BSSMAP PAGING
  • fix intra-BSC hand-over (used to work in NITB)
  • fix various error paths in hand-over logic
  • introduce new "handover 2" algorithm from Andreas Eversberg
  • introduce load-based hand-over to balance channel load between overlapping BTSs
  • implement SI2ter + SI2bis rest octets
  • switch to osmo-mgw for handling media/user plane (instead of old osmo-bsc_mgcp)
  • introduce osmo_fsm for subscriber_connection
  • reduce several GSM timers to more reasonable default values (T3113, T3109, T3101, ...)
  • permit codec list with both TCH/F and TCH/H channels
  • permit network supporting more than one A5 cipher
  • fix missing L2 pseudo-length in SI5/SI6 messages
  • introduce Access Control Class (ACC) ramping to deal with overload situations on network power-up
  • switch to "late assignment" by default (we used to do early / very early assignment)
  • many fixes related to 3GPP spec / protocol compliance


  • fix various use-after-free in GSUP and CC
  • fix GSM-MILENAGE in presence of 2G keys
  • cancel all paging on IMSI DETACH
  • many fixes related to 3GPP spec / protocol compliance
  • permit network supporting more than one A5 cipher
  • properly pass bearer capabilities between MNCC and CC
  • switch to osmo-mgw for handling media/user plane (instead of old osmo-bsc_mgcp)
  • use dynamic MGCP endpoint allocation using wildcard
  • migrate away from openssl to new libosmocore rand abstraction
  • fixes related to SMS validity time
  • delete expired SMS automatically
  • fix transmission of MM INFO messages
  • fix SMS to non-local subscriber


  • fix various crashes
  • fix response to PURGE_MS
  • notify GSUP clients (MSC, SGSN) when HLR subscriber information changes

OsmoMGW (and libosmo-mgcp-client)

  • Introduce osmo_fsm client API
  • various fixes of SDP parser
  • significantly improved compliance with MGCP spec
  • wildcarded endpoint allocation in CRCX


  • integrate libsofia-sip logging with libosmocore logging
  • add systemd service file

OsmoSTP (and libosmo-sigtran)

  • fix various memory leaks
  • introduce IPA/SCCPlite support (allows translation of SCCPlite to M3UA/SUA)


  • fix some crashes
  • migrate away from openssl to new libosmocore rand abstraction
  • fix display of GTP addresses in VTY

OsmoGGSN (and libgtp)

  • re-introduce support for kernel GTP acceleration (was temporarily removed when migrating from OpenGGSN)
  • fix byte-order of IPCP IPv4 DNS server addresses
  • add support for IPv4v6 End User Addresses
  • Validate packet src addr from MS
  • various sgsnemu fixes

Osmocom.org News: Osmocom.org Servers - expected osmocom.org downtime on Sunday, 2018-05-13

This Sunday (May 13), we're planning to do some of the pending migration of osmocom.org services from our old server to a new machine.

This will cause some downtime. Hopefully it will be minimal, but for sure there will be unexpected events that will mean some of the osmocom.org services will be unavailable at some point during Sunday :/

In terms of priorities, gerrit is high up on the list, so this is the primary focus. If that goes well, redmine is the next on the list.

In case you're interested in the gory details, #3076 is the overview ticket.

May 04, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - All OsmoDevCon 2018 Videos Released

All of the video recordings made at the recent 2018 Osmocom Developer Conference (OsmoDevCon2018) have meanwhile been released.

You can find the recordings at https://media.ccc.de/b/conferences/osmocon/osmodevcon18 with a back-up at this youtube playlist

Please excuse the bad audio quality in the Welcome to OsmoDevCon 2018 talk. We didn't pay attention to the clipping and only resolved it towards the end of that talk. All other videos have proper audio quality.

April 29, 2018

Harald "LaForge" Welte: OsmoDevCon 2018 retrospective

One week ago, the annual Osmocom developer meeting (OsmoDevCon 2018) concluded after four long and intense days with old and new friends (schedule can be seen here).

It was already the 7th incarnation of OsmoDevCon, and I have to say that it's really great to see the core Osmocom community come together every year, to share their work and experience with their fellow hackers.

Ever since the beginning we've had the tradition that we look beyond our own projects. In 2012, David Burgess was presenting on OpenBTS. In 2016, Ismael Gomez presented about srsUE + srsLTE, and this year we've had the pleasure of having Sukchan Kim coming all the way from Korea to talk to us about his nextepc project (a FOSS implementation of the Evolved Packet Core, the 4G core network).

What has also been a regular "entertainment" part in recent years are the field trip reports to various [former] satellite/SIGINT/... sites by Dimitri Stolnikov.

All in all, the event has become at least as much about the people than about technology. It's a community of like-minded people that to some part are still working on joint projects, but often work independently and scratch their own itch - whether open source mobile comms related or not.

After some criticism last year, the so-called "unstructured" part of OsmoDevCon has received more time again this year, allowing for exchange among the participants irrespective of any formal / scheduled talk or discussion topic.

In 2018, with the help of c3voc, for the first time ever, we've recorded most of the presentations on video. The results are still in the process of being cut, but are starting to appear at https://media.ccc.de/c/osmodevcon2018.

If you want to join a future OsmoDevCon in person: Make sure you start contributing to any of the many Osmocom member projects now to become eligible. We need you!

Now the sad part is that it will take one entire year until we'll reconvene. May the Osmocom Developer community live long and prosper. I want to meet you guys for many more years at OsmoDevCon!

There is of course the user-oriented OsmoCon 2018 in October, but that's a much larger event with a different audience.

Nevertheless, I'm very much looking forward to that, too.

The OsmoCon 2018 Call for Participation is still running. Please consider submitting talks if you have anything open source mobile communications related to share!

April 28, 2018

Osmocom.org News: OsmoTRX - Osmocom improves USRP1 support in OsmoTRX

The Ettus USRP1 hardware was the first SDR device that could be used to implement a GSM base station. At Osmocom we never removed the related support from OsmoTRX, but it was getting rather hard to use with USRP1 due to two reasons:

  1. libusrp had been removed from gnuradio after gnuradio 3.4.2 in FIXME
  2. OsmoTRX could only be built with either UHD (for USRP2/B2x0/... devices) or with libusrp/USRP1 support

In recent weeks, we have improved the situation by the following measures:

  1. Alexander Huemer took the last released libusrp from gnuradio-3.4.2 and released it at http://git.osmocom.org/libusrp/
  2. Pau Espin packaged this libusrp for Debian, it is now part of our nightly and latest Binary_Packages
  3. Pau Espin re-structured OsmoTRX to build two binaries from one build: osmo-trx-uhd and osmo-trx-usrp

Osmocom.org News: Cellular Network Infrastructure - Osmocom nightly + latest feeds for Ubuntu 18.04

As Ubuntu 18.04 (Bionic Beaver) has been released two days ago, Osmocom has enabled Binary_Packages builds for this new distribution in both nightly and latest. As a result, you can now use our binary package feeds on this most recent incarnation of Ubuntu just like on the other supported distributions.

This was relatively easy due to the openSUSE Build Service (OBS) immediately adding support for Ubuntu 18.04. so all we had to o is enable it, and fix up some minor failures. Thanks to OBS for making supporting new distributions very easy!

April 23, 2018

Osmocom.org News: osmo-fl2k - osmo-fl2k for using USB 3.0 VGA adapters as SDR transmitters

On April 22nd, Osmocom developer Steve Markgraf has released a new Osmocom project called osmo-fl2k during OsmoDevCon2018.

osmo-fl2k allows you to use the DAC contained in Fresco Logic FL2000 USB 3.0 VGA adapters as a SDR transmitter. Rather than rendering video signals to a screen attached to the VGA output, the DAC is used to generate RF signals in base band, possibly relying on the harmonics to achieve signals at much higher frequencies than possible at 165 MS/s in base-band.

The project thus follows the spirit of the earlier rtl-sdr project, which re-uses USB DVB receiver dongles with the RTL2832U chip as SDR receivers. Like-wise, osmo-fl2k creatively re-uses USB 3.0 VGA adaptors as SDR transmitters. The two projects are thus complementary.

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCon 2018 concludes

Today, OsmoDevCon2018, the annual Osmocom developer meeting concluded. It featured four days of exciting talks and discussions about open source mobile communications, by developers for developers.

The final schedule containing all 41 individual presentations/discussions/workshops of the four days can be found at https://pretalx.sysmocom.de/osmodevcon2018/schedule/

Thanks to c3voc (the CCC Video team), we have audio+video recordings. Almost all presentations (up to speaker discretion) will be released soon. We will publish another news item once the videos are released.

We'd like to extend our thanks to
  • the 20 speakers (at 25 attendees, that's 80%!)
  • the sponsor sysmocom for organization, covering all lunch + dinner catering as well as some travel funding
  • Lime Microsystems for donating 15 LimeSDR-mini to OsmoDevCon 2018 attendees
  • c3voc for their video recording
  • IN-Berlin for venue hosting (Sat-Mon)
  • CCC Berlin for venue hosting (Fri)

Video recordings of the talks will become available step by step at https://media.ccc.de/b/conferences/osmocon/osmodevcon18

April 22, 2018

Harald "LaForge" Welte: osmo-fl2k - Using USB-VGA dongles as SDR transmitter

Yesterday, during OsmoDevCon 2018, Steve Markgraf released osmo-fl2k, a new Osmocom member project which enables the use of FL2000 USB-VGA adapters as ultra-low-cost SDR transmitters.

How does it work?

A major part of any VGA card has always been a rather fast DAC which generates the 8-bit analog values for (each) red, green and blue at the pixel clock. Given that fast DACs were very rare/expensive (and still are to some extent), the idea of (ab)using the VGA DAC to transmit radio has been followed by many earlier, mostly proof-of-concept projects, such as Tempest for Eliza in 2001.

However, with osmo-fl2k, for the first time it was possible to completely disable the horizontal and vertical blanking, resulting in a continuous stream of pixels (samples). Furthermore, as the supported devices have no frame buffer memory, the samples are streamed directly from host RAM.

As most USB-VGA adapters appear to have no low-pass filters on their DAC outputs, it is possible to use any of the harmonics to transmit signals at much higher frequencies than normally possible within the baseband of the (max) 157 Mega-Samples per seconds that can be achieved.

osmo-fl2k and rtl-sdr

Steve is the creator of the earlier, complementary rtl-sdr software, which since 2012 transforms USB DVB adapters into general-purpose SDR receivers.

Today, six years later, it is hard to think of where SDR would be without rtl-sdr. Reducing the entry cost of SDR receivers nearly down to zero has done a lot for democratization of SDR technology.

There is hence a big chance that his osmo-fl2k project will attain a similar popularity. Having a SDR transmitter for as little as USD 5 is an amazing proposition.

free riders

Please keep in mind that Steve has done rtl-sdr just for fun, to scratch his own itch and for the "hack value". He chose to share his work with the wider public, in source code, under a free software license. He's a very humble person, he doesn't need to stand in the limelight.

Many other people since have built a business around rtl-sdr. They have grabbed domains with his project name, etc. They are now earning money based on what he has done and shared selflessly, without ever contributing back to the pioneering developers who brought this to all of us in the first place.

So, do we want to bet if history repeats itself? How long will it take for vendors showing up online advertising the USB VGA dongles as "SDR transmitter", possibly even with a surcharge? How long will it take for them to include Steve's software without giving proper attribution? How long until they will violate the GNU GPL by not providing the complete corresponding source code to derivative versions they create?

If you want to thank Steve for his amazing work

  • reach out to him personally

  • contribute to his work, e.g.

  • help to maintain it

  • package it for distributions

  • send patches (via osmocom-sdr mailing list)

  • register an osmocom.org account and update the wiki with more information

And last, but not least, carry on the spirit of "hack value" and democratization of software defined radio.

Thank you, Steve! After rtl-sdr and osmo-fl2k, it's hard to guess what will come next :)

April 21, 2018

Kevin Redon: 3GPP specifications revision control

Mobile networks such as GSM, UMTS, and LTE are based on 3GPP specifications; a lot of them (~ 3148). These are the reference documents when trying to understand or implementing any part of the mobile networks. They also evolve with time as details get corrected, features are added, or new radio access technologies such as New Radio (i.e. 5G) are released. Keeping track of the versions and added features is not an easy task, particularly when you are not working on them directly.

April 10, 2018

Osmocom.org News: Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoCon2018: Save the date + Call for Participation

OsmoCon 2018

OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers!

We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany.

For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others.

Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software.

You can find some initial information in our wiki at OsmoCon 2018, which will be updated as more information becomes available.

Call for Participation

We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals.

We are particularly looking for contributions about:

  • updates on features/functionality/status of individual Osmocom projects
  • success stories on how Osmocom projects are deployed in practice
  • migration from OsmoNITB to the post-NITB architecture
  • tutorials / workshops on how to setup / analyze Osmocom projects
  • statistics, reporting, operations aspects of Osmocom projects
  • third-party open source utilities to be used with Osmocom projects

Copyright (C) 2001-2010 by the respective authors.