General

Profile

News

multi-voltage USB UART: multi-voltage USB UART board released

Added by laforge 5 months ago

During the past 16 years I have been playing a lot with a variety of embedded devices.

One of the most important tasks for debugging or analyzing embedded devices is usually
to get access to the serial console on the UART of the device. That UART is often exposed
at whatever logic level the main CPU/SOC/uC is running on. For 5V and 3.3V that is easy,
but for ever more and more unusual voltages I always had to build a custom cable or a custom
level shifter.

In 2016, I finally couldn't resist any longer and built a multi-voltage USB UART adapter.

This board exposes two UARTs at a user-selectable voltage of 1.8, 2.3, 2.5, 2.8, 3.0 or 3.3V.
It can also use whatever other logic voltage between 1.8 and 3.3V, if it can source a reference
of that voltage from the target embedded board.

Rather than just building one for myself, I released the design as open hardware under CC-BY-SA
license terms. Full schematics + PCB layout design files are available.
For more information see mv-uart.

In case you don't want to build it from scratch, ready-made machine assembled boards are also made
available from sysmocom

OpenBSC: 3G Voice Works (2 comments)

Added by neels 7 months ago

I am glad to announce that we have succeeded in placing a 3G voice call between
two phones using an hNodeB cell and the Osmocom 3G core network. Find attached
a full network trace including IuCS signalling as well as the RTP voice stream.
This, proudly, is the first publicly available pcap of Iuh, IuCS and IuPS, and
it was created using exclusively free software in the core network stack.

The Osmocom 3G stack is being developed at sysmocom, supported by highly
appreciated sponsoring from NLnet and sysmocom customers -- thank you for
making this possible!

Osmocom has had 3G data connectivity working for some months now3, and the
IuPS code has already been merged to OpenBSC's master branch (though it still
requires libosmo-netif, libosmo-sccp and asn1c to be built from the branches
indicated below).

The 3G voice counterpart is taking somewhat longer, not because it's more
difficult per se, but mostly because it needs profound refactoring of our MSC.
So far our MSC was closely tied to the BSC code, and to include IuCS, we need to
separate them.

Are we done with 3G now? Not quite. Things need to be made fully configurable,
proper 3G authentication needs to be integrated, and all work needs to be put in
a stable release. We would also like to have a proper 2G A interface as a
companion to the 3G IuCS interface, which would allow us to completely replace
the OsmoNITB with the new OsmoCSCN.

NOTE from the future: OsmoCSCN has since been renamed to OsmoMSC!

Read this as a humble invitation to join NLnet1 and other sysmocom customers
in funding the open source 3G core network development here at sysmocom2.
The resulting software stack is free for everyone, including you, both in the
sense of free speech as well as the proverbial free beer, and we can still use
all the support we can get to wrap this up. If you would like to see this working
sooner rather than later, do not hesitate to contact us2.

So, we're still working on Osmocom 3G, but if you would like to take a look
ahead, here is how:

We have a 3G authentication implementation ready, but since this is not yet
integrated in our HLR/VLR and MSC libraries, we're still working with hardcoded
2G authentication tokens. So to test, you still need specially provisioned SIM
cards. Firstly, they must be incapable of 3G authentication, so that the phone
decides to fall back to 2G auth. Secondly, they must all be programmed with a
Ki of 000102030405060708090a0b0c0d0e0f. If you need help here, feel free to
contact us2 -- we're in the meantime working on integrating full 3G
authentication with osmo-cscn and osmo-sgsn.

To set up a 3G core network based on free Osmocom software, this is what you
need:

                                 +--------+
                             ,-->| MGCPGW |<--RTP--...
                            /    |        |
                            |    |        |<--MGCP
                            |    +--------+       \
                            /                     |
        +------------+<--RTP     +--------+       `->+----------+
 UE <-->| hNodeB     |           | HNB-GW |          | OsmoCSCN |
 UE <-->|            |<--Iuh---->|        |<--IuCS-->|          |
        |            |     ...-->|        |    ...-->|          |
        |            |           |        |          +----------+
        +------------+<--GTP-U   |        |
                              \  |        |          +------+           +------+
                              |  |        |<--IuPS-->| SGSN |<--GTP-C-->| GGSN |
                              |  +--------+    ...-->|      |   GTP-U-->|      |
                              |                      +------+  /        +------+
                              \_______________________________/

Instead of a traditional NodeB, we use "smaller" hNodeB 3G cell hardware to take
care of the radio interface. This has the advantage that it already has an RNC
integrated, which we would otherwise need to implement separately. The RNC will
talk Iuh, i.e. HNBAP and RANAP4, to OsmoHNBGW running on your box, let's call it
the core network computer (CN).

Besides the HNB-GW, your CN further comprises of OsmoCSCN for voice signalling
as well as the OsmoMGCPGW to direct RTP streams. For data, there are OsmoSGSN
and OpenGGSN.

In short, Iuh is the combined voice (IuCS, Iu circuit switched) and data (IuPS,
Iu packet switched) signalling, which the HNB-GW splits to OsmoCSCN (circuit
switched core network) and OsmoSGSN. When a phone (UE, user equipment) starts
a call, OsmoCSCN takes care of all the signalling, from authentication to RAB
assignment, and instructs the MGCPGW to forward the RTP streams from the hNodeB,
in our case, back to the same hNodeB and to the other UE. In the field, the
MGCPGW would instead forward to a remote media gateway.

To set up your CN, build and install the following projects from
http://git.osmocom.org, using below branches; the current state of which have
also been tagged as '3G_2016_09':

Once the CN stack is built, set up the configuration. Find attached files for an
example of a local test setup. Some details explained:

Tell the osmo-hnbgw which local IP address to use to listen for Iuh connections.
This needs to be on an interface reachable by the hNodeB. The IuCS and IuPS
links towards the osmo-cscn and osmo-sgsn are so far still hardcoded as
127.0.0.1 and 127.0.0.2, respectively, i.e. osmo-cscn and osmo-sgsn should run
on the same machine as the osmo-hnbgw. These will listen on the proper port
without further configuration (still hardcoded).

Also tell the MGCPGW (osmo-bsc_mgcp) which local IP address to bind to, which
has to be reachable both by the hNodeB as well as the osmo-cscn process. The
osmo-cscn.cfg is then told where to reach the MGCPGW.

A notable detail for 3G data is that the GGSN has to be reachable by the hNodeB.
Since the GTP standard defines fixed port numbers which both SGSN and GGSN have
to to use, the SGSN may not bind on the same IP address as the GGSN.

Once you have configured the IP addresses, start up your core network: launch
osmo-cscn, osmo-bsc_mgcp, osmo-sgsn, ggsn and osmo-hnbgw. You should see log
messages indicating established IuCS and IuPS links (HNBGW, CSCN and SGSN).

With your CN up and running, configure the hNodeB to contact osmo-hnbgw. Also
make sure the PLMN ID and LAC are configured correctly, to match the MCC and
MNC in the osmo-cscn.cfg -- otherwise the hNodeB may reject all attach requests.
Finally, do authorize the SIM card's IMSI, e.g. using osmo-cscn's telnet VTY,
and if necessary configure the hNodeB to allow access by this IMSI.

The attached pcap file contains a complete network trace of:

  • HNBAP of hNodeB registering at the HNB-GW;
  • two UEs registering first at the HNB-GW (HNBAP UE Register) and then on IuCS
    and IuPS (MM Location Updating, GMM Attach), coming in via Iuh at the HNB-GW
    and forwarded to OsmoCSCN and OsmoSGSN;
  • the two UEs browsing the websites nlnet.nl5 and the current xkcd webcomic,
    with PDP Context allocation as well as GTP-C and GTP-U6;
  • a voice call where the one UE calls the other (i.e. MO with Service Request to
    MT with Paging), with the RTP stream directed through our MGCP GW using CRCX
    and MDCX instructions;
  • each UE sending an SMS to the other.

The IP addresses used in attached network trace are:

  • 10.9.1.11: hNodeB 3G femto cell;
  • 10.9.1.120: CN computer's interface for Iuh and RTP, as well as the SGSN's
    GTP-C side towards the GGSN;
  • 10.9.1.13: CN computer's interface for GTP-U towards the hNodeB as well as
    GTP-C towards the SGSN7;
  • 127.0.0.1: loopback on the CN computer for IuCS;
  • 127.0.0.2: loopback on the CN computer for IuPS;
  • 10.23.42.*: IP addresses given to UEs within the GTP tunnel;
  • all other IP addresses are remote servers contacted by the UEs.

When looking at network traces, note the various protocols: Iuh, IuCS and IuPS
communicate via SCTP (as opposed to TCP or UDP). You will see the same Iu
messages twice8, e.g. once on IuCS between HNB-GW and CSCN, encapsulated in
RANAP/SUA9, and again on Iuh between HNB-GW and hNodeB, encapsulated in
RANAP/RUA. In contrast, the MGCP configuration and RTP streams for voice use
UDP, and so do GTP-U and GTP-C for the data link.

In conclusion, we still need some work to reach our goal of a fully operational
3G core network. The attached trace of a 3G voice call using exclusively free
Osmocom software proves that we are now very close indeed.

We invite you to test and use our 3G core network stack, and if you can,
consider joining NLnet and sysmocom as sponsor of the ground breaking work in
the Osmocom community.

Edit: see also Getting Started with 3G


1 NLnet foundation, https://nlnet.nl


2 sysmocom systems for mobile communications GmbH, https://sysmocom.de /


3 http://osmocom.org/news/30


4 See also this protocol stack diagram


5 nlnet.nl is browsable by https only, so all you see is TLS encrypted data.
I would have liked to see a DNS query for nlnet.nl, but the UE had already
cached its resolution to 193.200.132.212. There are, however, other DNS queries,
as well as a plain http session for xkcd.com.


6 I have, for privacy reasons, filtered from the pcap some services that the
UEs eagerly contacted but which were not browsed explicitly during the test.


7 It is however possible that few GTP-U packets end up at the SGSN between
activating the PDP context and redirecting GTP-U towards the hNodeB's address,
which can only be known after the IuPS RAB Assignment is complete.


8 Note that the timing differences between the internal loopback and eth0
interfaces may cause their ordering to appear slightly out of sync in the pcap.


9 RANAP/SUA is our non-standard choice of SIGTRAN for IuCS and IuPS, since it
has simpler layering than the standard RANAP/SCCP/M3UA. See also4.


Cellular Infrastructure: Discontinuous Transmission (DTX) Support

Added by laforge 9 months ago

Back in May, Osmocom developer Max Suraev has been working on implementing both uplink and downlink DTX support in the Osmocom GSM stack, most notably OsmoBTS and the OpenbSC libbsc (OsmoBSC and OsmoNITB).

The purpose of uplink DTX is to
  • reduce uplink interference with other (remote) cells on the same ARFCNs
  • conserve battery power in the mobile station (lower transmit duty cycle)
The purpose of downlink DTX is to
  • reduce power consumption and heat dissipation on the BTS
  • reduce downlink interference with other (remote) cells on the same ARFCNs

Downlink DTX is only permitted on secondary trnansceivers, i.e. on those TRX that do not carry the FCCH/SCH/BCCH beacon.

All related patches to OsmoBTS and OpenBSC have meanwhile been merged. You can use the dtx uplink [force] and dtx downlink VTY commands at the BTS node to enable the features.

Cellular Infrastructure: Support for dynamic TCH / PDCH switching

Added by laforge 9 months ago

The classic ETSI/3GPP specifications about GSM, particularly those related to A-bis, assume a fairly static allocation of the timeslots of a TRX inside a BTS. This means that the administrator configures each timeslot in the BSC to be one of the permitted channel combinations, for user traffic that's either SDCCH, TCH/F, TCH/H or PDCH.

The Osmocom project software, including OsmoBSC, OsmoNITB, OsmoBTS and OsmoPCU followed this static timeslot allocation when first implementing the related standards and systems.

This static allocation, particularly between circuit-switched calls and packet data leads to sub-optimal use of available (scarce) resources. What if there are no voice calls, but a high demand for packet data? Or why not (as an operator policy) provide more voice channels on demand, at the expense of packet data?

In 2013 years, Osmocom developer Andreas Eversberg did a BSC-side implementation of dynamic PDCH switching in OsmoNITB. However, related code unfortunately never made it to Osmocom master and it exposed some bit-rot over the years.

Neels Hofmeyr has recently picked up those patches, extended, fixed and forward-ported them to current master. They were subsequently merged. Corresponding changes inside OsmoBTS have been made with osmo-bts-sysmo and osmo-bts-litecell15, and have also been merged. Implementation for osmo-bts-trx is still ongoing (but difficult due to the desolate state of osmo-bts-trx with lack of a current maintainer).

With this first series of changes, only switching between TCH/F and PDCH is possible. Neels is currently working on making TCH/F, TCH/H and PDCH dynamic, resulting in even more flexibility even among full-rate and half-rate voice channels.

OsmoSGSN: OsmoSGSN GPRS encryption support

Added by laforge 9 months ago

All the years since OsmoSGSN came first into existance, it never had gained GPRS encryption support. While the original code had been written with encryption in mind, and libosmocore even contained a plugin infrastructure for GPRS encryption plugins, nobody had so far connected the dots, figured out the bugs in the existing code and made it fully work.

Thanks to analysis by Dieter Spaar and Max Suraev, we now have a functional implementation of GPRS encryption in OsmoSGSN. The SGSN contains the core infrastructure for it, while encyption is handled via libosmocore. A GEA3 implementation has just been merged to libosmocore - we also have experimentally verified operation with GEA1 + GEA2, but unfortunately no public documentation / implementation of those security by obscurity algorithms is available yet.

In terms of the SGSN changes required: Most have been merged, while some are still in the gerrit review process, see https://gerrit.osmocom.org/#/q/topic:gea

Cellular Infrastructure: Osmocom Wireshark improvements for AMR and Osmux

Added by laforge 9 months ago

Over the past weeks, Osmocom developer Daniel Willmann has been working on various improvements/extensions of the popular wireshark dissector in the context of using it with (Osmocom) GSM networks.

The extensions include:
  • support for playback of AMR from captured RTP streams (using libopencore-amrnb)
  • extend RTP jitter/delay statistics for AMR-RTP as used in A-bis/IP and A/IP
  • a new dissector for the Osmux (Osmocom Multiplex) protocol
  • statistics support for the Osmux protocol.

The above features allow for much better analysis of any voice plane related issues in Osmocom GSM networks.

All related changes can be found in http://git.osmocom.org/wireshark/log/?h=daniel/osmux and we are actively submitting them to mainline wireshark at this point.

OsmocomTETRA: Student sentenced to jail for showing TETRA insecurity

Added by laforge 11 months ago

According to some news report, including this report at softpedia, a 26 year old student at the Faculty of Criminal Justice and Security in Maribor, Slovenia has received a suspended prison sentence for finding flaws in Slovenian police and army TETRA network using OsmocomTETRA.

If a TETRA network (like any other network) is configured with broken security, then the people responsible for configuring and operating that network are to be blamed, and not the researcher who invests his personal time and effort into demonstrating that police radio communications safety is broken. On the outside, the court sentence really sounds like "shoot the messenger". They should instead have jailed the people responsible for deploying such an insecure network in the first place, as well as those responsible for not doing the most basic air-interface interception tests before putting such a network into production.

According to all reports, the student had shared the results of his research with the authorities and there are public detailed reports from 2015, like the report (in Slovenian) at https://podcrto.si/vdor-v-komunikacijo-policije-razkril-hude-varnostne-ranljivosti-sistema-tetra/.

(11-20/70)

Also available in: Atom