| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
A common function to append the nsvc state from osmo-sgsn or osmo-gbproxy
Change-Id: I7f0eaff7329ab98cad792d30b20ab053007aab85
|
|
|
|
|
|
|
|
| |
This function can be used to resolve the error message type for
a given message type. Can be used by generic error handlers that
work for any incoming message type.
Change-Id: Ic637bec53dd7fe3ec83da99b49b4eae34d5602b2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function can be used when there is only a part of GSM 04.80
message available - Facility IE, e.g. when a message is carried
over GSUP/MAP. Let's expose it.
Refactoring includes the following:
- adding the 'gsm0480_' prefix;
- correcting inverted return value;
- cosmetic code style changes.
Change-Id: I623c39ffbe6cdee65eade8435a2faa04d0da193e
|
|
|
|
|
|
|
|
| |
In some cases, there is no need to parse the whole message,
e.g. during the conversion from DTAP to GSUP/MAP. This
function can be used to extract given IE from a message.
Change-Id: I3989d061903352473305f80712f1a1560d05df3d
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function permits the user to register deprecated log categories,
which will ensure that if log categories are removed from a program,
old config files will still load.
We simply dynamically allocate a cmd_element and install it at
CFG_LOG_NODE. Not registering it at VIEW_NODE or ENABLE_NODE
ensures that it's not accessible from the interactive VTY, but only
from the config file / configure node.
Change-Id: I171f62ea2dc565b3a6c3eecd27fb7853e2529598
|
|
|
|
|
|
|
| |
we don't want to include deprecated commands in our VTY reference
manuals.
Change-Id: I5e179c9dca297b8c4bdbdf4e0e5b1d69eecc4232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The general idea about each osmo_fsm_instance having a separate
log-level was to be able to selectively increase/show/enable logging
for some FSM instances (e.g. of a particular subscriber) while
maintaining normal logging verbosity for all other instances of the
same FSM.
The introduction of LOGPFSML() in Change-Id
If295fdabb3f31a0fd9490d1e0df57794c75ae547 broke that idea, as it would
use a compile-time log level, irrespective of the
osmo_fsm_inst.log_level setting of the given instance.
Let's combine the two:
Use the explicit level stated at LOGPFSML(), _unless_ this instance
has a higher log_level configured.
This way, all FSMs should normally be created with
osmo_fsm_inst.log_level == LOGL_DEBUG. At that point LOGPFSM()
statements would be rendered at debug level, typically below the
threshold of most logging configurations.
Code that has explicit higher log levels like LOGPFSML(fi, LOGL_ERROR)
would always be printed, as it is an error message.
And if we now increase the osmo_fsm_inst.log_level, then even the normal
LOGPFSM() statements would suddenly be logged at that higher level,
selectively increasing log verbosity - like originally intended.
Change-Id: I1820f04d0c6f5d5ff08eb95b8c0e88764534491a
|
|
|
|
| |
Change-Id: Icca23940791f97fa64dbc3f2734270b99f9550c1
|
|
|
|
| |
Change-Id: I2b96db6e037e72e92317fec874877e473a1cf909
|
|
|
|
| |
Change-Id: Ia888d14c6e1f76374addd9b1ee66523f82fc06c9
|
|
|
|
|
|
| |
This is a combination of TLVP_VAP() and TLVP_GET_MINLEN()
Change-Id: Ic5a177941219ebc3a3bceb3f68bdb3b2cacb934b
|
|
|
|
| |
Change-Id: I18d7a29496929c761aeaba9c0aee847befc13108
|
|
|
|
| |
Change-Id: I3c0e53b846b2208bd201ace99777f2286ea39ae8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to be able to transfer SS/USSD messages via GSUP,
this change introduces the following new message types:
- OSMO_GSUP_MSGT_PROC_SS_*,
and the following new IE:
- OSMO_GSUP_SS_INFO_IE
which represents an ASN.1 encoded MAP payload coming to/from
the mobile station 'as is', without any transcoding.
Change-Id: Ie17a78043a35fffbdd59e80fd2b2da39cce5e532
Related: OS#1597
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike TCAP/MAP, GSUP is just a transport layer without the
dialogue/context. This prevents us from having session based
communication, required e.g. for USSD. But we can emulate
TCAP dialogue by adding additional IEs, which would allow
to relate each message to a particular session.
This change introduces the following IEs:
- OSMO_GSUP_SESSION_ID_IE,
- OSMO_GSUP_SESSION_STATE_IE,
which optionally can be used to indicate that the message is
related to a session with given ID, and to manage session
state, i.e. initiate, continue, and finish.
Change-Id: I1cee271fed0284a134ffed103c0d4bebbcfde2a8
Related: OS#1597
|
|
|
|
| |
Change-Id: Ib83143e467df068b7d462a8e51d94b9d961ce18f
|
|
|
|
| |
Change-Id: I775aba59942fb6f34fb31b71d2f0f2ac5c3ae831
|
|
|
|
|
|
|
|
|
|
|
| |
According to the 3GPP TS 04.80, table 2.5 'Release complete', a
RELEASE_COMPLETE message may containg optional FACILITY element.
Meanwhile, the 0xff byte is used to indicate that there is no
decoded message (legacy field). Let's avoid overwriting of
a decoded message.
Change-Id: I0c85292222749a48ca0c4b2e93f4fa2d61468c18
|
|
|
|
| |
Change-Id: I46a1cef3013c9bbf9b5a6d64e83cd84568f2523c
|
|
|
|
|
|
| |
This fixes the debian package builds for libosmocore.git
Change-Id: I454e3c0175ab5a89e8925e036a3644299367df0f
|
|
|
|
|
|
|
| |
From GSM 04.08
Section 10.5.4.21 / Table 10.5.127
Change-Id: I6574e8808aaf39fad8026290aa2cc657734e18b5
|
|
|
|
|
| |
Related: OS#2283 (inter-BSC Handover, BSC side, MT)
Change-Id: I692292a06c7d66004404560dc4ed933ca9107f9b
|
|
|
|
|
| |
Related: OS#2283 (inter-BSC Handover, BSC side, MO)
Change-Id: Idb6dc3eab0282158a17091d97ed77c1e2e3eb3c2
|
|
|
|
|
|
|
|
| |
The idea is to be able to add a gsm0808_cell_id to a gsm0808_cell_id_list2:
first convert it to a list, then re-use gsm0808_cell_id_list_add(). It will be
used by osmo-bsc to manage neighbor-BSS cell identifiers from VTY.
Change-Id: Ibf746ac60b1b1e920baf494b396658a5ceabd788
|
|
|
|
|
| |
Closes: OS#3293
Change-Id: I8dc2f24d4bf557ff7bb0f2f46881f9f8d9d7f86f
|
|
|
|
|
|
|
|
| |
There are some symbols for use between control_cmd.c and control_if.c,
which are not supposed to be exported publicly. Let's make sure we
keep those symbols local.
Change-Id: Ia85f36a9c4b2ebf4003718e0a230959638370320
|
|
|
|
| |
Change-Id: I24666d0b90a355e9fdefd280d48900b8cac1de64
|
|
|
|
| |
Change-Id: I3d9c8e117ad19f70a3273650d7c0f8280d7bdb9a
|
|
|
|
|
|
| |
Change-Id: Iff5699be1dc306120cc1752b0a892e4fcbc5a8c0
Fixes: 97d3da2c591984b47839fd1d9a5cba24a7f05fa1
Related: OS#3245
|
|
|
|
|
|
|
|
|
| |
Add a new VTY command which shows all rate counters registered
with libosmocore.
Change-Id: Id60a5aa2d961ae99cddf1e776358a5517dbc573d
Depends: Idb3ec12494ff6a3a05efcc8818e78d1baa6546bd
Related: OS#3245
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new function can be used to print a rate counter group according
to a format string. The intention is to generalize and replace manual
printing of counters as implemented for the 'show statistics' VTY
command of osmo-bsc.
Related: OS#3245
Related: osmo-bsc commit 71d524c059c5a5c90e7cb77d8a2134c1c68b9cde (g#9217)
Change-Id: Idb3ec12494ff6a3a05efcc8818e78d1baa6546bd
|
|
|
|
|
|
|
| |
For some strange reason, the osmo_mncc_name() inline function
was not in the mncc.h header, but in the mncc.c file. Let's fix that.
Change-Id: I2c3666510c981dffa4ba25bed517fd7ebd1250f5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of 64 bits
Fixes following AddressSanitizer report during gea_test run with gcc
8.1.0:
==8899==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc5f1719bb at pc 0x7fe574adc5fe bp 0x7ffc5f171460 sp 0x7ffc5f171450
WRITE of size 1 at 0x7ffc5f1719bb thread T0
#0 0x7fe574adc5fd in osmo_store64be_ext ../../include/osmocom/core/bit64gen.h:75
#1 0x7fe574adc649 in osmo_store64be ../../include/osmocom/core/bit64gen.h:104
#2 0x7fe574ade936 in _kasumi_kgcore libosmocore/src/gsm/kasumi.c:186
#3 0x7fe574ae2532 in gea4 libosmocore/src/gsm/gea.c:44
#4 0x7fe574ae266c in gea3 libosmocore/src/gsm/gea.c:60
#5 0x7fe574a9b616 in gprs_cipher_run libosmocore/src/gsm/gprs_cipher_core.c:95
#6 0x56422d3fb2ee in test_gea libosmocore/tests/gea/gea_test.c:29
#7 0x56422d3fb506 in main libosmocore/tests/gea/gea_test.c:49
#8 0x7fe5730f406a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#9 0x56422d3fadf9 in _start (libosmocore/tests/gea/.libs/lt-gea_test+0x1df9)
The kasumi_test is updated to calculate the entire array of bits
according to expected result. Before this commit it worked by writing
the entire last 64bit block, and addressSanitizer cannot catch it
because the allocated buffer is 64bit aligned too.
Change-Id: I7b2a0224a3b5527d5a3ad7e17efc73081b63eac1
|
|
|
|
|
|
|
|
| |
Before this patch, osmo_hexdump is called stacked in th esame printf
function. As a result, the first returned buffer is overwriten by the
second, which means the printed buffers will show as the same always.
Change-Id: I364328a59da31537c6c9b969e34edd360b685081
|
|
|
|
|
|
| |
Expect key sizes for GEA are 64-128 bits.
Change-Id: Iaf81992a2901733b630e3046b0c4bdc1fb9a8ace
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes following AddressSanitizer report:
==1983==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc245f47e6 at pc 0x7f3e2deea68c bp 0x7ffc245f4750 sp 0x7ffc245f4740
WRITE of size 1 at 0x7ffc245f47e6 thread T0
#0 0x7f3e2deea68b in osmo_nibble_shift_right libosmocore/src/bits.c:92
#1 0x55c01902e1ab in sh_chk libosmocore/tests/bits/bitrev_test.c:215
#2 0x55c01902ed8f in main libosmocore/tests/bits/bitrev_test.c:305
#3 0x7f3e2c93006a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#4 0x55c01902c059 in _start (libosmocore/tests/bits/.libs/lt-bitrev_test+0x5059)
This patch can be seen as a follow-up of commit
4fd6023b0383e7efa3b7b0211104a86ff5d3d4f6, which already fixed the
left-shift case in the same way.
Change-Id: I6e86d0164b7e982bf7b7449d5b3abfb3e1e5da46
|
|
|
|
| |
Change-Id: I3ac92217f83279d5f987ab34eb18b2e6cb1c7812
|
|
|
|
|
|
|
|
|
|
|
| |
The FSM allows to set individual action callback functions for each
state but it does not allow to leave the action callback pointer
unpopulated. However, there are cornercases where having no callback
function is desirable.
- Check if action callback is popolated before executing it.
Change-Id: I36d221c973d3890721ef1d376fb9be82c4311378
|
|
|
|
|
|
|
|
|
|
|
| |
* prefix all symbols/constants with osmo_
* use stdint.h types instead of kernel types
* use Doxygen API documentation
* use Osmocom CRC16-CCITT functions
* use Osmocom bit-reversal functions
* integrate with Automake
Change-Id: I109085ab3e412c20b19cd42fb7137aa0e4167542
|
|
|
|
|
|
|
| |
I've been importing from 94d7dbf108813ea45a91e27e9a8bd231d5a23fa7
but the isdnhdlc code hasn't seen any changes since 2012 anyway.
Change-Id: I3c58f9cb6921c2fdd0f2fcb11f622a0be88c7c63
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux offers file descriptor based periodic (interval) timers,
which can achieve a higher precision than our userspace based
timers and which can be slave'd to CLOCK_MONOTINIC or other clock
sources. Let's add some code for osmo_fd wrapped versions that
integrate well with our select() abstraction.
The code has been used in osmo-bts-trx since June 2017 (change-id
I51b19adde14ebb7ef3bb863d45e06243c323e22e), and I'm just renaming
and moving it to libosmocore here. After a merge, the osmo-bts
implementations can be removed in favor if this one.
Change-Id: Ibeffba7c997252c003723bcd5d14122c4ded2fe7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Change-Id: I8c2c103cdc7f9a45d7b2080c572f559fc3db58e4 we introduced
a check to enforce contention resolution always being used in
MS-originated LAPDm establishment on the main DCCH / SAPI0. This is
only required after RACH request (IMM.ASS.) and not after a normal
assignment command which was sent already via a dedicated channel.
Hence, we cannot enforce a strict requirement for contention resolution
in those cases.
We *could* use the RSL Channel Activation type as a constraint on
whether or not to enforce contention-resoluiton-only LAPDm
establishment, but this is out of the scope of the LAPDm code but would
have to be done inside OsmoBTS.
Related: OS#3252
Change-Id: Id903492ee90809fe98defcf4abc0419b8150069f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The RSL_IE_MS_POWER / RSL_IE_TIMING_ADVANCE is how we communicate
the SACCH L1 header values on the MS side between LAPDm and L3 (which
is a non-standard use of RSL).
However, those IEs only maek sense on the SACCH, where we have B4 frame
format and where we actually have a L1 header containing related
information. Let's make sure to skip those IEs on regular RLL UNIT DATA
INDICATION happening on other channel types.
Change-Id: I6f13e02192531479287f71de674d17ca2ceabdc6
Closes: OS#3249
|
|
|
|
|
|
|
|
| |
This is a purely cosmetic clean-up to use the msgb_tv_push() API
to pre-pend a Tag-Value IE to a msgb, rather than the existing
open-coding approach.
Change-Id: I19bbfa1e327a617685ed11d4182e533df33215cb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add:
- gsm0808_current_channel_type_1()
- gsm0808_permitted_speech()
- gsm0808_chosen_channel()
- gsm0808_channel_type_name()
gsm0808_permitted_speech() is moved from osmo-bsc's bssap_speech_from_lchan();
gsm0808_chosen_channel() is moved from osmo-bsc's lchan_to_chosen_channel();
Rationale: will be re-used by inter-BSC handover, makes sense to keep with the
other gsm0808 utils.
Related: OS#2283 (inter-BSC handover, BSC side)
Change-Id: I8a3cc5d4548e9a78d945d54c69ccced251edcec9
|
|
|
|
|
|
|
|
|
|
| |
* MO SAPI0 establishment *must always* have L3 payload for contention
resolution
* SAPI3 establishment *must never* use contention resolution
* MT establish must never use contention resolution
Change-Id: I8c2c103cdc7f9a45d7b2080c572f559fc3db58e4
Closes: OS#2370
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to TS 24.008 10.5.4.7 the called party BSC number IE
has a maximum length of 43 octets.
This length is assumed inside osmo-hlr with a magic number:
uint8_t msisdn_enc[43]; /* TODO use constant; TS 24.008 10.5.4.7 */
This change makes libosmocore provide a constant which osmo-hlr can use.
Change-Id: Ia0bf6ceadcac38a8c75d166402b54058e5c6c6d4
|
|
|
|
|
|
|
|
| |
It seems that during all those years it has never been noted that
the back-pointer from the lapdm_entity to the lapdm_channel was
never initialized. Let's fix that.
Change-Id: Iaca66cd6a2c9f315561e365b51163927868fc346
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the library probiding dlopen is not the same one providing
dlsym.
This is the case when compiling with AddressSanitizer enabled. In this
case, AC_SEARCH_LIBS([dlopen]...) reports no lib is required, but tests
using dlsym still require to link against -ldl.
Change-Id: Ic619b0885688066b60c97caf1e2c7e5402c1d9f7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imagine following scenario:
1- client connects to CTRL iface, a new conn is created with POLL_READ
enabled.
2- A non-related event happens which triggers a TRAP to be sent. As a
result, the wqueue for the conn has now enabled POLL_WRITE, and message
will be sent next time we go through osmo_main_select().
3- At the same time, we receive the GET cmd from the CTRL client, which
means POLL_READ event will be also triggered next time we call
osmo_main_select().
4- osmo_main_select triggers osmo_wqueue_bfd_cb with both READ/WRITE
flags set.
5- The read_cb of wqueue is executed first. The handler closes the CTRL
conn for some reason, freeing the osmo_fd struct and returns.
6- osmo_qeueue_bfd_cb keeps using the already freed osmo_fd and calls
write_cb.
So in step 6 we get a heap-use-after-free catched by AddressSanitizer:
[0;m20180424135406115 [1;32mDLCTRL[0;m <0018> control_if.c:506 accept()ed new CTRL connection from (r=10.42.42.1:53910<->l=10.42.42.7:4249)
[0;m20180424135406116 [1;34mDLCTRL[0;m <0018> control_cmd.c:378 Command: GET bts.0.oml-connection-state
[0;m20180424135406117 [1;34mDLINP[0;m <0013> bts_ipaccess_nanobts.c:417 Identified BTS 1/0/0
[0;m[1;36m20180424135406118 [1;34mDNM[0;m[1;36m <0005> abis_nm.c:1628 Get Attr (bts=0)
[0;m[1;36m20180424135406118 [1;34mDNM[0;m[1;36m <0005> abis_nm.c:1628 Get Attr (bts=0)
[0;m20180424135406118 [1;34mDCTRL[0;m <000e> osmo_bsc_ctrl.c:158 BTS connection (re)established, sending TRAP.
[0;m20180424135406119 [1;32mDLCTRL[0;m <0018> control_if.c:173 close()d CTRL connection (r=10.42.42.1:53910<->l=10.42.42.7:4249)
[0;m=================================================================
==12301==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000003e04 at pc 0x7f23091c3a2f bp 0x7ffc0cb73ff0 sp 0x7ffc0cb73fe8
READ of size 4 at 0x611000003e04 thread T0
#0 0x7f23091c3a2e in osmo_wqueue_bfd_cb /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bsc/libosmocore/src/write_queue.c:65
#1 0x7f23091ad5d8 in osmo_fd_disp_fds /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bsc/libosmocore/src/select.c:216
#2 0x7f23091ad5d8 in osmo_select_main /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bsc/libosmocore/src/select.c:256
#3 0x56538bdb7a26 in main /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bsc/osmo-bsc/src/osmo-bsc/osmo_bsc_main.c:532
#4 0x7f23077532e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#5 0x56538bdb8999 in _start (/home/jenkins/workspace/osmo-gsm-tester_run-prod/trial-896/inst/osmo-bsc/bin/osmo-bsc+0x259999)
Fixes: OS#3206
Change-Id: I84d10caaadcfa6bd46ba8756ca89aa0badcfd2e3
|