| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add segmentation callback to be used by the streaming backend of libosmo-netif
Related: OS#5753, OS#5751
Change-Id: I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
|
|
Always append to 'msg->tail' instead of to 'msg->data'.
Change-Id: I0ab8028c807b4181fddd3c00ea2e037c40cf0813
|
|
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
|
|
Change-Id: I1c3002716b08e31016cc6e623f8f8a413ef7916f
|
|
Change-Id: I0eceb380e401e1f842edbaa92f4b4738703a031c
|
|
Similar to support of sending Bter frame, the same rules apply when
receiving them.
Change-Id: If04115884743455c7bf2b2bc5f7e49e74b6ffb60
|
|
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
|
|
Change-Id: Ib94c64136c31ce4af67c314a8550d93946cc844f
|
|
This file is required to compile header files on machines that do not
have sys/socket.h.
Change-Id: Ia3eafc992221900bbbf1760f669725bf9da92105
|
|
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
|
|
This API is not really used or needed, so remove it.
See discussion in https://gerrit.osmocom.org/c/libosmocore/+/33084
Change-Id: I0dbc14a8cbbdc7b6e4688942c0dac865bbd72c8b
|
|
This was discussed in a previous change, but the change was merged
as-is.
Change-Id: I8b4a2dd7a336dea5c52c9da6e78bbc4d5f2a02f8
|
|
Change-Id: I70002a83c647854e0f2e30c0f6f82a2b0c63f114
|
|
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 compiler complains:
gsm48_rest_octets.c:79:11: warning: initializer overrides prior
initialization of this subobject [-Winitializer-overrides]
79 | [0x08] = {2, 2},
| ^~~~~~~
gsm48_rest_octets.c:78:11: note: previous initialization is here
78 | [0x08] = {2, 1},
| ^~~~~~~
And a quick look at 04.18 confirms:
0 1 0 0 0 2 1
0 1 0 0 1 2 2
Change-Id: I672e2ce53fd07157d15fec350cfbe32a19a52941
|
|
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
|
|
Change-Id: Ic1fc714bb04228a7f32e9925811e21c8efc610bd
|
|
Change-Id: I3554cea47e714c8fca18c3e9c0e6e80695915a90
|
|
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: 57a3b3a51fff40cff46c632285cd91e7458bf84e
|
|
Change-Id: Iaed1653c6001545f69ec6b466760f30d42bc4386
|
|
Change-Id: Iea787ec4c3b15a74f59d45825eae03740c5d28fa
|
|
In commit 57a3b3a51fff 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
|
|
Change-Id: I671ee927b49099f7c8cc1fbd5f8b19f94ba1af81
|
|
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
|
|
Change-Id: I9a631db088a4e279668beb962c98cc1a0929f44d
Related: OS#1572
|
|
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
|
