Dear Ruben,
I wonder if you could give us/me a hand in closing the gap between the official packages. In general we are willing to drop backwards compatibility with our install base to reach Debian standards. Ideally a user can easily upgrade from a Debian version to our nightly builds and you and other debian developers can hopefully easily take our source packages and move them forward as well.
Do you have experience with upstream making their own debian packages and a proper package being included in debian as well?
Shall I create tickets in our osmocom.org redmine to coordinate synchronization? Are you aware of different sysv init script names, paths for config/hlr files, package names?
From a very brief look:
+ We never handled the .copyright files correctly you do
+ debian/control you have nice short and long terms descriptions we should have
+ You have patches for typos and other parts (i have pushed the ggsn one and will go through the patches later)
+ Your have manpages and we never bothered with it. I think it is a really good debian rule (and good Unix legacy to force a manpage for binaries in /usr!)
- At least for OpenBSC you do not seem to package the -dbg symbols. As a developer I am always annoyed (e.g. with sofia sip) when I can't install the debug symbols.
- You seem to not include sysvinit (and systemd) service files?
Do you have a proposal on how we could move forward? How do you manage/maintain the extra debian/ directory?
kind regards
holger
Hi.
Anyone used $subj? If so, with which SIP servers? Could you share
respective sip server configuration samples?
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi all,
I would like to post the sysmocom/iups branch for review in gerrit, but I'm not
sure that we want those 40 commits to be posted to all mail inboxes and sit
there, ungrouped in the list of commits in gerrit.
gerrit shows 'related' patches, but it doesn't have the concept of a patch-set
per se. The list of pending patches will be very long, IIUC sorted with the
last branch commit on top and earlier ones further down.
I'd like to push it to for/master now, but first giving you guys a chance to
suggest another way for this special batch.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hello,
I fixed typos in the osmo-gsm-manuals repository.
This is my first contribution to the Osmocom project so I'm not quite sure if I did all the things (patch, email) in the right way.
Best Regards
Jonathan Brielmaier
---
OsmoBSC/chapters/alink.adoc | 4 ++--
OsmoBSC/chapters/overview.adoc | 4 ++--
OsmoBTS/abis/rsl.adoc | 4 ++--
OsmoBTS/chapters/architecture.adoc | 2 +-
OsmoBTS/chapters/bts-models.adoc | 10 +++++-----
OsmoBTS/chapters/interfaces.adoc | 2 +-
OsmoBTS/osmobts-abis.adoc | 2 +-
OsmoNITB/chapters/mncc.adoc | 2 +-
OsmoNITB/chapters/net.adoc | 2 +-
OsmoNITB/chapters/running.adoc | 4 ++--
OsmoNITB/chapters/smpp.adoc | 2 +-
OsmoPCU/chapters/configuration.adoc | 6 +++---
OsmoPCU/chapters/overview.adoc | 2 +-
OsmoPCU/osmopcu-gb.adoc | 2 +-
OsmoSGSN/chapters/configuration.adoc | 2 +-
OsmoSGSN/chapters/gsup.adoc | 4 ++--
common/chapters/gb.adoc | 2 +-
common/chapters/glossary.adoc | 10 +++++-----
common/chapters/preface.adoc | 10 +++++-----
common/chapters/vty.adoc | 8 ++++----
20 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/OsmoBSC/chapters/alink.adoc b/OsmoBSC/chapters/alink.adoc
index 37e64c0..081e03f 100644
--- a/OsmoBSC/chapters/alink.adoc
+++ b/OsmoBSC/chapters/alink.adoc
@@ -3,12 +3,12 @@
OsmoBSC implements a minimal sub-set of the GSM A interface as specified
in TS 08.08.
-Unlike classic A interface implementations for E1 interfacs, OsmoBSC
+Unlike classic A interface implementations for E1 interface, OsmoBSC
implements a variant of encapsulating the A interface over IP. To do
so, the SCCP messages are wrapped in an IPA multiplex and then
communicated over TCP. The audio channels are mapped to RTP streams.
-This protcol stacking is sometimes called "SCCPlite".
+This protocol stacking is sometimes called "SCCPlite".
===
diff --git a/OsmoBSC/chapters/overview.adoc b/OsmoBSC/chapters/overview.adoc
index 6577df8..580a42e 100644
--- a/OsmoBSC/chapters/overview.adoc
+++ b/OsmoBSC/chapters/overview.adoc
@@ -9,7 +9,7 @@ aspects of configuring and running the OsmoBSC.
OsmoBSC is one particular version of the OpenBSC software suite.
-Unlike the highly integrated OmsoNITB, OsmoBSC impleents a more classic
+Unlike the highly integrated OmsoNITB, OsmoBSC implements a more classic
GSM Base Station Controller with A-bis interface towards BTSs and A
interface towards a MSC.
@@ -39,7 +39,7 @@ implements a variant of encapsulating the A interface over IP. To do
so, the SCCP messages are wrapped in an IPA multiplex and then
communicated over TCP. The audio channels are mapped to RTP streams.
-This protcol stacking is sometimes called "SCCPlite".
+This protocol stacking is sometimes called "SCCPlite".
For more information, see <<alink>>.
diff --git a/OsmoBTS/abis/rsl.adoc b/OsmoBTS/abis/rsl.adoc
index f32fb94..331ccb3 100644
--- a/OsmoBTS/abis/rsl.adoc
+++ b/OsmoBTS/abis/rsl.adoc
@@ -91,7 +91,7 @@ Specific limitations apply, see the linked sections.
| 8.4.24 | ROUND TRIP DELAY REPORT
| 8.4.25 | PRE-HANDOVER NOTIFICATION
| 8.4.26 | MULTIRATE CODEC MODIFICATION REQUEST
-| 8.4.27 | MULTIRATE CODEC MODIFICATION ACKNOLEWDGE
+| 8.4.27 | MULTIRATE CODEC MODIFICATION ACKNOWLEDGE
| 8.4.28 | MULTIRATE CODEC MODIFICATION NEGATIVE ACKNOWLEDGE
| 8.4.29 | MULTIRATE CODEC MODIFICATION PERFORMED
| 8.4.30 | TFO REPORT
@@ -115,7 +115,7 @@ Specific limitations apply, see the linked sections.
Conforms to 3GPP TS 08.58 § 8.4.8 with this limitation:
-._Measuremet Result_ IE limitations
+._Measurement Result_ IE limitations
[options="header",cols="10%,30%,60%"]
|===
| TS 08.58 § | IE Name | Handling
diff --git a/OsmoBTS/chapters/architecture.adoc b/OsmoBTS/chapters/architecture.adoc
index aca5bb9..a0e66cd 100644
--- a/OsmoBTS/chapters/architecture.adoc
+++ b/OsmoBTS/chapters/architecture.adoc
@@ -83,7 +83,7 @@ order to specify which PHY instance is allocated to this specific TRX.
| common | bts_controlif_setup() | Initialization of Control Interface
| bts-specific | bts_model_ctrl_cmds_install() | Install model-specific control interface commands
| common | telnet_init() | Initialization of telnet interface
-| common | pcu_sock_init() | Initializaiton of PCU socket
+| common | pcu_sock_init() | Initialization of PCU socket
| common | main() | Installation of signal handlers
| common | abis_open() | Start of the A-bis connection to BSC
| common | phy_links_open() | Iterate over list of configured PHY links
diff --git a/OsmoBTS/chapters/bts-models.adoc b/OsmoBTS/chapters/bts-models.adoc
index 5a967f6..a4c65d2 100644
--- a/OsmoBTS/chapters/bts-models.adoc
+++ b/OsmoBTS/chapters/bts-models.adoc
@@ -33,10 +33,10 @@ Each bts_model may offer
== `osmo-bts-sysmo` for sysmocom sysmoBTS
-The sysmocom sysmoBTS is a range of GSM BTSs basd around an embedded
+The sysmocom sysmoBTS is a range of GSM BTSs based around an embedded
system implementing the PHY in a combination of DSP+FPGA. The PHY is
configured by a set of primitives described by header files. Those
-primitives are exchanged ove a set of message queues exposed on the
+primitives are exchanged over a set of message queues exposed on the
Linux-running ARM core via device nodes in `/dev/msgq/`. Internally,
the message queues map to shared memory between the Linux-running ARM
core and the DSP running the PHY implementation.
@@ -62,7 +62,7 @@ vice-versa.
<<osmo-bts-sysmo-dsp-trace>> for further information.
*--pcu-direct*::
Indicate that an external PCU (e.g. OsmoPCU) will directly
- open the DSP messge queues to the PHY / PH-SAP, and only MPH
+ open the DSP message queues to the PHY / PH-SAP, and only MPH
primitives are passed via OsmoBTS.
@@ -225,7 +225,7 @@ human-readable format to current VTY session.
===== `osmotrx ip HOST`
-Set the IP addess of the OsmoTRX transceiver to which we should connect
+Set the IP address of the OsmoTRX transceiver to which we should connect
to.
===== `osmotrx base-port (local|remote) <0-65535>`
@@ -293,7 +293,7 @@ OCTPKT session, which is mapped to an OsmoBTS PHY link. Depending on
the OCTSDR-2G software version, you may create multiple software TRX by
creating multiple OsmoBTS PHY instances inside that PHY link.
-Multiple DSPs may exsist in one circuit board, then each of the DSPs is
+Multiple DSPs may exist in one circuit board, then each of the DSPs is
interfaced by one OsmoBTS PHY link, and each of them may have one or
more OsmoBTS PHY instances creating a Multi-TRX configuration.
diff --git a/OsmoBTS/chapters/interfaces.adoc b/OsmoBTS/chapters/interfaces.adoc
index f5bf1b2..a95f524 100644
--- a/OsmoBTS/chapters/interfaces.adoc
+++ b/OsmoBTS/chapters/interfaces.adoc
@@ -51,7 +51,7 @@ limited and largely depends on the bts_model used.
==== trx.N.thermal-attenuation
-The idea of this paramter is to attenuate the system output power as part of
+The idea of this parameter is to attenuate the system output power as part of
thermal management. In some cases the PA might be passing a critical level,
so an external control process can use this attribute to reduce the system
output power.
diff --git a/OsmoBTS/osmobts-abis.adoc b/OsmoBTS/osmobts-abis.adoc
index 6b4f0da..930cbfb 100644
--- a/OsmoBTS/osmobts-abis.adoc
+++ b/OsmoBTS/osmobts-abis.adoc
@@ -11,7 +11,7 @@ these are not or not fully implemented, as well as OsmoBTS-specific extensions
to the A-bis interface not specified by 3GPP.
Extensions to the A-bis interface specific to OsmoBTS are detailed in this
-document. For details on the messages and IEs that comply with abovementioned
+document. For details on the messages and IEs that comply with above mentioned
3GPP specifications, please refer to those documents.
.3GPP document versions referred to by this document
diff --git a/OsmoNITB/chapters/mncc.adoc b/OsmoNITB/chapters/mncc.adoc
index 2b75923..504ce09 100644
--- a/OsmoNITB/chapters/mncc.adoc
+++ b/OsmoNITB/chapters/mncc.adoc
@@ -181,7 +181,7 @@ NITB and an external MNCC handler.
Direction: both
-Transfer the payload of a GSM Enanced Full-Rate (EFR) voice frame
+Transfer the payload of a GSM Enhanced Full-Rate (EFR) voice frame
between the NITB and an external MNCC handler.
==== GSM_TCHH_FRAME
diff --git a/OsmoNITB/chapters/net.adoc b/OsmoNITB/chapters/net.adoc
index ecd0889..455e1a6 100644
--- a/OsmoNITB/chapters/net.adoc
+++ b/OsmoNITB/chapters/net.adoc
@@ -62,7 +62,7 @@ OpenBSC(config-net)# mobile network code 89
The __MM INFO__ procedure can be used after a successful __LOCATION
UPDATE__ in order to transmit the human-readable network name as well as
-local time zone information to the MS. gq
+local time zone information to the MS.
By default, MM INFO is not active. You can activate it, and set its
configuration using the VTY. An example is provided below.
diff --git a/OsmoNITB/chapters/running.adoc b/OsmoNITB/chapters/running.adoc
index 47b5eb7..423ecf7 100644
--- a/OsmoNITB/chapters/running.adoc
+++ b/OsmoNITB/chapters/running.adoc
@@ -29,7 +29,7 @@ arguments:
for more information.
*-T, --timestamp*::
Enable time-stamping of log messages to stderr. This has mostly
- been deprecated by VTY based logging configu- ration, see
+ been deprecated by VTY based logging configuration, see
<<logging>> for more information.
*-e, --log-level 'LOGLEVEL'*::
Set the global log level for logging to stderr. This has mostly
@@ -42,7 +42,7 @@ arguments:
Authorize every subscriber to the network. This corresponds to
the `auth-policy open` VTY configuration option.
+
- WARNING:: This is dangerous as you may disrupt sevices to
+ WARNING:: This is dangerous as you may disrupt services to
subscribers that are not part of your network! Don't use unless
you absolutely know what you're doing!
*-P, --rtp-proxy*::
diff --git a/OsmoNITB/chapters/smpp.adoc b/OsmoNITB/chapters/smpp.adoc
index 1550abd..2557580 100644
--- a/OsmoNITB/chapters/smpp.adoc
+++ b/OsmoNITB/chapters/smpp.adoc
@@ -37,7 +37,7 @@ ESMEs are permitted to access the SMSC (`closed`), or whether any
ESME should be accepted (`accept-all`).
Use the `smpp-first` command to define if SMPP routes have higher
-precendence than MSISDNs contained in the HLR (`smpp-first`), or if
+precedence than MSISDNs contained in the HLR (`smpp-first`), or if
only MSISDNs found not in the HLR should be considered for routing to
SMPP (`no smpp-first`).
diff --git a/OsmoPCU/chapters/configuration.adoc b/OsmoPCU/chapters/configuration.adoc
index 1a86f32..bcf3ad7 100644
--- a/OsmoPCU/chapters/configuration.adoc
+++ b/OsmoPCU/chapters/configuration.adoc
@@ -59,7 +59,7 @@ reached, a higher coding scheme is chosen.
You can use the `cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3
<0-35> <0-35> cs4 <0-35>` command at the `pcu` VTY config node to tune
-the link quality ranges for the respecive coding schemes.
+the link quality ranges for the respective coding schemes.
==== Data Size based CS downgrade Threshold
@@ -114,7 +114,7 @@ filter).
==== Normal BSSGP Flow Control Tuning parameters
You can use the following commands at the `pcu` VTY config node to tune
-the the BSSGP flow control parameters:
+the BSSGP flow control parameters:
`flow-control-interval <1-10>`::
configure the interval (in seconds) between subsequent flow
@@ -185,7 +185,7 @@ parameters.
You can set those parameters at the `pcu` VTY config node as follows:
`alpha <0-10>`::
- Alpha parameter for MS power contrl in units of 0.1.
+ Alpha parameter for MS power control in units of 0.1.
Make sure to set the alpha value at System Information 13 (in
the BSC), too!
`gamma <0-62>`::
diff --git a/OsmoPCU/chapters/overview.adoc b/OsmoPCU/chapters/overview.adoc
index e13a7b8..0031474 100644
--- a/OsmoPCU/chapters/overview.adoc
+++ b/OsmoPCU/chapters/overview.adoc
@@ -6,7 +6,7 @@ OsmoPCU is the Osmocom implementation of the GPRS PCU (Packet Control
Unit) element inside the GPRS network.
The OsmoPCU is co-located within the BTS and connects to OsmoBTS via its
-PCU socket inteface.
+PCU socket interface.
On the other side, OsmoPCU is connected via the Gb interface to the
SGSN.
diff --git a/OsmoPCU/osmopcu-gb.adoc b/OsmoPCU/osmopcu-gb.adoc
index 7598900..fc2ca8f 100644
--- a/OsmoPCU/osmopcu-gb.adoc
+++ b/OsmoPCU/osmopcu-gb.adoc
@@ -72,7 +72,7 @@ NSVCI:: NS Virtual Connection Identifier
BVCI:: BSSGP Virtual Connection Identifier
For an explanation of those identifiers and their use in the NS and
-BSSGP protocols, please see the reelvant 3GPP specifications for NS (TS 08.16)
+BSSGP protocols, please see the relevant 3GPP specifications for NS (TS 08.16)
and BSSGP (TS 08.18).
In most cases, all above identities belong to different namespaces and
diff --git a/OsmoSGSN/chapters/configuration.adoc b/OsmoSGSN/chapters/configuration.adoc
index 0d010c3..8b259ed 100644
--- a/OsmoSGSN/chapters/configuration.adoc
+++ b/OsmoSGSN/chapters/configuration.adoc
@@ -125,7 +125,7 @@ The CDR file is a simple CSV file including a header line naming the
individual fields of each CSV line.
[[sgsn-cdr]]
-.Descripton of CSV fields in OsmoSGSN CDR file
+.Description of CSV fields in OsmoSGSN CDR file
[options="header",cols="15%,85%"]
|===
|Field Name|Description
diff --git a/OsmoSGSN/chapters/gsup.adoc b/OsmoSGSN/chapters/gsup.adoc
index 9efc8c0..838af7d 100644
--- a/OsmoSGSN/chapters/gsup.adoc
+++ b/OsmoSGSN/chapters/gsup.adoc
@@ -29,14 +29,14 @@ By default, the following identifiers should be used:
* IPA OSMO protocol extension: 0x05
For more information about the IPA multiplex, please see the 'OsmoBTS
-Abis/IP Specifiation'.
+Abis/IP Specification'.
=== Procedures
==== Authentication management
The SGSN sends a SEND_AUTHENTICATION_INFO_REQ message containing the MS's IMSI
-to the peer. On errors, especially if authentication info is not availabe for
+to the peer. On errors, especially if authentication info is not available for
that IMSI, the peer returns a SEND_AUTHENTICATION_INFO_ERR message. Otherwise
the peer returns a SEND_AUTHENTICATION_INFO_RES message. If this message
contains at least one authentication tuple, the SGSN replaces all tuples that
diff --git a/common/chapters/gb.adoc b/common/chapters/gb.adoc
index 793e23f..d01fa9b 100644
--- a/common/chapters/gb.adoc
+++ b/common/chapters/gb.adoc
@@ -58,7 +58,7 @@ The NS protocol features a number of configurable timers.
=== Examining Gb interface status
-There are several commans that can help to inspect and analyze the
+There are several commands that can help to inspect and analyze the
currently running system status with respect to the Gb interfaces.
.Example: Inspecting NS state
diff --git a/common/chapters/glossary.adoc b/common/chapters/glossary.adoc
index 4d68666..c39d439 100644
--- a/common/chapters/glossary.adoc
+++ b/common/chapters/glossary.adoc
@@ -8,7 +8,7 @@
3GPP::
3rd Generation Partnership Project
4FF::
- 4th Generaion Form Factor; the so-called nanoSIM form factor
+ 4th Generation Form Factor; the so-called nanoSIM form factor
A Interface::
Interface between BTS and BSC, traditionally over E1 (_3GPP TS 48.008_
<<3gpp-ts-48-008>>)
@@ -103,7 +103,7 @@ GGSN::
GMSK::
Gaussian Minimum Shift Keying; modulation used for GSM and GPRS
GPL::
- GNU General Public License, a copyleft-style Freee Software License
+ GNU General Public License, a copyleft-style Free Software License
Gp::
Gp interface between SGSN and GGSN; uses GTP protocol
GPS::
@@ -159,7 +159,7 @@ MNO::
MS::
Mobile Station; a mobile phone / GSM Modem
MSC::
- Mobile Switching Center; network element in the circuit-switcehd
+ Mobile Switching Center; network element in the circuit-switched
core network
MSISDN::
Mobile Subscriber ISDN Number; telephone number of the subscriber
@@ -168,7 +168,7 @@ MVNO::
NCC::
Network Color Code; assigned by national regulator
NITB::
- Network In The Box; combines functionality traditionally proivided
+ Network In The Box; combines functionality traditionally provided
by BSC, MSC, VLR, HLR, SMSC functions; see OsmoNITB
NSEI::
NS Entity Identifier
@@ -236,7 +236,7 @@ RFM::
Roaming::
Procedure in which a subscriber of one network is using the radio
network of another network, often in different countries; in some
- countris national roaming exists
+ countries national roaming exists
Routing Area::
Routing Area; GPRS specific sub-division of Location Area
RR::
diff --git a/common/chapters/preface.adoc b/common/chapters/preface.adoc
index d986cbe..13afec1 100644
--- a/common/chapters/preface.adoc
+++ b/common/chapters/preface.adoc
@@ -71,7 +71,7 @@ following key individuals and organizations, in no particular order:
annual Osmocom Developer Conference and releasing this manual.
* Jan Luebbe, Stefan Schmidt, Daniel Willmann, Pablo Neira, Nico Golde,
Kevin Redon, Ingo Albrecht, Alexander Huemer, Alexander Chemeris, Max
- Suraev, Tobias Engel, Jacob Erlbeck, Ivan Kluchnikov, Alexander Huemer
+ Suraev, Tobias Engel, Jacob Erlbeck, Ivan Kluchnikov
May the source be with you!
@@ -125,7 +125,7 @@ contributions can be many-fold, for example
by donating developer resources or by (partially) funding those people
in the community who do.
-We're looking forward to receicing your contributions.
+We're looking forward to receiving your contributions.
=== Osmocom and sysmocom
@@ -194,17 +194,17 @@ use case is compliant with the software licenses.
==== Trademarks
All trademarks, service marks, trade names, trade dress, product names
-and logos appearing in this manual are the property of their respecitve
+and logos appearing in this manual are the property of their respective
owners. All rights not expressly granted herein are reserved.
-For your convenience we have listed below some of the registrered
+For your convenience we have listed below some of the registered
trademarks referenced herein. This is not a definitive or complete list
of the trademarks used.
'Osmocom(R)' and 'OpenBSC(R)' are registered trademarks of Holger
Freyther and Harald Welte.
-'sysmocom(R)' and 'sysmoBTS(R)' is registered trasdemarks of
+'sysmocom(R)' and 'sysmoBTS(R)' are registered trademarks of
'sysmocom - systems for mobile communications GmbH'.
'ip.access(R)' and 'nanoBTS(R)' are registered trademarks of
diff --git a/common/chapters/vty.adoc b/common/chapters/vty.adoc
index 9103319..931cd1f 100644
--- a/common/chapters/vty.adoc
+++ b/common/chapters/vty.adoc
@@ -134,12 +134,12 @@ OpenBSC> <1>
terminal Set terminal line parameters
who Display who is on vty
logging Configure log message to this terminal
- sms SMS related comamnds
+ sms SMS related commands
subscriber Operations on a Subscriber
----
<1> press `?` here at the prompt, the character will not be printed
-If you have already entered a partial comamnd, `?` will help you to
+If you have already entered a partial command, `?` will help you to
review possible options of how to continue your command. Let's say you
remember that `show` is used to investigate the system status. But you
don't know exactly what the object was called that you'd like to show:
@@ -157,7 +157,7 @@ OpenBSC> show <1>
trx Display information about a TRX
timeslot Display information about a TS
lchan Display information about a logical channel
- paging Display information about paging reuqests of a BTS
+ paging Display information about paging requests of a BTS
paging-group Display the paging group
logging Show current logging configuration
alarms Show current logging configuration
@@ -172,7 +172,7 @@ OpenBSC> show <1>
----
<1> press `?` after the `show` command, the character will not be printed
-Now you decide you want to have a look at the the `network` object, so
+Now you decide you want to have a look at the `network` object, so
you type network and press `?` again:
.Example: Typing `?` after `show network`
--
1.9.1
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Please test the package and file bugs as you find them. I haven't added init/service files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
Best regards,
Ruben
Hi,
Developing a module for FreeRADIUS to support EAP-SIM and EAP-AKA authentication against a HLR.
The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA.
Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues.
Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards.
...but the differences are fairly minor at MTP3 and SCCP layers, and i've started work on a patchset for libosmo-sccp.
https://gerrit.osmocom.org/#/c/73/
Anyway, trying to gauge interest in splitting those layers out of Open BSC into a separate library, would be happy to take on M2UA as well for consistency.
It would almost certainly get more projects using the code. There's very little out there even in Perl land for working with SS7.
Thanks,
-Arran
Arran Cudbard-Bell <a.cudbardb(a)freeradius.org>
FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi Keith,
On May 5, 2016 6:02 PM, "Keith" <keith(a)rhizomatica.org> wrote:
>
> They generate constant bursts on the uplink, and this is what I can see
> that corresponds from osmo-bts log output:
>
> <0000> ../../../../osmo-bts/src/common/rsl.c:1642
> (bts=0,trx=0,ts=0,ss=0) Handing RLL msg UNIT_DATA_IND from LAPDm to MEAS
REP
> <0000> ../../../../osmo-bts/src/common/rsl.c:1592
> (bts=0,trx=0,ts=0,ss=0) Tx MEAS RES
MEAS RES means that there is an open logical channel between the phone and
the BTS. Have you looked at the list of open channels at the NITB VTY?
> I might also mention that this phone fails the USSD *#100# own number
> request - The message "Not Successful" appears on the screen very
> quickly if not immediately after pressing send. There is no network
> communication that I can detect.
Just a suggestion - is the phone network or SIM locked?
If it's locked, it may try to send some message to the network to verify
that it's connected to an allowed operator.
A useful log would be a pcap trace of communication between OpenBSC and
OsmoBTS (make sure osmo-trx communication is filtered out).
--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
Review at https://gerrit.osmocom.org/111
debian: Make upgrading from debian SID easier
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I6486f91bc11e0828b4ccd0e22f8e2135af0d271a
---
M debian/changelog
1 file changed, 6 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-netif refs/changes/11/111/1
diff --git a/debian/changelog b/debian/changelog
index 2180e56..6cd3378 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libosmo-netif (0.0.7) UNRELEASED; urgency=medium
+
+ * Move forward toward a new release.
+
+ -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 24 May 2016 23:06:33 +0200
+
libosmo-netif (0.0.6) unstable; urgency=medium
* Drop libosmovty dependency.
--
To view, visit https://gerrit.osmocom.org/111
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I6486f91bc11e0828b4ccd0e22f8e2135af0d271a
Gerrit-PatchSet: 1
Gerrit-Project: libosmo-netif
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Hello Jenkins Builder,
I'd like you to do a code review. Please visit
https://gerrit.osmocom.org/122
to review the following change.
osmux: Add function to delete all msgs pending for a circuit
Use this function in osmux_batch_del_circuit() since msgs are stored in a list
per circuit. After the circuit is free()d the msgs are lost.
Before this patch any messages enqueued inside a batch when the circiut is
deleted were leaking.
Change-Id: Ib0311652183332d0475bf7347023d518d38487ef
Ticket: OS#1733
Reviewed-on: https://gerrit.osmocom.org/120
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger(a)freyther.de>
---
M src/osmux.c
1 file changed, 11 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-netif refs/changes/22/122/1
diff --git a/src/osmux.c b/src/osmux.c
index 1f5bbe2..0bee9cc 100644
--- a/src/osmux.c
+++ b/src/osmux.c
@@ -225,6 +225,16 @@
circuit->nmsgs--;
}
+static void osmux_circuit_del_msgs(struct osmux_batch *batch, struct osmux_circuit *circuit)
+{
+ struct msgb *cur, *tmp;
+ llist_for_each_entry_safe(cur, tmp, &circuit->msg_list, list) {
+ osmux_batch_dequeue(cur, circuit);
+ msgb_free(cur);
+ batch->nmsgs--;
+ }
+}
+
struct osmux_input_state {
struct msgb *out_msg;
struct msgb *msg;
@@ -538,6 +548,7 @@
if (circuit->dummy)
batch->ndummy--;
llist_del(&circuit->head);
+ osmux_circuit_del_msgs(batch, circuit);
talloc_free(circuit);
}
--
To view, visit https://gerrit.osmocom.org/122
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib0311652183332d0475bf7347023d518d38487ef
Gerrit-PatchSet: 1
Gerrit-Project: libosmo-netif
Gerrit-Branch: releases/0.0.6-stable
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Review at https://gerrit.osmocom.org/120
osmux: Add function to delete all msgs pending for a circuit
Use this function in osmux_batch_del_circuit() since msgs are stored in a list
per circuit. After the circuit is free()d the msgs are lost.
Before this patch any messages enqueued inside a batch when the circiut is
deleted were leaking.
Change-Id: Ib0311652183332d0475bf7347023d518d38487ef
Ticket: OS#1733
---
M src/osmux.c
1 file changed, 12 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-netif refs/changes/20/120/1
diff --git a/src/osmux.c b/src/osmux.c
index 44b4b96..01d0bdc 100644
--- a/src/osmux.c
+++ b/src/osmux.c
@@ -225,6 +225,17 @@
circuit->nmsgs--;
}
+static void osmux_circuit_del_msgs(struct osmux_batch *batch, struct osmux_circuit *circuit)
+{
+ struct msgb *cur, *tmp;
+ llist_for_each_entry_safe(cur, tmp, &circuit->msg_list, list) {
+
+ osmux_batch_dequeue(cur, circuit);
+ msgb_free(cur);
+ batch->nmsgs--;
+ }
+}
+
struct osmux_input_state {
struct msgb *out_msg;
struct msgb *msg;
@@ -538,6 +549,7 @@
if (circuit->dummy)
batch->ndummy--;
llist_del(&circuit->head);
+ osmux_circuit_del_msgs(batch, circuit);
talloc_free(circuit);
}
--
To view, visit https://gerrit.osmocom.org/120
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ib0311652183332d0475bf7347023d518d38487ef
Gerrit-PatchSet: 1
Gerrit-Project: libosmo-netif
Gerrit-Branch: master
Gerrit-Owner: daniel <dwillmann(a)sysmocom.de>
Review at https://gerrit.osmocom.org/112
debian: Make upgrading from debian SID easier
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I77126b0b9a8dbc4dcdc02a5a3b4718129b308930
---
M debian/changelog
1 file changed, 7 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libsmpp34 refs/changes/12/112/1
diff --git a/debian/changelog b/debian/changelog
index 20ae3d3..aae6e0d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,10 @@
-libsmpp34 (1.10z1) UNRELEASED; urgency=low
+libsmpp34 (1.11) UNRELEASED; urgency=medium
+
+ * Move forward towards a new release.
+
+ -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 24 May 2016 23:07:49 +0200
+
+libsmpp34 (1.10z1) stable; urgency=low
* Add depedency from libsmpp34-dev to the main library
--
To view, visit https://gerrit.osmocom.org/112
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I77126b0b9a8dbc4dcdc02a5a3b4718129b308930
Gerrit-PatchSet: 1
Gerrit-Project: libsmpp34
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Review at https://gerrit.osmocom.org/102
filter/nat: Fix the context for the imsi assignment
In c09f8a3b7fb94ccef41e33c32bfe2bff1ffe0e44 as part of a cleanup
I accidently changed the talloc context from "con" to "bsc". The
issue occurred at an earlier commit when assigning req.ctx to the
"wrong" context. The allocation needs to be scoped by the struct
nat_sccp_connection and not the connection from BSC to NAT.
Before we have a nat_sccp_connection we scope the copied imsi to
the bsc_connection and then steal it, but for the identity resp
we will always have a nat_sccp_connection and can already use the
right context.
Change-Id: I53789aad2809e19338ad3b2deb72c4757e7bd524
Related: OS#1733
---
M openbsc/src/osmo-bsc_nat/bsc_nat_filter.c
M openbsc/tests/bsc-nat/bsc_nat_test.c
2 files changed, 4 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/02/102/1
diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat_filter.c b/openbsc/src/osmo-bsc_nat/bsc_nat_filter.c
index 393aea3..e735290 100644
--- a/openbsc/src/osmo-bsc_nat/bsc_nat_filter.c
+++ b/openbsc/src/osmo-bsc_nat/bsc_nat_filter.c
@@ -109,7 +109,7 @@
if (!hdr48)
return -1;
- req.ctx = bsc;
+ req.ctx = con;
req.black_list = &bsc->nat->imsi_black_list;
req.access_lists = &bsc->nat->access_lists;
req.local_lst_name = bsc->cfg->acc_lst_name;
diff --git a/openbsc/tests/bsc-nat/bsc_nat_test.c b/openbsc/tests/bsc-nat/bsc_nat_test.c
index a405763..b531c6b 100644
--- a/openbsc/tests/bsc-nat/bsc_nat_test.c
+++ b/openbsc/tests/bsc-nat/bsc_nat_test.c
@@ -978,10 +978,13 @@
}
memset(&cause, 0, sizeof(cause));
+ OSMO_ASSERT(!con->filter_state.imsi);
if (bsc_nat_filter_dt(bsc, msg, con, parsed, &cause) != 1) {
printf("FAIL: Should have passed..\n");
abort();
}
+ OSMO_ASSERT(con->filter_state.imsi);
+ OSMO_ASSERT(talloc_parent(con->filter_state.imsi) == con);
/* just some basic length checking... */
for (i = ARRAY_SIZE(id_resp); i >= 0; --i) {
--
To view, visit https://gerrit.osmocom.org/102
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I53789aad2809e19338ad3b2deb72c4757e7bd524
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Review at https://gerrit.osmocom.org/113
debian: Make upgrading from debian SID easier
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I838632e9e90378a03235c2aebd5bc9ed06627ec8
---
M debian/changelog
1 file changed, 7 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/13/113/1
diff --git a/debian/changelog b/debian/changelog
index 5f00a30..6a0362a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,10 @@
-openbsc (0.14.0) UNRELEASED; urgency=low
+openbsc (0.15.1) UNRELEASED; urgency=medium
+
+ * Move forward toward a new release.
+
+ -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 24 May 2016 23:14:31 +0200
+
+openbsc (0.14.0) unstable; urgency=low
* New upstream tag and additional patches.
--
To view, visit https://gerrit.osmocom.org/113
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I838632e9e90378a03235c2aebd5bc9ed06627ec8
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Review at https://gerrit.osmocom.org/110
debian: Make upgrading from debian SID easier
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I393ef6624f112794e15b81a0cc9dbd8b0a871b07
---
M debian/changelog
1 file changed, 7 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-abis refs/changes/10/110/1
diff --git a/debian/changelog b/debian/changelog
index f1842fa..b2cf0e9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,10 @@
-libosmo-abis (0.3.2) UNRELEASED; urgency=medium
+libosmo-abis (0.3.3) UNRELEASED; urgency=medium
+
+ * Move forward towards a new release.
+
+ -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 24 May 2016 23:02:47 +0200
+
+libosmo-abis (0.3.2) unstable; urgency=medium
* Bump so version to re-link libosmovty
--
To view, visit https://gerrit.osmocom.org/110
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I393ef6624f112794e15b81a0cc9dbd8b0a871b07
Gerrit-PatchSet: 1
Gerrit-Project: libosmo-abis
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Review at https://gerrit.osmocom.org/109
debian: Make upgrading from debian SID easier
Make sure the version number of this sourcepackage is higher than
the one found in Debian SID.
Change-Id: I87534954c1f4b499e27452382df412454ea16b64
---
M debian/changelog
1 file changed, 6 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/libosmo-sccp refs/changes/09/109/1
diff --git a/debian/changelog b/debian/changelog
index 9e5884e..b7a0c97 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libosmo-sccp (0.7.1) UNRELEASED; urgency=medium
+
+ * Move forward towards a new release.
+
+ -- Holger Hans Peter Freyther <holger(a)moiji-mobile.com> Tue, 24 May 2016 22:57:59 +0200
+
libosmo-sccp (0.7.0) unstable; urgency=medium
* New release.
--
To view, visit https://gerrit.osmocom.org/109
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I87534954c1f4b499e27452382df412454ea16b64
Gerrit-PatchSet: 1
Gerrit-Project: libosmo-sccp
Gerrit-Branch: master
Gerrit-Owner: Holger Freyther <holger(a)freyther.de>
Review at https://gerrit.osmocom.org/91
rtp_proxy.c: Ensure msgb_alloc is large enough for largest AMR frame
In AMR 12.2 (mode 7), the actual RTP payload is 33 bytes. Howeerver,
as we store the length of the (dynamically-sized) AMR payload in the
first byte, our buffer needs at least 33+1 byte in size.
Change-Id: If1ad5d2d68c85733306c75ea62f67fe8fbc143b3
---
M openbsc/src/libtrau/rtp_proxy.c
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/openbsc refs/changes/91/91/1
diff --git a/openbsc/src/libtrau/rtp_proxy.c b/openbsc/src/libtrau/rtp_proxy.c
index 8c982c9..6c04610 100644
--- a/openbsc/src/libtrau/rtp_proxy.c
+++ b/openbsc/src/libtrau/rtp_proxy.c
@@ -172,7 +172,7 @@
/* always allocate for the maximum possible size to avoid
* fragmentation */
new_msg = msgb_alloc(sizeof(struct gsm_data_frame) +
- MAX_RTP_PAYLOAD_LEN, "GSM-DATA (TCH)");
+ MAX_RTP_PAYLOAD_LEN+1, "GSM-DATA (TCH)");
if (!new_msg)
return -ENOMEM;
--
To view, visit https://gerrit.osmocom.org/91
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If1ad5d2d68c85733306c75ea62f67fe8fbc143b3
Gerrit-PatchSet: 1
Gerrit-Project: openbsc
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge(a)gnumonks.org>
On openbsc master, in do_lchan_free(), a T3111 timer is started in case
the lchan is in an error state. Why?
3GPP TS 04.08:
The sole purpose of timer T3111 is to let some time [pass] to acknowledge
the disconnection and to protect the channel in case of loss of the
acknowledge frame.
I'm asking because for dyn PDCH, I'm looking at jolly's branch, which adds
channel defragmentation: when a channel is released, do_pdch_defrag()
closes gaps in the assignments by swapping active channels into empty
slots. It appears that the defragmentation code doesn't want to wait for
T3111 ... and prefers to run through channel reallocations more quickly,
if that makes any sense?
Also, I'm not sure whether we want the defragmentation feature at this
time. It seems to be orthogonal, not related to dynamic reassignment of
TCH <-> PDCH per se.
Thanks for any opinions or hints!
For details, take a look at a6c1c652e5f9cd7f2e456af39a54b8fafdc5b344
openbsc/src/libbsc/abis_rsl.c:69:do_lchan_free()
(branch users/neels/dyn_pdch)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
> On 04 May 2016, at 14:01, gitosis(a)osmocom.org wrote:
Hi
> msc subscr: add paging timeout
>
> In NITB, the paging timeout would be handled from the BSC side. In IuCS, we
> need to invalidate the paging request from libmsc alone, so add a paging timer
> to gsm_subscriber.
>
> Possibly, the HNB-GW should respond with a paging failure and libmsc could
> trigger on that, nevertheless libmsc should not rely on a failure message to
> expire pending pagings.
I don't think this belongs into the gsm_subscriber. If you compare this with the architectural change that removed the "subscriber queue" we are going to repeat the same mistake again. The timeout belongs into the logical "operation" and not the subscriber (the object of the logical operation).
cheers
holger
Hi Daniel,
it seems I'm through with the IuPS branch refactoring.
I'm not entirely sure why I'm allowed to do so, but I managed to push the
branch to gerrit as refs/heads/sysmocom/iups, so you should see this in origin:
sysmocom/iups
The branch is fully mergeable to openbsc master as far as I'm concerned, I'm
fairly sure that it shouldn't break 2G GPRS -- but untested!!
Another limitation: the libosmo-netif and libosmo-sccp branches should possibly
be merged to master first.
About sysmocom/iups:
Most commits have been regrouped and relabeled, yet some remain as they were in
the "old" sysmocom/iu branch. I was originally aiming for a 1:1 similarity, but
I "had" to change various things:
* Some of the commit log messages from sysmocom/iu have been placed in the code
as comments instead.
* iu_rab_act_ps() was moved (too gprs specific)
* some changes were dropped because they were bogus
* comments were added, minor cosmetic changes were made
* at least the DRANAP, DSUA have been re-ordered cosmetically (to match)
* A test failure was fixed
* ...
* Some "unrelated" patches waiting for review on gerrit are not included in the
branch (https://gerrit.osmocom.org/91, 93, 94)
Please take a look at the new branch and test it with 3G IuPS. (Since IuCS does
not exist on the branch, maybe you need to trick around to have an osmo-cscn?
It's an interesting discussion how useful IuPS is without IuCS.)
If you have any local further developments on your box, please try to rebase
them onto the new branch.
If any problems show up, let's clear them in the coming days.
Thanks!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
My patches https://gerrit.osmocom.org/93 and 94 show as merge conflict in the
overview. Yet when I rebase them onto origin/master, neither has a merge
conflict.
Before 92 was submitted, gerrit said that 93 conflicted with
https://gerrit.osmocom.org/92 which has no overlaps, the changes are more than
60 lines apart. In the log I also see a jenkins build success.
I have no idea what to make of this. How can I see merge conflicts that gerrit
saw and be less confused?
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hello
Hello
I am using the OpenBTS/OpenBsc software and would like to ask if it is
possible to change the following parameters dynamically in the L2/L3 open
SW:
MCC
MNC
The name of the network provider
Band
ARFCN
TA filter
BA List
CA list
LAC
CRO Parameter: in a rage of -126 to 126
RAC
NMO
BSIC
Cell ID
T3212
Power of transmission
Neighbor list for UTRA and E-UTRA (System Info 2)
I saw that changing these parameters via Vty (telnet) affected only the
openbsc.cfg and openbts.cfg files by saving the changes but actually the
BSC was not affected from the changes - only after turning the BSC off and
on. Can we avoid BSC "restart"?
Thanks in advanced,
Ilan
Review at https://gerrit.osmocom.org/100
gprs_rlcmac_sched: fix mistype of CONTROL ACK
Change-Id: If37b33f69cd659d913ed81eb6060a42734ba524f
---
M src/gprs_rlcmac_sched.cpp
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-pcu refs/changes/00/100/1
diff --git a/src/gprs_rlcmac_sched.cpp b/src/gprs_rlcmac_sched.cpp
index b513b5b..fce3aaf 100644
--- a/src/gprs_rlcmac_sched.cpp
+++ b/src/gprs_rlcmac_sched.cpp
@@ -132,7 +132,7 @@
/*
* Assignments for the same direction have lower precedence,
- * because they may kill the TBF when the CONTOL ACK is
+ * because they may kill the TBF when the CONTROL ACK is
* received, thus preventing the others from being processed.
*/
--
To view, visit https://gerrit.osmocom.org/100
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If37b33f69cd659d913ed81eb6060a42734ba524f
Gerrit-PatchSet: 1
Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>