Implementation is imported from osmo-ggsn.git
97f60e3dca581797007524e0006ca9fafad59713 in46a_netmasklen() and adapter
to work with an osmo_sockaddr.
This will be used by osmocom-bb's "modem" app.
Change-Id: I75e75e251c6776801fffdde745aebedf21c68799
The function gsm_gsmtime2fn() uses a hack to account for the truncated
modulo implementation of C/C++. libosmocore offers proven modulo
functions, so lets use OSMO_MOD_FLR() instead. Also arrange the formula
so that it looks more like the one in the spec.
Also add better spec references and a final modulo GSM_MAX_FN to
prevent frame number results that exceed the valid range.
Change-Id: Ibf94bca8223f1f7858a6dd67bf27de0ab6feab20
So far ctrl interface did not allow to specify port to bind to.
Let's fix this and make it consistent with the way vty bind works.
N. B: the functions which ignore port configured via vty are marked as deprecated,
the sw which uses them should be ported to either newly added ctrl_init_default()
or simplified ctrl_interface_setup()
The similar change for vty interface will be addressed via separate patch series.
Related: OS#5809
Change-Id: I0fd87fd41fd3ac975273968d24f477daa3cd3aa9
Drop the code which tried to estimate the value for the next timeframe:
it accumulated error over time which only adds confusion.
N. B: this means that long-term intervals (day, hour) will show the rate of 0 until
corresponding timeframe passes. This matches how other monitoring software [1] behaves.
[1] https://learn.netdata.cloud
Fixes: OS#5671
Change-Id: I07232e9ff8bd62403ae82d9bd60d967d40b54ebc
The motivation behind adding and using the new API is explained in
the preceeding change [1]. Whenever any of the encoding functions
fails to encode either a Speech Codec or a Codec List IE, free()
the msgb and return NULL.
Change-Id: I28219b61b9347f0652f9fd0c717f6cdf3c63e8f9
Related: [1] I199ffa0ba4a64813238519178155dfc767aa3975
Related: SYS#6229
The problem with most of the existing gsm0808_* functions in this file
is that they assert() too much, assuming that their callers always pass
perfectly valid input parameters. But this is impossible on practice,
as there can be bugs in complex projects using them, liks osmo-bsc.
It was reported by a customer that a heavily loaded osmo-bsc crashed a
few times, dropping more than 100 sites without network coverage for
a few minutes. As was revealed during the investigaion, it crashed
due to a failing assert at the end of enc_speech_codec():
OSMO_ASSERT(sc->cfg == 0);
The problem is that somehow osmo-bsc is passing an unexpected sc->cfg
value to gsm0808_create_ass_compl2(), in particular 0x02, while the
given sc->type value (GSM0808_SCT_HR1) implies that there cannot be
any configuration bits on the wire.
The reason why and under which circumstances this can be happening
is not clear yet, but what we agreed on so far is that the library
API should be enforcing correctness of the input parameters in a
less agressive way, rather than aborting the process without
letting it any chance to recover.
Modify the original gsm0808_enc_speech_codec[_list]() functions, so
that a negative value is returned in case of an error. Rename them
and add backwards compatibility wrappers, because it's public API.
A separate patch making use of the new API follows next.
Change-Id: I199ffa0ba4a64813238519178155dfc767aa3975
Related: SYS#6229
I believe the gsm0808_* API is mature enough to avoid assert()ing
pointers accepted via function parameters. We can assume the caller
never passes NULL, as we do in almost all public API.
Change-Id: If9b4c92ace68191f5ddcc0a8a340fccbfe0f3dc0
This assert can be dropped because the switch statement above does
not leave any sc->type >= 0x0f for type_extended == false.
Change-Id: Iafb45ed66378f2c9c2480f81371e92c6d1da71a7
Use timerfd to schedule 1-second periodic timer once
instead rescheduling every second in timer callback.
Related: OS#5671
Change-Id: I2525fd691caa380a862d305cfcb4fa3cc50b70d0
Binding to a negative port should not be allowed.
Using signed value for unsigned parameter is a mistake to begin with.
Change-Id: I24f957641f2d8e230ccceb331a719496df0fdb1f
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I84fd99442d0cc400fa562fa33623c142649230e2
Those are similar to existing *msgb_alloc*() functions but allows
to change the size of destination msgb provided it fits the
data from source msgb.
Change-Id: I36d4c16241d19f0f73c325be4d0e0bdef6813615
Signed-off-by: Max <msuraev@sysmocom.de>
The OS#4993 has nothing to do with AF_PACKET/ENOBUFS,
the proper ticket is OS#4995 as referenced later in the same file.
Change-Id: Icf13b351dc74508fc312c535d68b13b7ce9b7e1e
The weird formatting not only makes it hard to read but caused linter to fail in the follow-up patch.
Change-Id: Ie4e56b4796c1b8f270a692453faccf102c963db5
gsm0808_create_lcls_conn_ctrl() was adding the LCLS-Configuration IE twice.
Correct is LCLS-Configuration followed by LCLS-Connection-Status-Control
(TS 48.008 3.2.1.91)
Change-Id: I455ac7695ad33ef9073bea7d1711508717732607
Ranges can now be specified in hexadecimal notation. In this case, only
hexadecimal values are accepted (prefixed with "0x").
In order to allow using a hexadecimal value as an input argument, the
command must specify the range in hexadecimal form.
This way all existing commands (decimal) won't get an hexadecimal value
unless they are further extended in the future, avoiding hard to notice
breakage due to use of stroul() without using base=0 or even worse,
using atoi() directly (which only understands decimal and provides no
error checking mechanism).
A command argument can be expanded to accept both decimal and hex in a
range by means of specifying both, example:
"mycmd (<0-255>|<0x0-0xff>)".
Related: OS#5631
Change-Id: Ia2b7fbbf5502c28374c21dbff548232680da27d4
The documentation for osmo_use_count_get_put states the return value is
"Negative on range violations or USE_LIST == NULL, the use_cb()'s
return value, or 0 on success"
However, the code in _osmo_use_count_get_put doesn't check if uc is NULL
- instead it would crash in osmo_use_count_find() where it is dereferenced.
Add a check for uc and return -EINVAL if it is NULL.
Change-Id: I792563696860a3100e95cafdd5fe57511819ef56
Related: SYS#5895
This reverts commit a4063efa7d.
Reason for revert: It is not possible to guess the IP address
family from uninitialized memory. This function simply glorifies
random noise into an IPv6 address. It makes no sense to have it.
Change-Id: Ifadd614604cf9d0c2ed1a405493c1c3fcb37ae23
This reverts commit e145e28a91.
Reason for revert:
The function osmo_sockaddr_strs_to_str() should not be part of the
osmo_sockaddr_str API. The implementation of this should live in
the function multiaddr_snprintf() added in patch
Icef53fe4b6e51563d97a1bc48001d67679b3b6e9
and should not use dynamic allocation.
Change-Id: I263dfd68313b896c5b474025fbca13c22ce41cdc
Sometimes we receive generic "struct sockaddr" with unspecified (AF_UNSPEC)
address family. It's handy to try to guess
the proper address (there're just 2 variants ATM in most practical applications).
Use the added function to relax input checks in osmo_sockaddr_str_from_in*()
Related: OS#5581
Change-Id: I1c90c56ce832f53b65e0d18d3cea94621c02a69a
This is similar to what we already do between BSC<->MSC to pass Osmux
CID (GSM0808_IE_OSMO_OSMUX_CID).
We now want to support Osmux between BSC and Osmocom BTS, hence add an
extension IE which will be used in ipaccess CRCX messages to tell the
BTS to use Osmux.
Change-Id: I580fe99c01bc0a844d877994ec6cd954310e265d
This feature is used by the BTS to signal to the BSC that it supports
using Osmux instead of RTP on the BTS<->BSC(MGW) data plane.
Related: SYS#5987
Change-Id: Ie79bfb6d0a7a8fe2842d2596b3244e7b74a0d5b6
Allow to restart SNS procedure and initiate a SNS-SIZE procedure with Reset.
SGSN side SNS restart will stop answer on ALIVE and is sending NS STATUS
invalid protocol state.
BSS side SNS restart will send a SNS Size procedure to reset the state.
Change-Id: Icb55d8449908d348ab10572eebcf971737fba00d
The decoding pointer was not increased correctly, ending up in reading
by 1 byte offset for each item in the list.
Change-Id: I16ed9bd65109a7ce32ff43c5789b4544479838e7
Make sure that there is no undefined references in shared libraries.
Inspired by GitHub PR#6 [1] by Michael Dickens. Tweaked by me.
Change-Id: I7ddd6c75935b0f25d78a948f1577656d77a204e3
Related: [1] https://github.com/osmocom/libosmocore/pull/6
This brings the tables up-to-date with Release 16 of both
ETSI 102 221 + 3GPP TS 31.102 specifications.
Change-Id: I7100f326f45f1f8742363eace0531a4ef3f049c0
As was demonstrated in [1], osmo_fsm_inst_state_chg_ms() is broken.
The problem is in state_chg(): this function is passing *milli*seconds
to osmo_timer_schedule(), while it expects *micro*seconds.
Change-Id: Ib0b6c3bdb56e4279df9e5ba7db16841645c452aa
Related: [1] I5a35730a8448292b075aefafed897353678250f9
Fixes: I35b330e460e80bb67376c77e997e464439ac5397
Fixes: OS#5622
Jumping to label 'error' before allocating memory and storing an
address to pointer 'rim_cont_buf' would result in passing garbage
to talloc_free(). Found with clang 14.
Change-Id: I9420615b64d3755fd9131e8561c516c39f83a15b
The testcase in gsm0408_test is still failing because the encoder
produces a different result (with octet 3a present). There is no
way to tell the encoder to use the implicit coding, and in general
this is not that critical, so we can live with that.
Change-Id: I722c168f01bffa915cb155eac234a796549d3762
That code path should not happen since this function is only called for
data frames coming with IUUP_FSM_EVT_IUUP_DATA_IND.
Control frames should come with specific events like
IUUP_FSM_EVT_IUUP_CONFIG_REQ.
Hence, let's add an assert to make sure we early exit if that ever
happens (it shouldn't), instead of carrying on reading uninitialized var
"dt".
Fixes: Coverity CID#272996
Change-Id: Iaeba59bc9ebfe817dbb7528572dc669c010ef14d
a program being developed right now crashed at this point, without
providing any meaningful information on where did it crash.
Change-Id: Ia14f43142e7409f72eb9efd5c9131bea5eed6e82
This patch addes support for GlobalPlatform command. Android is using
STORE DATA commands on a logical channel.
simtrace2-cardem-pcsc is failing otherwise e.g. on an Pixel 4 with Android 12.
Change-Id: Ib734fc852e7b63b9efdc414adccbd796a572eb55
Once the IuUP FSM moved away from Init state, it stopped handling
Initialization messages received from peers and simply ignored them
starting from that point. As a result, if the first IuUP Init ACK it
sent to the peer was lost, the peer would keep retrying with more IuUP
Init and getting no answer.
In any case, it seems possible and desirable that a peer may send an
IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415.
sec 6.5.2.1:
"""
Upon reception of a frame indicating that an Initialisation procedure is
active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole
protocol information contained in the INITIALISATION control frame to the
upper layers. It also stores the RAB sub-Flow Combination set (and thus
replaces a possible previous set) in order to control during the transfer of
user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches
the expected Iu UP frame payload total length). The peer Iu UP entity
receiving the INITIALISATION control frame shall choose a version that it
supports among the proposed versions indicated by the sender for which it
has enough initialisation information.
"""
sec B.2.2 "Initialisation State":
"""
After sending a positive acknowledgement of the last INITIALISATION control
frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that
CN does not know if the initialisation ACK was correctly received by the RNC
(and Initialisation procedure successfully completed) until it receives RAB
assignment response, or use data from the RNC. The CN must therefore be able
to continue receiving INITIALISATION control frames by re-entering the
Initialisation state (from Support Mode Data Transfer Ready State), if the CN
has started to send user data before receiving the indication that
Initialisation was successfully completed
"""
sec B.2.3 "Support Mode Data Transfer Ready State":
"""
In case of handover or relocation, Initialisation procedures may have to be
performed and Iu UP instance may have to enter the initialisation state.
"""
Related: SYS#5995
Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
Those events are not realy used there and they are not even present in
the FSM definition. Let's drop them.
Change-Id: I4beec96ac4bdf047ebf144a8b009b297b47cacdc
The event is expected since the user of the IuUP stack can send a
CONFIGURE.req to transition to state null. The handling was already
there in the function, but the bit was missing in the FSM definition.
Change-Id: I830835a5b8b98f8b91b866f5280f508098c9ae7e
These functions can be re-used for parsing in-band data from DTX
specific frames like SID_FIRST, SID_UPDATE, SID_ONSET, etc.
Change-Id: I0106de7a7f87517006e323299b2dc08457d1c6cf
Related: OS#5570
The new functions accept an additional mode_id poiner, which is
currently set for the following frames: AFS_ONSET, AHS_ONSET,
AHS_SID_FIRST_P2 with N * 16 - M bit pattern.
Also, the new API accepts soft-bits instead of hard-bits.
Converting bits from soft to hard is now performed internally.
Change-Id: Ibcac395f800bb64150c97fcdaca3523ecfc5fcee
Related: OS#5570
The initially merged IuUP API and implementation assumed that RFCI with
ID was always in the position of its ID inside the list of RFCIs. This
was the case for messages sent by ip.access nano3g as well as our own
osmocom implementation. However it was noticed that other nodes from
other vendors actually use other order, as allowed by the IuUP message
format.
Hence, we need to break the assumption and provide explicit ID
information in the list.
NOTICE: This commit breaks API and ABI compatibility with older versions
of libosmogsm, but not with any previous release of libosmocore since
the API is only available in master so far (it was added in
9fe1f9fb0b).
Similary, it's only user (osmo-mgw) only uses the API in master, so
there's no API breakage with older releases.
Related: SYS#5969
Change-Id: Ib21cee2e30bf83dff4e167f79541796007af9845
Parsing of CMI/CMC/CMR from AMR's special DTX frames is currently
not implemented. It's better to keep the old stored value rather
than resetting it to 0 every time we receive such a frame.
Add TODO comments for each DTX frame type.
Change-Id: Ic4edbb8ab873fe0bdd69a8710803628bc4f447d0
Related: OS#5570
As was demonstrated in [1], there is a TCH/AHS specific problem in
libosmocoding causing unexpected BER ~50% in decoded AHS_SID_UPDATE
frames. The reason is that A[H]S_SID_UPDATE employs quite tricky
interleaving algorithm, which is different from the algorithm used
by normal TCH/AHS speech frames or A[F]S_SID_UPDATE frames.
An AHS_SID_UPDATE frame consists of two halves (228 bits each):
+---------+--------------------|---------+--------------------+
| in-band | SID marker | in-band | coded data |
+---------+--------------------|---------+--------------------+
| 16 bits | 212 bits | 16 bits | 212 bits |
The first half contains coded in-band signalling data (16 bits) and
the identification marker (212 bits), which allows to detect that
it's an AHS_SID_UPDATE. This half is carried by even bits of the
first two bursts and odd bits of the last two bursts.
The other half also contains the in-band data (16 bits), while the
remaining 212 bits contain encoded SID_UPDATE (212 bits). This
half is carried by even bits of the last two bursts and odd bits
of the first two bursts.
Current implementation does not use odd bits of the first two
bursts at all, so buffer cB[] in gsm0503_tch_ahs_decode_dtx()
contains only 114 out of 228 bits.
This patch changes the logic, so that gsm0503_tch_ahs_decode_dtx()
would not split AHS_SID_UPDATE onto two frames anymore like its
TCH/AFS equivalent does, but attempt to deinterleave the second
half and attempt to decode the payload immediately.
Change-Id: I8686d895e96fa0e606c1898b6574cc80a8f46983
Related: [1] I434157e2091a306c039123cea08d84bd8533c937
Related: SYS#5853
At the moment msgb_apdu_de(resp) is used to check if the msgb that is
handed over to get_sw is properly populated with data.
However, since msgb_apdu_de() is just adding an offset, which cannot be
0 to ->l2h the returned value also can never be NULL. This means that we
cannot use msgb_apdu_de() to detect if resp contains a nullpointer.
Lets check if ->l2h is not NULL instead. This will make sure that ->l2h
is populated.
Change-Id: I32bc56c9264c01911a4f4b4f911b09e955205010
Related: OS#5560
Both gsm0503_tch_a[fh]s_decode_dtx() functions accept an optional
'dtx' pointer, which is used to indicate type of a received AMR
block to the caller in DTX mode of operation. If not NULL, it's
expected to be updated by gsm0503_detect_a[fh]s_dtx_frame() every
time one of the mentioned functions is called.
However, in case of FACCH both functions return early, so the value
of dtx remains unchanged and thus FACCH frames may be misinterpreted
as AMR's special DTX frames. This is rather critical during the DTX
silence periods, when all special DTX frames (e.g. SID_UPDATE) are
being treated as SUB frames. Each unsuccessful FACCH decoding
attempt will 'poison' SUB measurements, causing unexpected RxQual-
SUB values in the Uplink measurement reports.
Fix this by resetting *dtx to AMR_OTHER in the FACCH specific path.
Change-Id: I2e6f4b748c6445725211e264ab5f3f5a2712087a
Related: SYS#5853
There are two similar values in enum gsm0503_amr_dtx_frames:
* AFS_SID_UPDATE - precursor of SID UPDATE,
* AFS_SID_UPDATE_CN - the actual SID UPDATE.
The former is internally used by libosmocoding to mark the current
frame as a precursor of the actual SID UPDATE frame - the later.
+---+---+---+---+---+---+---+---+
| _ | _ | _ | _ | a | b | c | d | AFS_SID_UPDATE
+---+---+---+---+---+---+---+---+
| a | b | c | d | _ | _ | _ | _ | AFS_SID_UPDATE_CN
+---+---+---+---+---+---+---+---+
This is required because function gsm0503_tch_afs_decode_dtx() is
invoked by TDMA scheduler on every 4th received burst, while the
burst buffer is 8 bursts wide.
Currently, whenever gsm0503_detect_afs_dtx_frame() detects an
AFS_SID_UPDATE frame, we still attempt to decode it as a speech
or data below in gsm0503_tch_afs_decode_dtx(). This is indeed
a bug, which results in unexpected BER values:
* expected BER 0/212,
* actual BER 252/448.
We should return immediately once we have detected an AFS_SID_UPDATE.
This patch fixes unexpected BER-SUB values during DTXu silence periods.
Change-Id: I813081a4c0865958eee2496fe251ae17235ac842
Related: SYS#5853
"""
/libosmocore/src/coding/gsm0503_coding.c: In function 'osmo_conv_decode_ber_punctured':
/libosmocore/src/coding/gsm0503_coding.c:563:31: error: 'coded_len' may be used uninitialized [-Werror=maybe-uninitialized]
563 | *n_bits_total = coded_len;
| ~~~~~~~~~~~~~~^~~~~~~~~~~
/libosmocore/src/coding/gsm0503_coding.c:541:21: note: 'coded_len' was declared here
541 | int res, i, coded_len;
| ^~~~~~~~~
"""
This error is really a false positive. However, it is true that the code
used to be a bit more complex than required, since the 2 later conditions
could be inside the first one.
Let's simply do early termination to simplify the function, and get rid
of the gcc warning.
Change-Id: I31ebf0c4be61daf6395d9a9fac05c7fdceb8bcb9
The point of having a public API to register further stats reporters
is to enable applications or other libraries to do so. As we in
libosmocore don't know anything about the parameters of such a stats
reporter, don't try to do a partial save of them when saving the config
file.
Change-Id: I2986313375daec1c4959a6a914e3fb2980a5d7ca
We should either handle talloc returning NULL, or we should
OSMO_ASSERT(). Doing neither of the two is a bad idea.
Change-Id: I5e8d1cc22cf597f7f50c0f92bf86cb1f1413434c
In many cases, a lot of the counters are zero, and we're likely
not interested in those, but only the non-zero counters. Add a version
of the 'show stats' command which dumps only those items with a non-zero
total value.
Change-Id: Ie4df1c139e3c82deca1dd3cdab5d3909e0513684
It was recently found that several IEs which were added in the header
file were not actually added to the tlv_definition, and hence the tlv
parser failed to decode them. Let's make sure we don't foget to add new
IEs in the future.
Related: SYS#5915
Change-Id: Id8a679ca43eb0fcc4882780e9a95ec21c7f51972
There are cases where we want to be notified of a successful BVC reset,
e.g. for a signalling because we can then start resetting the PtP-BVCs.
With this hook it's now possible to do that.
Change-Id: If240dd13f0f674693018c93390386b2c8afb97af
Related: SYS#5908
pthread_getname_np() is a non-portable extension of pthreads. While
it exists in glibc, for example musl didn't have it until rather
recently (April 2021) and there still hasn't yet been a musl release
with this change, resulting even current OpenWRT not yet supporting
pthread_getname_np.
So let's check if pthread_getname_np is supported, and only use it
in that case.
Change-Id: Ibd01485af24e2fe574006f8d049bf37226dda966
Ever since Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a in 2020
(part of libosmocore >= 1.4.0) we have introduced cpu_sched_vty.c, which
directly uses libpthread. As a result, libosmovty should be using
pthread compiler flags and link against libpthread.
This missing dependency is causing osmocom applications to
fail to link on OpenWRT (at leats for ath79-generic).
Change-Id: I7febbf88cbe61eacd05f46a9316e773b5c148e77
Related: SYS#4986
According to TS 101 318, section 5.2.2, a SID frame is identified
by a SID codeword consisting of 79 bits (r34..r112) which are all 1.
Given that there are no gaps in the codeword, we don't really need
to use bitvec_get_bit_pos() and check each field individually.
This brings additional complexity and negatively affects performance.
Instead, let's use bitvec_get_bit_pos() to check all bits in a row.
Change-Id: I678f8ff92317fe87f1aca511a3a062ad898e55cc
Related: SYS#5853
Make sure that osmo_time_cc counts exactly the same, regardless of a
rate_ctr being present or not. Only skip sending counter increments when
there is no rate counter, do not affect anything else.
In osmo-bsc, we are discussing a patch where an lchan redirects
osmo_time_cc counter increments to different rate counters depending on
its current type. In my comments I am also claiming that osmo_time_cc
works the same regardless of a rate_ctr being present or not. Looking at
the code, this is not actually the case.
Before this patch, when there is no rate_ctr, the reported_sum would
freeze, and as soon as a rate_ctr shows up, all counter increments from
the previous reported_sum would be sent to the newly set rate_ctr.
Instead, we want counter increments to simply be lost while there is no
rate_ctr set. IOW, rate_ctr == NULL should mean >/dev/null.
Related: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347 (osmo-bsc)
Change-Id: I380b28d7ab0a6c8aab6c7e2a64bc73cab14863d2
If there's only a single device with matching VID/PID attached,
we don't need to insist that either the path or the address of the
device matches. Those are only needed to disambiguate multiple
devices with identical VID/PID.
Change-Id: I2ef245a56dfcf22758a0216b86d2a5c602ee5588
Pau Espin
Philipp Maier
arehbein
Vadim Yanitskiy
Neels Hofmeyr
Harald Welte
Keith Whyte
Daniel Willmann
Oliver Smith