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
With TLVP_PRESENT we only check if a given TLV/IE is present,
but don't verify that it's length matches our expectation. This can
lead to out-of-bounds reads, so let's always use TLVP_PRES_LEN.
Change-Id: I56e8b31ce51602d2681e3db501c48f84bfe7e438
3GPP TS 48.018 is quite clear: The RA-ID must only be included
when a PTP-BVCI is being reset [and only if the sender is the BSS].
Before this patch, osmo-pcu is including the RA-ID in BVC-RESET
for BVCI=0.
Change-Id: Ie87820537d6d616da4fd4bbf73eab06e28fda5e1
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
If a BVC-RESET is sent from SGSN, there must not be a cell ID IE
included. See "Note 1" of TS 48.018 Section 10.4.12.
Change-Id: I11d4e70d510265b9c09dffccdab10b3f0816715a
This reverts commit d1ceca9d48, as it
introduces regressions in both osmo-msc and osmo-nitb which have been
causing failing builds for several days now.
Change-Id: I4bd958d0cd2ab4b0c4725e6d114f4404d725fcf7
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for all osmo programs, completely replacing the Mobile
Identity coding with this new API. Hence deprecate the old MI API.
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
Change-Id: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
gcc-9.2.1 issues the following errror when compiling with -Werror:
In function ‘tl16v_put’,
inlined from ‘tvlv_put’ at ../../include/osmocom/gsm/tlv.h:156:9,
inlined from ‘tvlv_put’ at ../../include/osmocom/gsm/tlv.h:147:24,
inlined from ‘msgb_tvlv_put’ at ../../include/osmocom/gsm/tlv.h:223:9,
inlined from ‘bssgp_tx_paging’ at gprs_bssgp.c:1250:2:
../../include/osmocom/gsm/tlv.h:131:2: error: ‘memcpy’ reading between 128 and 65535 bytes from a region of size 9 [-Werror=stringop-overflow=]
131 | memcpy(buf, val, len);
| ^~~~~~~~~~~~~~~~~~~~~
Unfortunately I've not been able to work around it with some nice GCC
#pragma GCC diagnostic ignored "-Wstringop-overflow"
Change-Id: I22a0c399c6c00eaf87277002096a82844c9e198e
gcc-8.2 is printing the following warning, which is an error
when used -Werror like our --enable-werror:
In file included from gprs_bssgp.c:34:
In function ‘tl16v_put’,
inlined from ‘tvlv_put.part.3’ at ../../include/osmocom/gsm/tlv.h:156:9,
inlined from ‘tvlv_put’ at ../../include/osmocom/gsm/tlv.h:147:24,
inlined from ‘msgb_tvlv_push’ at ../../include/osmocom/gsm/tlv.h:386:2,
inlined from ‘bssgp_tx_dl_ud’ at gprs_bssgp.c:1162:4:
../../include/osmocom/gsm/tlv.h:131:2: error: ‘memcpy’ forming offset [12, 130] is out of the bounds [0, 11] of object ‘mi’ with type ‘uint8_t[11]’ {aka ‘unsigned char[11]’} [-Werror=array-bounds]
memcpy(buf, val, len);
Where "130" seems to be the maximum value of uint8_t, shifted right one +
2. But even as we use strnlen() with "16" as maximum upper bound, gcc
still believes there's a way that the return value of gsm48_generate_mid_from_imsi()
could be 130. In fact, even the newly-added OSMO_ASSERT() inside
gsm48_generate_mid() doesn't help and gcc still insists there is a problem :(
Change-Id: I0a06daa19b7b5b5badbb8b3d81a54c45b88a60ec
The longest BCd-digit type identity is the IMEISV with 16, so there's
no point in trying to parse up to 255 decimal digits, which will do
nothing but to overflow the caller-provided output buffer.
Let's also clearly define the required minimum size of the output
buffer and add a reltead #define for it.
Change-Id: Ic8488bc7f77dc9182e372741b88f0f06100dddc9
Add gsm48_encode_ra() which takes appropriate struct as [out] parameter
instead of generic buffer. Using uint8_t buffer instead of proper struct
type prooved to be error-prone - see Coverity CID57877, CID57876.
Old gsm48_construct_ra() is made into tiny wrapper around new
function. The test output is adjusted because of the change in function
return value which was constant and hence ignored anyway.
Related: OS#1640
Change-Id: I31f9605277f4945f207c2c44ff82e62399f8db74
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
Especially for short descriptions, it is annoying to have to type \brief for
every single API doc.
Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes
the first sentence of an API doc as the brief description.
Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
This was actually discovered by the following compiler warning in
gcc-6.2.0:
CC gprs_bssgp_bss.lo
gprs_bssgp_bss.c: In function ‘bssgp_rx_paging’:
gprs_bssgp_bss.c:544:2: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
if (TLVP_PRESENT(&tp, BSSGP_IE_TMSI) &&
^~
gprs_bssgp_bss.c:548:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
*(pinfo->ptmsi) = ntohl(*(uint32_t *)
^
This is an actual bug. If we recevied a BSSGP Paging Request without
P-TMSI, we might crash or report some random memory as P-TMSI to the
caller in the output data structure.
Change-Id: Ib4f307827cd7cccc91c1415a6fb5428d7cf8416d
Currently the size of the IMSI pointer is used instead of the size of
the talloc'ed buffer.
This commit changes the call to gsm48_mi_to_string to use the same
value that has been used with talloc_zero_size(). The length is
changed to 17 since that value is used for GSM_IMSI_LENGTH in
openbsc.
Fixes: Coverity CID 1040663
Sponsored-by: On-Waves ehf
Currently large values for Bmax default MS get sliced since a uint16_t is
used as the type of the corresponding parameter of bssgp_tx_fc_bvc.
GSM 48.018, 11.3.2 which in turn refers to 11.3.5 specifies a maximum
of 6MB (0xffff * 100).
This commit changes the type to uint32_t to cover the full value
range.
Sponsored-by: On-Waves ehf
Currently all 2 byte IE of the message are transmitted in the little
endian byte ordering.
This commit adds htons to the encoding expressions.
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.
This is a 24bit integer value, and thus we need to encode the three
least significant octets of the network-byte-order 32bit value, not the
three most significant octets.
Pau Espin
Harald Welte
Daniel Willmann
Alexander Couzens
Neels Hofmeyr