This patch is a preparation for the upcoming change making use of
the built-in static_assert(), which is available since C11.
When using built-in static_assert(), gcc v12.2.1 fails:
iuup.c: In function 'osmo_iuup_msgb_alloc_c':
iuup.c:194:33: error: expression in static assertion is not constant
194 | osmo_static_assert(size > IUUP_MSGB_HEADROOM_MIN_REQUIRED, iuup_msgb_alloc_headroom_bigger);
../../include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
This one is not really a *static* assert(), because it operates on the
user supplied argument 'size', which is not guaranteed to be an integer
literal. Neither it triggers a compilation failure as expected, nor
does it abort at run-time. It simply does nothing.
Change-Id: I53db679728250e0c60ed277efb18142073ffe9c4
This patch is a preparation for the upcoming change making use of
the built-in static_assert(), which is available since C11.
When using built-in static_assert(), gcc v12.2.1 fails:
include/osmocom/core/msgb.h: In function 'msgb_alloc_headroom_c':
include/osmocom/core/msgb.h:532:33: error: expression in static assertion is not constant
532 | osmo_static_assert(size >= headroom, headroom_bigger);
include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
include/osmocom/core/msgb.h: In function 'msgb_alloc_headroom':
include/osmocom/core/msgb.h:554:33: error: expression in static assertion is not constant
554 | osmo_static_assert(size >= headroom, headroom_bigger);
include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert'
86 | static_assert((exp), "(" #exp ") failed")
| ^~~
These are not really *static* assert()s, because they operate on the
user supplied arguments 'size' and 'headroom', which are not guaranteed
to be integer literals. Neither they trigger compilation failures
as expected, nor do they abort at run-time. They simply do nothing.
Change-Id: I17ef4f3283ce20a5b452b7874c826acfb02a0123
This patch adds the convolutional code definitions for CSD (circuit
switched data) on TCH/F channels with user bit rates of 2400, 4800, 9600
and 14400 bps.
Related: OS#4396, OS#1572
Change-Id: I412131d7ee2e676402bf8d88394af17c4447b664
In the unit tests we're using memcmp() to compare decoding results
against the expected results. This is a reasonable approach, but
there is a pitfall: not only the struct fields are compared, but
also the padding bytes preceding/following them.
When using gcc's extension zero-initializer {} or even the standard
approved { 0 } zero-initializer, padding bytes are not guaranteed
to be zeroed. Even worse, according to [1], the init behavior is
inconsistent between gcc and clang and optimization levels.
All decoding functions in {bsslap,bssmap_le}.c currently use gcc's
extension zero-initializer {}. This is not a problem when building
with CC=gcc, but with CC=clang the bssmap_le_test fails due to
mismatch of padding bytes in struct lcs_cause_ie:
[4] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[5] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU
[6] PERFORM LOCATION ABORT: ERROR: decoded PDU != encoded PDU
Out of the known struct initialization methods, only the memset()
has consistent behavior and sets all bytes to zero, including the
padding ones. Using it fixes the bssmap_le_test for CC=clang.
[1] https://interrupt.memfault.com/blog/c-struct-padding-initialization
Change-Id: Ib16964b16eb04315efc416164ed46c15b5dc7254
Fixes: OS#5923
Lets get rid of the magic number in struct osmo_i460_timeslot and
replace it with a define constant.
Change-Id: Id3a3782927c7dcbc873223d56129f291c04fee26
Related: OS#5198
It already happened several times [1][2] that new features were added
to enum osmo_bts_features, but the osmo_bts_features_{descs,names}[]
were left unchanged. Let's add static_assert()s to prevent this.
Change-Id: I8e3b7d3996e9f3e16c6d4e0d1d406fa538d5e9be
Related: [1] f4f5d54ea2
Related: [2] 18c6a8183f
Let's disambiguate. Our existing OSMO_AUTH_ALG_XOR was always only
the XOR-3G algorithm. Now that we recently introduced XOR-2G,
let's rename (with backwards compatibility #define).
Change-Id: I446e54d0ddf4a18c46ee022b1249af73552e3ce1
We've so far only been supporting XOR-3G algorithm as specified
in TS 34.108 (in both 3G and 2G-derivation mode).
However, XOR-3G used for 2G auth is different from the XOR-2G algorithm
as defined in Annex A of TS 51.010-1. Let's add support for that one,
too.
Change-Id: I0ee0565382c1e4515d44ff9b1752685c0a66ae39
According to 3GPP TS 48.008 V16.0.0 § 3.2.2.11, the "Channel and rate
type" fills the whole octet 4, so don't cut it off.
This fixes decoding of e.g. GSM0808_SIGN_FULL_PREF_NO_CHANGE, which I
noticed while writing a test.
Related: OS#5911
Change-Id: Ib5fba18eb82736c4f52f315ae1197159b7090e69
Currently there's a big mess where include dir osmocom/gprs/ is used by
both libosmogsm and libosmogb.
Most of the header files under osmocom/gprs/ are actually all the
headers of libosmogb (there's no osmocom/gb/ dir). But a couple files
are actually RLC/MAC (TS 44.060) related are are also stored in there.
Those files have no relation/use in Gb, and are actually interused with
GSM (eg System Information 13 Rest Octets).
Hence, it makes sense to have the RLC/MAC related parts inside
osmocom/gsm/ as they should be in libosmogsm (and they actually are,
see gprs_rlc.h function implemented in src/gsm/gsm48_rest_octets.c).
The fact that some libosmogsm headers were placed in osmocom/gprs
instead of osmocom/gsm already created some issues, like
libosmocore.spec.in putting "%_includedir/%name/osmocom/gprs/" under
libosmogb, which is wrong.
As a first step to fix the mess, we move the 2 RLC/MAC headers currently
under osmocom/gprs/{gprs_rlc,protocol/gsm_04_60}.h under a single header
gsm/protocol/gsm_44_060.h
The two old headers are left existing for backward compatibility and now
simply include the new libosmogsm header, plus a warning asking users to
switch to the new header so we can eventually get rid of them.
This means libosmogb depends on libosmogsm, which is fine and was
already the case beforehand (libosmogb using functions like
gsm48_encode_ra() and linking against it in src/gb/Makefile.am).
Change-Id: I70cc21bf25a7081070738abacb409ed19094c3b2
Those allow selecting source host:port for UDP socket sending GSMTAP data.
It's handy when you have several GSMTAP sources operating simultaneously.
Change-Id: I51b3604ba79e42c474aa17007e7e308a12afcea8
There may be situations where we must check if there are still I.460
subchannels active, so lets make the function osmo_i460_subchan_count
public
Change-Id: I0454ffe5809f21504c1e263a781c06596d452d4b
Related: OS#5198
Rename contrib/struct_endianess.py to contrib/struct_endianness.py, and
fix the typo everywhere. This is in preparation to call the script in
CI on all repositories.
Related: OS#5884
Change-Id: Idc4af9098ba1de26243464c772d6ea8be330646a
When a user reports a memory leak with a talloc report, this script is
useful to quickly get a handle of what is being leaked. The alternative
is eyeballing the talloc report for a very long time.
Change-Id: I5b3242dd6e0649925ac6abfd1e96625c682b8934
Add it, so a follow-up patch can use it in gsm0808_dec_channel_type
where 3GPP TS 48.008 § 3.2.2.11 refers to "if octet 3 indicates speech
or speech + CTM Text Telephony".
Related: OS#4393
Change-Id: Iaf12202c89b68290c2121bc016d08b9200a7278a
Stop iterating if the extension bit (0x80) is set but elem is too short
to read another byte.
Related: OS#4393
Change-Id: Id37109dba0f5d40f4b83f0cef9b1dbd9d6bb2c68
Previous SI10 patch added function without exposing it via public header.
Let's fix this.
Fixes: 600d4eeab7
Change-Id: Ia7530e9c8a21f6f99f3aac7baea5cbb38763c4f3
Let libosmocore-dev depend on libmnl-dev, as we build the debian package
without --disable-libmnl and so libosmocore.pc lists libmnl in requires.
This patch should fix the following error when trying to build any
debien package depending on libosmocore-dev:
Package 'libmnl', required by 'libosmocore', not found
A similar change in the rpm spec is not be needed, as rpm adds depends
from pc files automatically.
Fixes: 4eb89afa ("configure --enable-libmnl: Add libmnl to libosmocore.pc.in Requires")
Change-Id: I7fd578fcc22c0ea6ac04bdc26dc1741e4e26767c
netdev.h doesn't expose its use of libmnl publicly. It could actually be
implemented using other subsystems internally, such as ioctl() or other
OS-dependent APIs.
Hence, if --disable-libmnl is used, still make the API available but
make it fail with -ENOTSUP on functionalities which are only implemented
through libmnl so far.
Change-Id: I62bdea075afb9e0cc2bbcec6dd3a930e8f7bbc40
This module provides several operations on network devices
(interfaces), like monitoring changes, setting addresses, routes, link
state, etc.
It also supports managing network interfaces on several different netns
concurrently.
These functionalitites will be used by the tun module included in a
follow-up patch.
Change-Id: I7a00c0445a89e088676a4897061b65196d9197f1
Vadim Yanitskiy
Harald Welte
Philipp Maier
Neels Hofmeyr
Oliver Smith
Pau Espin
Max