| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 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
|
|
Change-Id: Ic1fc714bb04228a7f32e9925811e21c8efc610bd
|
|
Change-Id: I3554cea47e714c8fca18c3e9c0e6e80695915a90
|
|
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
|
|
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
|
|
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
|
|
Change-Id: Id2070f03b09feea966c5342361d409551e557d38
|
|
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
|
|
Change-Id: Ief4e03785f01f07c8d97b33bbb55c89a863baccc
|
|
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
|
|
As specified in TS 24.008 9.4.4 "Attach reject"
Change-Id: I2d36d76ee6fe8ed1a36e37a7d74fbbdc9c27c2c7
|
|
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
|
|
Change-Id: Iec0dbf617c8d0f2c8c44156d936244cedda9b303
|
|
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
|
|
This allows us to feed RLP frames (occurring in GSM CSD) into wireshark
for dissection.
Change-Id: Ibb7f0731c31e5a5cd2911f733da5510ce0f3a1d6
|
|
Change-Id: I87d977228b1e039c2876941d1c6df1f69d1a54d4
Related: OS#1572
|
|
From 3GPP TS 44.018 (version 15.4.0), table 10.5.2.6.1.
Change-Id: Ia6b428e5b6aaecf151cbfa980b89eff6d0fe6006
Related: OS#1572
|
|
From 3GPP TS 44.018 (version 15.4.0), table 10.5.2.6.1.
Change-Id: I6adda28698c0e479ef20f5d090c1f7f76a2ec97e
Related: OS#1572
|
|
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
|
|
Let's clarify what those modes mean
Change-Id: I77fc7b24ccd387f54a7c7edad666737252af6bd9
|
|
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
|
