The original GSM-FR ECU implementation from 2017 exhibits a lot of
defects, as detailed in OS#6027. Replace it with a new implementation
based on Themyscira libgsmfrp (a complete Rx DTX handler for GSM-FR),
but reduced to just the ECU function, without the comfort noise
generator function. (These two functions are coupled together in the
classic GSM architecture, but not in libosmocodec ECU model.)
Related: OS#6027
Change-Id: I0200e423ca6165c1313ec9a4effc3f3047f5f032
Table 1 in section 6 of 3GPP TS 46.011 (FR codec, substitution and
muting of lost frames) specifies a silence frame in the form of
GSM 06.10 parameters - add a const datum to libosmocodec embodying
this GSM 06.11 silence frame in GSM-FR RTP encoding.
Related: OS#6027
Change-Id: Idf31051ea783435268944286a71d2b0ac342a4b5
* make backend configurable for later
* segmentation callback for chunked streams
* logging target for osmo_io
* support partial writes
Change-Id: I50d73cf550d6ce8154bf827bf47408131cf5b0a0
Related: SYS#5094, OS#5751
Recently added osmo_{fr,efr}_sid_classify() functions classify FR
(EFR) codec frames according to the rules of GSM 06.31 (06.81)
section 6.1.1. Both of these specs also define the term "accepted
SID frame", encompassing both valid and invalid SID frames, but not
regular speech frames. A boolean check for this wider category of
"accepted SID frame" is a useful function - many existing calls to
legacy osmo_{fr,efr}_check_sid() functions should be converted
to this "accepted SID frame" check for full correctness. Add wrapper
functions for convenience, and to allow this transition to be made
without adding bloat to every use instance.
Change-Id: I5e6e91baf18440af01dccc6ac0171476a8a5c71c
We have osmo_mobile_identity_decode_from_l3(), which takes a msgb as
argument, and decodes msg->l3h. Not all callers have their data in this
form. Offer a more flexible API for the same decoding.
For example, before the new function, osmo-hnbgw, which extracts a NAS
PDU from asn.1 packed data for CN pooling, would allocate a new msgb and
copy the NAS data just to pass a data pointer as argument.
Related: SYS#6412
Change-Id: I9bd99ccd01f0eedc091fe51687ff92ae1fdff60b
After this patch, most vty_go_parent() functions are really obsolete, as
originally intended: A vty_go_parent() is only needed if the program
requires an action to run on VTY node exit.
vty_transcript_test.vty shows the fixed behavior.
For details, see preceding patch
"vty: show bug in implicit go_parent_node"
I2472daed7436a1947655b06d34eb217e595bc7f3
Change-Id: Id408c678d18ba19b1c1394c3fb657536153d2094
The difference between the RFC5993 and the TS101318 format is only that
RFC5993 has one additional ToC (Table of contents) byte at the
beginning. However it can be difficult to remember which of the two
formats has the ToC byte at at the beginning and which hasn't.
Let's add a constant that defines the length for both formats so that we
can make it more clear in the code which format we are refering to.
Related: OS#5688
Change-Id: I125ef9cdab98c073971841c175b1a7dcd927f9c2
The old name seems to describe that this function can only be used in
incoming message paths, but it can be used in transmitting context too,
so the param is actually a remote address.
Change-Id: I3f45a4ef339cadd47920ee3b36c38628b38221f6
Those network elements which receive a stream of codec frames that
may come from the uplink of GSM call A and which are responsible
for preparing the frame stream for the downlink of GSM call B
(OsmoMGW feeding TRAU-DL, or OsmoBTS receiving RTP and feeding DL
to its PHY) must be prepared for the possibility that their
incoming frame stream may contain corrupted SID frames, presumably
from bit errors on radio link A. Per the rules of section 6.1.1
of GSM 06.31 for FR and GSM 06.81 for EFR, SID frames with just one
errored bit are still to be accepted as valid, whereas frames with
more corrupted bits which are still recognizable as SID are classified
as invalid SID.
In the case of a TrFO call, the entity switching from leg A UL to
leg B DL is responsible for *not* transmitting invalid SID frames
on the destination leg (they should be treated like BFIs), and any
deemed-valid SID frames that are forwarded should be preened,
correcting that one bit error they may exhibit. The functions
added here provide that functionality.
Change-Id: Iec5c1f2619a82499f61cb3e5a7cd03ff0f020ad8
The existing osmo_{fr,efr}_check_sid() functions detect whether or not
the frame of bits passed to them constitutes an absolutely perfect
SID frame, with each of 95 SID code word bits set to 0 for FR or
1 for EFR. However, the rules of section 6.1.1 in GSM 06.31 & 06.81
allow up to one bit to be in error for the frame to be accepted as
valid SID, and the same rules also call out a third state (invalid SID)
in between valid SID frames and other frames that are classified as
speech. Support for these rules cannot be patched into those familiar
osmo_{fr,efr}_check_sid() functions because doing so would alter
behavior of existing programs, hence new functions need to be added.
The new functions that implement the exact rules of section 6.1.1 of
GSM 06.31 and 06.81 will need to be used if anyone needs to construct
an outgoing TRAU-UL frame (for example, as part of implementing
TS 28.062 TFO), and they are expected to be useful as part of more
sophisticated ECU implementations.
Change-Id: Ie91a52c6f04689082d8004311517d8ce0c544916
Including this header just for TALLOC_CTX is an overkill, we use
'void *' for talloc contexts in nearly all other Osmocom projects.
Change-Id: I4b9ffd7a329081df3d2c0b0ee8698a3cf759e94e
Related: OS#5960
Previously existing code provides osmo_fr_check_sid() and
osmo_hr_check_sid() functions for FR1 and HR1 codecs; these functions
are used by various RTP-touching programs in the Osmocom CNI suite
when they need to differentiate between speech and SID frames.
However, there was no corresponding function of this form for EFR
codec, with the result being that the same programs that handle
speech vs SID distinction correctly for FR1 and HR1 fail to do so
for EFR.
The present change adds an osmo_efr_check_sid() function to libosmocodec
that fully mirrors previously existing osmo_fr_check_sid() and
osmo_hr_check_sid(), providing the first step toward more correct
EFR handling in programs where a SID check may be needed.
Change-Id: Iab9fb60028f4135375287bc42f5da7ca7838b5f0
The convenience wrapper relieves the caller from manually resolving
the individual counter, and instead specify just the counter group
and the index.
Change-Id: If93e8b4fb0b86a87358f32d2b45438ca1887e9f3
The values are defined in 3GPP TS 44.018, section 10.5.2.6. Only the
radio interface rates for CSD (GSM48_CMODE_DATA_*) are given, but the
respective service rates can be found in 3GPP TS 45.003.
Change-Id: I716027f73ab6f20037f6de16e4a3740811aa38a2
Related: OS#1572
The decoding path of TLV_TYPE_SINGLE_TV is wrong, since it is not
shifting right the tag before using it. On the other hand, the encoding
path (tlv_encode_one) is doing that, so it is clear there's a bug.
It seems that in order to workaround the bug some IEs in gsm_04_08.h (TS
24.008 and TS 44.018) were defined incorrectly (eg 0x80) while the spec
clearly assigns eg. "8" to it, and makes sure no full byte IEI collides.
Some other IEIs like GSM48_IE_GMM_CIPH_CKSN which are also of the same
type were already correctly defined as 0x08.
Change-Id: I799e35dc8d4d153fa63bf50563a5482cdf4de2d7
3GPP TS 44.021 specifies the format for modified V.110 frames as used
on the GSM air (radio) interface. Implement encoders and decoders for
this modified V.110 format.
Related: OS#1572
Change-Id: I60a2f2690459359437df20cf4da9043fa7c3ad11
V.110 defines a B-channel protocol for transmission of synchronous and
asynchronous serial data of V-series interfaces via terminal adapters
over ISDN.
Let's add (unoptimized but easy to debug) functions for encoding and
decoding of V.110 frames for various bit-rates.
Related: OS#1572
Change-Id: I1b5fd3847d3bfb0a0f763e0574893962ec699680
As per gnu extension doc ->
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Thread-Local.html :
".. When used with extern or static, __thread must appear immediately
after the other storage class specifier."
Change-Id: Ied1d3cf3ad2ff424bd0a2682aff29a8939b419b8
Use the same 32k0, 29k0, 14k4, … notation for GSM0808_DATA_RATE, as
it is already used in RSL_CMOD_CSD. As GSM0808_DATA_RATE enumes were
just added to libosmocore and aren't used yet, don't add backwards
compatible defines.
Related: OS#4393
Change-Id: Ia965cdd9f53af756e5ffaff9b8f389b5ad629969
Use the 32k0, 29k0, 14k4, … notation instead of 32000, 29000, 14400 etc
to make transparent data enums with non-transparent data enums where
this notation is already used.
Related: OS#4393
Change-Id: I7b7c8f175f349811b17a3db68a57577bd3f1d2df
Provide the definitions from 3GPP TS 28.062, Table 7.11.3.1.3-2 as
generally usable API.
Likely users:
- upcoming patch to improve conversion between S0-S15 and MultiRate
config, I900fda192742fa8f6dd54e9131ef1704b14cc41a
- osmo-msc to figure out conversion between SDP AMR mode-set and 3GPP TS
48.008 Permitted Speech S0-S15.
- osmo-bsc to choose AMR modes for channel activation from cfg /
permitted speech from MSC.
Related: SYS#5066
Change-Id: Icef7dd626d3d4641c66b8dd87e2047fc0ab547d1
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
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
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
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
Previous SI10 patch added function without exposing it via public header.
Let's fix this.
Fixes: 600d4eeab7
Change-Id: Ia7530e9c8a21f6f99f3aac7baea5cbb38763c4f3
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
Write a new API and implementation to manage network namespace related
operations.
This will be used by the upcoming tundev module.
Change-Id: I0f2fba2fa42250a07211a7b7f479498f27c529da
There are some parts of libosmogsm which are not really GSM specific,
but rather ISDN bits that were inherited by GSM. This includes the
I.460 multiplex as well as the core LAPD protocol.
Let's move those bits to its own libosmoisdn library, before we add
more ISDN specific bits to the wrong place.
Backwards-compatibility is created by making libosmogsm depend on
libosmoisdn, and by providing wrapper include files for source
compatibility.
Change-Id: Ib1a6c762322fd5047be3188b1df22408ef06aa50
When someone is modifying a given library there's no need to be looking
at a common file contains tons of lines from different libraries.
Furthermore, this removes the need of "nobase" autofoo prefix, hence
following the usual directive of having one Makefile per directory.
Change-Id: I785891c2f89114bf8303c799094b637d3d25ac71
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
C/C++ only implements a so called "truncated modulo" function. Lets also
add a floored and an euclidian modulo function to be more complete.
The functions will be used to generalize the following Change:
I5fb2b0ada8d409730ac22963741fb4ab0026abdd
Change-Id: If61cd54f43643325c45f64531c57fe4c5802a9cf
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
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
We've started to encapsulate a varieth of ISDN related formats
as sub-types to GSMTAP_TYPE_E1T1 for quite some time. Let's add
some more formats, such as V5EF, V.110, V.120, X.75 and H.221
For the HDLC based V5EF, V.110, V.120 and X.75 the payload format is
clear. For V.110 and H.221 we will need to specify how the actual
payload looks like.
Change-Id: I8dee0f730cf91d6f9133d5c57f653e669ec8d598
The newly-introdiced pragma to disable strict-prototypes checking works
in C, but creates a -Werror=pragmas error in C++ code:
In file included from osmo-trx.cpp:45:
/build/deps/install/stow/libosmocore/include/osmocom/vty/logging.h:10:32: error: option
‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [-Werror=pragmas]
#pragma GCC diagnostic ignored "-Wstrict-prototypes"
So let's also suppress those errors for that one line of code...
Change-Id: I85596cf4538d7a8c522f4bce1620a2d19e2a910e
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea0). However,
its declaration in C file didn't contain "(void)", which meant the
number of parameters is undefined and thus compiler doesn't complain.
However, in recent Change-Id I84fd99442d0cc400fa562fa33623c142649230e2
we changed the declaration to '(void)' to allow building with
-Wstrict-prototypes. This caused downstream build-failures of osmo-mgw (1.4.0)
and osmo-e1-recorder (master).
So let's make one very small-scoped exception here.
Change-Id: Iadb54848b67db937b640dc2102dddb6e708a6a9f
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 macro msgb_sms() is basically an alias for msgb_l4(). Lets use
msgb_l4() in msgb_l4len() instead of msgb_sms().
Change-Id: I90d4f5c07fbaadd9e022752a2c64c4855f0b4227
When any of l1h, l2h, l2h or l4h is set to NULL (which is the default
for newly allocated message buffers). Then the msgb_lXhlen() functions
will return the address value of msgb->tail. This can lead to unexpected
results at a later point. We should have an OSMO_ASSERT to catch the
problem early.
Change-Id: I1795c559f190713ebbabfbabf3453ab77da46a49
Related: OS#5645
This makes it possible to pass expressions to the abovementioned
macros without any side-effects. Strictly speaking, this is only
necessary for argument 'b' of GSM_TDMA_FN_SUB, but let's also add
them to GSM_TDMA_FN_SUM for consistency.
Change-Id: I7f26156813139bbb7774e1eb342c91bc84fdad38
While at it, drop 8-1 in favour of 7. I don't think it is really more
understandable for readers to see some subtraction there...
Change-Id: I8b21eba9b9aa952f86abe7a6d4cdb1d1a61d9deb
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
I was warned by gcc about comparing a pointer with an integer when using
TLVP_PRESENT with something like:
bool expect = ...;
if (expect != TLV_PRESENT(...))
That's indeed dangerous because TLV_PRESENT is considered to return a
boolean, as opposite to TLV_VAL.
Change-Id: I45cc2745c695e30c37b10f592903ec3775a55492
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
Mychaela N. Falconia
Harald Welte
Neels Hofmeyr
Philipp Maier
Pau Espin
Vadim Yanitskiy
Eric Wild
Oliver Smith
Daniel Willmann