Let the API user pass their own default config when allocating
a soft-UART. Make the default config publicly accessible.
Change-Id: I7e78d60c747a8805064d5e4bacfd47a30bc65cba
Related: OS#4396
The problem with a single function controlling both Rx and Tx is
that enabling/disabling one of the directions requires knowing
state of the other one. In other words, disabling Tx requires
knowing the state of Rx, which may be inconvenient.
Change-Id: Ieacc7e639304eeb14fdb298c7e14d772c136ca6e
Related: OS#4396
This patch brings a Work-in-Progress implementation of the software
UART (Universal Asynchronous Receiver/Transmitter) to libosmocore.
Not only it will be useful in the context of retro-networking, but
also it's needed for the MS-side CSD implementation (see OS#4396).
It should be noted that the definition of struct osmo_soft_uart
is intentionally kept private, since the API is not stable yet.
Currently, the following limitations apply:
* Only the receiver part is implemented, the transmitter is TBD.
* Parity checking is not implemented in the receiver part.
* Software flow control is not implemented.
These missing components will be addressed in subsequent patches.
Change-Id: I2ca95963fd5852ddb89bdd35b86b31489127fe84
- Use forward decl. of struct gsmtap_inst in header
- Remove 'static inline' attributes from gsmtap_inst_fd() declaration,
move function definition to gsmtap_util.c and mark it as deprecated
- Add gsmtap_inst_fd2() as replacement for gsmtap_inst_fd()
Related: OS#6213
Change-Id: Ibe1a51205a6df764571b6d074e365825555609a5
These APIs are used to bind or unbind an active socket adding or
removing addresses from the existing set.
Related: OS#6077
Change-Id: Ifc6e7d643c2a0c53f479bfd0d5c36d08c0c01953
- Remove osmo_io_init() from header, since it has no function definition
- Add osmo_iofd_init() to header
Change-Id: I77f7ae2b211507f420d87c484ec75ee054fceb63
It's fine changing the define because due to the previous error it means
basically that it was never used so far, because using it triggers a
compilation error.
The error was introduced because I ended up not using this in the past
after submitting this code, and now that I want to use it it went
noticed that it fails.
Change-Id: Iee361d740845257fa62c9093e30e8079fa933827
We need this function in:
* osmocom-bb.git for trxcon and l1gprs,
* osmo-pcu.git replacing fn_cmp().
Change-Id: I9590f2e836fc48650decf1564b6ab46306c4fe2d
Related: OS#5500
Dequeue and free any excess messages, in case the new queue length
is shorter than the old.
Related: OS#5774
Change-Id: Ibfe51a2faf29f8ae160a9c330c9af0d09b5a9002
BCC and GCC share same call states, except for two states that have same
value, but different state names and conditions.
Related: OS#5364
Change-Id: I2180b43b940542565188f52c554c960858fe2a95
This allows setting several socket paramets which can only be set before
SCTP INIT phase (connect()).
Since no release with osmo_sock_init2_multiaddr2() happened yet, we are
allowed to extend struct osmo_sock_init2_multiaddr_pars without bumping
the version field.
Related: SYS#6558
Change-Id: Ibc55932d954279927d1e70ccce1e8bf32b180d44
The OSMO_SOCK_F_SCTP_ASCONF_SUPPORTED flag was added recently to enable
use of ASCONF in osmo_sock_inti2_multiaddr. Since we didn't release yet,
we are still in time to get rid of this flag.
It turns out that we'll want to add more features which must be set
before SCTP INIT (connect()) time, like setsockopt SCTP_INITMSG, which
in turn contains a struct with several parameters.
Hence, adding flags for all those makes no sense.
Instead, add a new API which allows passing an extensible struct which
allows much more fine-grained setup from the caller.
The new struct "pars" parameter is non-const on purpose, in order to be
able to extend the struct in the future if we wish to get/obtain some
data from the socket.
Related: SYS#6501
Related: SYS#6558
Change-Id: I1f6fd09a79b0a2bd794e5669d933be25bbf1eeaa
This reverts commit 54b1b3be37.
osmo-bts is forwarding the msgbs as they come from lapdm to the RSL on
the wire, which means we end up sending the osmocom-specific IEs on the
wire, something which was not envisioned when adding this IE.
Change-Id: Id9029ef378970322063478e9ce888daf335d6103
Related: OS#6142
This reverts commit d981794113.
osmo-bts is forwarding the msgbs as they come from lapdm to the RSL on
the wire, which means we end up sending the osmocom-specific IEs on the
wire, something which was not envisioned when adding this IE.
Change-Id: I0ab0d5b545b4862e72eb1842edd07ca2e4955311
Related: OS#6142
This makes it possible to track GSM time in the upper layers.
The existing RSL_IE_FRAME_NUMBER and RSL_IE_STARTNG_TIME cannot be used
there, since those are 16bit fields containing Relative FN values.
The IE needs to be added before the L3_INFO one, because user code
usually assumes the msgb->l3 pointing to L3_INFO value extends until the
end of the message, using msgb3_len(msg). Regarding having an extra IE
at the middle, it's not a big problem since the libosmocore version
submitting this commit to the upper layers is the same which will also
be parsing it through rsl_tlv_parse() later on by the app.
Related: OS#3626
Change-Id: Id62c18f49f270449067b25b7104eb8b47f1955ec
This will be used in RSLms to provide Absolute Frame Number information
of the primitive indications being sent to upper layers, so that it's
possible to track GSM time in the upper layers.
The existing RSL_IE_FRAME_NUMBER and RSL_IE_STARTNG_TIME cannot be used
there, since those are 16bit fields containing Relative FN values.
Related: OS#3626
Change-Id: Ia28caa24dd141b1162b6e11500d753353fe6500d
The SCTP_ASCONF_SUPPORTED sockopt, which enables ASCONF features
for the SCTP associations managed by the SCTP socket, gets its default
value from to sysctl "net.sctp.addip_enable", which, at least up to
current kernel 6.4.8 is set to "0" (disabled) by default.
As a result, ASCONF related features such as
setsockopt(SCTP_SET_PEER_PRIMARY_ADDR) fail with -EPERM
since ASNCONF extensions where not negotiated during the SCTP init
handshake.
This commit adds support for setting SCTP_ASCONF_SUPPORTED=1 during
socket creation, since that needs to be applied before the first
bind()/connect() (before first assoc is created).
Furthermore, for ASCONF features to work properly, the assoc also needs
to announce/use the AUTH extension, as per RFC5061 section 4.2.7.
Otherwise, the peer receiving an SCTP INIT with
ExtensionFeatures=ASCONF,ASCONF_ACK but without AUTH, will reject the
assoc with an ABORT since it's not complying with spec (this behavior
can be tweaked through sysctl "net.sctp.addip_noauth_enable").
The AUTH extension is enabled through sockopt SCTP_AUTH_SUPPORTED, and
its default value is that of sysctl "net.sctp.auth_enable", which is
also disabled (0) by default.
Kernel support for those is relatively new:
SCTP_FUTURE_ASSOC added in: 80df2704a375bb4b3c9c5cce9c00052361b16d61
Follows: v5.0-rc4
Precedes: v5.1-rc1
SCTP_ASCONF_SUPPORTED added in: df2c71ffdfae58961981d7cbcccea93688fc4e96
Follows: v5.3-rc5
Precedes: v5.4-rc1
SCTP_AUTH_SUPPORTED added in: 56dd525abd56f7acd7b44a52935726e3ada4916c
Follows: v5.3-rc5
Precedes: v5.4-rc1
Related: OS#6076
Change-Id: Iac07031927b66a9d32d2bb2faab817e4c922a359
Implementation ported from osmo-pcu.git
e98b315d12fb009359410809f4169f9380f3d933, function bts_rfn_to_fn().
This functionality can be used by osmo-pcu, libosmo-gprs or any other
related code which needs to handle RFNs.
Change-Id: Ib71e8da976f6cc84c3a4ab17b0a8c2101492e243
This field will be used in follow-up commits to provide FN information
in RSLms primitives towars upper layers. This is needed for instance on
the MS side when a CCCH_DATA.ind is received containing a TBF ImmAss
with a relative FN indicating the Starting Time. Without tracking FN
advance, the uppers layers are not capable of figuring out the absolute
FN of the TBF Starting time.
The struct lapdm_msg_ctx is not really used outside of libosmocore, so
we are safe extending it.
Related: OS#3626
Change-Id: Icf986f4202703eb452bedc1b749bb8ce0c73706f
msgb_tv32_put() already exists, but msgb_tv32_push doesn't.
The tv16 counterparts are already present, and having to pass 32bit
integers is also quite common, so let's add an API for it.
Change-Id: I68d5693a18d55ce8d0647359044157d7e5bfae50
We have a decoder for RIM ROUTING INFORMATION (bssgp_parse_rim_ri),
let's also have a decoder for RIM ROUTING ADDRESS (bssgp_parse_rim_ra.
Related: OS#6095
Change-Id: Ibca1f08906c4ffeecdae80d4e91c6c7b05fe4f8a
The API function bssgp_tx_rim() accepts decoded RIM PDU structs, encodes
them and eventually sends them. However, there may be cases where the
RIM PCU already exists in its encoded form. (This is in particular the
case when the RIM PDU is forwarded from GTP to BSSGP)
Lets add an API function bssgp_tx_rim_encoded to allow sending of
already encoded RIM PDUs
Related: OS#6095
Change-Id: Id4a793bbaf32d7b9d894dcc5be3faaf2f2d91d82
Under certain cases, gcc version 13.1.1 20230714 catches the fact that
the pointer being passed cannot be null, (eg local variable struct
osmo_sockaddr_str addr_str passed as &addr_str), and errors about
checking nullability of a pointer which cannot be null.
"""
/include/osmocom/core/sockaddr_str.h:63:10: error: the address of 'addr_str' will always evaluate as 'true' [-Werror=address]
63 | ((R) && (R)->af == AF_INET6)? "[" : "", \
| ^
"""
Let's add a macro which can be used for pointers known to be there (tbh,
I'd expect that to be the usual case in most code paths). Using this new
macro should be more optimal in those cases, and avoid gcc erroring.
Change-Id: I59c7b05450cb463d2e87ddb022f0b6ba7109d398
As per 3GPP TS 48.008, section 3.2.2.103, the "Codec Type" field may
contain either a certain 3GPP Speech Codec Type directly (4 bit value),
or the so called "Codec Extension" = 0xFh, in which case the real Codec
Type follows in the next octet as "Extended Codec Type".
CSD is such an example, the encoding is defined as follows:
8 7 6 5 4 3 2 1
+----+----+----+----+-------------------+
| -- | PI | PT | -- | 0xFh |
+----+----+----+----+-------------------+
| Extended Codec Type (CSData) |
+----+----+-----------------------------+
| R2 | R3 | |
+----+----+-----------------------------+
CSData is coded with 0xFDh or '1111 1101' (0xfd).
Let's have the "Codec Extension" value clearly defined in the header
file, but intentionally separate from the other GSM0808_SCT_* values.
Change-Id: Iafaa25070684d2ba400c75fa33e803651a5ce857
Related: OS#6110, OS#4393, OS#4394
It has been decided that the segmentation callback be changed
and moved to libosmo-netif, so we remove it here.
This reverts commit 2c59d1285e.
Related: OS#5753
Change-Id: I9b380326c63587fc79d6a5d8cd458188074fc55d
This is used for parsing e.g. the ipa header and setting msg->cb.
Guard against segmentation_cb changing msg->data in
iofd_handle_segmentation().
Change-Id: Idd2115baae98a7818aabb26232d4423d2d48fb5c
See 3GPP TS 45.003 section 3.6. This channel mode is a bit special,
because unlike the other CSD specific channel modes it's interleaved
over 8 (not 22!) consecutive bursts, just like TCH/FS.
Change-Id: I4685376c8deb04db670684c9ebf685ad6fc989fa
Related: OS#1572
Put the 'm' pointer into braces, so that it's possible to pass an
expression to these macros, e.g. a pointer-to-pointer dereference.
This patch makes the following example compile:
struct msgb **msg = /* ... */;
return msgb_l2(*msg); /* <-- currently this fails */
Currently it fails with the following error:
error: ‘msg’ is a pointer to pointer; did you mean to
dereference it before applying ‘->’ to it?
Change-Id: I2d19ea3c09ff9499314255d408fb71c07148fe25
Don't call write_enable() in osmo_iofd_register(). This was used to
detect whether a socket is connected or not, but would always be
enabled, even on unconnected sockets. Instead make this behaviour
explicit by calling osmo_iofd_notify_connected().
Change-Id: Ieed10bc94c8aad821c0a8f7764db0e05c054c1e3
This API is useful for checking whether a Downlink CCCH block belongs
to PCH or AGCH. We need this API in osmo-bts.git and osmocom-bb.git.
Change-Id: I8cbd31226754e95887358ed83a928e2f567f4cf3
Related: OS#5500
The ECU API of libosmocodec is unfortunately a peculiar non-3GPP
entity: an ECU by itself, severed from Rx DTX handler functions,
which is a logical/conceptual function with no place in the standard
3GPP architecture. The closest thing that exists in the standard
architecture is the TFO spec (TS 28.062 section C.3.2.1.1) calling
for an ECU application, but not comfort noise generation, in the case
of destination leg doing DTXd - but even then it is not a totally
"pure" ECU like libosmocodec API, it is an ECU plus a SID preener,
and the SID preening transform is not possible within the constraints
of existing libosmocodec ECU API. Hence truly correct handling of
corner cases, particularly invalid SID, is sadly impossible in the
current libosmocodec ECU framework.
The only current user of this API is the UL path in osmo-bts-trx;
however, as described in OS#6040, we would like to move that ECU call
from osmo-bts-trx model-specific code to the common layer of osmo-bts.
The current osmo-bts-trx incarnation avoids the SID handling problem
by suppressing the call to ECU frame_out() after any SID (valid or
invalid) was received on the air, thus pausing the RTP stream instead
of emitting ECU output during DTXu pauses. We would like to retain
the same behavior when we move this ECU call to the common layer,
into its proper place _after_ the link quality check in l1sap - but
the current method of flagging post-SID state in osmo-bts-trx will
no longer work on the other side of that link quality check.
As a workaround, have the ECU remember via a separate Boolean flag
whether it is in post-SID state or not (was the most recent frame_in()
any kind of SID or not), and provide is_dtx_pause() method to
retrieve this flag - the relocated ECU call in osmo-bts UL path
will use this new is_dtx_pause() method call to decide if it should
call frame_out() or switch to pausing RTP output.
Related: OS#6040
Change-Id: I3857be84bba12aaca0c2cca91458b7e13c5a642a
This allows renaming the iofd at any later point in time. This is useful
for instance if the parent object holding the iofd changes its name.
Change-Id: If2772a3ccaa98616e0189862a49ab0243435e343
Add segmentation callback to be used by the streaming backend of libosmo-netif
Related: OS#5753, OS#5751
Change-Id: I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
This message is (the only message) used on the NCH to notify the MS
about all currently ongoing voice group/broadcast calls.
Change-Id: Iff1555a2914ce0a1ead6ab883498adb2c33b135e
Code review for [1] has asked for providing proper API for struct
osmo_routing_area_id.
For historical reasons, we have struct gprs_ra_id and
struct osmo_routing_area_id serving the exact same purpose: represent a
decoded 3GPP TS 24.008 § 10.5.5.15 Routing area identification.
The "better" one is struct osmo_routing_area_id: it allows using API
like osmo_plmn_cmp(), because it is made up of meaningful sub-structs.
Implement de/coding using the functions already available for the
sub-struct osmo_location_area_id, and simply add the RAC.
Add a test in gsm0408_test.c.
Note that other utility functions are already available for struct
osmo_routing_area_id: osmo_rai_name2(), osmo_rai_cmp().
There is no real need to deprecate struct gprs_ra_id, because there is
not really anything wrong with it. It just isn't as well integrated with
other utility API as struct osmo_routing_area_id is. Just add comments.
[1] osmo-hnbgw.git:
cnpool: extract Mobile Identity from RANAP payload
https://gerrit.osmocom.org/c/osmo-hnbgw/+/33133
I373d665c9684b607207f68094188eab63209db51
Change-Id: Ic5e0406d9e20b0d4e1372fa30ba11a1e69f5cc94
I was the one who suggested adding this attribute during code review,
and now, having realized it was a bad idea, I am removing it. The
problem is that this attribute spams compilation logs of projects
including file <osmocom/crypt/auth.h>, even if the deprecated struct
is not used directly at all.
Change-Id: Ia5d365206207872d5d3fdd4ae40273eab909fb33
Fixes: 08450c9e "libosmogsm: Support authentication with 256-bit K and/or OP/OPc"
The TUAK algorithm is specified in 3GPP TS 35.231, 232 and 233 and
intended as an alternative to MILENAGE. It's based around the
cryptographic function of KeccakP1600, which is part of SHA-3.
This patch adds support for TUAK to the libosmogsm authentication
core API via 'struct osmo_auth_impl'.
Unit tests covering the test cases from the 3GPP specification are added
(and are all passing).
Change-Id: Ib905b8d8bdf248e8299bf50666ee1bca8298433d
3GPP specifies the C2 derivation function (generating GSM SRES from UMTS XRES)
independent of the MILENAGE algorithm. So instead of open-coding it in
milenage.c:gsm_milenage(), let's create a separate public function
osmo_auth_c2() similar to the already-existing osmo_auth_c3() function.
gsm_milenage() can then simply use that function.
Change-Id: I0e7cd55f5578f891cb6cc1b0442920ba5beddae4
There are 3G algorithms which support different lengths of RES values
(4, 8, 16 byte). For MILENAGE, we never really had to bother, as
the 4-byte RES is simply the first 4 bytes of the 8-byte RES.
However, for TUAK, the expected RES length is an input parameter to
the Keccak crypto functions, so the result of all parameters (including
CK, IK, ...) will be completely different for RES length 4 than RES
length 8.
So let's permit the caller of the osmocom auth API to specify the
requested RES length via the osmo_auth_vector.res_len parameter.
For backwards compatibility of callers of the old osmo_auth_gen_vec/
osmo_auth_gen_vec_auts API: Always force the res_len to 8 in this case,
which was the hard-coded length before this patch.
Change-Id: Ic662843fbe8b5c58e4af39ea630ad5ac13fd6bef
3GPP TS 33.102 Section 6.3.7 states that K can be 128 or 256 bits,
while our 'struct osmo_sub_auth_data' had a fixed-size 128bit field.
This means we cannot use our auth_core for algorithms with larger
key sizes, such as TUAK. Let's introduce osmo_sub_auth_data2 for
larger (and variable) sized K and OP[c].
K and OP[c] can even have different sizes in TUAK, where OP[c] is
always 256bit, but K can be 128 or 256 bits. So we need separate
length fields for K and OP[c].
I'm adding backwards-compatibility API wrappers, so old applications
just continue to work as they always did.
However, I'm not adding compatibility wrappers for the plug-in API
that can be used to register additional authentication implementations
at runtime. We don't know of any user of that API outside of
libosmocore, so the function signatures of the 'struct osmo_auth_impl'
are modified in an incompatible way.
Change-Id: Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
If a network element that receives call leg A UL and is responsible
for preparing leg B DL receives a GSM-HR SID frame whose SID field
is not all 1s but which is marked as valid SID by out-of-band means
(TRAU-UL frame control bits or the FT field in RFC 5993 ToC octet),
this SID frame should be rejuvenated (SID field reset to all 1s)
prior to retransmission on call leg B DL. Provide a function
that performs this operation.
Related: OS#6036
Change-Id: Iebc0863ffcc3f8f25aeb54d4b14fac0487bc2bbb
In Iec5c1f2619a82499f61cb3e5a7cd03ff0f020ad8 we added
osmo_{fr,efr}_sid_preen() functions that apply SID classification
of GSM 06.31/06.81 section 6.1.1 (osmo_{fr,efr}_sid_classify()),
reject invalid SID, and "rejuvenate" deemed-valid SID frames by
resetting their SID code word, correcting the one bit error that
may be present in a deemed-valid SID frame. However, the last
operation (rejuvenation of a SID frame by resetting its SID field)
should also be made available as its own function, as it may be
more efficient in some applications: for example, an application
may need to call osmo_{fr,efr}_sid_classify(), apply the rejuvenation
to valid SID, but also use the classification result to drive other
logic. Factor out these functions.
Change-Id: I1d6dd867a358bdda8850cd8c959d0f361c0a5b6d
Currently FACCH/[FH] encoding and decoding is implemented as part of
the gsm0503_tch_[fh]r_{en,de}code and gsm0503_tch_a[fh]s_{en,de}code
API. This works fine for speech because one FACCH frame completely
replaces one or two speech frames, but this is not the case for CSD.
According to 3GPP TS 45.002, sections 4.2.5 and 4.3.5, for TCH data
channels FACCH does not replace data frames but disturbs some amount
of bits from them. Therefore we need to be able to perform FACCH
encoding and decoding independently from CSD specific coding API.
Change-Id: I0c7a9c180dcafe64e6aebe53518d3d11e1f29886
Related: OS#1572
Implement all CSD specific channel modes, except TCH/F2.4. All of
these modes are more or less similar to each other. The TCH/F2.4
is more similar to TCH/FS and slightly more complicated.
FACCH/F and FACCH/H will be implemented in a follow-up change.
Change-Id: Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d
Related: OS#1572
The original design of gsm0503_tch_hr_{en,de}code() functions contains
a mistake in that a pseudo-RFC5993 format was chosen for HR codec frame
input and output, instead of "pure" (agnostic to outer RTP encoding)
form of 14 bytes. We would like to change this design so that we can
feed pure 14-byte HR codec frames to the channel coding function and
get such frames back from the channel decoding function - however,
we cannot break libosmocoding API for existing users. In the decoding
direction, create a new function that emits TS 101 318 format, and
turn the legacy gsm0503_tch_hr_decode() API into a wrapper function
for backward compatibility.
Related: OS#5688
Change-Id: If28ddb20789e8993b7558ca08020478615b4c708
OsmoHNBGW will need to obtain the NRI from GMM Attach Request and GMM
RAU Request to implement CN pooling.
Related: SYS#6412
Change-Id: Id661abfdb2c81a92c9046542bbc08d6ccd39f073
This adds the definition of 'struct rsl_ie_nch_drx_info' representing
the bit-field of the 'NCH DRX Information IE' of A-bis RSL.
Change-Id: I9586b5cb8514010d9358fcfc97c3d34741294522
Related: OS#5781
These functions encode/decode the NCH position field within the SI1
rest octets. This is used within ASCI (VBS/VGCS).
Change-Id: I24a0095ac6eee0197f9d9ef9895c7795df6cdc49
Related: OS#5781
The read length is not needed in the segmentation callback, msgb
already has all the necessary information, the parameter previously was
just msgb_length(msg).
Also handle negative return values (except -EAGAIN) of the callback as
errors which cause the msg to be dropped. -EAGAIN will defer the msg.
Change-Id: I6a0eebb8d4490f09a3cc6eb97d4ff47b4a8fd377
Added, because the field 'io_ops' of 'struct osmo_io_fd' is not a
reference, so subsequent changes to the osmo_io_ops structure that was
used to set it up aren't automatically reflected in the osmo_io_fd
structure that got its copy.
Change-Id: Ie45402ad8e86e3cecf75ad78a512c17e61e68b19
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
Vadim Yanitskiy
Harald Welte
Andreas Eversberg
arehbein
Pau Espin
Manawyrm
Daniel Willmann
Philipp Maier
Neels Hofmeyr