Replace some with atoi(), where the VTY has already validated correct
range of the argument.
Replace others with the new osmo_str_to_int() or osmo_str_to_int64()
functions, possibly covering more detection of invalid number strings.
Leave those strtol() callers that depend on endptr to provide the next
string token.
Related: SYS#5542
Change-Id: I0ebb06e751c28f7d1cdf328de29cd227a2449391
20 bytes is not enough for some VAMOS specific channel number values,
so the resulting string representation gets truncated by snprintf():
expected: "VAMOS TCH/H(0) on TS4\0"
actual: "VAMOS TCH/H(0) on T\0"
Let's enlarge the buffers to 32 bytes.
Change-Id: I68d839f4ab742cf56de34e7e22572a1163aec2da
This commit adds new Osmocom specific IEs required to pass C/I related
Power Control Parameters osmo-bsc => osmo-bts to be used by the MS Power
Control Loop being implemented.
Related: SYS#4917
Change-Id: Iffef0611430ad6c90606149c398d80158633bbca
To indicate to the BSC that a BTS supports temporary overpower of
SACCH/FACCH channels a new feature BTS_FEAT_ACCH_TOP is added.
Change-Id: I62fbfc30acd5d67b20727b75a8f256e6b5d31e06
Related: SYS#5319
To transfer the temporary overpower value from the BSC to the BTS, a new
RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP) is added.
Change-Id: I31c5be4bceb9140d63ab8e2f197f0acc68699426
Related: SYS#5319
After my system's gcc was upgraded, I get false positivies in a couple
places. Let's initialize those to make gcc happy.
"""
/git/libosmocore/src/socket.c: In function ‘osmo_sock_init’:
/git/libosmocore/src/socket.c:958:25: error: ‘sfd’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
958 | close(sfd);
| ^~~~~~~~~~
/git/libosmocore/src/gsm/gsm48.c: In function ‘osmo_mobile_identity_decode’:
/git/libosmocore/src/gsm/gsm48.c:690:20: error: ‘str_size’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
690 | if (rc < 1 || rc >= str_size) {
| ~~~~~~~^~~~~~~~~~~~~~~~~
/git/libosmocore/src/gsm/gsm48.c:679:22: error: ‘str’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
679 | rc = osmo_bcd2str(str, str_size, mi_data, 1, 1 + nibbles_len, allow_hex);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"""
Change-Id: I8aacfbc21e23f63a65e8baee3fd536a1fe1bdd8a
This feature signals support to configure Osmocom Dynamic Timeslot type
as SDCCH8, on top of historically supported TCH/H and TCH/F.
The idea is that when unneeded, the TS is configured as PDCH, and as
soon as there's need for an SDCCH and there's none available, the TS is
dynamically reconfigured to SDCCH8. Once all logical channels in the
dynamic TS are released and hence becomes free, the BSC will reconfigure
it to PDCH.
Related: SYS#5309
Change-Id: Ifc0ca8916bd3e93e5a60a7dd7391d2588fdb5532
They will gain support to be activated as SDCCH/8 soon too. Since new
name would start to be too large, use a more generic naming for it.
Related: OS#5309
Change-Id: I56dcfe4d17899630b17f80145c3ced72f1e91e68
Prepare for A5/4 support in osmo-msc.
Add new function gsm0808_create_cipher2() which takes a struct as
argument instead of individual fields. This is akin to e.g.
gsm0808_create_handover_request() below in the file, and allows
backwards compatibly extending the argument list without needing a new
function signature every time.
Add struct gsm0808_cipher_mode_command, as argument list for
gsm0808_create_cipher2(), with kc128 included.
Encode the Kc128 IE in gsm0808_create_cipher2().
Implement gsm0808_create_cipher() by calling gsm0808_create_cipher2().
Change-Id: Ib3906085e0c6e5a496a9f755f0f786238a86ca34
This feature provides the BSC with information on whether the BTS talks
the IPAC_PROTO_EXT_PCU osmocom extension over the underlying IPA
multiplex of the OML link.
Related: SYS#5303
Change-Id: Id62421f7f5540875ac877a187757f2cf0556bd02
generic sha code from git://w1.fi/hostap.git commit
5ea93947ca67ba83529798b806a15b247cdb2e93 which also happens
to be the source of our milenage code.
Related: SYS#5324
Change-Id: Ibf2e49edada944d91ceba62bd0d6b6ce69261fcd
When modifying chan modes, I first thought rather always fail if there
is no equivalent mode.
That is true for gsm48_chan_mode_to_vamos(), but for a change to
non-VAMOS, rather return the unchanged mode for non-VAMOS modes, so that
gsm48_chan_mode_to_non_vamos(GSM_CMODE_SIGN) works without failure.
This makes more convenient checking, e.g. in osmo-bsc's lchan_fsm.c
making sure that a non-VAMOS lchan has a non-VAMOS chan_mode, for all
types of lchans.
Change-Id: Ibf20f04d167e0e0599012ff530bc17ba8c8ab562
This could never possibly have worked. When iterating over the
different IEs to encode, we must of course use the tag of the current
iterator item, and not the hard-coded value of the second tag in the
list.
Change-Id: I148799c5bdb95f70118691c1150330ebac4fdf21
In 2018, I4723361e1094b358310541a7dc4c5c921c778a15 introuced a
check against an integer unterflow. However, the fheck got the
logic wrong, with the result of breaking the function completely:
It would always only detect the first tag within the IPA request
and then take the branch that assumes an integer underflow.
Change-Id: I344975d0bda565ff196a1c0c69305cd349b98a19
Defined in 48.018 10.5.2.82.
This will be used by Channel Mode Modify for VAMOS.
Related: SYS#4895 SYS#5315
Change-Id: I9bad6e7121af43dfa9706635e58279ce672a4e14
Also add functions to convert between VAMOS and non-VAMOS speech modes.
Related: SYS#4895 SYS#5315
Change-Id: Ie0ea592da5610ae70290106d004e549cf3212a89
This will be used by osmo-bts-omldummy to parse features strings from
the cmdline.
Note that osmo_bts_feature_name() already exists to return the longer
descriptive value_strings from osmo_bts_features_descs (_descs!).
Luckily that misses the plural 'features' in the name, so that I can
still add a properly named osmo_bts_features_name() function that only
returns the name, matching the common pattern used in osmocom code.
Related: SYS#4895
Change-Id: I699cd27512887d64d824be680303e70fff3677c1
The warning period encoding was wrong, resulting in way too short
warning periods being encoded than intended/specified by the caller.
Change-Id: Idf3cae48a6ab45550d7bbd937bb49a0e1a4e8aed
Even though the value is only between 0..120s, they didn't encode
it 1:1 in the uint8_t, but 3GPP chose to use the same encoding
as for the warning period (which has a much larger range).
Let's fix this in our implementation.
Before this patch, osmo-cbc wanted to send 30s keep-alive repetition
period, but a spec-compliant receiver actually decoded this as 80s.
Change-Id: I04baa6b6b99b092fa0512b3b6138a363c7f3a13d
CGI-PS type doesn't exist in GSM 08.08 Cell Id lists. That type of cell
id is osmocom-specific and used internally. In here CGI-PS is
automatically converted to CGI (since the later is an extension of this
one).
The encode/decode_cell_id_u are left intact (comment added) since those
can still be used (and are used by RIM code) to encode/decode TS 48.018
Cell Identifiers.
Related: SYS#4909
Change-Id: Id74f4577c397c1ba696f00395858311bd82cb2c8
It's a static internal function, so it makes sense to have it at start
of its related section.
It will be used by other functions in follow up patches.
Change-Id: I60f61f8f7bb6543feb068bdcee76d3b752565c95
Move it above the place where the bit is set, since the bit represents
whether Extension Information is available, not whether R99 is
available.
Change-Id: Ice592acc50a24efd7fe4cf1a91f1d48fd74f38d8
Comparing struct gprs_ra_id using memcmp can be error prone, so lets add
a compare function to compare two struct gprs_ra_id values reliably.
Change-Id: I4d7558c04d9d01761516526086be5104bb2eeada
Related: SYS#5103
Using 'uint8_t' for the length argument is definitely a bad idea.
Because of this, packing more than 255 septets would not work as
expected. Deprecate the old function and use 'size_t' instead.
Change-Id: Ib1aac538afeb0a5c76a1df472d555139a496e12e
This feature is used by BSC to gain knowledge on whether a given BTS
supports GPRS Cell Change Notification (CCN) related procedures on PDCH,
and as a result enable or not by default the CCN_ACTIVE bit in SI13 to
announce the support it is allowed to use the feature.
Related: SYS#4909
Change-Id: I61991266b95d0c13d51b47906cc07846e9cf1390
Older commit adding the 2 bits for Rel-4 extension forgot to increase
the length field (see TS 44.060 Table 12.24.1)
Fixes: 946bb95af1
Change-Id: I20efb4403cdf6c5bc717502a7075630044142f17
The libosmocore TLV parser had a number of insufficient bounds checks
leading to reads beyond the end of the respective input buffer.
This patch
* adds proper out-of-bounds checks to all TLV types
* simplifies some of the existing checks
* introduces test cases to test all the corner cases
where either TAG, or length, or value are not fully contained
in the input buffer.
Thanks to Ilja Van Sprundel for reporting these problems.
Change-Id: I98b02c914c9e3ecf56050af846292aa6979d7508
This structure is needed in order to identify a given cell within the
BSS during RIM transactions.
The naming was made up by myself since I couldn't find any naming
reference for this kind of data (RAI + CI).
Since LAI + CI = CGI, then RAI + CI = CGI-PS
osmo_rai_name2 family of functions get a "2" suffix due to already
existing functions handling struct struct gprs_ra_id in gsm48.h
Change-Id: If48f412c32e8e5a3e604a78d12b74787a4786374
We used to suppress/drop any "zero length" messages, but we didn't
include the header when computing the length. However, in CBSP there
are messages (at least KEEP-ALIVE-COMPLETE) which only consist of the
header without any information elements. We cannot simply drop such
messages.
This also fixes the return value of osmo_cbsp_recv_buffered() to be
the total number of received octets (including the header).
Change-Id: Ib620128a167cb77f061ee57e8f8ad707b96b1c0d
This is a fixed-length Tag-Value IE. Our decoder already parsed
it correctly, but the encoder encoded it as TLV, which is wrong.
Change-Id: I7e1d7eab8b8e51acd9a24c38e2d3d30bbf00847a
This reverts commit c9eab828ea.
The initial code was correct, which has also been used in osmo-bsc until
recently, where it moved to use this function from libosmocore and
errors started to show up in TTCN3 tests.
See 3GPP TS 44.018 Section 10.5.2.34 / Table 10.5.2.34.1: "SI 3 Rest
Octets information element":
"""
<SI3 Rest Octet> ::=
...
<3G Early Classmark Sending Restriction>
...
<3G Early Classmark Sending Restriction>::= L | H;
"""
Change-Id: I0ee48d3240c62c4d2e15063b26da7a2a617f383e
Related: OS#3075
Related: SYS#4021
We must always send the RELEASE.{indication,confirm} last before
returning from a function. We cannot rely on the datalink to
still be around after the call, as the SAP user might have destroyed
the data link meanwhile.
This fixes a heap use-after-free (at least) with RBS2000 when the BTS
is fully brought up and the OML data link is lost, see OS#1762
Change-Id: I8ccca8d5e5d07b666557afe12ab8ac4910ddfb00
Related: OS#1761
Related: OS#1762
This is required in order to tell MS that osmo-pcu now supports
Network Assisted Cell Change (NACC).
Related: SYS#4909
Change-Id: I2aaa8c1107c977f711c2d7530034f57e36e3a237
Commit bd6e7a9f2d did the initial porting
of rest_octet APIs from osmo-bsc, but introduced a bug when moving
bts->e_offset to a generic pointer independent of bts structure.
As a result, using this API from osmo-bsc makes gsm0408 unit test fail
due to bad encoding of several EARFCNs in si2quater.
Fixes: bd6e7a9f2d
Change-Id: I2bf5635b8536b11d69774d17ac1908019633e3af
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
This commit is a cherry-pick of osmo-bsc.git 6589f7c3a8dfdaaf66dda3afa6bbb1118ec825f9
Change-Id: Icc1ece39ad162d09720e104c5cbc12b07d6771a8
Related: OS#4652
When we add an EARFCN to to the SI2quater struct we do not add Serving
Cell Priority Parameters. This essentially causes to MS to ignore the
EARFCN because it is still undefined under which conditions the MS
should change to LTE.
This is a cherry-pick from osmo-bsc.git 295c965c063a8c431507191f6aef1ef78b720685
Related: SYS#4510
Change-Id: If9134759e9bc4ae0920800972632fd8c5dc9c2d9
This extends our existing TLV parser with the ability to
* validate that mandatory IEs of a given message are present
* validate that all present IEs are of required minimum length
Introducing this generic layer will help us to reduce open-coded
imperative verification across virtually all the protocols we
implement, as well as add validation to those protocols where we
don't properly perform related input validation yet.
Change-Id: If1e1d9adfa141ca86001dbd62a6a339f9bf9a912
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
This is fixed version of Ic8b2bfd00330235f5bed00771e421588abfaac1f,
which got reverted because it used the keyword "class" as struct member,
which lead into problems with c++ builds. This is now fixed.
Change-Id: Id8732551b33616227609cd6fcf6c3133751a89eb
Related: OS#4796 SYS#5114
This reverts commit a4939dc846,
which caused massive build failures in C++ programs like osmo-pcu
- unsurprisingly, as it calls a struct member "class", which is a
reserved keyword in C++.
Change-Id: Ia43e56385e7b580f492c560aee8ff8b1e8a0e1d8
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
Change-Id: Ic8b2bfd00330235f5bed00771e421588abfaac1f
Related: OS#4796 SYS#5114
3GPP TS 24.008, section 10.5.1.7 specifies a Repeated ACCH Capability
bit in the Classmark 3 IE. Unfortunately, there is no way specified how
the Repeated ACCH feature should be controlled on RSL level. Since it is
not unusual that BTS/BSC vendors occassionally add proprietary IEs to
different RSL messages we may pick this as a solution as well and add a
propritary RSL_IE_OSMO_REP_ACCH_CAP IE, so that we can enable repeated
FACCH/SACCH on the BTS side when we send RSL CHAN ACT or RSL CHAN MODE MODIFY
messages.
Change-Id: I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b
Related: OS#4796 SYS#5114
It could be that this spelling variant was originally used in the
specs., but now at least in 3GPP TS 44.018 they use 'existEnt'.
Change-Id: I847de910411f2edf7cc45b8c296b43e65fed5447
3GPP TS 44.006 8.6.3 "Procedures for re-establishment" is quite
explicit:
"""
When the data link layer receives in the multiple frame established state
or !!!timer recovery state!!! a DL-ESTABLISH- REQUEST primitive from layer
3 or an SABM (with L=0), the normal establishment procedure of sub-clause
8.4.1.2 shall be initiated.
"""
If L>0 in that state, send a DM as stated in 8.4.1.2:
"""
If the data link layer entity is unable to enter the multiple-frame-established
state, it shall respond to the SABM command with a DM response with the F bit
set to the same binary value as the P bit in the received SABM command.
"""
Related: OS#4549
Related: OS#4819
Change-Id: I7959dc39f883cd5c56c36a21176a2401838d7b62
As pespin point out, the kernel coding style says:
Do not unnecessarily use braces where a single statement will do.
[...]
This does not apply if only one branch of a conditional statement is a single
statement; in the latter case use braces in both branches:
Change-Id: Ia23c4bd018db141ff0afe77fe25678a9b2a395f0
The DEC_ERR() macro has a check for a missing type, but when used on the uint
h.type variable, emits a warning about an always-true statement. Try to work
around that warning with a cast to (int).
Related: CID#214888 CID#214890 CID#214891
Change-Id: Ic5fa87d23a6f0ce872de9c1dcfe36023981f70de
BSSLAP: there are APDUs transferred in BSSMAP-LE Connection Oriented
Information messages on Lb between BSC and SMLC.
Add BSSLAP coding for these APDU messages:
- TA Layer3
- TA Request
- TA Response, possibly containing Location Estimate coded in GAD
- Reject
- Reset (for intra-BSS handover during TA Request)
- Abort (for inter-BSS handover)
Add encoding and decoding tests.
Change-Id: I6409c4bcac402dc7626a3afce9081c59cd715fe8
GAD, Universal Geographical Area Description:
- raw coding for all GAD elements.
- SI-units encoding and decoding for Ellipsoid point with uncertainty circle,
which I presume is the typical "at most N meters away from cell tower located
at X,Y", which corresponds to the TA positioning currently being implemented.
- other SI-units GAD element encodings are so far not implemented.
Add encoding and decoding tests.
In gsm/protocol/gsm_23_032.h are the raw coding structs as defined in 3GPP TS
23.032.
In gsm/gad.h are structs carrying consistent units based on meters and degrees,
for convenient / less error prone handling of GAD data, and for human readable
representations of the GAD data.
The separation of the two is desirable because OsmoBSC will receive GAD data
from OsmoSMLC on the Lb interface, and pass on this data to the MSC via the A
interface. It is better to pass the GAD data as-is without de/encoding.
Change-Id: I7a9dd805a91b1ebb6353bde0cd169218acbf223c
According to 3GPP TS 48.008, section 3.2.2.44, the Chosen Encryption
Algorithm IE, which may be included in the following messages:
- 3.2.1.2 ASSIGNMENT COMPLETE
- 3.2.1.8 HANDOVER REQUEST
- 3.2.1.10 HANDOVER REQUEST ACKNOWLEDGE
- 3.2.1.12 HANDOVER COMPLETE
- 3.2.1.25 HANDOVER PERFORMED
- 3.2.1.31 CIPHER MODE COMPLETE
is coded as follows:
0000 0001 No encryption used
0000 0010 GSM A5/1
0000 0011 GSM A5/2
0000 0100 GSM A5/3
0000 0101 GSM A5/4
0000 0110 GSM A5/5
0000 0111 GSM A5/6
0000 1000 GSM A5/7
basically A5/X => X + 1. All other values are Reserved for future
international use. As can be seen, value 0x00 is RFU. Passing
this value to some encoding functions would result in a PDU with
this IE omitted. Although, some functions would still encode
Chosen Encryption Algorithm IE with this RFU value.
Let's ensure that all functions behave consistently.
Change-Id: If10e433a8174eabe6aa6d2c2937bf9cf5d14d7c9
According to 3GPP TS 44.005, section 4.2.2 "Priority":
a) on DCCH, a SAPI=0 frame always has higher priority than SAPI=3;
b) on ACCH, the priority arrangement is more complex:
b1) if a SAPI = 3 frame is awaiting transmission, two SAPI=0
frames shall not be sent in consecutive SACCH frames;
b2) on the network side (LAPDM_MODE_BTS), it must also be ensured
that any SAPI=3 frame is followed by at least one SAPI=0 frame;
b3) a SAPI = 0 frame may be repeated in the next SACCH period
if the Repeated SACCH is supported (see 3GPP TS 44.006, section 11).
We definitely need to extend our testing coverage to ensure that
we implement b) correctly, but for now let's focus on DCCH:
a) for DCCH, ensure that SAPI=0 frames preceed SAPI=3 ones;
b) for ACCH, re-use the existing round-robin implementation.
Change-Id: Ia3780bce1222b312ae2fd2d21496a4d6c5ccb6e0
Related: SYS#5047, OS#4731
This is basically a successor of gsm0808_create_sapi_reject(), but
instead of hard-coding GSM0808_CAUSE_BSS_NOT_EQUIPPED, it allows
the caller to specify a cause value to be used. The old function
is now deprecated and should not be used.
Change-Id: Iefe5484d0fa02d5722b628b1dc237d51d3fb1a9b
Related: OS#4728
The sysmobts uses the same OML attributes as IP.access. Because the IP.access
attribute only supports IPv4 as NSVC configuration, add an own attribute.
Change-Id: Ic261bc43a07fa741b97a9c6ec5a9ed6f5ecae588
When I wrote the new I.460 mux + demux code, I failed to realize that
* bit numbers in relevant ITU specs start with 1 as MSB ... 8 as LSB
* sub-slot 0 is bits 1+2, i.e. the two MSBs of a byte
* bit-ordering within each sub-slot is also MSB first
As a result, the code and test data was broken.
Change-Id: I6df7dbf411efbdeaf516e72ac552432bf5a569d0
When calling a user-provided call-back function for the i460 mux
or demux, always pass a pointer to the osmo_i460_subchan the callback
relates to. This way, the user can walk the i460 data structures
to obtain information about which mux/demux instances is calling.
Change-Id: Id842c72ce371a67fe5df6694e195c281aaf607ab
There is no way for the API user to know if the TX queue of the
multiplexer runs empty. However, this is criticil since an empty TX
queue will cause dropout of a TRAU frame, which can have quite severe
effects to the receiving end. Lets add a callback that allows the APU
user to insert appropiate idle frames or silent frames into the queue
before it runs empty.
Change-Id: I88a87724235fe50d55ce6215bb385c044072226e
Related: OS#2547
The define constants for the cause codes "BTS not equipped",
"remote transcoder failure" and "notification overflow" are missing.
Lets add them including value strings.
Change-Id: Ic3e936da00bd256bae03867887851f1a4e30e218
At least on Debian unstable, newlib is [currently?] buggy in that
we need to include sys/types.h before including inttypes.h, otherwise
PRIu64 is not defined.
Change-Id: Ic1c9cdf66cfd5b82bd7e20eaaf05b10e6bdb675e
Closes: OS#4686
When a subchannel is deleted or created the initalization mainly
consists of a memset over the wohle subchannel struct a message buffer
initailization.
However, when we delete a subchannel we also must take of the resetting
of the related struct. Currently this is done with a memest.
Unfortunately this creates not only a memory leak (there might be still
items in the multiplexer tx queue) but also it makes the application
crash when the message buffer is used the next time since the llist_head
of the tx queue looses its initialization.
Lets fix the memory leak problem and the message buffer problem and put
the reset functionality in a single place.
Change-Id: I937a9d4db95f44a860cd2c5dbb660dc1970b9a49
Previous both the IPA nanobts and the sysmobts has been using the IPv4 only OML
attribute NM_ATT_IPACC_NS_LINK_CFG.
A bts with BTS_FEAT_IPV6_NSVC supports IPv6 for NSVC (PCU<Gb>SGSN) using
the new OML attribute NM_ATT_OSMO_NS_LINK_CFG.
Change-Id: I9ef7949f66764b3c639e45eb440122e318da44a0
Follows patch I353adc1aa72377f7d4b3336d2ff47791fb73d62c that was merged too
soon. Applying my code review in form of this fixup patch.
Change-Id: I979bca0c6aaa8fe4feddda922bd2e6c1cb49585b
While processing an I-frame we may deliver its payload to L3. After
returning from L3 procesing, we run some additional code, assuming
the LAPD/DL state has not changed meanwhile.
However, if the application destroys the LAPD/DL meanwhile, our state
might be NULL again, and in this state we should not perform any further
action.
This is one of the cases where synchronous in-line dispatch across
various layers is hitting us. L3 should have an input queue, and only
start processing after all L2 work has completed and we're about to go
back to sleep in select().
Change-Id: I026b64503511002c13c0f4117648c366c48ecc62
Related: OS#1761
Closes: OS#4646
At some points, e.g. when allocating message buffers from the Tx
history, we used to allocate them exactly as large as the defined
headroom plus the user data. This means that the underlying PH layer
(E1 mostly) had no tailroom to add anything to the end of the message.
Especially for DAHDI this is a problem, as we need to make space for
two more bytes of frame check sequence (FCS).
So let's simply make sure we always have some extra space at the end
of such buffers.
Change-Id: Id362ce131157c7513d744b0248c7f78fb75c590c
Related: OS#4644
The previous example showed a type == IMSI while setting a TMSI value.
Rather show how to encode IMSI digits.
Change-Id: I41af6bf0d61443465172123297b1228584d791d6
This feature indicates if the given BTS supports paging coordination,
that is the transmission of CS paging (received on Abis) to be sent
via PACCH/PCU in PS domain fro MS with active TBF.
Change-Id: Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38
Related: OS#2406
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for current osmo CNI programs, replacing the Mobile
Identity coding with this new API. Deprecate the old MI API.
osmo-bsc: I71c3b4c65dbfdfa51409e09d4868aea83225338a
osmo-msc: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
osmo-sgsn: I4cacb10bac419633ca0c14f244f9903f7f517b49
Note that some GPRS and SGs related coding is done here in libosmocore and
hence currently remains using the old implementation (see previous version of
this patch: Ic3f969e739654c1e8c387aedeeba5cce07fe2307).
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
As a result, applications using osmo_mobile_identity will be stricter in
rejecting coding mistakes (some of which we currently have in our test suites,
and which we'll need to fix).
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
This patch was first merged as Ic3f969e739654c1e8c387aedeeba5cce07fe2307 and
caused test fallout, because it re-implemented old API with the new stricter
decoding. In this patch version, old API remains 1:1 unchanged to avoid such
fallout. Applications will soon switch to the new osmo_mobile_identity API and
become stricter on MI coding when that happens, not implicitly by a new
libosmocore version.
Change-Id: If4f7be606e54cfa1c59084cf169785b1cbda5cf5
This reverts commit d1ceca9d48, as it
introduces regressions in both osmo-msc and osmo-nitb which have been
causing failing builds for several days now.
Change-Id: I4bd958d0cd2ab4b0c4725e6d114f4404d725fcf7
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for all osmo programs, completely replacing the Mobile
Identity coding with this new API. Hence deprecate the old MI API.
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
Change-Id: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
These utilities will be used by osmo-bsc to determine the Network Resource
Indicator seen in the TMSI, and (potentially) by osmo-msc to compose a TMSI
with a specific NRI, for osmo-bsc's load balancing between several MSCs.
Add utility functions to:
- extract an NRI value from a TMSI.
- overwrite the NRI value in a TMSI.
- limit an NRI in a (random) TMSI to a given list of ranges.
- add NRI value ranges to a list.
- remove them from a list.
- match NRI value (range) to a list.
- parse NRI values from string, for VTY.
- common VTY functionality of adding/removing NRI values from argv.
Add C tests for the above.
Why we need public API for NRI ranges: In osmo-bsc alone, we need the same NRI
API twice, 1: to manage/list NRI value ranges per-MSC, and 2: to manage/list
NULL-NRI values. If we also consider (potentially) adding NRI support to
osmo-msc, we need the same API twice again there. Hence it is useful to define
re-used API up here in libosmocore.
Related: OS#3682
Change-Id: Icb57a2dd9323c7ea11b34003eccc7e68a0247bf5
The call identifier in the ASSIGNMENT COMMAND is encoded in the wrong
endieness. 3GPP TS 48.008, section 3.2.2.105 specifies that the least
significant byte should be transmitted first, which means that the
endieness here is little endian. Lets make sure that the endieness is
correctly transmitted, regardless of the host byte order.
Change-Id: I6468e502f552f99ab54aec9d4b1c169fdc0adfb8
Related: OS#4582
At the moment we print the pointer address to identify the log lines
belonging to a specific connection. Since pointer addresses are
difficult to work with, a human readable ID should be printed instead.
e.g. "This is LAPD instance for SAPI3 on bts0/trx1/ts5/lchan3"
Change-Id: Ie6742843fff809edffcac24c4dce4edf66bc71be
Closes: OS#1938
This implements a multiplexer and de-multiplexer for the ITU-T I.460
standard. The latter covers the transmission of sub-slots of 32/16/8k
inside 64k timeslots.
Change-Id: Id522f06e73b77332b437b7a27e4966872da70eda
Fix osmo_mi_name_buf() to snprintf() into the buf in *all* cases.
osmo_mi_name_c() is implemented via osmo_mi_name_buf(), which returns
compile-time string constants in special cases. That means that
osmo_mi_name_c() does return non-allocated strings in these special cases.
The caller of functions like osmo_mi_name_c() must always be able to rely on
getting a talloced string, or run a danger of deallocating const pointers.
Change-Id: I623959f01b72642bcdd18508097c5c405c59f6f1
This implementation is taken from OsmocomBB, in particular from:
target/firmware/layer1/rfch.c
Change return type to uint16_t, because neither ARFCN, nor MAI
can be negative. Add prefix 'gsm0502_' to the function's name.
Change-Id: I8aba1578cc9d1bd89d4f5d33a6e8fedc8bea789a
Related: OS#4546
As was pointed out by pespin, some compilers may not like the
lack of spaces around the format macro constants.
Change-Id: I4b6517989030c8e3f6a1bf16c43044e4e9137f40
In Change-Id Idf2b99e9ef014eba26e3d4f0f38c2714d3a0520a we accidentially removed this
symbol, let's re-introduce it.
Change-Id: I9fbcbcc6619ef0c63d3682fc86adc80045baab02
Function gsm0808_get_cipher_reject_cause() was previously available
in private gsm0808_utils.h. In practice, the exact same code is useful
to extract Cause IE value from any of the many other BSSMAP messages
which use it.
So let's rename it to gsm0808_get_cause() and make it avilable
to everyone to use.
Change-Id: Idf2b99e9ef014eba26e3d4f0f38c2714d3a0520a
See TS 08.08 section 3.2.1.34 SAPI "n" REJECT:
1) DLCI is a TV element, not V.
2) Cause is a TLV element and we have a special function to encode it.
Change-Id: I033afe556c06427d06ac55c4f78854a45e41aae6
AMR SID update frames are protected using an 1/4 convolutional coder,
wich is similar to the one used with 6,7 kbit voice frames. Except that
there is no puncturing and the length is different.
Change-Id: Ia35ed4178a7f0d816052b7e5d6478b93a1d9744f
Related: OS#2978
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I84ef43f700e125c7a65f92347f12844e07e65655
This is a bit of a hack, as we want to maintain binary compatibility
without breaking existing users of libosmocore. To do so, we use the
'num_auth_vectors' field in two ways now:
* In the existing use case as part of SEND_AUTH_INFO_RESPONSE, it
indicates the number of vectors stored in the 'auth_vectors' field
* In the new use case as part of SEND_AUTH_INFO_REQUEST, it indicates
the number of vectors actually requested by the MSC/SGSN/MME.
Change-Id: Iaecc47280f8ce54f3e3a888c1cfc160735483d0f
In July 2018 in commit Ide240279240322f643e142229eb7829f538c6314 we
introduced the successor gsm0480_gen_ussd_resp_7bit(), which is also
what both libosmogsm-internal code as well as osmo-hlr have been ported
to. For some reason it wasn't marked deprecated back then.
Change-Id: Iff4c91b5b98a73d9a30aa42f6b2a1ebcc8a45343
GSUP routing was introduced when adding the E interface. Hence that was the
first realm where routing errors could occur. I did notice back then that this
message type was special: it does not convey a response to a particular message
kind -- it does not make sense, for example, to return an Updating Location
Error cause, and do that for all conceivable message types. Instead, this tells
the sender that a deeper error exists, i.e. that the desired peer is completely
gone and unreachable.
I did not foresee though that for D-GSM, there would also be arbitrary GSUP
proxy routing, and that this error is not limited to E interface semantics.
From today's point of view, adding the "_E_" in the name was a mistake.
Remove that "_E_" to yield OSMO_GSUP_MSGT_ROUTING_ERROR (with unchanged message
type discriminator), but provide a #define linking the old name
OSMO_GSUP_MSGT_E_ROUTING_ERROR to the new one.
The only visible change should be that osmo_gsup_message_type_names[] now
returns the new name without "_E_". I am not aware of any regression test
fallout from that.
Change-Id: Ic8e8bd11522d6c51ac7aaf946516cbce26bc6e1e
The calculation of the beginning of a block for TCH/F, TCH/H and FACCH
can be challenging since those channels are affected by the diagonal
interleaving of the TCH channels. However, GSM 05.02 Section 7 Table 1
of 5 specifies how the blocks are distributed over the TDMA frame
interval. Lets add a mapping function that is based on that table
Related: OS#3803
Change-Id: I3d71c66f8c401f5afbad9b1c86c24580dab9e0ce
OSMO_GSUP_SUPPORTED_RAT_TYPES_IE corresponds to the Supported RAT Types
Indicator from 3GPP TS 29.002. See 8.1.2 MAP_UPDATE_LOCATION service,
which indicates the capabilities of the MSC/VLR to the HLR.
So far, have room for eight RAT types in the gsup_msg. That is an arbitrary
random choice without any rationale.
OSMO_GSUP_CURRENT_RAT_TYPE_IE is useful to communicate the currently
used RAN / RAT type of the current subscriber during Location Updating Request.
Change-Id: I93850710ab55a605bf61b95063a69682a2899bb1
As 3GPP doesn't specify how the BSC shall communicate ETWS Primary
Notifications over Abis/RSL, we have to use a vendor-specific RSL
message for this. And in order to know if the peer supports this
feature, we introduces BTS_FEAT_ETWS_PN.
Change-Id: I89c24a81ada6627694a9632e87485a61cbd3e680
Related: OS#4046, OS#4047
The user length is the first IE *in* the fixed-length TV, make sure
cbsp_dec_write_repl() respects that.
Change-Id: I864cafac2466a89a4bd9644bc73363fff2babd03
The CBSP code assumed that gsm0808_decode_cell_id_u() would return
the number of bytes it has consumed/parsed. But it actually always
returns '0', whcih makes us run in an endless loop :(
Change-Id: I5758af4ec11a827d4b888a3a16c4ec22de90a7d6
Rather than having the encoder/decoder library print some log
messages in case of encoding/decoding errors, let's provide something
akin to 'errno', but with a string instead of a numeric error code.
The 'osmo_cbsp_errstr' global variable (if set) contains a
human-readable string describing the most recent encoding/decoding error.
It exists separately for each thread and hence can be used safely in
multi-threaded environments.
Change-Id: Id9a5a595a76ba278647aee9470ded213d8464103
This introduces definitions as well as a parser+encoder for the
Cell Broadcast Service Protocol (CBSP) as specified in 3GPP TS 48.049.
CBSP is used on the interface between CBC and BSC.
Related: OS#3537
Change-Id: I5b7ae08f67e415967b60ac4b824db9e22ca00935
When using `OSMO_ASSERT(exp);` clang will warn about
an empty expression because the semi colon was superflous.
Use do {} while (0) to enfore the need of a semi colon.
This might break other test.
Change-Id: I2272d29a81496164bebd1696a694383a28a86434
The timeout is calculated dynamically in t200_by_lchan() based on FN
advance value estimated by bts_get_avg_fn_advance(), so it's informative
to have the final value printed out.
Change-Id: Ib50a9c23de881c66c9218833703cc41101e06bfd
Return ENOSPC if the decoding buffer is one byte too small, instead of
returning 0 and silently truncating the string. Add a new "truncated"
variable to detect if the loop breaks in the final iteration.
The string is not truncated if there is exactly one 0xf ('\0') higher
nibble remaining. This is covered by the existing test case "long
15-digit (maximum) MSISDN, limited buffer".
Related: OS#4049
Change-Id: Ie05900aca50cc7fe8a45d17844dbfcd905fd82fe
During testing with BTS_Tests_LAPDm.TC_t200_n200() it was discovered
that the existing LAPD[m] implementation always gave up at N200-1
retransmissions, rather than N200 retransmissions.
The first transmission doesn't count, and hence we must have N200
actual re-transmissions. The Error message is then described as
"T200 expired N200+1 times", i.e. we start T200 one more time after
the last re-transmission and only give up if it expires again (i.e.
no ACK received)
Change-Id: Ic33854ee61311f73b7db55eeef10280349151097
Related: OS4037
TS 04.06 specifies a N200 re-transmission counter that depends on the
channel type, which we didn't care about at all so far. Let's have the
caller tell us the channel type so we can internally look up the correct
N200 value for it.
At the same time, permit the user to specify T200 re-transmission timer
values for each SAPI on both DCCH and ACCH, which is required at least
in the BTS as per GSM TS 12.21. Also, extend the timer resolution of
the API from seconds to milli-seconds, which is more applicable as
particularly on the FACCH the recommended values are in the 200ms range.
Change-Id: I90fdc4dd4720d4e02213197c894eb0a55a39158c
Related: OS#3906
Related: OS#2294
Related: OS#4037
This function parses a single Cell ID list element into a
'union gsm0808_cell_id_u'. This function is going to be used
by the upcoming CBSP support.
Related: OS#3537
Change-Id: I08b33881667aa32f01e53ccb70d44d5b79c7c986
We have a number of library-internal static global buffers which are
mainly used for various stringification functions. This worked as
all of the related Osmocom programs were strictly single-threaded.
Let's make those buffers at least thread-local. This way every thread
gets their own set of buffers, and it's safe for multiple threads to
execute the same functions once. They're of course still not
re-entrant. If you need re-entrancy, you will need to use the _c()
or _buf() suffix version of those functions and work with your own
(stack or heap) buffers.
Change-Id: I50eb2436a7c1261d79a9d2955584dce92780ca07
3GPP TS 04.06 is quite clear that the [segmented] L3 payload can be as
long as 251 bytes. Our libosmocore lapdm implementation truncated
already at 200 bytes :(
Change-Id: I6769986f27dda1d429ed7b2e32c36d34663acba9
Closes: OS#4035
The library should either provide functions that implement encoding
of those rest octets, or it shouldn't. Providing a function that
doesn't do anything but pad the buffer is useless.
Change-Id: Ie10684de6a6b2663e2a871fcdb2b275b6ad7a1e7
There's very little sense behind introducing a function into
libosmogsm which doesn't implement 90% of the spec. Let's allow
the caller to provide the various optional bits of information to
the encoder, rather than generating mostly static SI6 rest octets.
Change-Id: Id75005a0c4a02ce7f809692d58b3bd226bc582b2
the symbols had an omso_ prefix, while the entry in the .map file
didn't. As a result, all related symbols were never exported and
hence not usable by any users of the dynamic library.
Change-Id: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330
The gsm48_rest_octets.c file was added in Change-Id
I47888965ab11bba1186c21987f1365c9270abeab, but it never actually
ended up being compiled as it wasn't listed in the makefile :/
Change-Id: I0355115c2645f236c9e32cf7a563cf51a857e8a3
Relsted: OS#3075
As gsm48_rest_octets.c is not listed in the Makefile.am, it's
never actually compiled and we never noticed that it's calling
functions by symbol names that don't exist :/
Change-Id: I7b1e436f70e0c60979261db87606f38271ec47d3
Related: OS#3075
libosmo{core,gsm,vty} code is GPLv2+. The rest octet code originated in
osmo-bsc.git and was moved here without changing the license. That was a
mistake, it always was meant to be under GPLv2-or-later after moving to
libosmocore.git.
Original copyright is mine. For contributions by sysmocom, I as the
managing director can approve the license change.
This means only Holger needs to ACK this.
Change-Id: Ief3009dc28dd83e1e26a7101af2eed2341684a87
The documentation of gsm48_decode_bcd_number2() clearly states that
the output truncation is a erroneous case, so it should actually
return negative in such cases. Let's return -ENOSPC.
Change-Id: I75680f232001ba419a587fed4c24f32c70c3ad2b
Thanks to the new unit test for BCD number encoding / decoding, it was
discovered that gsm48_decode_bcd_number2() does not properly handle
encoded LV if the output buffer size is equal to the original MSISDN
length + 1 (\0-terminator): one digit is lost.
For example, decoding of 15-digit long MSISDN to a buffer of size
16 (15 digits + 1 for \0) would give us only 14 digits.
The problem was that 'output_len' was being decremented before
checking the remaining buffer length and writing a digit to it.
As a result, the maximum length was always one byte shorter.
Change-Id: I61d49387fedbf7b238e21540a5eff22f6861e27a
Fixes: OS#4025
libosmo{core,gsm,vty} code is GPLv2+. The OAP code originated in
osmo-msc.git and was moved here without changing the license. That
was a mistake, it always was meant to be under GPLv2-or-later after
moving to libosmocore.git.
Copyright is with sysmocom, so I as the managing director can
approve the license change.
Change-Id: I08311fa8214c15f8df8945b9894226608cf96f15
We don't really *need* it in libosmocore as such, but the lack of
having all osmocom extensions listed here lead to using overlapping
definitions: 0x18 was used for dynamic PDCH on the Abis side, but also
for CBCH on the L1SAP side. Let's list them all here to increase
visibility in case anyone wants to extend this further...
Related: OS#4027
Change-Id: I93e557358cf1c1b622f77f906959df7ca6d5cb12
The caller of lapdm_rslms_recvmsg() (e.g. osmo-bts/src/common/rsl.c)
assumes the message ownership is transferred. However, in one of the
two error paths, msgb_free() was not called and hence we had a memory
leak.
Also clarify the msgb ownership transfer in a comment.
Related: OS#3750
Change-Id: Id60cb45e50bfc89224d97df6c68fcd2949751895
So far, the TLV code contained two types of functions
* tlp_parse() to parse all TLVs according to definition into tlvp_parsed
* various helper functions to encode individual TLVs during message
generation
This patch implements the inverse of tlv_parse(): tlv_encode(), which
takes a full 'struct tlv_pared' and encodes all IEs found in it. The
order of IEs is in numerically ascending order of the tag.
As many protocols have different IE/TLV ordering requirements, let's add
a tlv_encode_ordered() function where the caller can specify the TLV
ordering during the one-shot encode.
Change-Id: I761a30bf20355a9f80a4a8e0c60b0b0f78515efe
Add the constant, so it can be used in create-subscriber-on-demand
related patches. ITU-T Rec. E.164 6.1 states that maximum international
number length should be 15. I did not find a source for a minimum
length, but I've added the constant and set it to 1 for consistency
(based on the existing osmo_msisdn_str_valid() function).
Related: OS#2542
Change-Id: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1
IE GSM0808_IE_OSMO_OSMUX_SUPPORT (T, 1 byte) is sent in AoIP appended to
BSSMAP RESET in order to announce the peer that its MGW supports handling
Osmux streams upon call set up.
IE GSM0808_IE_OSMO_OSMUX_CID (TV, T 1 byte & V 1 byte) is sent in AoIP
during call set up:
* MSC->BSC Assignment Request
* BSC->MSC Assignemnt Complete
The 1 byte value contains the local Osmux CID, aka the recvCID aka CID where the
peer sending the Assign Req/Compl will look for Osmux frames on that
call. Hence, the peer receiving this CID value must use it to send Osmux
frames for that call.
As a result, a given call leg BSC<->MSC can have one different Osmux CID
per direction. For example:
* MS => MGW_BSC ==CID 0==> MGW_MSC
* MS <= MGW_BSC <=CID 1=== MGW_MSC
This allows for setups with 256 call legs per BSC on scenarios where NAT
is not a problem, where MSC can have a pool of 256 CID per MGW_BSC (or
remote peer).
Related: OS#2551
Change-Id: I28f83e2e32b9533c99e65ccc1562900ac2aec74e
This function is doing the bulk work of encoding a given Cell
ID List item. gsm0808_enc_cell_id_list2() is modified to be a
wrapper / loop around the new function.
The purpose of this is to expose Cell ID List Entry encoding
so that the upcoming CBSP protocol encoder can re-use this code.
Related: OS#3537
Change-Id: I6cc567798e20365e6587e6b2988e834306d8c80c
In testing against a particular EPC, the SGsAP-SERVICE-REQUEST
can contain a MO fallback value TLV with T 0xF1
Change-Id: Ia2460af9673818d375e28c67f1631b5f7eacdaeb
osmo-bsc so far omits the AoIP Transport Layer Address from its Handover
Request Acknowledge message, which breaks inter-BSC Handover for AoIP.
Allow fixing that.
One quirk I really don't like about this: I would prefer to directly use struct
sockaddr_storage as a member of the struct gsm0808_handover_request_ack. Even
though struct sockaddr_storage appears in various function signatures, the
gsm0808.c actually also gets built on embedded systems that lack arpa/inet.h
(for me indicated by the ARM build job on jenkins). Compiling gsm0808.c works
only because the actual coding of struct sockaddr_storage is implemented in
gsm0808_util.c, which (apparently) does not get built on embedded and hence,
even though there are undefined references to e.g.
gsm0808_enc_aoip_trasp_addr() it works.
Related: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff (osmo-bsc)
Change-Id: Ia71542ea37d4fd2c9fb9b40357db7aeb111ec576
In osmo_gsup_decode(), call gsm48_decode_bcd_number2() to avoid deprecation
warning, and also actually check the return value to detect invalid IMSI IEs.
Change-Id: Iaded84d91baad5386c8f353c283b6b9e40a43b05
gsm48_decode_bcd_number() is marked as deprecated, so
gsm48_decode_bcd_number2() will cause deprecation warnings as long as it calls
gsm48_decode_bcd_number(). Hence move the code to gsm48_decode_bcd_number2().
Change-Id: I81925e9afb3451de9b8a268d482f79ee20ca14d6
The input_len argument for gsm48_decode_bcd_number2() includes the BCD length
*and* the length byte itself, so add the missing +1.
Also clarify the API doc for the input_len argument.
Change-Id: I87599641325c04aae2be224ec350b1a145039528
gsm48_decode_bcd_number() is unable to provide proper bounds validation of
input and output data, hence osmo-msc's vlr.c introduced a static
decode_bcd_number_safe() a long time ago. Move to libosmocore.
I need to use the same function to decode an MSISDN during inter-MSC Handover,
instead of making it public in osmo-msc, rather deprecate the unsafe function
and provide a safer version for all callers. Mark the old one deprecated.
Change-Id: Idb6ae6e2f3bea11ad420dae14d021ac36d99e921
Change two instances of Speech Version values to enum gsm0808_permitted_speech.
It is often not trivial to find the right values for a uint8_t member, giving
the enum name makes it a lot easier/safer to use.
In gsm0808_create_handover_required(), use msgb_tv_put() so that the enum's
storage size doesn't matter. (Already used for handover_performed)
Fix typo in doc of gsm0808_create_handover_required().
Change-Id: I6387836bab76e1fa42daa0f42ab94fc14b70b112
Based on a draft created by Neels, which is the result of reading a MAP
trace of two MSCs negotiating inter-MSC handovers, and of reading the
TS 29.002, TS 29.010 and related specs:
https://lists.osmocom.org/pipermail/openbsc/2019-January/012653.html
I figured out that the "Handover Number" mentioned in the specifications
is the same as the MSISDN IE that we already have, so we can use that
instead of creating a new IE (example usage in tests/gsup/gsup_test.c).
Create a new OSMO_GSUP_MSGT_E_ROUTING_ERROR message type, which the GSUP
server uses to tell a client that its message could not be forwarded to
the destination (see [1]). MAP has no related message.
[1]: Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5 (osmo-hlr.git)
Related: OS#3774
Change-Id: Ic00b0601eacff6d72927cea51767801142ee75db
osmo-msc and osmo-hlr have distinct subsystems handling incoming GSUP messages.
So far we decide entirely by message type which code path should handle a GSUP
message. Thus no GSUP message type may be re-used across subsystems.
If we add a GSUP message to indicate a routing error, it would have to be a
distinct message type for subscriber management, another one for SMS, another
one for USSD...
To allow introducing common message types, introduce a GSUP Message Class IE.
In the presence of this IE, GSUP handlers can trivially direct a received
message to the right code path. If it is missing, handlers can fall back to the
previous switch(message_type) method.
Change-Id: Ic397a9f2c4a7224e47cab944c72e75ca5592efef
We have a habit of returning static buffers from some functions,
particularly when generating some kind of string values. This is
convenient in terms of memory management, but it comes at the expense
of not being thread-safe, and not allowing for two calls of the
related function within one printf() statement.
Let's introduce _c suffix versions of those functions where the
caller passes in a talloc context from which the output buffer shall
be allocated.
Change-Id: I8481c19b68ff67cfa22abb93c405ebcfcb0ab19b
The function osmo_dump_gsmtime_buf gets a pointer *buf and a parameter
buf_len. The pointer *buf is a string buffer and the function places an
\0 at the end of the buffer before it exists. However it uses
sizeof(buf) as part of the index calculation, which is incorrect. Lets
correct this by using buf_len instead.
Change-Id: Id24263aa7c9a53544f1639b6ceb09ce5615d5114
We have a number of static buffers in use in libosmo*. This means
the related functions are not usable in a thread-safe way. While
we so far don't have many multi-threaded programs in the osmocom
universe, the static buffers also prevent us from calling the same
e.g. string-ify function twice within a single printf() call.
Let's make sure there's an alternative function in all those cases,
where the user can pass in a caller-allocated buffer + size, and make
the 'classic' function with the static buffer a wrapper around that
_buf() variant.
Change-Id: Ibf85f79e93244f53b2684ff6f1095c5b41203e05
ipa_ccm_idtag_parse_off is broken, and can only be used with
len_offset=1 on ID Request messages, otherwise won't work correctly.
Modify ipa_ccm_idtag_parse to at least parse those correctly, and
document the limitations.
Those two functions are already deprecated and only used in openbsc by 3
callers:
* ipa_ccm_idtag_parse in ussd_read_cb(): Broken, that function can only
work for Requests and it's used to parse a Response.
* ipa_ccm_idtag_parse_off in forward_sccp_to_msc (NAT): Broken, it can
only be used to parse Requests and it's used to parse a Response.
Furthermore, len_offset=2 is passed which makes no sense and most
probably it fails always, or can even make the program crash.
* ipa_ccm_idtag_parse_off in (answer_challenge): This one is fine and
could actually be replaced with ipa_ccm_id_get_parse after this commit
is merged.
Change-Id: I6efc852dfc041192f554e41a58290a0f63298021
This reverts commit 1261db1505.
The patch broke openbsc's external tests, and currently it is unclear
whether it is just an error in the test or if openbsc makes wrong
assumptions about the length value. Let's revert the patch to unblock
the master-openbsc jenkins job.
Related: OS#3851
Change-Id: I9adea35ff6de36c1611c7f85dde1b15bc1c0e786
IPA CCM is using a somewhat weird TLV encoding scheme:
* 16bit length (of tag and value)
* 8bit tag
* value
Our existing code mapping the CCM to 'struct tlv_parse' used the plain
length value without accounting for the one-byte tag.
This patch ensures we only report the length of the "value" part,
excluding the tag.
Change-Id: I435aaa33605bd48635715a2c81aa2d231c1abf51
Neels Hofmeyr
Vadim Yanitskiy
Pau Espin
Philipp Maier
Neels Hofmeyr
Eric Wild
Harald Welte
Sylvain Munaut
Oliver Smith
Daniel Willmann
Kevin Redon