gprs_bssgp and gprs_bssgp_util.c also contains code related to send and
receive RIM PDUs via BSSGP and also code to encode and decode RAN
INFORMATION PDUs. Lets move this to gprs_bssgp_rim.c
Change-Id: Icda279452962b06e552cb1361d2a27b7dc8a6b04
Related: SYS#5103
Whenever a RIM PDU is received, log to which RIM routing information
(address) it is going to and where it is comming from.
Change-Id: Ia08d3b162a4f6257cccaa7f0764fa7ea498355ef
Related: SYS#5103
At the moment libosmogb offers no convinient way to send RIM PDUs. Also
parsing an incoming RIM messages into destination, source routing
info and RIM container is not available.
Change-Id: I18134fd9938040d2facb6beee3732628b167ce8c
Related: SYS#5103
Historically, BSSGP uses a non-constant, user-configurable integer
varieable for the logging sub-system. Let's replace this with a
statically-allocated library logging constant.
This is required if we want to use the subsystem number in e.g.
static initialized for osmo_fsm.log_subsys.
Change-Id: I506190aae9217c0956e4b5764d1a0c0772268e93
In I7da8b25c9a89a7e3ae6c1680ba838e136d7d5293 we introduced the enum
values for all the new BSSGP message types up to Release 15. Let's
also add value_strings for them here.
Change-Id: Ia108ba0d5f1f2c9d46f0c0bd11cd93104b9d62ea
Add bssgp_ns_send callback() to set the transmission path into the
NS library. This allows to use the Gb implementation with
the old NS and the new upcoming NS implementation.
Users of the old NS implementation don't have to set the callback as
the default is the old NS implementation.
Only users of the new NS implementation need to set the callback and
the callback data.
Change-Id: I3a498e6a0d68b87fed80c64199b22395796761b4
Let's fix some erroneous/accidential references to wrong license,
update copyright information where applicable and introduce a
SPDX-License-Identifier to all files.
Change-Id: I39af26c6aaaf5c926966391f6565fc5936be21af
Considering the various styles and implications found in the sources, edit
scores of files to follow the same API doc guidelines around the doxygen
grouping and the \file tag.
Many files now show a short description in the generated API doc that was so
far only available as C comment.
The guidelines and reasoning behind it is documented at
https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation
In some instances, remove file comments and add to the corresponding group
instead, to be shared among several files (e.g. bitvec).
Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
This function originates from openbsc/src/gprs but is just specific
to BSSGP/Gb on the same level like bssgp_msgb_alloc.
This commit puts the former gprs_msgb_copy function beside
bssgp_msgb_alloc.
Renamed function:
gprs_msgb_copy -> bssgp_msgb_copy
Sponsored-by: On-Waves ehf
Currently out-of-memory is not handled by bssgp_msgb_alloc, leading
to SEGV failures if msgb_alloc_headroom returns NULL.
This commit adds an OSMO_ASSERT to catch this case, which improves
the situation only slightly. But bssgp_msgb_alloc is used in many
places without checking the return value, so just adding a
conditional early NULL return would not fix the issue either.
Fixes: Coverity CID 1293377
Sponsored-by: On-Waves ehf
The copyright holders Harald Welte, Holger Freyther, Andreas Eversberg
and sysmocom - s.f.m.c. GmbH (represented by Holger and Harald) agree
that the license of libosmogb should be GPLv2+ and not AGPLv3+.
The reason the source files stated AGPLv3+ is due to the history, as
they were moved from OpenBSC to libosmocore at the time we needed to use
them from osmo-pcu. It was an oversight back then to not re-license
them accordingly.
Currently the bssgph field is not set when using the bssgp_tx_*
functions. This hinders unit testing of generated messages.
This patch initializes the bssgph field directly after allocation a
new bssgp msgb in bssgp_msgb_alloc() so that it is set by default.
Sponsored-by: On-Waves ehf
Currently the BVCI is not set in all invocations to bssgp_tx_status()
when the cause is UNKNOWN_BVCI.
This patch adds the argument where it is missing.
It also adds a check for compliance (GSM 08.18, 10.4.14.1) to
bssgp_tx_status() to emit errors when the following requirement is
not fulfilled: The BVCI must be included if (and only if) the cause
is either "BVCI blocked" or "BVCI unknown".
Sponsored-by: On-Waves ehf