Planet Osmocom

October 21, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #16 - SIM profile, personali...

We're happy to announce the 16th incarnation of OsmoDevCall

This time laforge will be presenting on SIM card profile creation, personalization, production

When: Friday, October 22nd, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at October 21, 2021 08:15 AM

October 16, 2021

Osmocom.org News

pySim - pySim-shell support for sysmoISIM-SJA2 key data / files

Starting from f44256c7dff6d24f1f940d4ca71219abbb0c7e34, pySim-shell now supports the non-standard files of the sysmoISIM-SJA2 SIM cards containing authentication key material for AKA and TS 03.48 OTA.

This way you can now interactively inspect and/or modify aspects such as

UMTS AKA key material and configuration

pySIM-shell (MF/ADF.USIM/EF.USIM_AUTH_KEY)> read_binary_decoded
{
    "cfg": {
        "only_4bytes_res_in_3g": 0,
        "use_sres_deriv_func_2_in_3g": 0,
        "use_opc_instead_of_op": 1,
        "algorithm": "milenage" 
    },
    "key": "07583fd7518b42752fea8b7063faa756",
    "op": null,
    "opc": "440aac831e58941abe17a5db76470776" 
}
pySIM-shell (MF/ADF.USIM/EF.USIM_SQN)> read_binary_decoded 
{
    "flag1": {
        "skip_next_sqn_check": 0,
        "delta_max_check": 1,
        "age_limit_check": 0,
        "sqn_check": 0,
        "ind_len": 5
    },
    "flag2": {
        "rfu": 0,
        "dont_clear_amf_for_macs": 0,
        "aus_concealed": 1,
        "autn_concealed": 1
    },
    "delta_max": 8589934592,
    "age_limit": 8589934592,
    "freshness": [ 32, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ]
}

Milenage configuration (constants)

pySIM-shell (MF/DF.SYSTEM/EF.MILENAGE_CFG)> read_binary_decoded
{
    "r1": 64,
    "r2": 0,
    "r3": 32,
    "r4": 64,
    "r5": 96,
    "c1": "00000000000000000000000000000000",
    "c2": "00000000000000000000000000000001",
    "c3": "00000000000000000000000000000002",
    "c4": "00000000000000000000000000000004",
    "c5": "00000000000000000000000000000008" 
}

OTA key material

pySIM-shell (MF/DF.SYSTEM/EF.0348_KEY)> read_record_decoded 1
{
    "sec_domain": 0,
    "key_set_version": 112,
    "key_type": "kic",
    "key_length": 16,
    "algorithm": "des",
    "mac_length": 8,
    "key": "c039ed58f7b81446105e79ebfd" 
}

by laforge at October 16, 2021 08:31 AM

pySim - pySim-prog critical fix against corruption of key material

In 80901d6d39fd05b923c48145147c47f0ad5252ca we fixed a critical bug regarding the writing of key material when using the classic pySim-prog utility. All versions since 2e6dc03f345150353ecc796f18614c02256bd2df on July 31st are affected.

This means if you are using any of the affected versions in the range above, writing keys will write an erroneous key to your card, where the first byte of the user-specified key is dropped, the remaining 15 bytes are written from offset 0, and the last byte of the key will not be updated on the card.

Programming key material by sysmo-{isim,usim}-tool was not affected by this.

Users are requeste to update to current master or any version including 80901d6d39fd05b923c48145147c47f0ad5252ca

We apologize for any inconvenience.

by laforge at October 16, 2021 08:22 AM

October 10, 2021

Harald "LaForge" Welte

First steps towards an ITU-T V5.1 / V5.2 implementation

As some of you may know, I've been starting to collect "vintage" telecommunications equipment starting from analog modems to ISDN adapters, but also PBXs and even SDH equipment. The goal is to keep this equipment (and related software) alive for demonstration and practical exploration.

Some [incomplete] information can be found at https://osmocom.org/projects/retro-bbs/wiki/

Working with PBXs to simulate the PSTN (ISDN/POTS) network is fine to some extent, but it's of course not the real deal. You only get S0-buses and no actual Uk0 like actual ISDN lines of the late 80ies and 90ies. You have problems with modems not liking the PBX dialtone, etc.

Hence, I've always wanted to get my hand on some more real-world central-office telephone network equipment, and I finally have a source for so-called V5.1/V5.2 access multiplexers. Those are like remote extension boxes for the central office switch (like EWSD or System 12). They aggregate/multiplex a number of analog or ISDN BRI subscriber lines into E1 lines, while not implementing any of the actual call control or ISDN signalling logic. All of that is provided by the actual telephone switch/exchange.

So in order to integrate such access multiplexers in my retronetworking setup, I will have to implement the LE (local exchange) side of the V5.1 and/or V5.2 protocols, as specified in ITU-T G.964 and G.965.

In the limited spare time I have next to my dayjob and various FOSS projects, progress will likely be slow. Nonetheless I started with an implementation now, and I already had a lot of fun learning about more details of those interfaces and their related protocols.

One of the unresolved questions is to what kind of software I would want to integrate once the V5.x part is resolved.

  • lcr would probably be the most ISDN-native approach, but it is mostly unused and quite EOL.

  • Asterisk or FreeSWITCH would of course be obvious candidates, but they are all relatively alien to ISDN, and hence not very transparent once you start to do anything but voice calls (e.g. dialup ISDN data calls in various forms).

  • yate is another potential candidate. It already supports classic SS7 including ISUP, so it would be a good candidate to build an actual ISDN exchange with V5.2 access multiplexers on the customer-facing side (Q.921+Q.931 on it) and SS7/ISUP towards other exchanges.

For now I think yate would be the most promising approach. Time will tell.

The final goal would then be to have a setup [e.g. at a future CCC congress] where we would have SDH add/drop multiplexers in several halls, and V5.x access multiplexers attached to that, connecting analog and ISDN BRI lines from individual participants to a software-defined central exchange. Ideally actually multiple exchanges, so we can show the signaling on the V5.x side, the Q.921/Q.931 side and the SS7/ISUP between the exchanges.

Given that the next CCC congress is not before December 2022, there is a chance to actually implement this before then ;)

by Harald Welte at October 10, 2021 10:00 PM

October 08, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #15 - VoLTE/IMS pcap deep-dive

We're happy to announce the 15th incarnation of OsmoDevCall

This time laforge will be presenting a VoLTE / IMS pcap file deep dive.

When: Friday, October 8th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

UPDATE: Location moved to https://meet.sysmocom.de/OsmoDevCall due to server problems at franken.de

by laforge at October 08, 2021 05:49 AM

September 23, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #14 - ISO7816 smart card int...

We're happy to announce the 14th incarnation of OsmoDevCall

This time tnt will be presenting about his work on an ISO 7816 smart card interface FPGA softcore.

When: Friday, September 24th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at September 23, 2021 06:49 PM

September 03, 2021

Osmocom.org News

Cellular Network Infrastructure - Osmocom package feeds for Debian 11 + Ubuntu 21.04

Osmocom is happy to announce releasing binary package feeds for the latest tagged versions and nightly builds for both Debian 11 and Ubuntu 21.04.

At the same time, we have retired the support for Debian 8 and Ubuntu 19.10.

The full list of distributions and architectures we provide binary packages for can be seen at Latest_Builds and Nightly_Builds - including links to the package feeds and instructions how to use them.

by laforge at September 03, 2021 03:57 PM

August 24, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #13 - osmo-remsim in practice

We're happy to announce the 13th incarnation of OsmoDevCall

This time laforge will be presenting about osmo-remsim in practice

The talk will cover
  • introduction to osmo-remsim architecture
  • supported hardware / software
  • practical demonstration

When: Friday, August 27th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at August 24, 2021 11:49 AM

August 12, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #12 - GSM-R and its differen...

We're happy to announce the 12th incarnation of OsmoDevCall

This time laforge will be presenting about GSM-R and its differences to GSM.

When: Friday, August 13th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at August 12, 2021 11:30 AM

July 22, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #11 - high-level overview on...

We're happy to announce the 11th incarnation of OsmoDevCall

This time laforge will be presenting a high-level introduction to IMS and its use in VoLTE and VoWiFi.

When: Friday, July 23rd, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at July 22, 2021 06:43 AM

July 19, 2021

Harald "LaForge" Welte

Notfallwarnung im Mobilfunknetz + Cell Broadcast (Teil 2)

[excuse this German-language post, this is targeted at the current German public discourse]

Ein paar Ergänzungen zu meinem blog-post gestern.

Ich benutzt den generischen Begriff PWS statt SMSCB, weil SMSCB strikt genommen nur im 2G-System existiert, und nur ein Layer ist, der dort für Notfallalarmierung verwendet wird.

Zu Notfallwarn-Apps

Natürlich sind spezielle, nationale Deutsche Katastrophenschutz-Apps auch nützlich! Aber diese sollten allenfalls zusätzlich angeboten werden, nachdem man erstmal die grundlegende Alarmierung konform der relevanten internationalen (und auch EU-)Standards via Cell Broadcast / PWS realisiert. Man sagt ja auch nicht: Nachrichtensendungen braucht man im Radio nicht mehr, weil man die bereits im Fernsehen hat. Man will auf allen verfügbaren Kanälen senden, und zunächst jene mit möglichst universeller Reichweite und klaren technischen Vorteilen benutzen, bevor man dann zusätzlich auch auf anderen Kanälen alarmiert.

Wie sieht PWS für mich als Anwender aus

Hier scheint es größere Missverständnisse zu geben, wie das auf dem Telefon letztlich aussieht. Ist ja auch verständlich, hierzulande sieht man das nie, ausser man ist zufällig in einem Labor/Basttel-Netz z.B. auf einer CCC-Veranstaltung unterwegs, in der das Osmocom-Projekt mal solche Nachrichten versendet hat.

Die PWS (ETWS, CMAS, WEA, KPAS, EU-ALERT, ...) nachrichten werden vom Telefon empfangen, und dann je nach Konfiguration und Priorität behandelt. Für die USA ist im WEA vorgeschrieben, dass Alarme einer bestimmten Prioritatsklasse (z.B. der Presidential Level Alert) immer zwangsweise zur Anzeige gebracht werden und immer mit einem lauten sirenenartigen Alarmton einhergehen. Es ist sogar explizit verboten, dass der Anwender diese Alarme irgendwo ausstellen, stumm schalten o.ä. kann. Insofern spielt es keine Rolle, ob das Telefon gerade Lautlos gestellt ist, oder es nicht gerade unmittelbar bei mir ist.

Bei manchen Geräten werden die Warnungen sogar mittels einer text2speech-Engine laut über den Lautsprecher vorgelesen, nachdem der Alarmton erscheint. Ob das eine regulatorische Anforderung eines der nationalen System ist, weiss ich nicht - ich habe es jedenfalls bereits in manchen Fällen gesehen, als ich mittels Osmocom-Software solche Alarme in privaten Labornetzen versandt habe.

Noch ein paar technische Details

  • PWS-Nachrichten werden auch dann noch ausgestrahlt, wenn die Zelle ihre Netzanbindung verloren hat. Wenn also z.B. das Glasfaserkabel zum Kernnetz bereits weg ist, aber noch Strom da ist, werden bereits vorher vom CBC (Cell Broadcast Centre) an die Mobilfunkzelle übermittelte Warnungen entsprechend ihrer Gültigkeitsdauer weiter autonom von der Zelle ausgesendet Das ist wieder ein inhärenter technischer Vorteil, der niemals mit einer App erreichbar ist, weil diese erfordert dass das komplette Mobilfunknetz mit allen internen Verbindungen und dem Kernnetz sowie die Internetverbindung vom Netzbetreiber zum Server des App-Anbieters durchgehend funktioniert.

  • PWS-Nachrichten können zumindest technisch auch von Telefonen empfangen werden, die garnicht im Netz eingebucht sind, oder die keine SIM eingelegt haben. Ob dies in den Standards gefordert wird, und/oder ob dies die jeweilige Telefonsoftware das so umsetzt, weiss ich nicht und müsste man prüfen. Technisch liegt es nahe, ähnlich wie das Absetzen von Notrufen, das ja auch technisch in diesen Fällen möglich ist.

Zu den Kosten

Wenn - wie in der idealen Welt - das Vorhalten von Notfallalarmierung eine Vorgabe bereits zum Zeitpunkt der Lizenzvergabe für Funkfrequenzen gewesen wäre, wäre das alles einfach ganz lautlos von Anfang an immer unterstützt gewesen. Keiner hätte extra Geld investieren müssen, weil diese minimale technische Vorgabe dann ja bereits Teil der Ausschreibungen der Betreiber für den Einkauf ihres Equipments gewesen wäre. Zudem hatten wir ja bereits in der Vergangenheit Cell Brodacast in allen drei Deutschen Netzen, d.h. die Technik war mal [aus ganz andern Gründen] vorhanden aber wurde irgendwann weggespart.

Das jetzt nachträglich einzuführen heisst natürlich, dass es niemand eingeplant hat, und dass jeder beteiligte am Markt sich das vergolden lassen will. Die Hersteller freuen sich in etwa wie "Oh, Ihr wollt jetzt mehr als ihr damals beim Einkauf spezifiziert habt? Schön, dann schreiben wir mal ein Angebot".

Technisch ist das alles ein Klacks. Die komplette Entwicklung aller Bestandteile für PWS in 2G/3G/4G/5G würde ich auf einen niedrigen einmaligen sechsstelligen Betrag schätzen. Und das ist die einmalige Investition in der Entwicklung, welche dann über alle Geräte/Länder/Netze umgebrochen wird. Bei den Milliarden, die in Entwicklung und Anschaffung von Mobilfunktechnik investiert wird, ist das ein Witz.

Die Geräte wie Basisstationen aller relevanten Hersteller unterstützen natürlich von Haus aus PWS. Die bauen für Deutschland ja nicht andere Geräte, als jene, die in UK, NL, RO, US, ... verbaut werden. Der Markt ist international, die gleiche Technik steht überall.

Weil man jetzt zu spät ist, wird das natürlich von allen Seiten ausgenutzt. Jeder Basisstationshersteller wird die Hand aufhalten und sagen, das kostet jetzt pro Zelle X EUR im Jahr zusätzliche Lizenzgebühren. Und die Anbieter der zentralen Komponente CBC werden auch branchenüblich die Hand aufhalten, mit satten jährlichen Lizenzgebühren. Und die Consultants werden auch alle die Hand aufhalten, weil es gibt wieder etwas zu Integrieren, zu testen, ... Das CBC ist keine komplexe Technik. Wenn man das einmalig als Open Source entwickeln lässt, und in allen Netzen einsetzt, bekommt man es quasi zum Nulltarif. Aber das würde ja Voraussetzen, dass man sich wirklich mit der Technik befasst, versteht um welch simple Software es hier geht, und dass man mal andere Wege in der Beschaffung geht, als nur mal eben bei seinen existierenden 3 Lieferanten anzurufen, die sich dann eine goldene Nase verdienen wollen.

In der öffentlichen Diskussion wird von 20-40 Millionen EUR gesprochen. Das sind überzogene Forderungen der Marktteilnehmer, nichts sonst. Aber selbst wenn man der Meinung ist, dass man lieber das Geld zum Fenster hinauswerfen will, statt Open Source Alternativen zu [ver]suchen, dann ist auch diese Größenordnung etwas, dass im Vergleich zu den sonstigen Anschaffungs- und Betriebskosten eines Mobilfunknetzes verschwindend gering ist. Ganz zu schweigen von den Folgekosten im Bereich Bergung/Rettung, Personenschäden, etc. die sich dadurch mittelfristig bei Katastrophen einsparen lassen.

Oder anders betrachtet: Wenn sogar das wirtschaftlich viel schwächere Rumänien sich sowas leisten kann, dann wird es wohl auch die Bundesrepublik Deutschland stemmen können.

by Harald Welte at July 19, 2021 10:00 PM

July 18, 2021

Harald "LaForge" Welte

Notfallwarnung im Mobilfunknetz + Cell Broadcast

[excuse this German-language post, this is targeted at the current German public discourse]

In mehrerern Gegenden Deutschlands gab es verheerende Hochwasser, und die Öffentlichkeit diskutiert deshalb mal wieder die gute alte Frage nach dem adäquaten Mittel der Alarmierung der Bevölkerung.

Es ist einfach nur ein gigantisches Trauerspiel, wie sehr die Deutsche Politik und Verwaltung in diesem Punkt inzwischen seit Jahrzehnten sämtliche relevanten Standards verpennt, und dann immer wieder öffentlich durch fachlich falsche und völlig uninformierte Aussagen auffällt.

Das Thema wurde vor dem aktuellen Hochwasser bereits letztes Jahr im Rahmen des sog. WarnTag öffentlich diskutiert. Auch hier von Seiten der öffentlichen Hand ausschliesslich mit falschen Aussagen, wie z.B. dass es bei Cell Broadcast Datenschutzprobleme gibt. Dabei ist Cell Broadcast die einzige Technologie, wo keine Rückmeldung des einzelnen Netzteilnehmers erfolgt, und das Netz nichtmal weiss, wer die Nachricht empfangen hat, und wo dieser Empfang stattgefunden hat. Ganz wie beim UKW-Radio.

Fakt ist, dass alle digitalen Mobilfunkstandards seit GSM/2G, d.h. seit 1991 die Möglichkeit mitbringen, effizient, schnell und datensparsam alle Nutzer (einer bestimmten geographischen Region) mit sogenannten broadcast Nachrichten zu informieren. Diese Technik, in GSM/2G genannt Cell Broacast (oder auch _SMSCB_), unterscheidet sich Grundlegend von allen anderen Kommunikationsformen im Mobilfunknetz, wie Anrufe und herkömmliche SMS (offiziell SMS-PP). Anrufe, SMS und auch mobile Paketdaten (Internet) werden immer f"ur jeden Teilnehmer individuell auf ihm zugewiesenen Funkressourcen übermittelt. Diese Ressourcen sind beschränkt. Es können in keinem Mobilfunknetz der Welt alle Teilnehmer gleichzeitig telefonieren, oder gleichzeitig SMS empfangen.

Stattdessen benutzt Cell Broadcast - wie der Name bereits unmissverständlich klar macht - Einen broadcast, d.h. Rundsendemechanismus. Eine Nachricht wird einmal gesendet, benötigt also nur eine geteilte Ressource auf der Luftschnittstelle, und wird dann von allen Geräten im Empfangsbereich zeitgleich empfangen und dekodiert. Das ist wie UKW-Radio oder klassisches terrestrisches Fernsehen.

Cell Broadcsat wurde bereits in den 1990er Jahren von Deutschen Netzbetreibern benutzt. Und zwar nicht für etwas lebensnotwendiges wie die Notfallsignalisierung, sondern für so banale Dinge wie die Liste jener Vorwahlen, zu denen gerade ein vergünstigter "wandernder Ortstarif" Besteht. Ja, sowas gab es mal bei Vodafone. Oder bei O2 wurden über lange Zeit (aus unbekannten Gründen) die GPS-Koordinaten der jeweiligen Basisstation als Cell Broadcast versendet.

In der folgenden (nun fast abgeschalteten) Mobilfunkgeneration 3G wurde Cell Broadcast leicht unbenannt als Service Area Broadcast beibehalten. Schliesslich gibt es ja Länder mit - anders als in Deutschland - funktionierender und kompetenter Regulierung des Telekommunikationsmarktes, und die langjährig bestehenden gesetzlichen Anforderungen solcher Länder zwingen die Netzbetreiber und auch die Ausrüster der Neztbetreiber, neue Mobilfunkstandards so zu entwickeln, dass die gesetzlichen Vorgaben bzgl. der Alarmierung der Bevölkerung im Notfall funktioniert.

Im Rahmen dieser Standardisierung haben eine Reihe von Ländern innerhalb der 3GPP-Standardisierung (zuständig für 2G, 3G, 4G, 5G) sogenannte Public Warning Systems (PWS) standardisiert. Zu diesen gehören z.B. das Japanische ETWAS (Earthquake and Tsunami Warning System), das Koreanische KPAS (Korean Public Alerting System), das US-Amerikanische WEA (Wireless Emergency Alerts) und auch das EU-ALERT mit den nationalen Implementationen NL-ALERT (Niederlande) und UK-ALERT (Großbritannien).

Die zahlreichen Studien und Untersuchungen, die zur Gestaltung obiger Systeme und der internationalen Standards im Mobilfunk geführt haben, weisen auch nochmal nach, was sowieso vorher jedem Techniker offensichtlich erscheint: Eine schelle Alarmierung aller Teilnehmer (einer Region) kann nur über einen Broadcast-Mechanismus erfolgen. In Japan war die Zielvorgabe, die Alarmierung in Erdbebenfällen innerhalb von weniger als 4 Sekunden an die gesamte betroffene Bevölkerung zu übertragen. Und das ist mit PWS möglich!

Die relevanten PWS-Standards in 2G/3G/4G/5G bieten jede Menge nützliche Funktionen:

  • Benachrichtigung in bestimmten geographischen Regionen

  • Interoperable Schnittstellen, so das Netzwerkelemente unterschiedlicher Hersteller mit einander Kommunizieren

  • Konfigurierbare Benachrichtigungstexte, nicht nur in der primären Landessprache, sondern auch in mehreren anderen Sprachen, die dann automatisch je nach Spracheinstellung des Telefons wiedergegeben werden

  • Unterschiedliche Schweregrad von Alarmierungen

  • Übermittlung nicht nur im Broadcast, sondern auch im Unicast an jeden Teilnehmer, der gerade in einem Telefongespräch ist, und dessen Telefon gerade währenddessen aus technischen Gründen den Broadcast nicht empfangen würde

  • Unterschied zwischen Wiederholung einer Übertragung ohne Änderung des Inhalts und einer übertragung mit geändertem Inhalt

Es gibt also seit vielen Jahren internationale Standards, wie sämtliche heute eingesetzten Mobilfunktechniken zur schnellen, effizienten und datensparsamen Alarmierung der Bevölkerung eingesetzt werden können.

Es gibt zahlreiche Länder, die diese Systeme seit langem einsetzen. Das US-Amerikanische WEA wurde nach eigenen Angaben seit 2012 bereits mehr als 61.000 Mal benutzt, um Menschen vor Unwetter oder anderen Katastrophen zu warnen.

Sogar innerhalb der EU hat man das EU-ALERT System spezifiziert, welches weitgehend mit dem amerikanischen WEA identisch ist, und auf die gleichen Techniken aufbaut.

Und dann gibt es Länder wie Deutschland, die es seit genauso vielen Jahren vermissen lassen, durch Gesetze oder Vorschriften

  1. die Netzbetreiber zum Betrieb dieser Broadcast-Technologien in ihrem Netz verpflichtet

  2. die Netzbetreiber zur Bereitstellung von standardisierten Schnittstellen gegenüber den Behörden wie Zivilschutz / Katastrophenschutz zu verpflichten, so das diese selbständig über alle Netzbetreiber Warnungen versenden können

  3. die Gerätehersteller z.B. über Vorschriften des FTEG (Gesetz über Funkanlagen und Telekommunikationsendeinrichtungen) zu Verpflichten, die PWS-Nachrichten anzuzeigen

In den USA, dem vermeintlich viel mehr dem Freien Markt und dem Kapitalismus anhängenden System ist all dies der Regulierungsbehörde FCC möglich. In Deutschland mit seiner sozialen Marktwirtschaft ist es anscheinend unmöglich, den Markt entsprechend zu regulieren. Eine solche Regulierung schafft man in Deutschland nur für wirklich wichtige Themen wie zur Durchsetzung der Bereitstellung von Schnittstellen für die Telekommunikationsüberwachung. Bei so irrelevanten Themen wie dem Katastrophenschutz und der Alarmierung der Bevölkerung braucht man den Markt nicht zu regulieren. Wenn die Netzbetreiber kein PWS anbieten wollen, dann ist das einfach so Gottgegeben, und man kann da ja nichts machen.

Falls jemand sich SMSCB und PWS technisch näher ansehen will: In 2019 haben wir im Osmocom-Projekt eine Open Source Implementation des kompletten Systems von BTS über BSC bis zum CBC, sowie der dazwischen befindlichen Protokolle wie CBSP vorgenommen. Dies wurde freundlicherweise durch den Prototype Fund mit EUR 35k finanziert. Ja, so günstig kann man die nötige Technik zumindest für eine einzelne Mobilfunkgeneration entwickeln...

Man kann also in einem selbst betriebenen Labor-Mobilfunknetz, welches auf Open Source Software basiert mehr in Punkt standardkonformer Notfallalarmierung, als die Deutsche Politik, Verwaltung und Netzbetreiber zusammen hinbekommen.

Wir haben in Deutschland Leute, die diese Standards in und auswendig kennen, sogar daran mitgearbeitet haben. Wir haben Entwickler, die diese Standards implementiert haben. Aber wir schaffen es nicht, das auch mal selbst praktisch zu benutzen - das überlassen wir lieber den anderen Ländern. Wir lassen lieber zuerst die ganze Katastrophenalarmierung mittels Sirenen vergammeln, machen den Netzbetreibern keine Vorgaben, entwicklen komische Apps, die Anwender extra installieren müssen, die prinzipbedingt nicht skalieren und beim Test (WarnTag) nicht funktionieren.

Was für eine Glanzleistung für den hochentwickelten Techhologie-Standort Deutschland.

by Harald Welte at July 18, 2021 10:00 PM

Notfallwarnung im Mobilfunknetz + Cell Broadcast

[excuse this German-language post, this is targeted at the current German public discourse]

In mehrerern Gegenden Deutschlands gab es verheerende Hochwasser, und die Öffentlichkeit diskutiert deshalb mal wieder die gute alte Frage nach dem adäquaten Mittel der Alarmierung der Bevölkerung.

Es ist einfach nur ein gigantisches Trauerspiel, wie sehr die Deutsche Politik und Verwaltung in diesem Punkt inzwischen seit Jahrzehnten sämtliche relevanten Standards verpennt, und dann immer wieder öffentlich durch fachlich falsche und völlig uninformierte Aussagen auffällt.

Das Thema wurde vor dem aktuellen Hochwasser bereits letztes Jahr im Rahmen des sog. WarnTag öffentlich diskutiert. Auch hier von Seiten der öffentlichen Hand ausschliesslich mit falschen Aussagen, wie z.B. dass es bei Cell Broadcast Datenschutzprobleme gibt. Dabei ist Cell Broadcast die einzige Technologie, wo keine Rückmeldung des einzelnen Netzteilnehmers erfolgt, und das Netz nichtmal weiss, wer die Nachricht empfangen hat, und wo dieser Empfang stattgefunden hat. Ganz wie beim UKW-Radio.

Fakt ist, dass alle digitalen Mobilfunkstandards seit GSM/2G, d.h. seit 1991 die Möglichkeit mitbringen, effizient, schnell und datensparsam alle Nutzer (einer bestimmten geographischen Region) mit sogenannten broadcast Nachrichten zu informieren. Diese Technik, in GSM/2G genannt Cell Broacast (oder auch _SMSCB_), unterscheidet sich Grundlegend von allen anderen Kommunikationsformen im Mobilfunknetz, wie Anrufe und herkömmliche SMS (offiziell SMS-PP). Anrufe, SMS und auch mobile Paketdaten (Internet) werden immer für jeden Teilnehmer individuell auf ihm zugewiesenen Funkressourcen übermittelt. Diese Ressourcen sind beschränkt. Es können in keinem Mobilfunknetz der Welt alle Teilnehmer gleichzeitig telefonieren, oder gleichzeitig SMS empfangen.

Stattdessen benutzt Cell Broadcast - wie der Name bereits unmissverständlich klar macht - Einen broadcast, d.h. Rundsendemechanismus. Eine Nachricht wird einmal gesendet, benötigt also nur eine geteilte Ressource auf der Luftschnittstelle, und wird dann von allen Geräten im Empfangsbereich zeitgleich empfangen und dekodiert. Das ist wie UKW-Radio oder klassisches terrestrisches Fernsehen.

Cell Broadcast wurde bereits in den 1990er Jahren von Deutschen Netzbetreibern benutzt. Und zwar nicht für etwas lebensnotwendiges wie die Notfallsignalisierung, sondern für so banale Dinge wie die Liste jener Vorwahlen, zu denen gerade ein vergünstigter "wandernder Ortstarif" Besteht. Ja, sowas gab es mal bei Vodafone. Oder bei O2 wurden über lange Zeit (aus unbekannten Gründen) die GPS-Koordinaten der jeweiligen Basisstation als Cell Broadcast versendet.

In der folgenden (nun fast abgeschalteten) Mobilfunkgeneration 3G wurde Cell Broadcast leicht umbenannt als Service Area Broadcast beibehalten. Schliesslich gibt es ja Länder mit - anders als in Deutschland - funktionierender und kompetenter Regulierung des Telekommunikationsmarktes, und die langjährig bestehenden gesetzlichen Anforderungen solcher Länder zwingen die Netzbetreiber und auch die Ausrüster der Neztbetreiber, neue Mobilfunkstandards so zu entwickeln, dass die gesetzlichen Vorgaben bzgl. der Alarmierung der Bevölkerung im Notfall funktioniert.

Im Rahmen dieser Standardisierung haben eine Reihe von Ländern innerhalb der 3GPP-Standardisierung (zuständig für 2G, 3G, 4G, 5G) sogenannte Public Warning Systems (PWS) standardisiert. Zu diesen gehören z.B. das Japanische ETWAS (Earthquake and Tsunami Warning System), das Koreanische KPAS (Korean Public Alerting System), das US-Amerikanische WEA (Wireless Emergency Alerts, früher bekannt als CMAS) und auch das EU-ALERT mit den nationalen Implementationen NL-ALERT (Niederlande) und UK-ALERT (Großbritannien) sowie RO-ALERT (Rumänien).

Die zahlreichen Studien und Untersuchungen, die zur Gestaltung obiger Systeme und der internationalen Standards im Mobilfunk geführt haben, weisen auch nochmal nach, was sowieso vorher jedem Techniker offensichtlich erscheint: Eine schelle Alarmierung aller Teilnehmer (einer Region) kann nur über einen Broadcast-Mechanismus erfolgen. In Japan war die Zielvorgabe, die Alarmierung in Erdbebenfällen innerhalb von weniger als 4 Sekunden an die gesamte betroffene Bevölkerung zu übertragen. Und das ist mit PWS möglich!

Die relevanten PWS-Standards in 2G/3G/4G/5G bieten jede Menge nützliche Funktionen:

  • Benachrichtigung in bestimmten geographischen Regionen

  • Interoperable Schnittstellen, so dass Netzwerkelemente unterschiedlicher Hersteller miteinander kommunizieren

  • Konfigurierbare Benachrichtigungstexte, nicht nur in der primären Landessprache, sondern auch in mehreren anderen Sprachen, die dann automatisch je nach Spracheinstellung des Telefons wiedergegeben werden

  • Unterschiedliche Schweregrade von Alarmierungen

  • Übermittlung nicht nur im Broadcast, sondern auch im Unicast an jeden Teilnehmer, der gerade in einem Telefongespräch ist, und dessen Telefon gerade währenddessen aus technischen Gründen den Broadcast nicht empfangen würde

  • Unterschied zwischen Wiederholung einer Übertragung ohne Änderung des Inhalts und einer übertragung mit geändertem Inhalt

Es gibt also seit vielen Jahren internationale Standards, wie sämtliche heute eingesetzten Mobilfunktechniken zur schnellen, effizienten und datensparsamen Alarmierung der Bevölkerung eingesetzt werden können.

Es gibt zahlreiche Länder, die diese Systeme seit langem einsetzen. Das US-Amerikanische WEA wurde nach eigenen Angaben seit 2012 bereits mehr als 61.000 Mal benutzt, um Menschen vor Unwetter oder anderen Katastrophen zu warnen.

Sogar innerhalb der EU hat man das EU-ALERT System spezifiziert, welches weitgehend mit dem amerikanischen WEA identisch ist, und auf die gleichen Techniken aufbaut.

Und dann gibt es Länder wie Deutschland, die es seit genauso vielen Jahren vermissen lassen, durch Gesetze oder Vorschriften

  1. die Netzbetreiber zum Betrieb dieser Broadcast-Technologien in ihrem Netz verpflichtet

  2. die Netzbetreiber zur Bereitstellung von standardisierten Schnittstellen gegenüber den Behörden wie Zivilschutz / Katastrophenschutz zu verpflichten, so das diese selbständig über alle Netzbetreiber Warnungen versenden können

  3. die Gerätehersteller z.B. über Vorschriften des FTEG (Gesetz über Funkanlagen und Telekommunikationsendeinrichtungen) zu Verpflichten, die PWS-Nachrichten anzuzeigen

In den USA, dem vermeintlich viel mehr dem Freien Markt und dem Kapitalismus anhängenden System ist all dies der Regulierungsbehörde FCC möglich. In Deutschland mit seiner sozialen Marktwirtschaft ist es anscheinend unmöglich, den Markt entsprechend zu regulieren. Eine solche Regulierung schafft man in Deutschland nur für wirklich wichtige Themen wie zur Durchsetzung der Bereitstellung von Schnittstellen für die Telekommunikationsüberwachung. Bei so irrelevanten Themen wie dem Katastrophenschutz und der Alarmierung der Bevölkerung braucht man den Markt nicht zu regulieren. Wenn die Netzbetreiber kein PWS anbieten wollen, dann ist das einfach so Gottgegeben, und man kann da ja nichts machen.

Falls jemand sich SMSCB und PWS technisch näher ansehen will: In 2019 haben wir im Osmocom-Projekt eine Open Source Implementation des kompletten Systems von BTS über BSC bis zum CBC, sowie der dazwischen befindlichen Protokolle wie CBSP vorgenommen. Dies wurde freundlicherweise durch den Prototype Fund mit EUR 35k finanziert. Ja, so günstig kann man die nötige Technik zumindest für eine einzelne Mobilfunkgeneration entwickeln...

Man kann also in einem selbst betriebenen Labor-Mobilfunknetz, welches auf Open Source Software basiert mehr in Punkt standardkonformer Notfallalarmierung, als die Deutsche Politik, Verwaltung und Netzbetreiber zusammen hinbekommen.

Wir haben in Deutschland Leute, die diese Standards in und auswendig kennen, sogar daran mitgearbeitet haben. Wir haben Entwickler, die diese Standards implementiert haben. Aber wir schaffen es nicht, das auch mal selbst praktisch zu benutzen - das überlassen wir lieber den anderen Ländern. Wir lassen lieber zuerst die ganze Katastrophenalarmierung mittels Sirenen vergammeln, machen den Netzbetreibern keine Vorgaben, entwicklen komische Apps, die Anwender extra installieren müssen, die prinzipbedingt nicht skalieren und beim Test (WarnTag) nicht funktionieren.

Was für eine Glanzleistung für den hochentwickelten Techhologie-Standort Deutschland.

by Harald Welte at July 18, 2021 10:00 PM

July 09, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #10 - setting up open5gs

We're happy to announce the 10th incarnation of OsmoDevCall

This time miaoski will be presenting a live demo on how to setup a 4G/5G core network with open5gs.

The topics will include a brief introduction of open5gs, its environment, config files, network topology.

When: Friday, July 9th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at July 09, 2021 02:47 PM

June 25, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #9 - No presentation, just i...

We're happy to announce the 9th incarnation of OsmoDevCall

This time nobody has volunteered to give a talk, so we will just have the USSE (Unstructured Supplementary Social Event).

When: Friday, June 25th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at June 25, 2021 03:54 PM

June 08, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #8 - Screen sharing peek at ...

We're happy to announce the 8th incarnation of OsmoDevCall

This time keith will be presenting a screen sharing peek at TIC A.C. infrastructure in Oaxaca

TIC A.C. is an operator of Osmocom based community cellular networks in indigenous communities of the Mexican state of Oaxaca. Keith works with Rhizomatica and TIC A.C. and will give us some live insight into how they operate

When: Friday, June 11th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at June 08, 2021 01:26 PM

May 27, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - OsmoDevCall #7 - Hacking binary protocol...

We're happy to announce the 6th incarnation of OsmoDevCall

This time fixeria will be presenting about Hacking binary protocols with Pycrate

When: Friday, May 28th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at May 27, 2021 05:04 PM

May 12, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #6 - SS7/SIGTRAN in 2G/3G networks

We're happy to announce the 6th incarnation of OsmoDevCall

This time laforge will be presenting about SS7 and SIGTRAN in 2G/3G networks

This talk will cover some classic circuit-switched SS7 basics as well as SIGTRAN (SS7 over IP) and how this is used as underlying transport for a variety of interfaces in the 2G (GSM) and 3G (UMTS) cellular networks even today.

When: Friday, May 14th, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at May 12, 2021 09:58 PM

April 18, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #5 - YIG & YANG (Yet ANother yiG driver)

We're happy to announce the 5th incarnation of OsmoDevCall

This time horiz0n will be presenting about YIG & YANG (Yet ANother yiG driver)

This talk will briefly introduce the working principles of YIG (Yttrium Iron Garnet) microwave circuits, their applications and finally conclude with a presentation of a recently developed driver circuit.

When: Friday, April 23rd, 2021 from 20:00 CEST

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at April 18, 2021 05:21 PM

April 11, 2021

Osmocom.org News

pySim - Video of pySim-shell presentation

As part of the April 9, 2021 OsmoDevCall, there was a presentation by laforge on pySim-shell, the latest member of the pySim software suite.

pySim-shell is an interactive, scriptable command-line environment for expliring, editing and configuring SIM/USIM/ISIM cards.

A video recording of the talk is now available from https://people.osmocom.org/tnt/osmodevcall/osmodevcall-20210409-laforge-pysim-shell_h264_420.mp4

Thanks to tnt for editing/merging the video.

by laforge at April 11, 2021 12:53 PM

April 07, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #4 - pySim-shell for SIM card configuration

We're happy to announce the 4th incarnation of OsmoDevCall

This time Harald Welte will be presenting about pySim-shell, the next generation of SIM card configuration tool

When: Friday, April 9th, 2021 from 20:00 CET

Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at April 07, 2021 07:25 PM

March 20, 2021

Osmocom.org News

Osmocom Conferences (OsmoDevCon + OsmoCon) - OsmoDevCall #3 - multi-TRX + frequency hopping in Os...

We're happy to announce the 3rd incarnation of OsmoDevCall

This time Vadim Yanitskiy will be presenting about multi-TRX + frequency hopping in OsmoBTS

When: Friday, March 26th, 2021 from 20:00 CET
Where: https://meeting4.franken.de/b/har-xbc-bsx-wvs (Big Blue Button of https://franken.de/)

by laforge at March 20, 2021 06:21 PM

February 26, 2021

Osmocom.org News

Cellular Network Infrastructure - February 2021 Osmocom CNI releases

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

Those new tagged/released versions contain in some cases up to one year of work
since the previous versions released during January 2020 (on some projects,
patch and intermediate releases were done during the year). The primary focus
was on bug-fixing and stabilization as well as some major new features, such as
IPv6 support.

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
libgtpnl 1.2.2 http://git.osmocom.org/libgtpnl/plain/debian/changelog?h=1.2.2
libasn1c 0.9.33 http://git.osmocom.org/libasn1c/plain/debian/changelog?h=0.9.33
libsmpp34 1.14.1 http://git.osmocom.org/libsmpp34/plain/debian/changelog?h=1.14.1
libosmocore 1.5.1 http://git.osmocom.org/libosmocore/plain/debian/changelog?h=1.5.1
libosmo-abis 1.1.1 http://git.osmocom.org/libosmo-abis/plain/debian/changelog?h=1.1.1
libosmo-netif 1.1.0 http://git.osmocom.org/libosmo-netif/plain/debian/changelog?h=1.1.0
libosmo-sccp (+ OsmoSTP) 1.4.0 http://git.osmocom.org/libosmo-sccp/plain/debian/changelog?h=1.4.0
libosmo-ranap (+ OsmoHNBGW) 0.7.0 http://git.osmocom.org/osmo-iuh/plain/debian/changelog?h=0.7.0
OsmoTRX 1.3.0 http://git.osmocom.org/osmo-trx/plain/debian/changelog?h=1.3.0
OsmoBTS 1.3.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=1.3.0
OsmoPCU 0.9.0 http://git.osmocom.org/osmo-bts/plain/debian/changelog?h=0.9.0
OsmoBSC 1.7.0 http://git.osmocom.org/osmo-bsc/plain/debian/changelog?h=1.7.0
OsmoMSC 1.7.0 http://git.osmocom.org/osmo-msc/plain/debian/changelog?h=1.7.0
OsmoHLR 1.3.0 http://git.osmocom.org/osmo-hlr/plain/debian/changelog?h=1.3.0
osmo-mgw 1.8.1 http://git.osmocom.org/osmo-mgw/plain/debian/changelog?h=1.8.1
osmo-sip-connector 1.5.0 http://git.osmocom.org/osmo-sip-connector/plain/debian/changelog?h=1.5.0
OsmoSGSN 1.7.0 http://git.osmocom.org/osmo-sgsn/plain/debian/changelog?h=1.7.0
OpenGGSN 1.7.1 http://git.osmocom.org/osmo-ggsn/plain/debian/changelog?h=1.7.1
osmo-pcap 0.1.3 http://git.osmocom.org/osmo-pcap/plain/debian/changelog?h=0.1.3
osmo-gbproxy 1:0.1.0 http://git.osmocom.org/osmo-gbproxy/plain/debian/changelog?h=0.1.0
osmo-cbc 0.2.2 http://git.osmocom.org/osmo-cbc/plain/debian/changelog?h=0.2.2
osmo-smlc 0.2.0 http://git.osmocom.org/osmo-smlc/plain/debian/changelog?h=0.2.0
osmo-e1d 0.2.0 http://git.osmocom.org/osmo-e1d/plain/debian/changelog?h=0.2.0
osmo-gsm-manuals 1.1.0 http://git.osmocom.org/osmo-gsm-manuals/plain/debian/changelog?h=1.1.0

Noteworthy Changes

Misc / Common

  • libosmocore: Introduce support for signalfd
  • libosmocore: Improvements/fixes for multi-thread processes
  • libosmocore: Event loop migrated from select() to poll()
  • libosmocore: The library now provides Hashtable data structure support
  • libosmocore: The library now provides an inter-thread queue API
  • libosmocore: Initial support for static userspace probes via systemtap
  • libosmocore: lapdm: fixed SAPI-0/SAPI-3 frame prioritization on DCCH
  • libosmocore: logging: New systemd-journal target
  • libosmocore: logging: New log line prefix "thread-id"
  • libosmogb: New NS2 API (see Network_service_(NS))
  • libosmogb: Add Frame Relay support
  • libosmo-abis: Improve TRAU support
  • VTY: New "expert" mode introduced
  • VTY: Commands can now contain attributes providing information about the command
  • VTY: Most projects generate now xml output automatically at build time
  • VTY: Most projects now allow setting scheduler cpu-affinity and RR priority
  • Several improvements and fixes to stats / rate counters
  • Lots of fixes for struct bit fields on big-endian systems
  • RPM spec files added to most projects
  • IPv6 support added to lots of interfaces on several projects, both on transport side as well as on signalling.

OsmoTRX

  • uhd: Support UHD >=3.11 logging framework
  • lms: Initial multi-arfcn support
  • ipc: Introduce new backend osmo-trx-ipc
  • Introduce osmo-prbs-tool: PRBS tool sending PRBS sequence to TRX
  • CTRL threads removed, now handled by main thread
  • OsmoTRX now provides Nominal Tx Power to osmo-bts through "NOMTXPOWER" in TRXC protocol
  • Introduced new TRXC "MUTE" command
  • TxGain is now applied based on expected Tx output power through empirical measurements (#4583)
  • Calculate RSSI offset based on RxGain configuration
  • New rate counters available to check whether timing issues are occurring in low level layers, TRXD, etc.
  • Documentation improvementes and fixes
  • Several generic optimizations, fixes, etc.

OsmoBTS

OsmoPCU

OsmoBSC

  • Ericsson RBS2000: Improved Support (OM2000)
  • Siemens BS-11: Improved support
  • Validate codec settings configuration at startup
  • OML failure reports are store and can be displayed over VTY
  • Stats / counters improvements and fixes
  • IMSI filtering features have been removed completely
  • All BSC originated USSD notification features have been removed completely
  • Support MSC pooling
  • ACC barring: Implement barred subset rotation
  • Lots of improvements to Handover related logic
  • Cell Broadcast: CBSP VTY configuration commands rewritten
  • LCS: Introduced support for Lb interface (against SMLC)
  • New set of FSMs handling OML provisioning
  • Improvements to BTS power control (BS power)
  • Support ACCH repetition
  • Support Emergency Call preemption
  • Support specifying PS neighbors in VTY (Introduce CTRL interface for Neighbor resolution)
  • Per-burst attenuation for BS power control is now applied correctly

OsmoMSC

  • Rudimentary NRI support added
  • Support new MNCCv7 protocol version (with IPv6 support)
  • Lots and lots of fixes and small improvements
  • Proper call teardown if a call leg disconnects unexpectedly

OsmoHLR (and libosmo-gsup-client)

  • Introduce support for D-GSM (Distributed GSM), mslookup server
  • Introduce libosmo-mslookup library and osmo-mslookup-client tool
  • GSUP connections now set TCP_NODELAY
  • support the XOR algorithm for UMTS AKA

OsmoMGW (and libosmo-mgcp-client)

  • Add CTRL interface
  • Support E1 endpoints
  • Full IPv6 support in both MGCP and RTP

osmo-sip-connector

  • MNCC v7: IPv6 support

OsmoSTP (and libosmo-sigtran)

  • IPv6 support (together with IPv4+IPv6 SCTP multi-homing)
  • Initial support for M3UA and SUA sub-protocol [S]SNM
  • Initial support for SCCP minimalistic SCMG implementation
  • Lots of fixes and small improvements

OsmoSGSN

  • Implement RAT change between 2G and 3G
  • Support RIM procedure routing
  • Use the new NS2 osmocom stack

OsmoGGSN (and libgtp)

  • Introduce netns support for tun interfaces
  • sgsnemu: Support handling IPv6 SLAAC in tun interface, improve IPv6 support

by pespin at February 26, 2021 03:56 PM

February 13, 2021

Osmocom.org News

OsmoBTS - Summary of OsmoBTS work during 2020

This is a summary of the work that has happened on OsmoBTS in the January 2020 through early February 2021 time frame.

In general, a large focus has been on variuos "enterprise" features that are mostly relevant to operating BTSs with large number of TRX in dense (urban) interference limited networks. This is quite a bit different from the more traditional OsmoBTS use cases in rural applications, where networks are limited by coverage, and not by interference.

OsmoBTS (osmo-bts-trx) has now been tested successfully with configurations up to 8TRX.

Major changes:
  • BS (downlink) power control
  • baseband frequency hopping
  • tons of fixes regarding the accuracy of measurement reports (which is very important for proper hand-over performance)
  • EWMA based filtering of power control loops
  • Repeated downlink SACCH support; 3GPP Release 6 (#4794)
  • Repeated uplink SACCH support; 3GPP Release 6 (#4795)
  • Repeated downlink FACCH support (#4796)

The slightly more detailed versions below:

Common/General changes

  • various fixes regarding measurement reporting / averaging
  • 11bit RACH support
  • print lchan name in all log lines / simplify debugging (#1938)
  • improved reporting of BTS features/capabilities to BSC
  • BS (downlink) power control
  • power ramp-down on BTS shutdown
  • power ramp-up/ramp-down during ADM state changes
  • many fixes to A-bis OML MO finite state machines
  • OML: fix ARFCN range checks
  • support setting real-time scheduler priority via VTY
  • OML Fix Radio Carrier OPSTATE change report not sent in all scenarios
  • OML + PCU interface: Support for IPv6 NS-VCs to PCU
  • automatic VTY reference generation --vty-ref-xml (#1601)
  • Only send SI13 if PCU is connected (#3075)
  • Don't broadcast SI4 GPRS indicator if PCU is not connected (#3075)
  • power_control: EWMA based uplink power filtering
  • count measurements for FACCH/F only once (#4799)
  • count all blocks for "SUB" for TCH/F in signaling mode (#4799)
  • fix number of expected measurements (#4799)
  • fix integer overflow in measurement processing (#4799)
  • fix L1 SAPI activation ordering in hand-over (likely impacts handover performance)
  • Repeated downlink SACCH support; 3GPP Release 6 (#4794)
  • Repeated uplink SACCH support; 3GPP Release 6 (#4795)
  • Repeated downlink FACCH support (#4796)
  • Activate DL SACCH only when TA is known (#4008, #4009)

osmo-bts-trx specific changes

Traditionally, osmo-bts-trx used to have less features than the other osmo-bts variants (such as osmo-bts-sysmo for sysmoBTS devices).
The focus of the development has meanwhile shifted, and osmo-bts-trx has been catching up significantly, and in some cases even exceeding the capabilities of osmo-bts-{sysmo,lc15,oc2g,octphy}.

  • TRX: nope indications; fixes many measurement related issues
  • TRX: AMR DTX frame detection (#2978)
  • TRX: fix uplink measurement reporting durign hand-over (#4592)
  • TRX: power-ramping during BTS power up
  • TRX: Fix reading out of buffer during tx of dummy burst on PDCH TS with EGPRS enabled (#4606)
  • TRX: baseband frequency hopping support (#4546)
  • TRX: Fix crash due to ASSERT related to dynamic timeslots (#4920)
  • TRX: Fix crash due to ASSERT related to rf-lock and dynamic timeslots
  • TRX: significantly reduce clock advance, reducing latency significantly (#4487)

by laforge at February 13, 2021 06:01 PM

OsmoPCU - Summary of OsmoPCU work during 2020

This is a summary of the work that has happened on the osmo-pcu software in 2020, specifically the timeframe January 2020 through early February 2021.

  • large number of various CSN.1 encoder/decoder fixes
  • fix an infinite loop in CSN.1 dissector
  • fix pcu_sock related memory leak
  • MS RA capability parsing fixes (#4463)
  • properly encode P-TMSI in RR PAGING REQUEST
  • Fix UL-ACK not sent to MS if intermediate UL block is lost
  • 11bit RACH support (EGPRS Packet channel Requeset, #1548)
  • do not encode out-of-range TA value
  • fix RRBP field in packet uplink assignment
  • add support for IPv6 NS-VCs
  • add support for frequency hopping
  • fix crashes due to NULL pointer deref (#4756)
  • downgrade to DL MCS1-4 when USF for GPRS_only MS (#4544)
  • Get rid of LLC UI dummy blocks following other data (#4849)
  • support GPRS concurrently with EGPGRS (previously only either/or)
  • support Gb interface with IP-SNS
  • Fix Dl EGPRS data blocks being generated occasionally on GPRS TBFs (#4973)
  • NACC (Network Assisted Cell Change) support
So in short:
  • lots of bugs fixed all over
  • GPRS and EPGRS are no longer exclusive, but GPRS-only MS can be served while EGPRS is active
  • Network Assisted Cell Change is going to significantly improve cell reselection performance
  • IPv6 support on the Gb interface
  • IP-SNS support on the Gb interface

We are planning to tag a new osmo-pcu release soon-ish. This is mainly awaiting the full stabilization of the "NS2" (new NS code) VTY interface and APIs. Once released, those will be stable and cannot be modified in incompatible manner anymore.

by laforge at February 13, 2021 05:51 PM

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.

by laforge at December 27, 2020 12:32 PM

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.

by laforge at December 27, 2020 12:26 PM

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.

December 04, 2020 01:00 AM

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.

by laforge at October 03, 2020 02:01 PM

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.

by laforge at July 20, 2020 07:03 AM

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

by laforge at July 17, 2020 06:44 PM

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!

by neels (nhofmeyr@sysmocom.de) at May 08, 2020 12:24 AM

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

OsmoTRX

  • 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

OsmoBTS

  • 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.

OsmoPCU

  • 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

OsmoBSC

  • 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

OsmoMSC

  • 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

OsmoSIPConnector

  • 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

OsmoSGSN

  • 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

by pespin at January 08, 2020 05:44 PM

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.

by Harald Welte at January 04, 2020 11:00 PM

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.

by Harald Welte at January 04, 2020 11:00 PM

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:

by laforge at January 02, 2020 09:52 PM

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

by laforge at January 02, 2020 09:33 PM

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.

by Harald Welte at December 19, 2019 11:00 PM

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.

Links

by neels (nhofmeyr@sysmocom.de) at November 27, 2019 04:49 PM

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 :/

by laforge at November 16, 2019 09:22 PM

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.

by laforge at November 16, 2019 09:08 PM

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.

by laforge at November 16, 2019 08:56 PM

November 14, 2019

Osmocom.org News

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!

by laforge at October 14, 2019 06:39 PM

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.

by tsaitgaist at October 01, 2019 04:25 PM

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.

by Harald Welte at September 28, 2019 10:00 PM

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

OsmoTRX

  • 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

OsmoBTS

  • 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
  • RSL BS POWER CONTROL support
  • 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

OsmoBSC

  • 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

OsmoMSC

  • 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

OsmoHLR

  • 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)

osmo-sip-connector

  • support international Caller-ID
  • support emergency calling
  • handle SIP re-invite
  • support MNCC HOLD/RETRIEVE

OsmoSTP (and libosmo-sigtran)

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

OsmoSGSN

  • 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

by laforge at September 28, 2019 07:51 AM

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.

by laforge at September 28, 2019 06:53 AM

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:

by laforge at September 11, 2019 09:01 AM

May 24, 2019

Osmocom.org News

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/

by laforge at May 14, 2019 09:29 AM

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

by laforge at May 09, 2019 09:37 PM

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.
https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source

by neels (nhofmeyr@sysmocom.de) at May 09, 2019 10:52 AM

May 01, 2019

Osmocom.org News

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

by laforge at January 27, 2019 09:15 AM

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

Misc

  • 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)

OsmoTRX

  • 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

OsmoBTS

  • 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

OsmoBSC

  • 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

OsmoMSC

  • 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

OsmoHLR

  • 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

osmo-sip-connector

  • 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

OsmoSGSN

  • 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

by laforge at January 24, 2019 12:49 AM

October 19, 2018

Osmocom.org News

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!

by laforge at October 10, 2018 08:50 AM

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!

by laforge at October 03, 2018 09:20 AM

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!

by Harald Welte at September 28, 2018 10:00 PM