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
Enable write on first message in both iofd_txqueue_enqueue{,_front}(),
but only if the iofd is not closed.
Change-Id: I75827491bb9fe0c6d1e4a195ac434f049b1a6ba6
gsm48.c provides a function to decode mobile identity from various
messages. TALKER INDICATION is sent by the talking subscriber of a voice
group call to idenitfy the current talker. The mobile identity is
required to distinguish between calling subscriber and other subscribers.
Related: OS#4854
Change-Id: I331fac82e3c15abb01f554b2e70576100f2eea2d
Similar to HP/Aruba, only the word or abbreviation of 'configure' is
required to enter config mode. This is the default. It is still possible
to add other configuration sources than 'terminal' if implemented in
the future.
Change-Id: I56d5d1bd5526603a397c62542e667c413f4952ca
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
According to 3GPP TS 45.003, section 3.9.2, the convolutional coding
is *not* employed in the case of SID_FIRST. This is why we're using
sid_first_dummy[] in this function.
The conv[] array is not initialized in the case of AFS_SID_FIRST and
passing it to tch_amr_reassemble() is highly likely a copy-paste bug.
Pass the sid_first_dummy[] instead.
Change-Id: Ic8bfc34ce9d14821fe4e82932325f0c517d443a1
Fixes: CID#272949 "Uninitialized scalar variable"
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
Write to str even in case of error because this is already the current
behaviour and it's what osmo_stream_cli_get_sockname() and
osmo_sock_get_name2{,_c}() expect.
Change-Id: I76727993224ef87b475c33360c24966e82e866ec
Fixes: Coverity CID#321044
Rename msg_len -> received_len, len -> expected_len
so the variable names have a consistent scheme.
For instance,
extra_len = msg_len - len
becomes
extra_len = received_len - expected_len
Change-Id: I3d752ce91a1b16c855522f643d10a52ef28a8a84
If tx_ph_data_enqueue() is called, frames will be written into a queue,
if there is a pending frame or if polling of TX frames is used. In
this case the return value must be 0.
Sending a RSL_MT_UNIT_DATA_REQ from upper layer causes a call to
tx_ph_data_enqueue(). The return code is returned to the sender. The
sender must not get an error returned, if the message is enqueued.
Change-Id: Iaeaf7c66cb3cf5cc81bc8e15d468e8e7704c1407
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
Bter frames may be used on downlink of a main DCCH or SACCH channel.
It applies to SAPI 0 and UI frames only. It includes a short layer 2
header with 2 bits only. All other bits are used for the message. The
message size is 23 bytes on main DCCH and 21 bytes on SACCH.
The length of the L3 messsage is used to distinguish between Bter frames
and other (UI) frames.
Note that the L3 message header is different, so that the length of the
UI frame will determine which header is used.
Change-Id: Ia3a25c009d1ff09f83258bdb226a85b81466d7a1
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
So far, we were executing the cryptographic functions to generate
MILENAGE authentication tuples *twice* for every call to
milenage_gen_vec: Once for UMTS, and another time for GSM.
Let's do this properly: Execute once for UMTS, an then call the
computationally much simpler C2 and C3 functions to compute the
SRES and Kc values from RES, and CK+IK, respectively.
Change-Id: I20ecf6d32974c1ba196bf56deba5b2cd971eaffb
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
This allows the tool to support K/OPc lengths != 128 bit.
Let's add more length checks of command-line arguments while we're
adding those checks for K/OPc.
Change-Id: Iffed02ec0fc9c9a996da6f218d67314e381cbb29
Since Change-Id Ie775fedba4a3fa12314c0f7c8a369662ef6a40df we are
supporting K-lengths != 128 bit. However, our existing MILENAGE
and XOR-3G algorithms only support that key length, so let's add
some explicit checks for that.
Change-Id: Iae8b93cf059abda087101cdd01bbcf92d355753b
Let's make sure that nobody ever ends up calling the algo_impl
call-backs with data of a non-matching algorithm. This should
never happen at all, as all normal users should go through
the auth_core.c:osmo_auth_gen_vec* API, which dispatches based
on algorithm.
Change-Id: I22b504b6cffb4999b2f14772fffcb2f6f02c198c
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
Every BTS needs to have some graceful handling for the scenario
where it is time to send out a speech frame on TCH DL, but there is
no frame to be sent. One possible solution is to transmit dummy
FACCH, but this option is unattractive for TCH/HS where FACCH
displaces two speech frames rather than one. A more elegant
solution is to emit a speech frame with inverted CRC3, causing
the MS receiver to declare a BFI condition to its Rx DTX handler.
Setting all u(k) bits to 0 is one way to produce such an inverted-CRC
speech frame (normal TCH FR/HR CRC3 for an all-zeros frame would be
111), and this method is in fact what sysmoBTS PHY is observed to do.
Add the same ability to gsm0503_tch_{fr,hr}_encode() functions,
indicated by payload length of 0.
Change-Id: Iade3310e16b906efb6892d28f474a0d15204e861
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
These two functions are structured as switch statements handling
different types of input, but they also have a lot of empty spacing
lines in strange places, making them difficult to read and even more
difficult to add new functionality while maintaining the same style.
Remove those extra spaces.
Change-Id: I595a80898283d0932fb33f582347ec39a9481d1a
Vadim Yanitskiy
Daniel Willmann
Harald Welte
Andreas Eversberg
Pau Espin
Neels Hofmeyr
Eric Wild