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
As was demonstrated in the unit test [1], FACCH bitstealing does not
work as expected in conjunction CSD specific encoding functions.
The problem is in _tch_csd_burst_map(): we don't check the stealing
flags hu(B) and hl(B) and overwrite both odd and even numbered bits
unconditionally. Even worse, we reset these stealing flags to 0.
* Do not overwrite the hu(B) and hl(B) flags.
* Copy *even* numbered bits only if hu(B) is not set.
* Copy *odd* numbered bits only if hl(B) is not set.
Change-Id: Ib5395c70e3e725469c18ff7d4c47c62ddfdbd55d
Related: [1] Idc6decec3b84981d2aab4e27caab9ad65180f945
Related: OS#1572
In test_csd() we encode three data frames filled-in with three specific
patterns and then try decoding them. Additionally execute the same set
of tests, but with FACCH/[FH] bitstealing (pattern 0x2b).
As can be seen from the test output, we have problems decoding FACCH:
* FACCH/F: decoding fails (n_errors=0 / n_bits_total=0),
* FACCH/H: decoding with errors (n_errors=2 / n_bits_total=456).
A patch fixing the problem follows.
Change-Id: Idc6decec3b84981d2aab4e27caab9ad65180f945
Related: OS#1572
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 block length for TCH/F4.8 is off by 4 bits. Value 152 matches
with what TS 45.003 section 3.4.3 defines, but for some reason the
encoder generates more bits (468) than it must (456). This results
in buffer overruns when encoding TCH/F4.8.
All block length values in conv_codes_gsm.py are 4 bits less than
the respective values in TS 45.003. I have no idea why...
Change-Id: Id86d1aa0fd6791a8be431b5547bb723c74c35757
Related: OS#1572
Let's make sure the new API is covered by unit tests.
This patch also fixes a deprecation warning.
Change-Id: I4dea43f68941b5986ecc51b2e41c80741a711002
Related: 57a3b3a51f
In commit 57a3b3a51f I added new function gsm0503_tch_hr_decode2(),
but I forgot to add it to libosmocoding.map - and without the latter,
osmo-bts-trx and other applications can't use the new function.
Fix that omission.
Related: OS#5688
Change-Id: I6e75ca95409b5c368e8e04d0e0aba41e0331d9e6
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
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 encoding
direction, make the new format our preferred one, but support the
extra-octet format for backward compatibility.
Related: OS#5688
Change-Id: I13eaad366f9f68615b9e9e4a5f87396a0e9dea0f
This function needs to look at hl and hu stealing bits in order to
decide if it should decode FACCH/H instead of TCH/HS traffic.
However, out of the 8 (in total) hl and hu bits that get set when
FACCH/H stealing takes place, the function only looked at 7 of them
- one was missed. Fix this bug.
Change-Id: I08c4358b26d69910190f89a53b654bc58c2efea9
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
According to 3GPP TS 45.003, section 3.6.4, the interleaving for
TCH/F2.4 is done as specified for the TCH/FS in subclause 3.1.3.
Change-Id: I52078263cd593503a9e8f024e51e18d7b0906131
Related: OS#1572
libosmo-netif does a non blocking connect(), which as per definition of
the socket API is signalled from the OS to the user by marking the file
descriptor writable.
osmo_io needs to signal this somehow. Previously osmo_io would only call
the write_cb if actual data has been sent. This patch changes the behaviour
so that calling osmo_iofd_write_enable() will call write_cb() on a writable
socket even if the write queue is empty.
Change-Id: I893cbc3becd5e125f2f06b3654578aed0aacadf3
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
Andreas Eversberg
Neels Hofmeyr
Daniel Willmann
Vadim Yanitskiy
Eric Wild
Harald Welte