Instead of counting digits and slashes of the IPA Unit ID manually,
use POSIX regex functions, so the code is easier to maintain and
read. As a bonus, this fixes CID#188854: variable 'remain_slash'
was of type 'uint8_t', so it could never be lower than zero.
Change-Id: Id613bf650833dd38eaad08fdfffdf8dbe2f002b1
Related: CID#188854 Unsigned integer overflow
The 'return' that makes Coverity angry can be safely replaced by 'break'.
Change-Id: Ib3d7519421319fb0e6d65441bba123b7b01f4556
Fixes: CID#188873 Identical code for different branches
Fixes: CID#188850 Identical code for different branches
Fixes: CID#188845 Identical code for different branches
We don't need to know position of matches: just yes or no.
This change would save some computation power.
Change-Id: Ia8414bf83d030adfae806c0aeaa757bc4c8cda2b
At the moment the length field of the bssmap header is not parsed.
Instead the length is computed out of the known header length and the
number of bytes received. This is prone to error, lets make sure that
extranous data at the end of a message is ignored by parsing the bssmap
length correctly.
Change-Id: Idef2e783d2377a2ad1f697ea4d26491a32b3e549
Related: OS#3806
With the FORGET_MGW_ENDPOINT event, the MGW endpoint FSM notifies the gscon
that it has deallocated and that hence the gscon should forget all references
to it (to avoid a use-after-free).
Also do this for the endpoint FSM and endpoint ci pointers in the conn->ho.*
sub struct.
I saw a use-after-free after a Handover Failure message tears down the lchan
and MGW endpoint before triggering the handover_fsm.c cleanup code, which also
tries to clean up an endpoint CI if it was created for the failed Handover.
Change-Id: I6702ccd0df44bea5eb8b26d471d7903c24e6e30b
The symbol GSM0808_SC_CFG_AMR_4_75_5_90_7_40_12_20 is used in
lchan_fsm.c, but gsm_08_08.h, where the symbol is declared is not
included.
Change-Id: I46f910b3e0f2c7d8c78c1681acef30b9419e39f0
MGCP/SDP provides fmtp parameters in order to signal which of the two
available AMR framing modes (octet-aligned or bandwith-efficient) should
be used on the link between BSS and core network. osmo-bsc currently
does not set up this mode which means that the RTP packets from the BTS
are forwared without inspection/modification, which may lead to
malfunction when a BTS is using a framing mode that is not supported by
the other end.
- Add VTY option to setup the framing mode
- Generate related fmtp parameters in SDP
Depends: osmo-mgw I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
Change-Id: If6d40b2407b87aad2227ea7f15533ef01a3771b3
Related OS#3807
Before this patch, all OML GET ATTRIBUTES messages were encoded with
an erroneous OML header length value. The length value was always three
bytes less than the actual message length. This patch fixes the
problem.
Change-Id: I56068de0bb14a99ec39be587e542e27cddb7d1df
Closes: OS#3799
When "Config-NB-Code = 1" is set via the S-bits, then the resulting
multirate configuration IE will contain 12.2K. Since the generator
function is not aware if the lchan is activated for HR or FR it sets the
flag for 12.2k always.
We have to add a check here in order to set the 12.2k flag in the IE
back to 0 so that the active set contains a set of useable rates.
Change-Id: I40e7f568f4822040a2d1e78f22dbba0e49d0167e
Related: SYS#4470
When gsm48_mr_cfg_from_gsm0808_sc_cfg() is used to generate the AMR
multirate configuration IE, make sure that lchan allocation fails in
cases where the multirate configuration IE can not be generated.
Change-Id: Icd3e5674b10b8ae223c0d13ae33fc9ae7e8a8a18
Depends: libosmocore I6fd7f4073b84093742c322752f2fd878d1071e15
Related: SYS#4470
When match_codec_pref() is called and the codec selections from the
ASSIGNMENT COMMAND are matched against the interal capabilities, the
configurations are checked one by one. When a match is found that match
is returned.
However, the implementation currently does not check the AMR S15-S0 bits
when the actual matching happens. This is done afterwards in case AMR
gets picked. Unfortunately if the MSC implementation is not obeying the
settings the MSC has previously communicated in the L3 COMPL message we
may end up with an S15-S0 configuration that has all rate selection
(which eventually end up as active set in RSL) bits set to zero. This is
an invalid configuration and should be prevented. Also the handling of
the S15-S0 bits should happen as part of the matching so that there is a
chance to try the nect codec in the list if AMR is unuseable.
Also S15-S0 has one special setting "Config-NB-Code = 1" (S1 = 1). When
this bit is set, the four (in HR only three) most common rates are
selected into the active set. If there are also other S-bits set besides
S1 we should prefer S1 and discard the other bits.
- Perform handling of S15-S0 while matching
- If S1 is set, prefer this setting and discard all other settings
Change-Id: Ie52376b51fe07ed07056e8df2e9557293ff67a78
Related: SYS#4470
The current configuration for permitted AMR rates on BTS level has been
choosen arbitrarily. Lets choose the possible rates so that they match the
"Config-NB-Code = 1" as defined in 3GPP TS 28.062 Table 7.11.3.1.3-2.
(The current default behavior is not changed since the MSC level
configuration only permits 5.90k by default.)
Change-Id: I916953e3fdb54168671dd13b359e78662fa31059
Related: SYS#4470
This commit breaks voice channel assignment. It results in the
Assignment Complete sent to the MSC for a voice lchan lacking
AoIP Transport Layer Address, Speech Version and Speech Codec.
Hence the MSC cannot complete the Assignment for a voice call.
Let's revisit this patch, test thoroughly and re-merge later.
This reverts commit 4d3a21269b.
Reason for revert: <INSERT REASONING HERE>
Change-Id: I72aaa03539919e7e85b5b75b133326cec5e68bc9
This commit aims at better ordering of content in order to get rid of
sigtran stuff in gsm_data. This way we can avoid requiring
libosmo-sigtran when building ipaccess utils.
Change-Id: I8941f059d6e4eb21a971d48d2b66c29ec3355a6d
To support the 3 possible preferences, the changes needed were:
- Replace 'full_rate' bool with a 3 option enum to represent
the channels types for signalling
- Switch from _pref/_alt to using an array sorted in preference
order
Change-Id: I4c7499c8c866ea3ff7b1327edb3615d003d927d3
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When a new lchan is selected during handover, some of the properties of
the old lchan are inherited by the new lchan. At the moment S15-S0 is
not not inherited so that the value for those bits will always be 0x0000
for the new lchan. Since those bits also define the active set AMR codec
the channel activation will fail because 0x0000 is invalid (active set
with zero rates)
Change-Id: Ifd470397e99985394634da1bb13ccfc5041984d2
Related: OS#3503
When the ASSIGNMENT COMPLETE message is composed,
lchan->ch_mode_rate.s15_s0 is used to fill in the S15-S0 which are
returned to the MSC. This is not correct since the assignment process
may involve multiple lchans, so that at the point where the ASSIGNMENT
COMPLETE is generate, the stored S15-S0 may be lost already because the
lchan has changed. To prevent this, we must use
lchan->activate.info.s15_s0, which is retained throught lchan changes.
Change-Id: I9a7b3ce8646d641569eac24e202f44cdb5f67b3d
Related: OS#3503
When the MSC allocates a channel through the ASSIGNMENT REQUEST, it may
ask for a TCH/H and a TCH/F at the same time and tell which of the two
types it prefers.
The process of channel allocation currently selects, based on the BTS,
MSC and MS capabilites exactly one apropriate codec/rate (e.g. TCH/H)
and then tries to allocate it. If that allocation fails, there is no way
to try the second choice and the assignment fails.
For example: The MSC asks for TCH/F and TCH/H, prefering TCH/F, then the
channel allocator will try TCH/F and if it fails (all TCH/F are
currently in use), then TCH/H is never tried.
Since the BSC currently only trys the first best codec/rate that is
supported it also ignores the preference.
Lets fix those problems by including the preference information and both
possible codec/rate settings into the channel allocation decision.
Change-Id: I5239e05c1cfbcb8af28f43373a58fa6c2d216c51
Related: OS#3503
In some test and debug situations it is useful to have the ability to
lock certain lchans in a way that the BSC can not allocate them. One
application might be to simulate an exhaustion of all TCH/H channels in
order to force the BSC to take one of the available TCH/F.
Lets add a command to the vty which alloes us sen lchans from
LCHAN_ST_UNUSED
to LCHAN_ST_BORKEN and vice versa.
Change-Id: I397e68e26d6a1727890353fa34f4897b54795866
Related: OS#3503
handover_fsm.c accesses conn->assignment.req.s15_s0 to find out the current
lchan's AMR configuration. However, conn->assignment.* values are only valid
during an ongoing assignment. Those values may be overwritten by any failed
Assignment attempt, at any time, and hence do not reflect the currently
assigned conn->lchan. Those realms must be kept separate.
The assignment.req.s15_s0 get passed to lchan_activate(), so it makes most
sense to store these values in struct gsm_lchan once the lchan activation
succeeded.
Add gsm_lchan.s15_s0, store the s15_s0 received in lchan_activate_info during
lchan_activate().
In handover_fsm.c, use conn->lchan->s15_s0 instead of conn->assignment.*.
Change-Id: Id8018fd9d56421f2ab7be91703018f6d6f21c929
When the MSC sends a BSSMAP CLEAR CMD containing a CSFB Indication IE,
it lets us know that the to-be-released connection related to a CSFB
call.
We as the BSC then subsequently should include the "Cell Selection
Indicator after release of all TCH and SDCCH" IE in the RR RELEASE
message sent to the MS/UE. This IE contains the LTE neighbor cells
that we're configured to broadcast in si2quater.
That in turn will make sure the MS/UE can return very quickly to
the LTE cell.
Closes: OS#3777
Change-Id: Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Requires: libosmocore Id4bd7f7543f5b0f4f6f876e283bd065039c37646
Requires: libosmocore I0e101af316438b56d63d43fc2cb16d7caf563d07
Requires: libosmocore I8980a6b6d1973b67a2d9ad411c878d956fb428d1
We meanwhile have chapters about the CTRL interface protocol as well
as the auto-generated list of CTRL interface commands/values, so
let's remove the somewhat redundant information.
Change-Id: I062d7eec3b3fc53c31726be3b3a407a2dd3b8b56
We still haven't re-introduced support for E1 based BTSs, so let's
remove the relevant chapters from the manuals. Also, make sure
we don't call anything OsmoNITB in this manual anymore.
Change-Id: I834d65836731958b6be823a18e35407183398715
It makes a lot of sense to first describe the VTY interface before
going on using it to configure something. Also, configuration related
topics relevant to operators/sysadmins should precede other content
only relevant to developers, like the details of the CTRL or Abis/IP
protocol.
Change-Id: I0872d072bbb06f9409a72b93133d136167f03b38
This adds some instructions on how to configure 3G/4G neighbor
cells within osmo-bsc. I didn't want to add a new top-level
chapter but instead chose to add it to the handover section which
describes also the configuration of 2G neighbors.
Change-Id: I81df1a453858b6fca80c8adf234b1d5b8bf5283d
In GSM specs, the entire interface between two elements is designated
with some letter, like the A interface between BSC and MSC. The
interface uses a variety of protocols stacked on each other.
In the specific case of A, there is no "A" on top of SCCP, but
there's "BSSAP" on top of SCCP.
This is followed somewhat un-orthodox by 3GPP, as "A over IP" is
a violation of that principle. It should have been called "A utilizing
IP", "A based on IP", "A with IP" or something the like.
In any case, at no point do the specs ever claim that "A" is stacked
on top of SCCP, so let's fix this.
Change-Id: Ieb0d8f6c71debe1234aff343a994c2096326da1b
Currently the VTY only displays the lchans that are currently in use
(show lchan summary). In some situations (debugging) it can be useful
to list all lchans, regardless of their state. So lets add a command
for that.
Change-Id: Ie4d763476905fa8f84b4d7cdad4cc7dd879f84a5
Related: OS#3503
* use gsm0808_create_ass_compl2() to add BSS Status IE to Assignment
Complete message
* drop local helpers
Depends-on: (libosmocore) I547c6b8707123aa8c1ef636db88908df112d90a4
Change-Id: I6916928391667cd9c345becf00e7c8561846c295
Related: OS#2487
On rsl_rx_chan_rqd(), so far osmo-bsc tried to preferably assign the lchan type
that was asked for in the RACH. Firstly, this contained a bug, and secondly,
it does not make sense to heed that preference, since we do late assignment.
Ignore the preference for the MS' TCH kind.
We do late assignment to avoid codec mismatches. In the "old days", we would
heed the MS' TCH channel kind, even if the MSC or BSC didn't actually allow
or prefer that channel kind. Hence, in the presence of both TCH/F and TCH/H,
the MS could ask for TCH/F (which we would grant on the MO side) and the BSC
or MSC could prefer TCH/H (which we would apply on the MT side), and hence
fabricate a codec mismatch. Instead, since quite some time now, we *always*
assign an SDCCH first, and only later on do another Assignment to hand out
a proper voice lchan that heeds the MS capability bits as well as MSC's and
BSC's preferences.
By completely ignoring the channel kind the MS asked for in the RACH, we
also eliminate this bug in rsl_rx_chan_rqd():
- If the first "lchan_select_by_type(GSM_LCHAN_SDDCH)" fails (all SDDCH in use),
we should try to fall back to any TCH instead, to serve as SDCCH.
- the first "if (!lchan && lctype != GSM_LCHAN_SDCCH)" was an attempt to prefer
a fallback to the lchan type the MS requested.
- the remaining two "if (!lchan && lctype == GSM_LCHAN_SDCCH)" were obviously
only applied if the MS asked for an SDCCH, and skipped if the type was TCH/*.
- hence, missing was: if the MS asked for a TCH, to also try the *other* TCH
kind that the MS did not ask for. (Example: all SDCCH in use, MS asks for
TCH/F, but BSC has only TCH/H lchans; we should assign TCH/H as SDCCH, instead
we said "no resources")
Change-Id: Ie3684cf071751f9528183d761c588102936e498c
Related: OS#3503
The function lchan_select_by_type() will unsolicitedly select a TCH/F
when it is asked for a TCH/H but a TCH/H is not available. This behavior
is presumably a leftover from before the split. Now every fallback to
another rate must be agreed with the MSC in advance, it is a spec
violation to silently fallback to TCH/F when asked for a TCH/H.
Change-Id: I057e70bc81b3dac470f6d1d2a37533ec3a7a79d0
Related: OS#3503
The function lchan_select_by_chan_mode() is prone to select an half rate
lchan when EFR is used, even though EFR is not defined for half-rate.
Lets protect against that.
Change-Id: I961d9aaba81424053ab1dc04ce7799e716af4cd8
Related: OS#3503
Vadim Yanitskiy
Philipp Maier
Harald Welte
Pau Espin
Neels Hofmeyr
Sylvain Munaut