OSMO_GSUP_SUPPORTED_RAT_TYPES_IE corresponds to the Supported RAT Types
Indicator from 3GPP TS 29.002. See 8.1.2 MAP_UPDATE_LOCATION service,
which indicates the capabilities of the MSC/VLR to the HLR.
So far, have room for eight RAT types in the gsup_msg. That is an arbitrary
random choice without any rationale.
OSMO_GSUP_CURRENT_RAT_TYPE_IE is useful to communicate the currently
used RAN / RAT type of the current subscriber during Location Updating Request.
Change-Id: I93850710ab55a605bf61b95063a69682a2899bb1
We first set the ISTRIP bit only to remove it in the next line.
Let's try to avoid confusing the reader.
Change-Id: Icba43dd4b6dc4f9c7f8fcf91d24b3baac4e0c74a
I missed code review, so here are my comments in form of a follow-up patch
for Id56a1226d724a374f04231df85fe5b49ffd2c43c.
- Fix 'as_unit' arg name to 'val_unit' as in the C file and API doc.
- Explain rounding-up behavior of value conversion in API doc.
- Use osmo_tdef_get_entry() instead of a loop.
Related: OS#4190
Change-Id: Ia91c2f17e40fb9e79ffa5a7f28ce9c3605664402
This API is already useful for users willing to set a given timer to a
given value. It will also contain code later that checks for value being
inside valid range for that timer.
Related: OS#4190
Change-Id: Id56a1226d724a374f04231df85fe5b49ffd2c43c
As 3GPP doesn't specify how the BSC shall communicate ETWS Primary
Notifications over Abis/RSL, we have to use a vendor-specific RSL
message for this. And in order to know if the peer supports this
feature, we introduces BTS_FEAT_ETWS_PN.
Change-Id: I89c24a81ada6627694a9632e87485a61cbd3e680
Related: OS#4046, OS#4047
We don't want to expose the details of a given ECU implementation to
the user (e.g. osmo-bts), but have a generic abstraction layer where
an ECU implementation can simply register a few call-back functions
with the generic core.
As the developer and copyright holder of the related code, I hereby
state that any ECU implementation using 'struct osmo_ecu_ops' and
registering with the 'osmo_ecu_register()' function shall not be
considered as a derivative work under any applicable copyright law;
the copyleft terms of GPLv2 shall hence not apply to any such ECU
implementation.
The intent of the above exception is to allow anyone to combine
third party Error Concealment Unit implementations with libosmocore,
including but not limited to such published by ETSI.
Change-Id: I4d33c9c7c2d4c7462ff38a49c178b65accae1915
The user length is the first IE *in* the fixed-length TV, make sure
cbsp_dec_write_repl() respects that.
Change-Id: I864cafac2466a89a4bd9644bc73363fff2babd03
The CBSP code assumed that gsm0808_decode_cell_id_u() would return
the number of bytes it has consumed/parsed. But it actually always
returns '0', whcih makes us run in an endless loop :(
Change-Id: I5758af4ec11a827d4b888a3a16c4ec22de90a7d6
When a VTY closes, dispatch the VTY_CLOSED signal before tearing down the VTY
buffer and fd.
In particular this fixes:
- a crash during telnet_close_client(), invoked by the VTY_CLOSED event, which
logs to DLGLOBAL and uses vty->obuf that, so far, vty_close() had already
unallocated earlier (OS#4164).
- the logging about closing a telnet session so far logged:
DLGLOBAL INFO Closing telnet connection r=NULL<->l=NULL
By dispatching the VTY_CLOSED event while the fd is still valid, we instead
get the actual connection IP address and port being closed:
DLGLOBAL INFO Closing telnet connection r=127.0.0.1:36708<->l=127.0.0.1:4258
Related: OS#4164
Change-Id: I1d235cbfbfb9aaf411316642c7bcfac12106df44
Rather than having applications maintain their own talloc cotexts,
let's offer some root talloc contexts in libosmocore. Let's also
make them per thread right from the beginning. This will help
some multi-threaded applications to use talloc in a thread-safe
way.
Change-Id: Iae39cd57274bf6753ecaf186f229e582b42662e3
This way it's easier by osmo_verify_transcript_vty.py to skip and avoid
breaking existent test in osmo-hlr.
Fixes: d0b3b9edac
Change-Id: Iab9423661e4f4eefca2e3d02b60a43f913ed92a3
The intention of osmo_tdef_get()'s val_if_not_present argument was to return a
default timeout, or to optionally abort the program for missing timer
definitions if the default timeout is < 0. This was the case in the original
implementation of this API in osmo-bsc, but in the migration to libosmocore,
the argument was by accident changed to an unsigned type. In consequence, the
assertion in the implementation that was intended to abort the program seemed
bogus to coverity, and was fixed by removal in
I7a544d2d43b83135def296674f777e48fe5fd80a -- the wrong direction, as is obvious
from the API doc for osmo_tdef_get().
Note that osmo-bsc master passes -1 in various places and expects the
program-abort behavior that was missing from the libosmocore implementation.
Change the val_if_not_present argument to a signed type, and revert removal of
the assertion, so that passing -1 has the effect described in the API doc:
program abort on missing timer definition.
This bug was not detected because it is hard to write tests that expect a
program abort to happen, hence no tests for this API feature exist.
Related: OS#4152
Change-Id: Ie61c3c85069916336e6dbd91a2c16f7634816417
When reading SUT logs resulting from TTCN3 runs, it can be hard to figure out
which log section corresponds to which test code. Add a 'logp' command on VIEW
and ENABLE nodes that simply echos an arbitrary message on log output, useful
to set markers / explanations from the TTCN3 code, which then appear in all log
outputs and can make it trivial to figure out which log section is interesting.
logging_vty_test# logp lglobal notice This is the log message
DLGLOBAL NOTICE This is the log message
From TTCN3, could be used like this, e.g. in BSC_Tests.ttcn:
private function f_logp(charstring log_msg) runs on MSC_ConnHdlr
{
// log on TTCN3 log output
log(log_msg);
// log in stderr log
f_vty_transceive(BSCVTY, "logp lglobal notice " & log_msg);
}
...
f_logp("f_probe_for_handover(" & log_label & "): Ending the test: Handover Failure stops the procedure.");
Change-Id: Ife5dc8999174c74e0d133729284fe526d6eaf8d9
As a result whitespace ended up in some variables and then command
"expr" was not happy about it.
It was spotted because src/coding/Makefile.am had some whitespacing.
Since it's the only one, let's drop the whitespace there too to have
similar line in all Makefile.am files.
Change-Id: I33afef5e4ef9eb36de81274533f46598ba9a0edb
There's no real good reason for using that function (static buffer)
instead of osmo_str_tolower_buf(local buffer), so let's use the later.
In any case, we get rid of TLS variables in those places, which is a
performance improvement.
It will also allow later shrinking of those buffers if we decide to
define maximum logging category and level name length.
Change-Id: I2e99de1142020e4d80ef0a094e4e751f7903f5f9
This way we get rid of extra 128 bytes in memory per thread created.
It makes sense to share the buffer since it's same size and it doesn't
make much sense to be using both osmo_str_tolower and osmo_strtoupper at
the same time (usually you either want to move everything to uppercase
or everything to lowerase). In required scenarios, one can still use the
_buf versions.
Change-Id: I032803faa0e27c2efdff1ff276acabab95a8319a
The pseudotalloc layer doesn't yet support talloc_named() API
which will be used by the upcoming "context" change. Let's add
this function to pseudotalloc.c for our arm-non-eabi builds.
Change-Id: I4d91ebd73a3357a17ef9143a1b41b90186d4c128
when using gcc 8.3.0 on Debian unstable and doing an embedded build,
I'm getting the following error:
> fsm.c:621:40: error: format '%ld' expects argument of type
> 'long int', but argument 6 has type 'time_t {aka long long int}'
> [-Werror=format=]
Let's avoid that...
Change-Id: I92fb9b08def8475739f0dc6316de43b166f48ac3
After reading data from the socket, assigned to a given VTY, we
need to '\0'-terminate the received string. Otherwise, further
access to that string, stored in a heap buffer vty->buf, would
lead to a heap overrun.
== How to reproduce?
$ python -c "print 'A' * 512" | telnet $HOST $PORT
==21264==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6190000211e0 at pc 0x000000435d2f
bp 0x7ffc06c7add0 sp 0x7ffc06c7a578
READ of size 1025 at 0x6190000211e0 thread T0
#0 0x435d2e in __interceptor_strlen (/usr/local/bin/osmo-msc+0x435d2e)
#1 0x7fb95bfa5624 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6624)
#2 0x7fb95c1be2bc in vty_hist_add /opt/osmocom/libosmocore/src/vty/vty.c:578
#3 0x7fb95c1be2bc in vty_execute /opt/osmocom/libosmocore/src/vty/vty.c:703
#4 0x7fb95c1be2bc in vty_read /opt/osmocom/libosmocore/src/vty/vty.c:1425
#5 0x7fb95c1bfd78 in client_data /opt/osmocom/libosmocore/src/vty/telnet_interface.c:157
#6 0x7fb95b90bd33 in osmo_fd_disp_fds /opt/osmocom/libosmocore/src/select.c:223
#7 0x7fb95b90bd33 in osmo_select_main /opt/osmocom/libosmocore/src/select.c:263
#8 0x5006cc in main /opt/osmocom/osmo-msc/src/osmo-msc/msc_main.c:723:3
#9 0x7fb959935f44 in __libc_start_main /build/eglibc-xkFqqE/eglibc-2.19/csu/libc-start.c:287
#10 0x4226fb in _start (/usr/local/bin/osmo-msc+0x4226fb)
== Why exactly 512?
Because the initial size of the heap buffer is 512 (see VTY_BUFSIZ).
Later on it can be realloc()ated, so X > 512 should also work.
Found using AddressSanitizer and Radamsa [1] fuzzer.
[1] https://gitlab.com/akihe/radamsa
Change-Id: I82f774ad18d0e555eb8f3590a519946d9c583c78
Unfortunately, osmo_sock_get_name_buf() fails in telnet_close_client():
DLGLOBAL INFO telnet_interface.c:130 Closing telnet connection <error-in-getsockname>
because getsockname(), getpeername(), and even close() fail with:
"Bad file descriptor".
This looks like a bug of the existing code.
Change-Id: I77b31abfa159d2f269deaa5a08d94b7bbba7d23c
Unconditional initialization follows the structure definition,
so there is no need to do it twice. This prevents compiler
from warning about potential errors.
Change-Id: If9fd2826f132dfa203dda62940d93dbdfcfd92ac
ubsan will report undefined behavior due to the SUN_LEN macros interaction with a null pointer,
so let's tell ubsan to ignore this function. After carefully reviewing the final publically
availlable drafts of the C99,C11 and C18 standards I can confirm that dereferencing null pointers
is still undefined behavior, as such ubsan will always warn with absolutely every existing compiler
version. Since the sanitizers are periodically synced between llvm and gcc I'm also fairly confident
that rebuilding everything with compiler_rt to use the integrated sanitizers would result in the same message.
I sincerly hope that this explanation provides to be sufficient, If not I'd be willing to show up at
the next llvm dev meeting to provide quotes from actual sanitizer developers to back up these claims.
Change-Id: I0ff445072f1b46390c9f70b21d61c789e39358d5
Rather than having the encoder/decoder library print some log
messages in case of encoding/decoding errors, let's provide something
akin to 'errno', but with a string instead of a numeric error code.
The 'osmo_cbsp_errstr' global variable (if set) contains a
human-readable string describing the most recent encoding/decoding error.
It exists separately for each thread and hence can be used safely in
multi-threaded environments.
Change-Id: Id9a5a595a76ba278647aee9470ded213d8464103
This introduces definitions as well as a parser+encoder for the
Cell Broadcast Service Protocol (CBSP) as specified in 3GPP TS 48.049.
CBSP is used on the interface between CBC and BSC.
Related: OS#3537
Change-Id: I5b7ae08f67e415967b60ac4b824db9e22ca00935
When using `OSMO_ASSERT(exp);` clang will warn about
an empty expression because the semi colon was superflous.
Use do {} while (0) to enfore the need of a semi colon.
This might break other test.
Change-Id: I2272d29a81496164bebd1696a694383a28a86434
The timeout is calculated dynamically in t200_by_lchan() based on FN
advance value estimated by bts_get_avg_fn_advance(), so it's informative
to have the final value printed out.
Change-Id: Ib50a9c23de881c66c9218833703cc41101e06bfd
This reverts commit b3f94eb39e, that
unfortunately breaks some projects which call osmo_fsm_register()
on DSO load (i.e. using __attribute__((constructor))) before the
logging is initialized.
Change-Id: Idc6fcce7e946c23d48589b920e309d60aa7b6645
As suggested by Vadim while reviewing a related fix for ipa_keepalive.c
in libosmo-abis (see https://gerrit.osmocom.org/#/c/libosmo-abis/+/13540/),
it makes sense to print an error message if anyone registers a FSM
that specifies an allstate_action callback but at the same time no
events that would ever end up in that callback.
Change-Id: I9e73f7363ab15a00843e3f0d1e5776f4be7ebc46
For instance, take command "single0 [one]":
If user executes "single0 on", VTY func will receive argv[0]="one"
instead of argv[0]="on".
Related: OS#4045
Change-Id: I5f4e2d16c62a2d22717989c6acc77450957168cb
For instance, take command "multi0 (one|two|three)":
If user executes "multi0 tw", VTY func will receive argv[0]="two"
instead of argv[0]="tw".
Fixes: OS#4045
Change-Id: I91b6621ac3d87fda5412a9b415e7bfb4736c8a9a
Check against MAX argc is changed to == since it cannot be incremented
twice without passing the check.
Change-Id: Ia330e475989fda863bedcc3cbf94deaf8dd83037
It was noticed that multithreaded processes like osmo-trx can crash upon
using ctime().
Related: OS#4055
Change-Id: I19ebf29a2f1fc855bb7d56766b338c7c3432dfd1
Huge conditional block inside for loop is negated in this patch
together with a "continue" keyword, similar to what was already done
recently in 4742526645.
Change-Id: I803c4ed38e9ab09bf929528c75a60e6f65da3928
inner block defined variable "enum match_type ret" was being masking
outter block variable "int ret = 0". The ret variable was being given
non zero values only inside the inner block, so that change was done on
the inner variable and not the outer one, which is returned.
Fixes: 5314c513f2
Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
Huge conditional block inside foor loop is negated in this patch
together with a "continue" keyword.
Change-Id: I9715734ed276f002fdc8c3b9742531ad36b2ef9e
Return ENOSPC if the decoding buffer is one byte too small, instead of
returning 0 and silently truncating the string. Add a new "truncated"
variable to detect if the loop breaks in the final iteration.
The string is not truncated if there is exactly one 0xf ('\0') higher
nibble remaining. This is covered by the existing test case "long
15-digit (maximum) MSISDN, limited buffer".
Related: OS#4049
Change-Id: Ie05900aca50cc7fe8a45d17844dbfcd905fd82fe
Instead of copy+pasting the same LOGPFSMSRC("State change to " ...)
with slightly different trailer depending on the FSM timer, let's first
snprintf() to a stack variable and then have a single log statement.
Change-Id: I49528c4ca1fa11aef09c2092615dccca450b847c
So far, the public API of osmo_fsm only allowed integral seconds as
timeout. Let's change that to milli-seconds in order to cover more
use cases.
This introduces
* osmo_fsm_inst_state_chg_ms()
* osmo_fsm_inst_state_chg_keep_or_start_timer_ms()
Which both work exactly like their previous counterparts without the _ms
suffix - the only difference being that the timeout parameter is
specified in milli-seconds, not in seconds.
The value range for an unsigned long in milli-seconds even on a 32bit
platform extends to about 48 days.
This patch also removes the documentation notice about limiting the
maximum value to 0x7fffffff due to time_t signed-ness. We don't use
time_t but unsigned long.
Change-Id: I35b330e460e80bb67376c77e997e464439ac5397
During testing with BTS_Tests_LAPDm.TC_t200_n200() it was discovered
that the existing LAPD[m] implementation always gave up at N200-1
retransmissions, rather than N200 retransmissions.
The first transmission doesn't count, and hence we must have N200
actual re-transmissions. The Error message is then described as
"T200 expired N200+1 times", i.e. we start T200 one more time after
the last re-transmission and only give up if it expires again (i.e.
no ACK received)
Change-Id: Ic33854ee61311f73b7db55eeef10280349151097
Related: OS4037
TS 04.06 specifies a N200 re-transmission counter that depends on the
channel type, which we didn't care about at all so far. Let's have the
caller tell us the channel type so we can internally look up the correct
N200 value for it.
At the same time, permit the user to specify T200 re-transmission timer
values for each SAPI on both DCCH and ACCH, which is required at least
in the BTS as per GSM TS 12.21. Also, extend the timer resolution of
the API from seconds to milli-seconds, which is more applicable as
particularly on the FACCH the recommended values are in the 200ms range.
Change-Id: I90fdc4dd4720d4e02213197c894eb0a55a39158c
Related: OS#3906
Related: OS#2294
Related: OS#4037
This function parses a single Cell ID list element into a
'union gsm0808_cell_id_u'. This function is going to be used
by the upcoming CBSP support.
Related: OS#3537
Change-Id: I08b33881667aa32f01e53ccb70d44d5b79c7c986
We have a number of library-internal static global buffers which are
mainly used for various stringification functions. This worked as
all of the related Osmocom programs were strictly single-threaded.
Let's make those buffers at least thread-local. This way every thread
gets their own set of buffers, and it's safe for multiple threads to
execute the same functions once. They're of course still not
re-entrant. If you need re-entrancy, you will need to use the _c()
or _buf() suffix version of those functions and work with your own
(stack or heap) buffers.
Change-Id: I50eb2436a7c1261d79a9d2955584dce92780ca07
3GPP TS 04.06 is quite clear that the [segmented] L3 payload can be as
long as 251 bytes. Our libosmocore lapdm implementation truncated
already at 200 bytes :(
Change-Id: I6769986f27dda1d429ed7b2e32c36d34663acba9
Closes: OS#4035
The library should either provide functions that implement encoding
of those rest octets, or it shouldn't. Providing a function that
doesn't do anything but pad the buffer is useless.
Change-Id: Ie10684de6a6b2663e2a871fcdb2b275b6ad7a1e7
There's very little sense behind introducing a function into
libosmogsm which doesn't implement 90% of the spec. Let's allow
the caller to provide the various optional bits of information to
the encoder, rather than generating mostly static SI6 rest octets.
Change-Id: Id75005a0c4a02ce7f809692d58b3bd226bc582b2
the symbols had an omso_ prefix, while the entry in the .map file
didn't. As a result, all related symbols were never exported and
hence not usable by any users of the dynamic library.
Change-Id: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330
The gsm48_rest_octets.c file was added in Change-Id
I47888965ab11bba1186c21987f1365c9270abeab, but it never actually
ended up being compiled as it wasn't listed in the makefile :/
Change-Id: I0355115c2645f236c9e32cf7a563cf51a857e8a3
Relsted: OS#3075
As gsm48_rest_octets.c is not listed in the Makefile.am, it's
never actually compiled and we never noticed that it's calling
functions by symbol names that don't exist :/
Change-Id: I7b1e436f70e0c60979261db87606f38271ec47d3
Related: OS#3075
libosmo{core,gsm,vty} code is GPLv2+. The rest octet code originated in
osmo-bsc.git and was moved here without changing the license. That was a
mistake, it always was meant to be under GPLv2-or-later after moving to
libosmocore.git.
Original copyright is mine. For contributions by sysmocom, I as the
managing director can approve the license change.
This means only Holger needs to ACK this.
Change-Id: Ief3009dc28dd83e1e26a7101af2eed2341684a87
The documentation of gsm48_decode_bcd_number2() clearly states that
the output truncation is a erroneous case, so it should actually
return negative in such cases. Let's return -ENOSPC.
Change-Id: I75680f232001ba419a587fed4c24f32c70c3ad2b
Thanks to the new unit test for BCD number encoding / decoding, it was
discovered that gsm48_decode_bcd_number2() does not properly handle
encoded LV if the output buffer size is equal to the original MSISDN
length + 1 (\0-terminator): one digit is lost.
For example, decoding of 15-digit long MSISDN to a buffer of size
16 (15 digits + 1 for \0) would give us only 14 digits.
The problem was that 'output_len' was being decremented before
checking the remaining buffer length and writing a digit to it.
As a result, the maximum length was always one byte shorter.
Change-Id: I61d49387fedbf7b238e21540a5eff22f6861e27a
Fixes: OS#4025
libosmo{core,gsm,vty} code is GPLv2+. The tdef code originated in
osmo-msc.git and was moved here without changing the license. That
was a mistake, it always was meant to be under GPLv2-or-later after
moving to libosmocore.git.
Copyright is with sysmocom, so I as the managing director can
approve the license change.
Change-Id: Ie483ff6f6ea0a56c477649677b4b163c49df11d7
libosmo{core,gsm,vty} code is GPLv2+. The OAP code originated in
osmo-msc.git and was moved here without changing the license. That
was a mistake, it always was meant to be under GPLv2-or-later after
moving to libosmocore.git.
Copyright is with sysmocom, so I as the managing director can
approve the license change.
Change-Id: I08311fa8214c15f8df8945b9894226608cf96f15
We don't really *need* it in libosmocore as such, but the lack of
having all osmocom extensions listed here lead to using overlapping
definitions: 0x18 was used for dynamic PDCH on the Abis side, but also
for CBCH on the L1SAP side. Let's list them all here to increase
visibility in case anyone wants to extend this further...
Related: OS#4027
Change-Id: I93e557358cf1c1b622f77f906959df7ca6d5cb12
The caller of lapdm_rslms_recvmsg() (e.g. osmo-bts/src/common/rsl.c)
assumes the message ownership is transferred. However, in one of the
two error paths, msgb_free() was not called and hence we had a memory
leak.
Also clarify the msgb ownership transfer in a comment.
Related: OS#3750
Change-Id: Id60cb45e50bfc89224d97df6c68fcd2949751895
So far, the TLV code contained two types of functions
* tlp_parse() to parse all TLVs according to definition into tlvp_parsed
* various helper functions to encode individual TLVs during message
generation
This patch implements the inverse of tlv_parse(): tlv_encode(), which
takes a full 'struct tlv_pared' and encodes all IEs found in it. The
order of IEs is in numerically ascending order of the tag.
As many protocols have different IE/TLV ordering requirements, let's add
a tlv_encode_ordered() function where the caller can specify the TLV
ordering during the one-shot encode.
Change-Id: I761a30bf20355a9f80a4a8e0c60b0b0f78515efe
Any non-anciant version of talloc implements talloc_steal()
as a #define using the _talloc_steal_loc() symbol. Let's be
more compatible.
This fix is relevant to using osmo_fsm inside the osmo-ccid-firmware
builds for Cortex-M4. In this situation, for some strange reason,
libosmcoore is compiled using src/pseudotalloc/talloc.h, but later then
linked against the real libtalloc.
Change-Id: I1ee7f5e9b1002cff37bb8341ad870e1da5f1f9ff
Add the constant, so it can be used in create-subscriber-on-demand
related patches. ITU-T Rec. E.164 6.1 states that maximum international
number length should be 15. I did not find a source for a minimum
length, but I've added the constant and set it to 1 for consistency
(based on the existing osmo_msisdn_str_valid() function).
Related: OS#2542
Change-Id: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1
IE GSM0808_IE_OSMO_OSMUX_SUPPORT (T, 1 byte) is sent in AoIP appended to
BSSMAP RESET in order to announce the peer that its MGW supports handling
Osmux streams upon call set up.
IE GSM0808_IE_OSMO_OSMUX_CID (TV, T 1 byte & V 1 byte) is sent in AoIP
during call set up:
* MSC->BSC Assignment Request
* BSC->MSC Assignemnt Complete
The 1 byte value contains the local Osmux CID, aka the recvCID aka CID where the
peer sending the Assign Req/Compl will look for Osmux frames on that
call. Hence, the peer receiving this CID value must use it to send Osmux
frames for that call.
As a result, a given call leg BSC<->MSC can have one different Osmux CID
per direction. For example:
* MS => MGW_BSC ==CID 0==> MGW_MSC
* MS <= MGW_BSC <=CID 1=== MGW_MSC
This allows for setups with 256 call legs per BSC on scenarios where NAT
is not a problem, where MSC can have a pool of 256 CID per MGW_BSC (or
remote peer).
Related: OS#2551
Change-Id: I28f83e2e32b9533c99e65ccc1562900ac2aec74e
osmo_sock_get_name_buf():
In case the getsockname() call is failing for some weird reason,
we shouldn't return an uninitialized, non-zero-terminated string
buffer to the caller, as most callers will be too lazy to test the
return value.
This holds even more true for users of the internal
osmo_sock_get_name2() and osmo_sock_get_name2_c() functions which indeed
very much ignore the return value of osmo_sock_get_name_buf().
Change-Id: I2d56327e96b7a6783cca38b828c5ee74aed776ae
This reverts commit 9685a48c7b which has
caused massive fall-out among (particularly) unit tests in osmo-{msc,bts,pcu}.
Change-Id: Iede72e86451d94cf678045992cb71f6b1bf16896
This function is doing the bulk work of encoding a given Cell
ID List item. gsm0808_enc_cell_id_list2() is modified to be a
wrapper / loop around the new function.
The purpose of this is to expose Cell ID List Entry encoding
so that the upcoming CBSP protocol encoder can re-use this code.
Related: OS#3537
Change-Id: I6cc567798e20365e6587e6b2988e834306d8c80c
In testing against a particular EPC, the SGsAP-SERVICE-REQUEST
can contain a MO fallback value TLV with T 0xF1
Change-Id: Ia2460af9673818d375e28c67f1631b5f7eacdaeb
osmo-bsc so far omits the AoIP Transport Layer Address from its Handover
Request Acknowledge message, which breaks inter-BSC Handover for AoIP.
Allow fixing that.
One quirk I really don't like about this: I would prefer to directly use struct
sockaddr_storage as a member of the struct gsm0808_handover_request_ack. Even
though struct sockaddr_storage appears in various function signatures, the
gsm0808.c actually also gets built on embedded systems that lack arpa/inet.h
(for me indicated by the ARM build job on jenkins). Compiling gsm0808.c works
only because the actual coding of struct sockaddr_storage is implemented in
gsm0808_util.c, which (apparently) does not get built on embedded and hence,
even though there are undefined references to e.g.
gsm0808_enc_aoip_trasp_addr() it works.
Related: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff (osmo-bsc)
Change-Id: Ia71542ea37d4fd2c9fb9b40357db7aeb111ec576
In osmo_gsup_decode(), call gsm48_decode_bcd_number2() to avoid deprecation
warning, and also actually check the return value to detect invalid IMSI IEs.
Change-Id: Iaded84d91baad5386c8f353c283b6b9e40a43b05
gsm48_decode_bcd_number() is marked as deprecated, so
gsm48_decode_bcd_number2() will cause deprecation warnings as long as it calls
gsm48_decode_bcd_number(). Hence move the code to gsm48_decode_bcd_number2().
Change-Id: I81925e9afb3451de9b8a268d482f79ee20ca14d6
The input_len argument for gsm48_decode_bcd_number2() includes the BCD length
*and* the length byte itself, so add the missing +1.
Also clarify the API doc for the input_len argument.
Change-Id: I87599641325c04aae2be224ec350b1a145039528
For async callbacks it is useful to determine whether a given VTY pointer is still valid.
For example, in osmo-msc, a silent call can be triggered by VTY, which causes a
Paging. The paging_cb then writes to the VTY console that the silent call has
succeeded. Unless the telnet vty session has already ended, in which case
osmo-msc crashes; e.g. from an osmo_interact_vty.py command invocation. With
this function, osmo-msc can ask whether the vty pointer passed to the paging
callback is still active, and skip vty_out() if not.
Change-Id: I42cf2af47283dd42c101faae0fac293c3a68d599
gsm48_decode_bcd_number() is unable to provide proper bounds validation of
input and output data, hence osmo-msc's vlr.c introduced a static
decode_bcd_number_safe() a long time ago. Move to libosmocore.
I need to use the same function to decode an MSISDN during inter-MSC Handover,
instead of making it public in osmo-msc, rather deprecate the unsafe function
and provide a safer version for all callers. Mark the old one deprecated.
Change-Id: Idb6ae6e2f3bea11ad420dae14d021ac36d99e921
Change two instances of Speech Version values to enum gsm0808_permitted_speech.
It is often not trivial to find the right values for a uint8_t member, giving
the enum name makes it a lot easier/safer to use.
In gsm0808_create_handover_required(), use msgb_tv_put() so that the enum's
storage size doesn't matter. (Already used for handover_performed)
Fix typo in doc of gsm0808_create_handover_required().
Change-Id: I6387836bab76e1fa42daa0f42ab94fc14b70b112
Based on a draft created by Neels, which is the result of reading a MAP
trace of two MSCs negotiating inter-MSC handovers, and of reading the
TS 29.002, TS 29.010 and related specs:
https://lists.osmocom.org/pipermail/openbsc/2019-January/012653.html
I figured out that the "Handover Number" mentioned in the specifications
is the same as the MSISDN IE that we already have, so we can use that
instead of creating a new IE (example usage in tests/gsup/gsup_test.c).
Create a new OSMO_GSUP_MSGT_E_ROUTING_ERROR message type, which the GSUP
server uses to tell a client that its message could not be forwarded to
the destination (see [1]). MAP has no related message.
[1]: Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5 (osmo-hlr.git)
Related: OS#3774
Change-Id: Ic00b0601eacff6d72927cea51767801142ee75db
osmo-msc and osmo-hlr have distinct subsystems handling incoming GSUP messages.
So far we decide entirely by message type which code path should handle a GSUP
message. Thus no GSUP message type may be re-used across subsystems.
If we add a GSUP message to indicate a routing error, it would have to be a
distinct message type for subscriber management, another one for SMS, another
one for USSD...
To allow introducing common message types, introduce a GSUP Message Class IE.
In the presence of this IE, GSUP handlers can trivially direct a received
message to the right code path. If it is missing, handlers can fall back to the
previous switch(message_type) method.
Change-Id: Ic397a9f2c4a7224e47cab944c72e75ca5592efef
Calling sizeof() on a pointer would result in getting size of the
pointer (usually 4 or 8 bytes) itself, but not the size of the
memory it points to.
Change-Id: I83f55a9638b75d9097d37992f7c84707791f10f6
Fixes: CID#194266
Calling sizeof() on a pointer to dynamically allocated memory would
result in getting size of the pointer (usually 4 or 8 bytes) itself,
but not the size of allocated memory.
Change-Id: I8ffda4dea2b7f9b4b76dfeecad1fab6384c5a62c
Fixes: CID#197629, CID#197628, CID#197627
Fixes: CID#197626, CID#197625, CID#197624
We often compose FSM instance IDs from context information, for example placing
an MSISDN string or IP:port information in the FSM instance id, using
osmo_fsm_inst_update_id_f(). This fails if any characters are contained that
don't pass osmo_identifier_valid(). Hence it is the task of the caller to make
sure only characters allowed in an FSM id are applied.
Provide API to trivially allow this by replacing illegal chars:
- osmo_identifier_sanitize_buf(), with access to the same set of illegal
characters defined in utils.c,
- osmo_fsm_inst_update_id_f_sanitize() implicitly replaces non-identifier
chars.
This makes it easy to add strings like '192.168.0.1:2342' or '+4987654321' to
an FSM instance id, without adding string mangling to each place that sets an
id; e.g. replacing with '-' to yield '192-168-0-1:2342' or '-4987654321'.
Change-Id: Ia40a6f3b2243c95fe428a080b938e11d8ab771a7
To be able to append an escaped or quoted string using
OSMO_STRBUF_APPEND_NOLEN(), the function signature must have the buf and len as
first args, like most other *_buf() functions.
Add osmo_escape_str_buf2() and osmo_quote_str_buf2() to match this signature.
A recent patch [1] has changed the return value of osmo_escape_str_buf() to
char*, removing the const. However, the functions may return const strings,
hence re-add the const. The new signatures always return the non-const buffer.
To avoid code duplication, implement osmo_quote_str_buf() and
osmo_escape_str_buf() by calling the new functions.
I decided to allow slight changes to the behavior for current osmo_escape_str()
and osmo_escape_str_buf(), because impact on callers is minimal:
(1) The new implementation uses OSMO_STRBUF_*, and in consequence
osmo_quote_str() no longer prints an ending double quote after truncated
strings; Before, a truncated output was, sic:
"this string is trunca"
and now this becomes, sic:
"this string is truncat
I decided to not keep the old behavior because it is questionable to begin
with. It looks like the string actually ended at the truncation boundary
instead of the reason being not enough space in the output buffer.
(2) The new osmo_escape_str_buf2() function obviously cannot pass-thru an
unchanged char* if no escaping was needed. Sacrifice this tiny optimization
feature to avoid code duplication:
- it is an unnoticeable optimization,
- the caller anyway always passes a string buffer,
- the feature caused handling strings and buffers differently depending on
their content (i.e. code that usually writes out strings in full length
"suddenly" truncates because a non-printable character is contained, etc.)
I considered adding a skip_if_unescaped flag to the osmo_quote_str_buf2()
function signature, but in the end decided that the API clutter is not worth
having for all the above reasons.
Adjust tests to accomodate above changes.
[1] 4a62eda225
Ibf85f79e93244f53b2684ff6f1095c5b41203e05
Change-Id: Id748b906b0083b1f1887f2be7a53cae705a8a9ae
Move from a static implementation in tdef_vty.c to utils.c, I also want to use
this in osmo-msc.
The point is that the telnet VTY allows unambiguous partly matches of keyword
args. For example, if I have a command definition of:
compare (apples|oranges)
then it is perfectly legal as for the vty parser to write only
compare app
One could expect the VTY to then pass the unambiguous match of "apples" to the
parsing function, but that is not the case.
Hence a VTY function implementation is faced with parsing a keyword of "app"
instead of the expected "apples".
This is actually a very widespread bug in our VTY implementations, which assume
that exactly one full keyword will always be found. I am now writing new
commands in a way that are able to manage only the starts of keywords.
Arguably, strstr(a, b) == a does the same thing, but it searches the entire
string unnecessarily.
Change-Id: Ib2ffb0e9a870dd52e081c7e66d8818057d159513
Add global flag osmo_fsm_term_safely() -- if set to true, enable the following
behavior:
Detect osmo_fsm_inst_term() occuring within osmo_fsm_inst_term():
- collect deallocations until the outermost osmo_fsm_inst_term() is done.
- call osmo_fsm_inst_free() *after* dispatching the parent event.
If a struct osmo_fsm_inst enters osmo_fsm_inst_term() while another is already
within osmo_fsm_inst_term(), do not directly deallocate it, but talloc-reparent
it to a separate talloc context, to be deallocated with the outermost FSM inst.
The effect is that all osmo_fsm_inst freed within an osmo_fsm_inst_term()
cascade will stay allocated until all osmo_fsm_inst_term() are complete and all
of them will be deallocated at the same time.
Mark the deferred deallocation state as __thread in an attempt to make cascaded
deallocation handling threadsafe. Keep the enable/disable flag separate, so
that it is global and not per-thread.
The feature is showcased by fsm_dealloc_test.c: with this feature, all of those
wild deallocation scenarios succeed.
Make fsm_dealloc_test a normal regression test in testsuite.at.
Rationale:
It is difficult to gracefully handle deallocations of groups of FSM instances
that reference each other. As soon as one child dispatching a cleanup event
causes its parent to deallocate before fsm.c was ready for it, deallocation
will hit a use-after-free. Before this patch, by using parent_term events and
distinct "terminating" FSM states, parent/child FSMs can be taught to wait for
all children to deallocate before deallocating the parent. But as soon as a
non-child / non-parent FSM instance is involved, or actually any other
cleanup() action that triggers parent FSMs or parent talloc contexts to become
unused, it is near impossible to think of all possible deallocation events
ricocheting, and to avoid running into freeing FSM instances that were still in
the middle of osmo_fsm_inst_term(), or FSM instances to enter
osmo_fsm_inst_term() more than once. This patch makes deallocation of "all
possible" setups of complex cross referencing FSM instances easy to handle
correctly, without running into use-after-free or double free situations, and,
notably, without changing calling code.
Change-Id: I8eda67540a1cd444491beb7856b9fcd0a3143b18
To prevent re-entering osmo_fsm_inst_term() twice for the same osmo_fsm_inst,
add flag osmo_fsm_inst.proc.terminating. osmo_fsm_inst_term() sets this to
true, or exits if it already is true.
Update fsm_dealloc_test.err for illustration. It is not relevant for unit
testing yet, just showing the difference.
Change-Id: I0c02d76a86f90c49e0eae2f85db64704c96a7674
We don't need to know position of matches: just yes or no.
This change would save some computation power.
Change-Id: Id55ffe64cc1a35dd83f61dbb0f9828aa676696f9
We have a habit of returning static buffers from some functions,
particularly when generating some kind of string values. This is
convenient in terms of memory management, but it comes at the expense
of not being thread-safe, and not allowing for two calls of the
related function within one printf() statement.
Let's introduce _c suffix versions of those functions where the
caller passes in a talloc context from which the output buffer shall
be allocated.
Change-Id: I8481c19b68ff67cfa22abb93c405ebcfcb0ab19b
Provide a common implementation of use counting that supports naming each user
as well as counting more than just one use per user, depending on the rules the
caller implies.
In osmo-msc, we were originally using a simple int counter to see whether a
connection is still in use or should be discarded. For clarity, we later added
names to each user in the form of a bitmask of flags, to figure out exactly
which users are still active: for logging and to debug double get / double put
bugs. This however is still not adequate, since there may be more than one CM
Service Request pending. Also, it is a specialized implementation that is not
re-usable.
With this generalized implementation, we can:
- fix the problem of inadequate counting of multiple concurrent CM Service
Requests (more than one use count per user category),
- directly use arbitrary names for uses like __func__ or "foo" (no need to
define enums and value_string[]s),
- re-use the same code for e.g. vlr_subscr and get fairly detailed VLR
susbscriber usage logging for free.
Change-Id: Ife31e6798b4e728a23913179e346552a7dd338c0
For handling RTP IP addresses and ports, osmo-mgw, osmo-bsc and osmo-msc
so far have their own separate shims and code duplication around
inet_ntoa(), htons(), sockaddr conversions etc. Unify and standardize
with this common API.
In the MGW endpoint FSM that was introduced in osmo-bsc and which I
would like to re-use for osmo-msc (upcoming patch moving that to
osmo-mgw), it has turned out that using char* IP address and uint16_t
port number types are a convenient common denominator for logging,
MGCP message composition and GSM48. Ongoing osmo-msc work also uses this
for MNCC.
This is of course potentially useful for any other IP+port combinations
besides RTP stream handling.
Needless to say that most current implementations will probably stay
with their current own conversion code for a long time; for current
osmo-{bsc,msc,mgw} work (MGW endpoint FSM) though, I would like to move
to this API here.
Change-Id: Id617265337f09dfb6ddfe111ef5e578cd3dc9f63
The function osmo_dump_gsmtime_buf gets a pointer *buf and a parameter
buf_len. The pointer *buf is a string buffer and the function places an
\0 at the end of the buffer before it exists. However it uses
sizeof(buf) as part of the index calculation, which is incorrect. Lets
correct this by using buf_len instead.
Change-Id: Id24263aa7c9a53544f1639b6ceb09ce5615d5114
We have a number of static buffers in use in libosmo*. This means
the related functions are not usable in a thread-safe way. While
we so far don't have many multi-threaded programs in the osmocom
universe, the static buffers also prevent us from calling the same
e.g. string-ify function twice within a single printf() call.
Let's make sure there's an alternative function in all those cases,
where the user can pass in a caller-allocated buffer + size, and make
the 'classic' function with the static buffer a wrapper around that
_buf() variant.
Change-Id: Ibf85f79e93244f53b2684ff6f1095c5b41203e05
osmo_escape_str_buf() used to have the somewhat odd semantics that
if no escaping was needed, it would return the original pointer without
making any copy to the output buffer. While this seems like an elegant
optimization, it is a very strange behavior and it works differently
than all of our other *_buf() functions. Let's unify the API and
turn osmo_escape_str_buf() into a strlcpy() if no escaping is needed.
Change-Id: I3a02bdb27008a73101c2db41ac04248960ed4064
ipa_ccm_idtag_parse_off is broken, and can only be used with
len_offset=1 on ID Request messages, otherwise won't work correctly.
Modify ipa_ccm_idtag_parse to at least parse those correctly, and
document the limitations.
Those two functions are already deprecated and only used in openbsc by 3
callers:
* ipa_ccm_idtag_parse in ussd_read_cb(): Broken, that function can only
work for Requests and it's used to parse a Response.
* ipa_ccm_idtag_parse_off in forward_sccp_to_msc (NAT): Broken, it can
only be used to parse Requests and it's used to parse a Response.
Furthermore, len_offset=2 is passed which makes no sense and most
probably it fails always, or can even make the program crash.
* ipa_ccm_idtag_parse_off in (answer_challenge): This one is fine and
could actually be replaced with ipa_ccm_id_get_parse after this commit
is merged.
Change-Id: I6efc852dfc041192f554e41a58290a0f63298021
In gsmtap_source_init() we dynamically allocate a gsmtap_inst struct,
but don't free it if the subsequent call to osmo_fd_register() fails.
Change-Id: I970b493f3a64fbe9c3f68fcfba5097ee3ff72960
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
This change fixes the following Doxygen warnings:
timer.c:69: warning: argument 'callback' of command @param is not
found in the argument list of
osmo_timer_setup(struct osmo_timer_list *timer,
void(*cb)(void *data), void *data)
timer.c:69: warning: argument 'pointer' of command @param is not
found in the argument list of
osmo_timer_setup(struct osmo_timer_list *timer,
void(*cb)(void *data), void *data)
core/timer.h:70: warning: The following parameters of
osmo_timer_setup(struct osmo_timer_list *timer,
void(*cb)(void *data), void *data)
are not documented:
parameter 'cb'
parameter 'data'
Change-Id: If5668f40a7bfde2f4f22329a071c8c6eff23b99e
rate_ctr.c:411: warning: unable to resolve reference
to `handle_group' for \ref command
rate_ctr.c:208: warning: unable to resolve reference
to `talloc' for \ref command
Change-Id: I24a80ff6cf11ce0455529515d1ecb9900f0271a8
Doxygen was confused by duplicated documentation for both
definition and declaration of rate_ctr_for_each_counter().
Moreover, both variants contained some mistakes.
Let's avoid this duplication and keep the only (corrected) one.
Change-Id: Icca2d4a95bd5f96ae85a86909ec90fb8677cacf3
This change fixes the following Doxygen warnings:
src/msgb.c:479: warning: argument 'msg' of command @param is not
found in the argument list of
msgb_printf(struct msgb *msgb, const char *format,...)
core/msgb.h:708: warning: The following parameters of
msgb_printf(struct msgb *msgb, const char *format,...)
are not documented:
parameter 'msgb'
parameter 'format'
As a bonus, it dot-terminates all sentences.
Change-Id: Ib708664336eef06f748d408ae02a13c754b6647a
This change should fix the following warnings:
logging.c:956: warning: unable to resolve reference to `talloc'
for \ref command
logging.c:203: warning: argument 'in' of command @param is not
found in the argument list of
log_level_str(unsigned int lvl)
logging.c:194: warning: argument 'in' of command @param is not
found in the argument list of
log_parse_level(const char *lvl)
logging.c:708: warning: argument 'print_catname' of command
@param is not found in the argument list of
log_set_print_category(struct log_target *target,
int print_category)
logging.c:687: warning: argument 'print_filename' of command
@param is not found in the argument list of
log_set_print_filename2(struct log_target *target,
enum log_filename_type lft)
logging.c:729: warning: argument 'print_catname' of command
@param is not found in the argument list of
log_set_print_level(struct log_target *target,
int print_level)
logging.c:893: warning: argument 'in' of command @param is not
found in the argument list of
log_target_destroy(struct log_target *target)
Change-Id: I85f6c70216b7574b49b90bb1469869a47f721713
This reverts commit 1261db1505.
The patch broke openbsc's external tests, and currently it is unclear
whether it is just an error in the test or if openbsc makes wrong
assumptions about the length value. Let's revert the patch to unblock
the master-openbsc jenkins job.
Related: OS#3851
Change-Id: I9adea35ff6de36c1611c7f85dde1b15bc1c0e786
This reverts commit cff2242e68.
The patch broke openbsc:
../../src/libcommon/libcommon.a(talloc_ctx.o): In function `talloc_ctx_init':
/build/openbsc/src/libcommon/talloc_ctx.c:50: undefined reference to `tall_sigh_ctx'
See also:
https://lists.osmocom.org/pipermail/openbsc/2019-March/012843.html
Change-Id: Ib4cb31427a1cad063bc9f1a10b9c3182b314a9f2
As indicated in the commitlog of
Id58ca18eb826b8f4183a7cf0dbb2b38cba702a09,
the symbol was never exported in a header file, so it should be safe
to mark it as static.
Change-Id: I7132ffe9a7efcab226cc639d1b2357f7115bcadf
This function is broken ever since it was added back in 2018 in commit
Id58ca18eb826b8f4183a7cf0dbb2b38cba702a09
Rather than allocating from the user-supplied 'root_ctx', it is
allocating from the context that it's trying to create (which is
NULL at that time, rendering the entire operation more or less
a no-op. For sure you will not see osmo_signal structures never in
any talloc report.
Change-Id: I922d26815a3baa5be74bd3ee89d498555882d62f
The naming of these constants dates back to when the code was private
within OpenBSC. Everything else was renamed (bsc_fd -> osmo_fd) at
the time, but somehow the BSC_FD_* defines have been missed at the
time.
Keep compatibility #defines around, but allow us to migrate the
applications to a less confusing naming meanwhile.
Change-Id: Ifae33ed61a7cf0ae54ad487399e7dd2489986436