| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Both LAC and TAC take 2 octets and follow MCC/MNC fields on the wire.
We abuse gsm48_encode_ra() for encoding of MCC/MNC, but it can also
be abused to encode TAC in bssgp_create_rim_ri(). There is no need
to encode '0000'O and then override it with osmo_store16be().
Change-Id: I986552aa52cf38b1c5290d2e5cd3ff2d1c36a4e5
|
|
Change-Id: Ifc3dda1fe5e9743072751dbb14c2d973388cb3b2
Fixes: CID#215836
|
|
Receive and forward RIM messages to bssgp_prim_cb()
Change-Id: Idfd0a65872a2cc6089885afd8d31b0b029d85d47
Related: SYS#5103
|
|
The RIM Routing Information IE (see also 3GPP TS 48.018, section
11.3.70) is used to control the flow of BSSGP rim messages at the SGSN.
Change-Id: I6f88a9aeeb50a612d32e9efd23040c9740bc4f11
Related: SYS#5103
|
|
osmo-pcu unit tests fail ue to this new log line. Let's rather simply
leave a comment there, since anyway known apps will be migrating soon
the new APIs.
Fixes: fde19ed579c3145959301bbe75fde15509276040
Change-Id: Ib9bf528db08f7aaa4adaf7b6a320679a4f11a53d
|
|
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
|
|
This is needed for osmo-gbproxy where we need more control over BSSGP.
Related: SYS#4998
Change-Id: Ifa769bce920a08cf93553dcb164a3fcf50162517
|
|
Change-Id: Id03ebef31bb513e2b3b5bc709a91e9352ebbbc79
|
|
Change-Id: I1cfccc2cb696d9e95f590b99559d0a987031adfe
|
|
Change-Id: Ic66f7e640cd473fa2c8473a3e91f57332ae9bf6a
|
|
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
|
|
This reverts commit d1ceca9d48eb3d8b212f386a1ebb35d8fc612297, 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
|
|
So far we had a function to allocate a new bssgp_bvc_ctx, but not
the opposite one. Let's finally introduce it, so it will be used
at least in OsmoPCU.
Please note that the new symbol has 'bssgp_' prefix, not 'btsctx_'.
Change-Id: Ia78979379dbdccd6e4628c16f00d0c06d9212172
|
|
Change-Id: I47d6623b9eca704e3c2537cfb5799a4c0749a7bc
Related: #3701
|
|
Handle NSEI the same way as BVCI is handled: assign it to variable
instead of repetitive calls to msgb_nsei() - this simplifies log update
in follow-up patches and makes code slightly easier to read.
Change-Id: I919a717ca22646849d6ec7f62c677c536db0ed31
|
|
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
|
|
To reset the state of BSSGP allow to flush the BSSGP queues.
When testing (with TTCN3) the test object should be resetted between
each test.
Introduce the functions:
bssgp_fc_flush_queue() - flushs a single flow control object
bssgp_flush_all_queues() - flushs queues of all BSSGP connections
Change-Id: I29b6ad6742ddf9b0b58b4af37d9a1cf18e019325
|
|
Return "invalid mandatory information" error status to
the sender in case bssgp_tlv_parse() failed.
To avoid loops, do not respond with an error status to
STATUS PDUs which failed parsing.
Change-Id: If73719b75a94d6742bdefc9b6572525cb00a96ee
Related: OS#3178
|
|
The return code from bssgp_tlv_parse() was not checked for a parsing
error. In case of a parsing error the stored return code could have
been overwritten later in this function.
Explicitly check for a parsing error and log corresponding packets.
Change-Id: Id3d7c52ec3df2bcf4efcee0e0b14fe22ef96964e
Related: OS#3178
|
|
Enable representing three-digit MNC with leading zeros. The MNCs 23 and 023 are
actually different; so far we treated both as 23. Re-encode an incoming BCD or
string of 023 as it were, i.e. not dropping the leading zero as 23.
Break ABI compatibility by changing the size and ordering of structs
gprs_ra_id, osmo_plmn_id, osmo_cell_global_id, ... by adding an mnc_3_digits
flag.
Change ordering in gprs_ra_id because the canonical oder is {Mobile Country
Code, Mobile Network Code}, so have the mcc member first.
ABI compatibility cannot be maintained for struct gprs_ra_id, since it is a
direct member of structs bssgp_bvc_ctx and bssgp_paging_info, and even just
adding a flag to the end would cause ABI changes of those structs. Similarly,
osmo_plmn_id is a direct member of osmo_location_area_id, and so forth.
Add new API to set and read this additional flag to preserve leading zeros:
- osmo_plmn_to_bcd(), osmo_plmn_from_bcd() after
gsm48_mcc_mnc_to_bcd() and gsm48_mcc_mnc_from_bcd().
- gsm48_decode_lai2(), gsm48_generate_lai2() after
gsm48_decode_lai(), gsm48_generate_lai().
- gsm0808_create_layer3_2() after gsm0808_create_layer3() and gsm0808_create_layer3_aoip().
- various osmo_*_name() functions in gsm23003.h (osmo_rai_name() still in
gsm48.h close to struct gprs_ra_id definition). The amount and duplication of
these may seem a bit overboard, but IMO they do make sense in this way.
Though most code will soon see patches unifying the data structures used, in
some cases (vty, ctrl) they are required singled out. Without these
functions, the formatting ("%0*u", mnc_3_digits ? 3 : 2, mnc) would be
duplicated all over our diverse repositories.
In various log output, include the leading MNC zeros.
Mark one TODO in card_fs_sim.c, I am not sure how to communicate a leading zero
to/from a SIM card FS. The focus here is on the core network / BSS.
To indicate ABI incompatibility, bump libosmogsm and libosmogb LIBVERSIONs;
adjust debian files accordingly.
Implementation choices:
- The default behavior upon zero-initialization will be the mnc_3_digits flag
set to false, which yields exactly the previous behavior.
- I decided against packing the mnc with the mnc_3_digits field into a
sub-struct because it would immediately break all builds of dependent
projects: it would require immediate merging of numerous patches in other
repositories, and it would make compiling older code against a newer
libosmocore unneccessarily hard.
Change-Id: Id2240f7f518494c9df6c8bda52c0d5092f90f221
|
|
Use bssgp_msgb_tlli_put() instead of copy-pasted code.
Change-Id: I06d60566a19dcae701f8648c19fbd8db6d586f77
|
|
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
|
|
All successful and all error code paths of bssgp_fc_in() free the msgb, except
the code path calling fc_enqueue() when the msg is dropped (due to queue being
full, or failure to allocate).
Callers could theoretically catch the -ENOSPC return value and discard the
msgb. However, in other code paths, a callback's return value is returned,
which is expected to free the msgb, so such callback would have to never return
-ENOSPC when it freed the msgb. Much simpler semantics would be to free the
msgb in every code path, no matter which kind of error occurred.
Who is currently calling bssgp_fc_in and how do they handle the return value?
- bssgp_fc_test.c ignores the return value (and hits a mem leak aka sanitizer
build failure if the queue is full).
- fc_timer_cb() ignores the return value.
- bssgp_tx_dl_ud() returns the bssgp_fc_in() rc.
- which is returned by a cascade of functions leading up to being returned,
for example, by gprs_llgmm_reset(), which is usually called with ignored
return code.
At this point it is already fairly clear that bssgp_fc_in() should always free
the msgb, since the callers don't seem to distinguish even between error or
success, let alone between -ENOSPC or other errors.
bssgp_fc_test: assert that no msgbs remain unfreed after the tests.
Adjust expected results.
Helps fix sanitizer build on debian 9.
Change-Id: I00c62a104baeaad6a85883c380259c469aebf0df
|
|
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
|
|
The rate_ctr.c code would do this mangling automatically, but let's
avoid using this from new versions of our code for
simplicity/explicitness.
Change-Id: I24a556f447cfac25efb6e83cac2d0c2972d98fe3
|
|
Change-Id: I9bf8f4dd784ccddbb9926492a85fff3293a0e913
Related: OS#1638
|
|
That's necessary for SGSN to properly handle BSS response to reset
procedure initiated by SGSN (foe example via 'bssgp bvc nsei 101 bvci 0
reset' command).
According to 3GPP TS 48.018 §8.4 "after performing the BVC Reset
procedure all affected BVCs are assumed to be unblocked at the SGSN" so
there's no need in any special handling.
Change-Id: I90dfbd0195a8403406429ccc746299d072445f7b
Related: OS#1638
|
|
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
|
|
Change-Id: I0c2aaf1ab462c923d62232f1a63fae1e4eb18b4d
|
|
Change-Id: I5ed17702cd9487e1cab6bae39802aa11fb6a37b0
|
|
Add a new function timer function to set up the timer, similar to what
we have in the Linux kernel. This patch also converts existing opencoded
timer setup in the libosmocore tree as initial client of this new
function.
This patch implicitly removes function callback passed by reference that
defeat compile time type validation.
Compile-tested only, but I ran make check that reports success when
testing timer infrastructure.
Change-Id: I2fa49972ecaab3748b25168b26d92034e9145666
|
|
My recent logging patch was merged to master a bit too soon. Accomodate the
request for naming that matches the general "LOG" prefix instead of "LOGGING".
libosmocore will not be backwards-compatible with the few commits from
change-id I5c343630020f4b108099696fd96c2111614c8067 up to this one. This and
following commits are backwards compatible with those before that short window.
See also:
* openbsc change-id Ib2ec5e4884aa90f48051ee2f832af557aa525991
* osmo-pcu change-id I4db4a668f2be07f3d55f848d38d1b490d8a7a685
Change-Id: I424fe3f12ea620338902b2bb8230544bde3f1a93
|
|
It is too easy for calling code to use the same filter and context indexes for
different filters and structs. For example, openbsc's IMSI filter and libgb's
GPRS_BVC filter both fall on index 1 even though there are plenty more indexes
to choose from. To alleviate this, have one central definition here, sort of
like ports.h does for VTY and CTRL port numbers.
Add static asserts to make sure the indexes fit in the available array and bit
mask space.
Calling code like openbsc.git and osmo-pcu need adjustments and/or should move
to using these enum values instead of their local definitions.
Taking this opportunity to also prepare for a split of struct gsm_subscriber in
openbsc into bsc_subsciber and vlr_subscriber with appropriate separate filter
index constants for both subscriber types.
Include previous LOG_FILTER_ALL in the LOGGING_FILTER_* enum, and replace its
use by (1 << LOGGING_FILTER_ALL).
Change-Id: I5c343630020f4b108099696fd96c2111614c8067
|
|
This allows feeding a custom time for unit tests by overriding
osmo_gettimeofday.
Change-Id: Ic7a81a6eb51f27fe452962b91f2eae2070d87089
|
|
gprs_bssgp.c:461:9: runtime error: load of misaligned address
0x62100001a66b for type 'uint32_t', which requires 4 byte alignment
gprs_ns.c:937:16: runtime error: load of misaligned address
0x61d00002a97f for type 'uint16_t', which requires 2 byte alignment
|
|
Print string representation of Cause IE and PDU type instead of
numerical value.
|
|
This commit adds class_id fields to the rate_ctr and stat_item group
descriptions. The stats reporter code is extended to only process
groups whose class_id does not exceed a per reporter max_class level.
If the class_id is not set, the code assumes 'global' for groups with
idx == 0 and 'subscriber' otherwise.
The following vty command is added to config-stats:
level (global|peer|subscriber) Set the maximum group level
Sponsored-by: On-Waves ehf
|
|
Currently the DL sometimes hangs and sometimes a lot of messages
(still not able to send PDU) are logged. This is caused by an invalid
timer delay computation, setting msecs either to 0 or to some big value.
This is due to an '&' operator at the wrong place, accessing some
parts in fc instead of the first element of the list.
This commit fixes that issue.
Sponsored-by: On-Waves ehf
|
|
Currently bssgp_rx_ptp might be called with bctx being NULL, when the
NS BVCI is neither BVCI_SIGNALLING nor BVCI_PTM, but the message is
a BVC_RESET or it contains an BVCI IE != BVCI_SIGNALLING where the
BVCI is not known.
This patch ensures that bssgp_rx_ptp will only be called with a
non-NULL bctx. A log message will be issued, if the bctx is NULL when
this was not expected.
Fixes: Coverity CID 1040674
Sponsored-by: On-Waves ehf
|
|
Currently the implementation of bssgp_tx_dl_ud conditionally adds
some optional IE if dup != NULL. Later on is dereferences dup to
access qos_profile and fc, but this without checking dup in advance.
This may lead to an segmentation violation fault.
This commit changes the value range of the function to only accept
dup != NULL. An assertion will fail otherwise. All other explicit
checks for non-NULL are removed.
Fixes: Coverity CID 1040673
Sponsored-by: On-Waves ehf
|
|
Currently incoming BSSGP STATUS messages are just logged and no other
action is taken. This makes it impossible for higher layers to react
to failures which are indicated by corresponding STATUS messages
unless a timeout is triggered as a result of that failure later on.
This commit adds a bssgp_rx_status() function and calls it on
incoming STATUS messages. That function logs a message, increments the
new BSSGP_CTR_STATUS counter if the bctx context exists and invokes
an NM_STATUS status indication. The latter will allow the application
to handle failures immediately. Since all STATUS messages should be
handled, the function is already called in bssgp_rcvmsg and the
message is no longer handled in (and will not reach) bssgp_rx_sign
and bssgp_rx_ptp.
Ticket: OW#1414
Sponsored-by: On-Waves ehf
|
|
Currently each incoming PtP BSSGP STATUS message is handled as 'not
yet implemented' and a BSSGP STATUS message (cause
BSSGP_CAUSE_PROTO_ERR_UNSPEC) is sent back to the peer. This will
cause endless messages loops if both peers use this BSSGP stack
implementation. This does not apply to signalling messages.
This commit changes the implementation of bssgp_rx_ptp() to just do
logging in this case.
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 sending SUSPEND/RESUME messages to this function (like it
is done in the osmo-sgsn) results in STATUS messages complaining
about an unknown BVCI. The reason is, that these messages rely on a
TLLI/RAI pair to identify the context and do not contain an explicit
BVCI.
This patch modifies bssgp_rcvmsg() to only complain about and unknown
BVCI if one is given but a matching context is not found (except for
RESET messages). The ctx argument is removed from the functions
handling SUSPEND and RESUME since it will always be NULL then.
Sponsored-by: On-Waves ehf
|
|
In the OsmoSGSN we have a crash with a DEAD/BLOCKED GPRS-NS and
segmented SN-UNITDATA. For the caller it is not easy to know if
the passed msg buffer has been freed or not. The most easy solution
is to always take the ownership and either pass it on or free it
in case of an error.
Adjust indirect and direct callers of gprs_ns_sendmsg. I found
the following call-chains with an external msgb parameter.
gprs_ns_sendmsg
<- _bssgp_tx_dl_ud
<- bssgp_fc_in
<- bssgp_tx_dl_ud
Update the test to allocate a real msgb because for the test with
'1000' we will msgb_free it right away.
Sponsored-by: On-Waves ehf
|
|
Currently BSSGP messages with an NS BVCI of 0 (signalling) are
discarded if they aren't RESET messages. Thus valid signalling
messages (e.g. BLOCK) are not handled properly, because the BVCI IE
is ignored if it present. Instead a STATUS message referring to BVCI
0 (instead of the BVCI used in the BLOCK message) is returned.
This patch changes the implementation to use the BVCI contained in
the BVCI IE if that is present in a signalling message.
It fixes BSSGP BLOCK/UNBLOCK for the osmo-sgsn.
Note that signalling messages without an BVCI IE (e.g.
SUSPEND/RESUME) are still rejected.
Ticket: OW#1205
Sponsored-by: On-Waves ehf
|
