This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "SCCP Library".
The branch, master has been updated
via dcb360a9dbd418ac582b2996cf394390b154fe0a (commit)
via dae7491c14f5e7bdfecb25fba5c2624127daadc8 (commit)
from 9fc351de69a2f3f451a2c44145fbabb156ef410a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/libosmo-sccp/commit/?id=dcb360a9dbd418ac582b2996cf3…
commit dcb360a9dbd418ac582b2996cf394390b154fe0a
Author: Philipp Maier <pmaier(a)sysmocom.de>
Date: Fri Jul 21 12:55:24 2017 +0200
xua: fix possible memory leak in seems osmo_ss7_asp_use_default_lm()
The function seems osmo_ss7_asp_use_default_lm() does not guard
against an asp->lm_priv FSM instance already existing. If this
function is called a second time, it will overwrite asp->lm_priv,
causing the original fsm instance to leaked.
Check if asp->lm_priv already exists and terminate (free) the
FSM if present.
Change-Id: I4ad435c042a435c4e641c6e5c53b91265dd23d40
http://cgit.osmocom.org/libosmo-sccp/commit/?id=dae7491c14f5e7bdfecb25fba5c…
commit dae7491c14f5e7bdfecb25fba5c2624127daadc8
Author: Philipp Maier <pmaier(a)sysmocom.de>
Date: Wed Jul 19 18:41:09 2017 +0200
sccp: make simple client configurable via VTY
The osmo_sccp_simple_client_on_ss7_id and osmo_sccp_simple_client
are not entirely configurable via VTY commands. The relation to
the VTY is implicit. The user may set up instance objects via
VTY (cs7/ss7, AS, ASP), which are then automatically created on
startup.
Each cs7 instance gets its own ID via the VTY configuration. When
osmo_sccp_simple_client_on_ss7_id() is called with the cs7 instance
id. (for osmo_sccp_simple_client() the ID will be hardcoded to 1),
the function automatically checks if the CS7 instance is present,
if not it will create one automatically using the caller supplied
parameters as a defult. If a CS7 instance is present, the function
checks for the presence of an AS and an ASP. These objects are
present, they will be used. If not, new objects will be created.
Both functions must not be called if an SCCP instance is already
present. Since there can only be one SCCP instance per CS7 instance,
this is an error condition.
Add additional logic that checks to detect an already existing, valid
configuration. If no or an insufficient configuration is detected,
use the caller supplied parameters as default configuration.
Change-Id: I293f3526ce6182dca74a169a23449dbc7af57c7c
-----------------------------------------------------------------------
Summary of changes:
include/osmocom/sigtran/osmo_ss7.h | 5 ++
src/osmo_ss7.c | 52 ++++++++++++++
src/sccp_user.c | 137 +++++++++++++++++++++++++++----------
src/xua_default_lm_fsm.c | 5 ++
4 files changed, 161 insertions(+), 38 deletions(-)
hooks/post-receive
--
SCCP Library
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Osmocom BTS-side code (Abis, scheduling, ...)".
The branch, master has been updated
via 0ebf985492e528e85acb60692c0cb91219598e04 (commit)
from 8785978c37d87bfefe3d469b9d4f614f082ef9e7 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-bts/commit/?id=0ebf985492e528e85acb60692c0cb91…
commit 0ebf985492e528e85acb60692c0cb91219598e04
Author: Max <msuraev(a)sysmocom.de>
Date: Thu Jul 20 16:28:20 2017 +0200
lc15: port lc15bts-mgr dependency changes
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit:
* adjust comments to simplify further diffs
* add libsystemd dependency to lc15bts-mgr
* add software watchdog which uses it
* ocxo calibration and gps related code
Change-Id: I475a330af771891ba3c897294ce0dd57ec2ba8db
Related: SYS#3732
-----------------------------------------------------------------------
Summary of changes:
configure.ac | 1 +
src/osmo-bts-litecell15/Makefile.am | 9 +-
src/osmo-bts-litecell15/calib_file.c | 62 ++++----
src/osmo-bts-litecell15/misc/lc15bts_mgr.c | 9 ++
src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c | 140 ++++++++++++------
src/osmo-bts-litecell15/misc/lc15bts_mgr_temp.c | 6 +-
src/osmo-bts-litecell15/misc/lc15bts_swd.c | 178 +++++++++++++++++++++++
src/osmo-bts-litecell15/misc/lc15bts_swd.h | 7 +
8 files changed, 327 insertions(+), 85 deletions(-)
create mode 100644 src/osmo-bts-litecell15/misc/lc15bts_swd.c
create mode 100644 src/osmo-bts-litecell15/misc/lc15bts_swd.h
hooks/post-receive
--
Osmocom BTS-side code (Abis, scheduling, ...)
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Osmocom BTS-side code (Abis, scheduling, ...)".
The branch, master has been updated
via 8785978c37d87bfefe3d469b9d4f614f082ef9e7 (commit)
from 0e9dadc3d8e475eff867388b2db65919da36c505 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-bts/commit/?id=8785978c37d87bfefe3d469b9d4f614…
commit 8785978c37d87bfefe3d469b9d4f614f082ef9e7
Author: Max <msuraev(a)sysmocom.de>
Date: Fri Jul 21 17:12:17 2017 +0200
lc15bts-mgr: separate service file
The sysmobts- and lc15bts- mgr have different semantics for the same
command line option (-n: writing to EEPROM vs writing to ROM). and
different default value. Hence it make sense to use separate files,
similar to osmo-bts-*.service
Change-Id: I645a81e30d7146ff26720391db763b6d585037e6
Related: SYS#3728
-----------------------------------------------------------------------
Summary of changes:
contrib/{sysmobts-mgr.service => lc15bts-mgr.service} | 4 ++--
contrib/sysmobts-mgr.service | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
copy contrib/{sysmobts-mgr.service => lc15bts-mgr.service} (50%)
hooks/post-receive
--
Osmocom BTS-side code (Abis, scheduling, ...)
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "An utility library for Open Source Mobile Communications".
The branch, master has been updated
via 5cfa6dc99324b86a104c697e3ffe8f6d82bd3a22 (commit)
from a7ccf6158c1e0ad87bda1f5cac07b4aa1bbcf6b2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/libosmocore/commit/?id=5cfa6dc99324b86a104c697e3ffe…
commit 5cfa6dc99324b86a104c697e3ffe8f6d82bd3a22
Author: Harald Welte <laforge(a)gnumonks.org>
Date: Fri Jul 21 16:52:29 2017 +0200
osmo_sock_init2(): Fix creation of non-bound sockets
If osmo_sock_init2() was used with CONNECT flag but without BIND
flag, an invalid check for "did we create a socket yet" caused
the socket to never be created, and subsequently the entire function
to return an error.
Change-Id: I0206dbb9c5b8f74d7fb088576941b092acd2ca22
-----------------------------------------------------------------------
Summary of changes:
src/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
An utility library for Open Source Mobile Communications
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Small Hardware Projects".
The branch, master has been updated
via 4e58d0341286e71213d2e92751d79c0e2d987e1e (commit)
from 251847b5612a1d18c13451a7b7e5854ad550ad9f (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-small-hardware/commit/?id=4e58d0341286e71213d2…
commit 4e58d0341286e71213d2e92751d79c0e2d987e1e
Author: Harald Welte <laforge(a)gnumonks.org>
Date: Sat Jul 22 10:44:51 2017 +0200
mv-uart: annotate individual pins in brd and generate mv-uart-pinout.pdf
-----------------------------------------------------------------------
Summary of changes:
multivoltage-uart/mv-uart-pinout.pdf | Bin 0 -> 18192 bytes
multivoltage-uart/mv-uart.brd | 19 +++++++++++++++++++
2 files changed, 19 insertions(+)
create mode 100644 multivoltage-uart/mv-uart-pinout.pdf
hooks/post-receive
--
Small Hardware Projects
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Tools to centralize packet capture and storing".
The branch, master has been updated
via 2fe9cb937d2e7aba621ee48a2892782e5f1cbbbc (commit)
via 2aea8704f391675a704d0431497cf0100ca76b9a (commit)
via 604e0711596e7e06600a2d7aea3394d36e5d3bda (commit)
from 4776b2972e84ef75b3a1c884da19604d87fc7f68 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
-----------------------------------------------------------------------
Summary of changes:
debian/osmo-pcap-client.init | 2 +-
debian/osmo-pcap-client.install | 2 +-
debian/osmo-pcap-server.install | 2 +-
include/osmo-pcap/common.h | 9 +++++++++
osmoappdesc.py | 6 +++---
src/Makefile.am | 2 +-
src/osmo_client_main.c | 2 +-
src/osmo_client_network.c | 3 ++-
src/osmo_server_main.c | 2 +-
9 files changed, 20 insertions(+), 10 deletions(-)
hooks/post-receive
--
Tools to centralize packet capture and storing
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "UNNAMED PROJECT".
The branch, laforge/gsmtap-category has been created
at 717cdf540558b95f31e4c8ea58d0fc9e06429228 (commit)
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-pcu/commit/?id=717cdf540558b95f31e4c8ea58d0fc9…
commit 717cdf540558b95f31e4c8ea58d0fc9e06429228
Author: Harald Welte <laforge(a)gnumonks.org>
Date: Fri Jul 21 21:56:23 2017 +0200
Introduce GSMTAP categories
When looking at GSMTAP output so far, one is easily overwhelmed by way
too much information being presented. A lot of is consists of DUMMY
frames, which are probably of lowest interest, ever.
A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by
which the user can configure which particular categories (uplink or
downlink control or data, gprs or egprs, ...) he actually wants to
see in his logs.
Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
-----------------------------------------------------------------------
hooks/post-receive
--
UNNAMED PROJECT
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Legacy: The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)".
The branch, pmaier/aoip2 has been updated
via e773bff7cea7ca8ac80055095396e5275ba2ee1e (commit)
via d93ee55ecfbf834ed71bdf830d5f1de5982d893a (commit)
via bce69325220f2af7cc0746611de30225263514d9 (commit)
via 067fbaf92216e8ad8037e6d2e372476cbafb6cec (commit)
from 4f451dc0a9865b676a1920bd1a632c213952e7ad (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openbsc/commit/?id=e773bff7cea7ca8ac80055095396e527…
commit e773bff7cea7ca8ac80055095396e5275ba2ee1e
Author: Philipp Maier <pmaier(a)sysmocom.de>
Date: Fri Jul 21 18:49:12 2017 +0200
gsm04_08.c patches from neels (remove when committed properly)
0001-imsi-detach-improve-error-logging.patch
0002-imsi-detach-always-close-connection-explicitly.patch
http://cgit.osmocom.org/openbsc/commit/?id=d93ee55ecfbf834ed71bdf830d5f1de5…
commit d93ee55ecfbf834ed71bdf830d5f1de5982d893a
Author: Philipp Maier <pmaier(a)sysmocom.de>
Date: Fri Jul 21 18:47:19 2017 +0200
a-iface: move clear command to subscriber_conn.c
The clear command is currently triggered from the wrong place.
This is a fixup that corrects that. However, it will introduce
another problem: The clear command is not sent on detatach.
http://cgit.osmocom.org/openbsc/commit/?id=bce69325220f2af7cc0746611de30225…
commit bce69325220f2af7cc0746611de30225263514d9
Author: Philipp Maier <pmaier(a)sysmocom.de>
Date: Fri Jul 21 18:38:36 2017 +0200
vty: Fixup sccp/ss7 configuration
The sccp/ss7 configuration is now fixed. The cs7 instance id is
implicitly detected from the bsc_addr or the msc_addr. Depending
on what is listed last. (I am not sure if that is wise, maybe
we should only use the local/bsc address to do the lookup).
Remove cs7-instance vty command
Modify VTY commands, so that the fixed API is used
Set msc->a.cs7_instance from the VTY to when msc/bsc addr is parsed
Fix the initalization to use osmo_sccp_simple_client_on_ss7_id() and
pass the cs7-instance id we determined from the vty.
The whole thing is not waterproof yet. We are still not at the
point where we allow to leave the local address out. This would
be fine, but when it is left out, the only way to determine the
cs7 instance is to use the msc_addr then.
We also might want to make sure to reach a state where all cs7
related config may be left out (like with the MSC)
http://cgit.osmocom.org/openbsc/commit/?id=067fbaf92216e8ad8037e6d2e372476c…
commit 067fbaf92216e8ad8037e6d2e372476cbafb6cec
Author: Philipp Maier <pmaier(a)sysmocom.de>
Date: Fri Jul 21 17:27:31 2017 +0200
fixup for: mgcp: display properly mgcp-messages in log
-----------------------------------------------------------------------
Summary of changes:
openbsc/include/openbsc/bsc_msc_data.h | 2 +-
openbsc/src/libmgcp/mgcp_protocol.c | 3 ++
openbsc/src/libmsc/gsm_04_08.c | 28 ++++++-------
openbsc/src/libmsc/osmo_msc.c | 4 --
openbsc/src/libmsc/subscr_conn.c | 7 ++++
openbsc/src/osmo-bsc/osmo_bsc_sigtran.c | 20 ++++++---
openbsc/src/osmo-bsc/osmo_bsc_vty.c | 73 ++++++++-------------------------
7 files changed, 56 insertions(+), 81 deletions(-)
hooks/post-receive
--
Legacy: The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Tools to centralize packet capture and storing".
The branch, laforge/ipip has been updated
discards 394e050d5405b74bce76d8e2bc1e8a148632f506 (commit)
via abc6dd83bc27da426f463919567784a44ed99fa7 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (394e050d5405b74bce76d8e2bc1e8a148632f506)
\
N -- N -- N (abc6dd83bc27da426f463919567784a44ed99fa7)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-pcap/commit/?id=abc6dd83bc27da426f463919567784…
commit abc6dd83bc27da426f463919567784a44ed99fa7
Author: Harald Welte <laforge(a)gnumonks.org>
Date: Fri Jul 21 18:12:01 2017 +0200
Add support for generating IPIP to osmo-pcap-client
This allows the user to change the configuration between either using
a) the classic OsmoPCAP protocol (over TCP with or without TLS)
which is used when you want to talk to an osmo-pcap-server
b) the (new) IPIP encapsulation, which will simply take the IP
packet (without Ethernet or pcap header) and transmit it inside IPIP
to the specified server IP address. This is useful for gettin
real-time streaming into wireshark.
Change-Id: I8056fc163ac2f15adcb964d867dd5e51df4e4710
-----------------------------------------------------------------------
Summary of changes:
src/osmo_client_network.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
hooks/post-receive
--
Tools to centralize packet capture and storing
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Tools to centralize packet capture and storing".
The branch, laforge/ipip has been updated
discards b147795a3ed4b42c3beb7539d52c84af5caba558 (commit)
via 394e050d5405b74bce76d8e2bc1e8a148632f506 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (b147795a3ed4b42c3beb7539d52c84af5caba558)
\
N -- N -- N (394e050d5405b74bce76d8e2bc1e8a148632f506)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/osmo-pcap/commit/?id=394e050d5405b74bce76d8e2bc1e8a…
commit 394e050d5405b74bce76d8e2bc1e8a148632f506
Author: Harald Welte <laforge(a)gnumonks.org>
Date: Fri Jul 21 18:12:01 2017 +0200
Add support for generating IPIP to osmo-pcap-client
This allows the user to change the configuration between either using
a) the classic OsmoPCAP protocol (over TCP with or without TLS)
which is used when you want to talk to an osmo-pcap-server
b) the (new) IPIP encapsulation, which will simply take the IP
packet (without Ethernet or pcap header) and transmit it inside IPIP
to the specified server IP address. This is useful for gettin
real-time streaming into wireshark.
Change-Id: I8056fc163ac2f15adcb964d867dd5e51df4e4710
-----------------------------------------------------------------------
Summary of changes:
src/osmo_client_network.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
hooks/post-receive
--
Tools to centralize packet capture and storing