Add a function to convert struct gsm48_multi_rate_conf, which holds the
codec settings for AMR, to S0-S15 bit representation as defined in
3GPP TS 48.008 3.2.2.49
Change-Id: I4e656731b16621736c7a2f4e64d9ce63b1064e98
Related: OS#3548
The cell identifier list parameter is mandatory. Document it as
such, and tweak code which treated it like an optional parameter.
No functional change. The existing code already asserts that
a non-NULL value is passed for this parameter.
Change-Id: I3716f9d5b210e0a7e6f45c9fe3fc34024e5234ad
Related: OS#3021
There was gsm0480_l3hdr_push() declared in a header file, but
not exposed in 'libosmogsm.map'. Furthermore, for some reason
it was a part of GSM 04.80 API, what is not actually correct.
Let's rename this symbol, and properly expose it as a part of
the GSM 04.08 API. Also, let's introduce an auxiliary wrapper
for messages, where the transaction identifier is required
(see GSM 04.07, section 11.2.3.1.2).
Change-Id: I8a045efe8335d83fcbe8d43eb180972e3b1d9dda
I was contacted by the (previously unknown) author who provided
the new location of the original code.
Change-Id: I2dabab20ad018ce473817986bdb250131c010bf1
In the previous commit we deprecated ipa_ccm_idtag_parse() but
also removed ipa_ccm_idtag_parse_off(), for which I couldn't find
any users. However, legacy openbsc.git still uses this function,
so let's re-introiduce it in its original form.
Change-Id: Ibfe53b04340eb355c8bfb8453a2af1522a4b6baf
In the past, the function ipa_ccm_idtag_parse() was used to parse
the payload of IPA CCM ID RESP packets. However, the function was
based on a possible misunderstanding of the message encoding, and
callers actually counted the first (upper) length nibble as part
of the header and passed a pointer to the second
(lower) length nibble of the first TLV into this function. As such,
it was unfixable, and had to be replaced with a new function called
ipa_ccm_id_resp_parse(). At the same time, we also add
ipa_ccm_id_get_parse() to parse the slightly different format of
the IPA CCM ID GET payload.
We can never be 100% sure what is "correct", as our understanding
of the protocol is entirely based on protocol analysis, without any
official documentation available.
This patch also introduces unit test coverage for both of the new
functions.
Revert "ipa: Add libosmogsm.map entry for ipa_ccm_idtag_parse_off"
This reverts commit 7f31c90b80.
Revert "ipa: Properly parse LV stream of a ID_GET request"
This reverts commit f558ed4bb9.
It introduced a function/behavior that was not originally intended:
The parse of IPA CCM ID GET (8bit length followed by 1 byte tag
and variable-length payload) instead of the IPA CCM ID RESP (16bit
length followed by 1 byte tag and variable-length payload).
Change-Id: I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
As we're moving this to a common/shared library now, we need to use
the osmo_ namespace prefix for symbol names, struct/type names and
constants.
Change-Id: Ie36729996abd30b84d1c30a09f62ebc6a9794950
This imports the code from osmo-msc 6afef893e17bce67e4d4119acd34d480ed03ba77
with minimal changes to make it compile. Symbol renaming to osmo_
prefix is done separately in a follow-up patch to have a as-clean-as-possible
import first.
Change-Id: I9bc38102318da02d1fe46ef516df3cfd6bf8e3da
Contrary to the existing gsm0480_create_ussd_resp(), the new function
only generates the value part of the FACILITY IE, and not the IE
Tag/Length or the 04.08 L3 header. This is needed in the context of
GSUP-encapsulated USSD, as here we don't work with L3 messages, but
only pass on the FACILITY IE value.
Change-Id: Ide240279240322f643e142229eb7829f538c6314
enum gsm0808_permitted_speech does not have any value strings. Lets
add value strings to make debugging easier.
Change-Id: I5b5612a5df2758b0137a34c17f7c8c2b3f07c806
The conv_gen.py utility was tested against both Python 2 and 3,
so there is no need to enforce Python 2. Also, having:
#!/usr/local/bin/python{2|3}
is a bad idea, because Python may be installed in a different location.
Change-Id: I6007d481047b584db13d6eda70fb99f11f9ddaa1
A loooong time ago, we introduced osmo_panic() as a wrapper around
abort(). The advantage is, that this wrapper can be overridden, and
that it will also work in embedded (bare iron) targets, where the
abort simply translates to an infinite loop.
Change-Id: I5a70eb65952cbc329bf96eacb428b07a9da32433
Add:
gsm0808_create_handover_detect()
gsm0808_create_handover_complete()
gsm0808_create_handover_failure()
To existing structs gsm0808_old_bss_to_new_bss_info and
gsm0808_handover_required, add a final 'more_items' flag that makes future
extensions API and ABI compatible.
Fix the msgb string for Handover Request Ack.
Extend some API doc comments.
Related: OS#2283 (inter-BSC Handover, BSC side, MT)
Change-Id: I03ee7ce840ecfa0b6a33358e7385528aabd4873f
In Change-Id I1cee271fed0284a134ffed103c0d4bebbcfde2a8 we added support
for a new session state IE, but we didn't add any value_string array
for string conversion of it. Let's fix this.
Change-Id: I3d9f087786dc37c42498fa9a2be07483ec93ba7b
This function can be used to resolve the error message type for
a given message type. Can be used by generic error handlers that
work for any incoming message type.
Change-Id: Ic637bec53dd7fe3ec83da99b49b4eae34d5602b2
This function can be used when there is only a part of GSM 04.80
message available - Facility IE, e.g. when a message is carried
over GSUP/MAP. Let's expose it.
Refactoring includes the following:
- adding the 'gsm0480_' prefix;
- correcting inverted return value;
- cosmetic code style changes.
Change-Id: I623c39ffbe6cdee65eade8435a2faa04d0da193e
In some cases, there is no need to parse the whole message,
e.g. during the conversion from DTAP to GSUP/MAP. This
function can be used to extract given IE from a message.
Change-Id: I3989d061903352473305f80712f1a1560d05df3d
In order to be able to transfer SS/USSD messages via GSUP,
this change introduces the following new message types:
- OSMO_GSUP_MSGT_PROC_SS_*,
and the following new IE:
- OSMO_GSUP_SS_INFO_IE
which represents an ASN.1 encoded MAP payload coming to/from
the mobile station 'as is', without any transcoding.
Change-Id: Ie17a78043a35fffbdd59e80fd2b2da39cce5e532
Related: OS#1597
Unlike TCAP/MAP, GSUP is just a transport layer without the
dialogue/context. This prevents us from having session based
communication, required e.g. for USSD. But we can emulate
TCAP dialogue by adding additional IEs, which would allow
to relate each message to a particular session.
This change introduces the following IEs:
- OSMO_GSUP_SESSION_ID_IE,
- OSMO_GSUP_SESSION_STATE_IE,
which optionally can be used to indicate that the message is
related to a session with given ID, and to manage session
state, i.e. initiate, continue, and finish.
Change-Id: I1cee271fed0284a134ffed103c0d4bebbcfde2a8
Related: OS#1597
According to the 3GPP TS 04.80, table 2.5 'Release complete', a
RELEASE_COMPLETE message may containg optional FACILITY element.
Meanwhile, the 0xff byte is used to indicate that there is no
decoded message (legacy field). Let's avoid overwriting of
a decoded message.
Change-Id: I0c85292222749a48ca0c4b2e93f4fa2d61468c18
The idea is to be able to add a gsm0808_cell_id to a gsm0808_cell_id_list2:
first convert it to a list, then re-use gsm0808_cell_id_list_add(). It will be
used by osmo-bsc to manage neighbor-BSS cell identifiers from VTY.
Change-Id: Ibf746ac60b1b1e920baf494b396658a5ceabd788
For some strange reason, the osmo_mncc_name() inline function
was not in the mncc.h header, but in the mncc.c file. Let's fix that.
Change-Id: I2c3666510c981dffa4ba25bed517fd7ebd1250f5
Fixes following AddressSanitizer report during gea_test run with gcc
8.1.0:
==8899==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc5f1719bb at pc 0x7fe574adc5fe bp 0x7ffc5f171460 sp 0x7ffc5f171450
WRITE of size 1 at 0x7ffc5f1719bb thread T0
#0 0x7fe574adc5fd in osmo_store64be_ext ../../include/osmocom/core/bit64gen.h:75
#1 0x7fe574adc649 in osmo_store64be ../../include/osmocom/core/bit64gen.h:104
#2 0x7fe574ade936 in _kasumi_kgcore libosmocore/src/gsm/kasumi.c:186
#3 0x7fe574ae2532 in gea4 libosmocore/src/gsm/gea.c:44
#4 0x7fe574ae266c in gea3 libosmocore/src/gsm/gea.c:60
#5 0x7fe574a9b616 in gprs_cipher_run libosmocore/src/gsm/gprs_cipher_core.c:95
#6 0x56422d3fb2ee in test_gea libosmocore/tests/gea/gea_test.c:29
#7 0x56422d3fb506 in main libosmocore/tests/gea/gea_test.c:49
#8 0x7fe5730f406a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#9 0x56422d3fadf9 in _start (libosmocore/tests/gea/.libs/lt-gea_test+0x1df9)
The kasumi_test is updated to calculate the entire array of bits
according to expected result. Before this commit it worked by writing
the entire last 64bit block, and addressSanitizer cannot catch it
because the allocated buffer is 64bit aligned too.
Change-Id: I7b2a0224a3b5527d5a3ad7e17efc73081b63eac1
In Change-Id: I8c2c103cdc7f9a45d7b2080c572f559fc3db58e4 we introduced
a check to enforce contention resolution always being used in
MS-originated LAPDm establishment on the main DCCH / SAPI0. This is
only required after RACH request (IMM.ASS.) and not after a normal
assignment command which was sent already via a dedicated channel.
Hence, we cannot enforce a strict requirement for contention resolution
in those cases.
We *could* use the RSL Channel Activation type as a constraint on
whether or not to enforce contention-resoluiton-only LAPDm
establishment, but this is out of the scope of the LAPDm code but would
have to be done inside OsmoBTS.
Related: OS#3252
Change-Id: Id903492ee90809fe98defcf4abc0419b8150069f
The RSL_IE_MS_POWER / RSL_IE_TIMING_ADVANCE is how we communicate
the SACCH L1 header values on the MS side between LAPDm and L3 (which
is a non-standard use of RSL).
However, those IEs only maek sense on the SACCH, where we have B4 frame
format and where we actually have a L1 header containing related
information. Let's make sure to skip those IEs on regular RLL UNIT DATA
INDICATION happening on other channel types.
Change-Id: I6f13e02192531479287f71de674d17ca2ceabdc6
Closes: OS#3249
This is a purely cosmetic clean-up to use the msgb_tv_push() API
to pre-pend a Tag-Value IE to a msgb, rather than the existing
open-coding approach.
Change-Id: I19bbfa1e327a617685ed11d4182e533df33215cb
Add:
- gsm0808_current_channel_type_1()
- gsm0808_permitted_speech()
- gsm0808_chosen_channel()
- gsm0808_channel_type_name()
gsm0808_permitted_speech() is moved from osmo-bsc's bssap_speech_from_lchan();
gsm0808_chosen_channel() is moved from osmo-bsc's lchan_to_chosen_channel();
Rationale: will be re-used by inter-BSC handover, makes sense to keep with the
other gsm0808 utils.
Related: OS#2283 (inter-BSC handover, BSC side)
Change-Id: I8a3cc5d4548e9a78d945d54c69ccced251edcec9
* MO SAPI0 establishment *must always* have L3 payload for contention
resolution
* SAPI3 establishment *must never* use contention resolution
* MT establish must never use contention resolution
Change-Id: I8c2c103cdc7f9a45d7b2080c572f559fc3db58e4
Closes: OS#2370
It seems that during all those years it has never been noted that
the back-pointer from the lapdm_entity to the lapdm_channel was
never initialized. Let's fix that.
Change-Id: Iaca66cd6a2c9f315561e365b51163927868fc346
gnutls_global_init must be called at least once for
gnutls < 3.3.0. It doesn't hurt calling it twice, except
a reference counter is increased.
gnutls >= 3.3.0 will call it automatic.
Fixes: OS#2986
Change-Id: I241b6ae5aa8df13dd78f04658cf0953e9561c9e2
3GPP TS 48.058 has a very clear definition of which messages are
"transparent" and hence have the T-bit == 1. This is *not* just
all RLL messages, but basically only RLL_DATA.{ind,req} and
RLL_UNITDATA.{ind,req}. All other messages are non-transparent.
Change-Id: I9f83654af189d818563d799bf623325b7fee8e70
Closes: OS#3188
Provide comprehensive API to obtain string representations of Cell Identifiers
and -Lists.
Change gsm0808_test.c to use the new functions (which simplifies the output a
bit), so that we don't duplicate printing code in gsm0808_test.c, and so that
the not-so-trivial printing code is also tested.
In gsm0808_test, also test gsm0808_cell_id_list_name_buf()'s return value and
truncation behavior.
The rationale for gsm0808_cell_id_list_name(), i.e. printing an entire list of
cell identifiers, is that even though the maximum is 127 elements, a list of
more than a few elements is hardly ever expected in practice (even more than
one element isn't actually expected: either "entire BSS" or a single LAC). It
is thus useful to log the entire list when it shows up in Paging and Handover.
Change-Id: I9b2106805422f96c5cc96ebb9178451355582df3
According to the GSM TS 04.07, section 11.2.3.1.1 "Protocol
discriminator", bits 1 to 4 of the first octet of a standard
L3 message contain the protocol discriminator IE.
Meanwhile, the GSM48_PDISC_USSD represents value 0x11, i.e.
0b10001, that requires 5 bits, and moreover it is not
documented anywhere. Let's drop it.
Change-Id: Ic4eb8a6db4ff1dfd535bd0c84e7acf1908422f64
don't blindly trust the tag-length value in an IPA CCM ID GET
message. This could result in a remotely-triggered integer underflow.
Change-Id: I4723361e1094b358310541a7dc4c5c921c778a15
Clarify semantics and micro-optimise for the case of single Cell Identifer IEs.
Test in gsm0808_test.c
So far we have gsm0808_enc_cell_id_list2(), but there also exist instances of
single Cell Identifiers (3GPP TS 48.008 3.2.2.17).
It is possible to decode the same using the cell identifier list API, but this
forces the caller to also keep a full struct gsm0808_cell_id_list2 with all its
127 entries around.
E.g. for handover, there are two Cell Identifiers (Serving and Target); I'd
need two full cell id lists for each, and these would be dynamically allocated
for each handover operation, whether it uses them or not.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: I9f9c528965775698ab62ac386af0516192c4b0cc
Allow passing multiple struct tlv_parsed in an array, to allow parsing as many
repeated IEs as are expected by the caller.
From tlv_parse(), call tlv_parse2() with dec_multiple = 1 to yield the previous
behavior. tlv_parse() remains valid API.
An example of multiple IEs is the BSSMAP Handover Request, containing Cell
Identifier (Serving) and Cell Identifier (Target), both defined by 3GPP TS
48.008 3.2.2.17 with identical IE tags; both are mandatory.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: Id04008eaf0a1cafdbdc11b7efc556e3035b1c84d
This will be used by the upcoming neighbor_ident API in osmo-bsc, where the vty
interface allows composing neihbor BSS cell identifier lists, and we want to
allow adding individual items from individual user commands.
It will also be useful to accumulate cell identifiers in case a subscriber sees
multiple alternative cells from a neighboring BSS, and we want to pass these on
to the MSC in a Handover Required.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: I5781f5fa5339c92ab2e2620489b002829d206925
This will be used by cell idenitifier list code, like upcoming neighbor_ident
VTY in osmo-bsc and regression tests.
Change-Id: Iebc5cdf61b697b1603900993fc265af3eca0cedf
There seems to be quite some confusion / overlap between enum
gsm48_reject_value, gsm48_gsm_cause and gsm48_gmm_cause. I tried to go with
gsm48_gsm_cause_names[], but e.g. GSM48_REJECT_CONGESTION is not represented.
Instead of attempting to mix/merge those enums, provide a separate value string
array for enum gsm48_reject_value.
This will be used by osmo-msc's libvlr (refactoring of FSM result handling),
I27bf8d68737ff1f8dc6d11fb1eac3d391aab0cb1.
Change-Id: I6661f139e68a498fb1bef10c266c2f064b72774a
fix for some spelling issues found by lintian
Signed-off-by: Thorsten Alteholz <osmocom@alteholz.de>
Change-Id: I69976ecae6939d9ff51bfe4ce7374890c6563b82
If either an INVOKE, either a RETURN_RESULT component has the
data with incorrect length (see Annex A, 3GPP TS 04.80), the
whole message is probably incorrect.
Let's drop such messages instead of silent truncation.
Change-Id: I2a169b0b84aa26ea2521edd55ff005c27ae6d808
As it was already documented before, the 'ss_request' struct has
a rudiment of deprecated 'ussd_request' struct - the 'ussd_text'
field. It represents the data either of an INVOKE component,
either of a RETURN_RESULT component, encoded as ASCII in case
if DCS is 0x0f (i.e. decoded by the code itself), otherwise
raw bytes 'as is'.
Previously, there was no possibility to distinguish between
ASCII and raw bytes with different DCS. Moreover, the payload
decoding is not desired in some cases.
Let's introduce the new fields, which will carry the raw
unmodified payload, its length and DCS (Data Coding Scheme).
Change-Id: Ia193d175021e145bb3b131290231f307dbefc64a
libosmocore has no value strings for BSSMAP cause codes yet.
- Add value strings for BSSMAP cause codes and a function
to retrieve them
Change-Id: I313dd8d7b06374e1e35ddc18b7a42562d9e25d45
Related: OS#1609
Use non-deprecated API to decode encode in gsm0808_enc_cell_id_list2().
Adjust gsm0808_test.c to now expect the correct results instead of previous
failure.
Change-Id: I1ce78883995e0d484368046b69db5afb2b4adc97
The speech codec defaults are not correct. The defaults recommended
in 3GPP TS 28.062, Table 7.11.3.1.3-2 are limited by 3GPP TS 48.008,
Section 3.2.2.103. Some defaults are actually reserved for future
use. Also the endianess of the 16 bit values is reversed.
- correct values so that they match the specification
- transmit bytes in the correct endianess
Change-Id: I6c3a34d39a375d71c4128fd38f06629e8b98b100
This is a more modern way of printing the Abis OML Formatted Object
Header, without assuming that it would be used in a log statement
or prescribing the log level to be used.
Change-Id: I9b2c2afec28882b817d104d5b062651ade7aadd8
Since commit bf383a1d83 tlv_parse()
will return the first occurrence of a repeated IE. Add a test to
verify this behaviour. This test passes with the current code and
fails if bf383a1d83 is reverted.
While here, fix lies in documentation about the return value of tlv_parse()
and fix a typo in another comment.
Change-Id: I041f38548c5e4236920991d6c681c1c1e04de9ca
Related: OS#2904
The implementation was entirely broken, reading data from wrong offsets
and always writing to the first element of the decoded list.
Also, add a new test for this function which found the problems.
Change-Id: If0fafbc7171da2a3044bfa9a167208a1afa1c07b
Related: OS#2847
Depends: Ife4e485e2b86c6f3321c9700611700115ad247b2
Cell ID lists with CI were misparsed because parse_cell_id_ci_list()
failed to report the amount of consumed bytes to its caller.
Also add a regression test which uncovered the bug.
Change-Id: Ife4e485e2b86c6f3321c9700611700115ad247b2
Depends: If6b941720de33dca66b6b1aa2cb95a3275708b7f
Related: OS#2847
This makes gsm0808_dec_cell_id_list() properly decode 3-digit MNCs.
Add a test which encodes/decodes a LAI_AND_LAC list with 3-digit MNCs.
Change-Id: If6b941720de33dca66b6b1aa2cb95a3275708b7f
Related: OS#2847
The cell ID list decoder merged in 11a4d9dd91
has a bug which was introduced part-way through the review process in
gerrit at https://gerrit.osmocom.org/#/c/6509/
When Neels suggested "why not just {...}id_list[MAXLEN] once?" I changed
the cell identifier list from a union of arrays to an array of unions.
After this change, elements smaller than the largest type in the union
were not laid out consecutively in memory anymore. E.g. uint16_t lac
values now occur at offsets of sizeof(id_list[0]) instead of offsets
of sizeof(uint16_t).
The problem is that I forgot to adjust the decoder accordingly, so the
decoder writes to the wrong offsets and returns cell identifier lists
which appear to contain uninitialized values when read back by API
consumers.
I found this problem while adding new regression tests to libosmocore to
test encoding and decoding. This commit adds one such tests for LAC list
decoding, which failed due to the above bug. I plan to write more tests,
however because this first test already uncovered a severe issue I chose
to submit a fix now and work on additional tests in later commits.
Change-Id: Ie1a5a9d858226be578cf11a03cf996d509bd51fb
Related: OS#2847
Global and LAI+LAC cell IDs were being misparsed due to an off-by-one.
This code was incorrectly converted from osmo-bsc, where an additional
offset of one byte was needed to skip the cell identifier field.
In libosmocore, these parsing routines receive a buffer pointer which
is already positioned at the start of the cell identifier field.
Change-Id: I7f3e8ace26176e9cbfe2542961d2a95662aa4d97
Related: OS#2847
Introduce gsm0808_dec_cell_id_list2() with supports additional types of
cell identifier lists. The new parsing routines are based on similar
routines used by the paging code in osmo-bsc's osmo_bsc_bssap.c.
Likewise, introduce gsm0808_enc_cell_id_list2() with support for the
same additional types of cell identifier lists.
The old API using struct gsm0808_cell_id_list is deprecated.
The previous definition was insufficient because it assumed that all
decoded cell ID types could be represented with a single uint16_t.
It was declared in a GSM protocol header (gsm/protocol/gsm_08_08.h)
despite being a host-side representation of data in an IE.
The only user I am aware of is in osmo-msc, where this struct is used
for one local variable. osmo-msc releases >= 1.1.0 make use of this API.
While here, fix a small bug in a test:
test_gsm0808_enc_dec_cell_id_list_bss() set the cell ID type to 'LAC'
but obviously wants to use type 'BSS'.
Change-Id: Ib7e754f538df0c83298a3c958b4e15a32fcb8abb
Related: OS#2847
In osmo_mnc_from_str() do not try to return some values even if the validation
fails; hence don't try to decode a NULL pointer. That whole idea was half-baked
and a can of worms to begin with.
Change-Id: Ibaaa128ac60b941a015a31134eb52aef56bc6e22
osmo-bsc and osmo-bts share enums and value strings to describe
feature data that is exchanged via OML (manufacturer id) on startup.
Also the functions to set and get the respecitive bits in the feature
bitvectors are in osmo-bsc and osmo-bts. This is a code duplication
and should be resolved.
- add enum osmo_bts_features (replaces enum gsm_bts_features)
- add osmo_bts_features_descs (replaces gsm_bts_features_descs)
- add osmo_bts_set_feature (replaces gsm_btsmodel_set_feature)
- add osmo_bts_has_feature (replaces gsm_btsmodel_has_feature)
Change-Id: Id0c35aef11aa49aa40abe7deef1f9dbd12210776
osmo_mnc_from_str() preserves leading zeros in the string and is useful for
VTY config parsing (osmo-bsc, osmo-msc, osmo-sgsn, osmo-pcu).
osmo_{plmn,mnc}_cmp() takes care of the slight intricacy of ignoring the 3-digit flag
if the MNC is anyway >99. Will be used by osmo-sgsn.git and osmo-bsc.git. (All
current users just care about identical MNC, but a proper cmp doesn't hurt.)
Change-Id: Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6
Enable representing three-digit MNC with leading zeros. The MNCs 23 and 023 are
actually different; so far we treated both as 23. Re-encode an incoming BCD or
string of 023 as it were, i.e. not dropping the leading zero as 23.
Break ABI compatibility by changing the size and ordering of structs
gprs_ra_id, osmo_plmn_id, osmo_cell_global_id, ... by adding an mnc_3_digits
flag.
Change ordering in gprs_ra_id because the canonical oder is {Mobile Country
Code, Mobile Network Code}, so have the mcc member first.
ABI compatibility cannot be maintained for struct gprs_ra_id, since it is a
direct member of structs bssgp_bvc_ctx and bssgp_paging_info, and even just
adding a flag to the end would cause ABI changes of those structs. Similarly,
osmo_plmn_id is a direct member of osmo_location_area_id, and so forth.
Add new API to set and read this additional flag to preserve leading zeros:
- osmo_plmn_to_bcd(), osmo_plmn_from_bcd() after
gsm48_mcc_mnc_to_bcd() and gsm48_mcc_mnc_from_bcd().
- gsm48_decode_lai2(), gsm48_generate_lai2() after
gsm48_decode_lai(), gsm48_generate_lai().
- gsm0808_create_layer3_2() after gsm0808_create_layer3() and gsm0808_create_layer3_aoip().
- various osmo_*_name() functions in gsm23003.h (osmo_rai_name() still in
gsm48.h close to struct gprs_ra_id definition). The amount and duplication of
these may seem a bit overboard, but IMO they do make sense in this way.
Though most code will soon see patches unifying the data structures used, in
some cases (vty, ctrl) they are required singled out. Without these
functions, the formatting ("%0*u", mnc_3_digits ? 3 : 2, mnc) would be
duplicated all over our diverse repositories.
In various log output, include the leading MNC zeros.
Mark one TODO in card_fs_sim.c, I am not sure how to communicate a leading zero
to/from a SIM card FS. The focus here is on the core network / BSS.
To indicate ABI incompatibility, bump libosmogsm and libosmogb LIBVERSIONs;
adjust debian files accordingly.
Implementation choices:
- The default behavior upon zero-initialization will be the mnc_3_digits flag
set to false, which yields exactly the previous behavior.
- I decided against packing the mnc with the mnc_3_digits field into a
sub-struct because it would immediately break all builds of dependent
projects: it would require immediate merging of numerous patches in other
repositories, and it would make compiling older code against a newer
libosmocore unneccessarily hard.
Change-Id: Id2240f7f518494c9df6c8bda52c0d5092f90f221
This breaks all existing / older osmocom-bb builds, and hence
cannot be accpeted. See also https://gerrit.osmocom.org/#/c/6679
Related: OS#2985
This reverts commit 3c38e60cd5.
Change-Id: Icfc52ca4e5cbe3a444d98037d27fa101e3614e06
Add generic function which allows caller to set Mobile Identity
explicitly. This allows to use IMEI or IMEISV for example. Make
gsm48_generate_mid_from_imsi() into wrapper around new function.
Change-Id: Id79be7abfff75ecd0d248bbeed93e605abeec9b3
Most GSM related specifications require the receiver to use the
*first* occurrence of repeated IEs. The Osmocom TLV parser so
far did the opposite: It reported only the *last* occurrence in
case of repeated IEs. Let's change our implementation to be
more in-line with relevant specs, such as 3GPP TS 24.008 8.6.3.
Change-Id: Icde09e075f68c842a7a96cf7160c8e44b77cf82d
* match return type of osmo_gsup_encode() with osmo_gsup_decode() to allow
propagating error to caller
* check return value of osmo_gsup_encode() in GSUP test
* return errors instead of braking app with aseert
Change-Id: Idaa1deecb6d9e15329bd51867b4f6a03357461f0
Related: OS#2864
Some times I *really* regret ever having merged OSMO_VALUE_STRING,
as it generates completely unusable and way too long strings :(
Change-Id: I8de7c01f9ea1d66c384e57449c4140186f5ce6c5
As MNCC is rather hard to debug (wireshark cannot trace UNIX domain
sockets), let's add our own decoder that we can use from related
debug log statements in the respective programs.
Change-Id: I216aaf70868ba5f3860a60c4b2442957531a3011
According to GSM 04.80 section 2.5 "Release complete", a message
of the mentioned type may contain optional IEs, such as Cause
and Facility. Let's parse them.
Change-Id: Ib8fc1f6bae472b0b264b6158f372b6cce255b222
Some SS messages (e.g. RELEASE COMPLETE) may contai multiple
IEs (Information Elements). Let's parse them all.
Change-Id: I20cc59c25fdbda176bcf76437174cda829518d60
According to GSM 04.08, 4.4.2 "ASN.1 data types":
the USSD-DataCodingScheme shall indicate use of
the default alphabet using the 0x0F value.
Previously, the UnstructuredSS Request messages with not
default alphabet were not being handled. Let's fix this.
Change-Id: I73d602f6f20b0afe7600d16bbd432069ae7be788
According to the GSM 04.80 (version 5.0.0) specification Annex A
"Expanded ASN.1 Module "SS-Protocol", the maximum size of a USSD
OCTET STRING is 160 bytes.
Thus according to ETSI TS 123 038 (version 10.0.0) specification
6.1.2.3 "USSD packing of 7 bit characters", in 160 octets, it's
possible to pack (160 * 8) / 7 = 182.8, that is 182 characters.
The remaining 6 bits are set to zero.
This change defines both mentioned values:
- GSM0480_USSD_OCTET_STRING_LEN 160
- GSM0480_USSD_7BIT_STRING_LEN 182
keeping the old MAX_LEN_USSD_STRING 'as is' due to compatibility
reasons. Now the new value is used for ss_request structure, while
old one is still used for deprecated ussd_request structure.
Change-Id: I6dead74f9ecea079752ff2400cdaf7c30187784e
According to GSM 04.80 Section 2.5 'Release complete' Table 2.5,
the 'RELEASE COMPLETE' message payload is optional, so let's drop
the length check in gsm0480_decode_ss_request() for this type.
Change-Id: I63b7f8ce403169a9dbdbdb031db16693de2196d6