During inter-BSC-incoming, the MSC sends the chosen encryption algorithm in the
Handover Request message. Actually parse this Chosen Encryption Algorithm IE.
Place the chosen algorithm and the CK into lchan_activate_info->encr so that
the new lchan will use the same ciphering on this new BSS as it did on the old
BSS.
Change-Id: I5b269f50bd2092516bfdf87746196983d3ac49d1
For intra-BSC handover, the previous encryption is copied from the old lchan,
which of course is not available during inter-BSC handover. Hence the lchan
activation info needs to include an explicit encryption information, and we
must not rely on the presence of the previous lchan to copy encryption
information from.
Add struct lchan_activate_info.encr to allow passing encryption info through
lchan_activate() without requiring a previous struct gsm_lchan to be present.
Instead of copying from the old lchan, always copy encryption info to
lchan_activate_info, and during activation, just before sending the Channel
Activation, copy the lchan_activate_info.encr to the new lchan.
This prepares for upcoming I5b269f50bd2092516bfdf87746196983d3ac49d1 which
obtains the encryption information from an intra-BSC-incoming Handover Request
message.
Related: OS#3842
Related: I5b269f50bd2092516bfdf87746196983d3ac49d1
Change-Id: Ib3d259a5711add65ab7298bfa3977855a17a1642
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
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
The function lchan_alloc() does not exist anymore, however there is
still a prototype definition in chan_alloc.h and a comment in
abis_rsl.c. Lets remove those.
Change-Id: I36227ea306d28587ac70acbe596c7756b23d88c7
Previously LCHAN_RTP_EV_IPACC_MDCX_ACK was not permitted for
LCHAN_RTP_ST_ESTABLISHED state in lchan FSM. However this message is
normal in case of LCLS loop closed via IPA (as opposed to MGCP). Let's
permit this message and log it to make debug output easier to read.
Change-Id: Ib642df799f3405c4d707eb57b2ebc84386d7f03f
Related: OS#2487
In theroy the function T_def_get_entry() may return a nullpointer. In
this case we would run straight into a nullpointer dereference problem.
However, the requested timer is statically defined and should always be
there. However Coverity still reports this as a problem. Lets put an
OSMO_ASSERT to make clear that there is no problem here.
Fixes: CID#190403
Change-Id: If5238132d9d5a1507b9955a0b2dc4b1bced220e8
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
After this, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint.
osmo-mgw-for-bsc.cfg:
mgcp
domain bsc
osmo-bsc.cfg:
msc 0
mgw endpoint-domain bsc
Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw)
Change-Id: I492023e9dca0233ec0a077032455d9f2e3880f78
There could multiple reason for OML or RSL link towards BTS to be
dropped: ctrl command, vty, new link etc. Introduce "reason" parameter
to corresponding functions and log it on link drop to simplify
troubleshooting issues with more complex setups.
Change-Id: I8c8d8132ba67c31e40dbecdfe2e09be08c744899
Fix crash after AMR configuration fails.
The crash is due to an assertion that finds a non-NULL conn in the lchan, when
re-using an lchan that has failed in AMR configuration earlier on. That is
because the AMR config still happens in state UNUSED.
DCHAN ERROR lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) lchan allocation failed in state UNUSED: Can not generate multirate configuration IE
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: (type=TCH_F) After failure handling, already in state UNUSED
...
...
DCHAN DEBUG lchan(0-0-2-TCH_F_TCH_H_PDCH-0)[0x6120000066a0]{UNUSED}: Received Event LCHAN_EV_ACTIVATE (lchan_fsm.c:324)
Assert failed !lchan->conn ../../../../src/osmo-bsc/src/osmo-bsc/lchan_fsm.c:491
The FSM design idea is that when returning to the UNUSED state, all lchan state
is cleared. However, when calling lchan_activate(), a failure may happen still
in state UNUSED, so that we don't transition *back* to UNUSED properly.
So, first transition out of UNUSED before failures can happen. (Other ways to
solve this would be to invoke lchan clearing even if already in UNUSED, but
semantically, transitioning first makes more sense.)
Upon LCHAN_EV_ACTIVATE, just remember the lchan_activate_info and transition to
WAIT_TS_READY, so that on lchan_fail(), we can normally transition back to
UNUSED and clear the lchan.
Move the initial lchan activation code to lchan_fsm_wait_ts_ready_onenter().
Also, there is a bit of duplication of members of the lchan->activate (lchan
state) and the lchan_activate_info (passed to lchan_activate()) structs. The
fix for this also removes the dup:
Add struct lchan_activate_info as child struct at lchan->activate.info, drop
the other lchan->activate members that would dup .info.*. Move struct
lchan_activate_info declaration to gsm_data.h.
Apply the new '.info' member struct throughout the code.
Related: OS#3737
Change-Id: Ide665b10fa3f4583059c55346db8da833959e3cc
* use osmo_lcls struct from libosmocore
* use enum values instead of magic numbers
Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858
Related: OS#3659
According to 3GPP TS 08.58 §8.5.1 BCCH INFORMATION:
"If the Full BCCH information element is not included this indicates that
transmission of the indicated SYSTEM INFORMATION message shall be stopped."
However, some ipaccess nanoBTS firmware versions are known to not support
some SI elements and also to dislike receiving BCCH Information for those SI,
even if received with empty BCCH Information meaning they should not be used.
Upon receival of this kind of message, nanoBTS sends a Failure Report
with following text:
Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****
This kind of issue only appears with some fw versions, since it's known
to work fine in other ones, so let's not disable this kind of mesage by
default on all BTs of type "nanobts".
Instead, add a VTY command that allows disabling this kind of message in
order to be able to operate those nanoBTS units.
Fixes: OS#3707
Change-Id: Idec1daabc21de4eea5c55edd1dbb0e0775720fc7
Since we actually want to match by IMSI as specified by filter in VTY.
It will allow to match based on other information later.
Change-Id: Ia73fd2f38e42396db8f6d2cc6b2c163aa8f67f3f
Limiting the logging filter only to IMSIs that we have as local
subscriber doesn't make sense for osmo-bsc since all subscribers are
initially unknown.
Create a bsc subscriber and enable logging there. This struct will then
be used and liked to the gsm_subscr_conn when receiving the Location
update.
Related: OS#3641
Change-Id: Ia20bdc15565417020205d7b2b06b04a01c03106c
Currently, we see all subscribers' FSM transitions on NOTICE level even though
the code uses LOGPFSML(LOGL_DEBUG), because LOGPFSML() uses the max loglevel of
the passed level and the FSM instance's level. Too noisy!
By default, start out all gscon FSM instances on DEBUG level, so it is possible
to silence the osmo-bsc log. Individual instances can still be lifted (I
presume using the CTRL interface?).
Change-Id: Ie021483e93ab174abac51357bcca8895756566c4
When an internal handover is done the specification demands to inform
the MSC about the event.
- Add sending of BSSMAP HANDOVER PERFORMED msg.
Change-Id: If26e5807280e0f75a423b3b04f8e3c698c82a351
Depends: libosmocore I825106858bd89afc9837811b8fed2e8accc82441
Related: OS#3645
The current idea of calling gscon_release_lchans is not enough because
the conn is still present.
Insetad pretend we got a disconnect indication from the MSC which will
call gscon_release_lchans as well as terminate the conn state machine
which will clean up conn state as well.
Related: OS#3680
Change-Id: Iccf5f6864ffe238189907c4bb3ea333948621b4c
The idea is to have a base static value which is set like before "timer
t3113 [seconds]", but now have a part of this timeout calculated
dynamically based on BTS channel configuration and channel load.
This patch only implements initial support to calculate based on channel
configuration, but doesn't include code to calculate based on channel
load. To implement the later part, we probably need to keep track of BTS
paging queues per paging group, which we don't do nowadays.
Dynamic calculation is enabled by default, and default static base value
is decreased accordingly. This way, in a typical setup were the default
10 seconds were used, now the calculated final value is 11 seconds.
That's intended because it was observed experimentally in osmo-gsm-tester with
a similar channel setup that sometimes paging response can arrive slightly
later than 10 seconds.
Related: OS#3680
Change-Id: I4fb2969b690151415038631fb6ad059aa6835c7f
When we enter WAIT_RLL_RTP_RELEASED
(lchan_fsm_wait_rll_rtp_released_onenter), we call lchan_do_release()
which in turn dispatches LCHAN_RTP_EV_RELEASE to lchan_rtp_fsm.c, which
will dispatch back an LCHAN_EV_RTP_RELEASED event, which will be handled
by lchan_fsm_wait_rll_rtp_released(), which will change state to
WAIT_BEFORE_RF_RELEASE. When going back the stack (return), we are still
in lchan_fsm_wait_rll_rtp_released_onenter() which again triggers a
change state to WAIT_BEFORE_RF_RELEASE because it checks same conditions
than first one.
20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1388 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: lchan detaches from conn SUBSCR_CONN(conn3)[0x612000002da0]
20181128203727051 DMSC osmo-bsc/lchan_fsm.c:1391 SUBSCR_CONN(conn3)[0x612000002da0]{CLEARING}: lchan lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0] detaches from conn
20181128203727051 DCHAN osmo-bsc/lchan_fsm.c:1359 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{ESTABLISHED}: state_chg to WAIT_RLL_RTP_RELEASED
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:959 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) SAPI[0] = 1
20181128203727052 DRR osmo-bsc/gsm_04_08_rr.c:254 Sending Channel Release: Chan: Number: 0 Type: 2
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:945 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Received Event LCHAN_RTP_EV_RELEASE
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Freeing instance
20181128203727052 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x6120000027a0]{ESTABLISHED}: Deallocated
20181128203727052 DCHAN osmo-bsc/lchan_rtp_fsm.c:572 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: Received Event LCHAN_EV_RTP_RELEASED
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:856 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: (type=TCH_F) Still active SAPIs: 0
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:1011 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_RLL_RTP_RELEASED}: state_chg to WAIT_BEFORE_RF_RELEASE
20181128203727052 DRSL osmo-bsc/abis_rsl.c:633 (bts=0,trx=0,ts=6,ss=0) DEACTivate SACCH CMD
20181128203727052 DCHAN osmo-bsc/lchan_fsm.c:986 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_BEFORE_RF_RELEASE}: transition to state WAIT_BEFORE_RF_RELEASE not permitted!
Change-Id: I5d95bbd8244cc8e9c1cfb6fe0f76148332386a3d
lchan sends TS_EV_LCHAN_UNUSED to its parent (ts) during release time. It
was experimentally found that it can happen that an lchan can be terminated
while waiting for a PDCH DEACT (N)ACK response.
The fsm definition actually states that this event can be received in
state TS_ST_WAIT_PDCH_DEACT, but it was not handled before and as a result the
process aborted due to the default switch case.
Change-Id: If61493e7d5449bf2c2de9fd34cdf2410625e92ac
When lchan_rtp_fsm instance is allcoated with
osmo_fsm_inst_alloc_child(..., LCHAN_EV_RTP_RELEASED) we already let fsm
code to take care of sending that event ito the parent when the fsm is
terminated (but only if freeing cause is not OSMO_FSM_TERM_PARENT).
The lchan_rtp_fsm cleanup() callback, which is called immediatelly before
sending to the parent the event defined during osmo_gsm_install_alloc_child(),
currently also sends that same event, which ends up in a duplicated
event being sent as shown in log files below.
Let's only send the event in cleanup() if we are in the
cause=OSMO_FSM_TERM_PARENT scenario, to make sure parent always receives the
event, but only once.
20181128193707326 DAS osmo-bsc/assignment_fsm.c:127 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=6,ss=0) Assignment failed
20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Terminating (cause = OSMO_FSM_TERM_ERROR)
20181128193707326 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Removing from parent SUBSCR_CONN(conn4)[0x612000002920]
20181128193707326 DCHAN osmo-bsc/lchan_fsm.c:1333 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Received Event LCHAN_RTP_EV_ROLLBACK
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST)
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Removing from parent lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]
20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:441 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: notify=NULL
20181128193707326 DRSL osmo-bsc/mgw_endpoint_fsm.c:482 mgw-endpoint(conn4)[0x6120000021a0]{WAIT_MGW_RESPONSE}: (rtpbridge/*@mgw) CI[0] to-BTS: DLCX :0: Scheduling
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:742 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED
20181128193707326 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Freeing instance
20181128193707327 DCHAN fsm.c:381 lchan_rtp(0-0-6-TCH_F_PDCH-0)[0x612000002320]{WAIT_MGW_ENDPOINT_AVAILABLE}: Deallocated
20181128193707327 DCHAN osmo-bsc/lchan_rtp_fsm.c:193 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: Received Event LCHAN_EV_RTP_RELEASED
20181128193707330 DCHAN osmo-bsc/lchan_fsm.c:1347 lchan(0-0-6-TCH_F_PDCH-0)[0x6120000039a0]{WAIT_TS_READY}: transition to state WAIT_RLL_RTP_RELEASED not permitted!
20181128193707330 DAS osmo-bsc/assignment_fsm.c:128 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Freeing instance
20181128193707330 DAS fsm.c:381 assignment(conn4_0-0-6-TCH_F_PDCHasPDCH-0)[0x6120000024a0]{WAIT_LCHAN_ACTIVE}: Deallocated
Change-Id: I3e95a21e5a5ec6c35b1ab20b7a642fd7eb81e556
Before this patch, TCH lchans waiting for dynamic TS to
switch PDCH->TCH wouldn't be counted.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: I32008859cc23cd2afddd79daae21497d0945fed0
If TS is in state changing from PDCH->TCH, the TCH lchan provoking the
switch would be skipped and not terminated before this patch.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: I9dc2a6e5b15376d049bd2ac5ddfa24340771b5c8
If ts_is_lchan_waiting_for_pchan() wasn't accounting for TCH lchans
waiting for TS to deactive PDCH in order to setup the TS as TCH.
Since now TCH lchan is catched by ts_is_lchan_waiting_for_pchan() when
TS state is TS_ST_WAIT_PDCH_DEACT, there's no need to check for that
case in caller ts_is_pchan_switching(), since it will never hit because
the callee returns true in that case now.
See osmo-bsc I9cedb77d6578597f1febab36c54b2ee427c7a4a2 for similar
extensive explanation.
Change-Id: Ib03e5a91438a5b74a04e69f81fab565842b02b66
Documentation of the function explicitly states that the out
target_pchan param returns the "PCHAN waited for". If we return false,
then no PCHAN is being waited for. The 2 callers of this function only
use this out param if function returns true, so let's simplify the code.
Change-Id: Ib8f9b7e1f584dee885d6823dc043682577572bd8
In general PDCH channels are not handled as lchans in BSC (lchan_fsm.c),
and so when a TS is in ts->pchan_is=GSM_PCHAN_PDCH, no lchan slot is
being used.
However, during Dynamic TS PDCH Deactivation being in progress (state
WAIT_PDCH_DEACT in timeslot_fsm.c), ts->pchan_is =GSM_PCHAN_PDCH, but
an lchan slot of that TS is actually already being used by a TCH lchan:
it's the one who initiated the deactivate in order to be able to use the TS.
While being in WAIT_PDCH_DEACT state and receiving a PDCH DEACT NACK,
ts_fsm_error() was called in order to kill the TS and it was expected
that it would kill any lchan using it (or willing to start using it). In
order to do that, it calls ts_lchans_dispatch() which in turns iterates
over all lchans attached to the TS using ts_for_each_lchan().
However, when the NACK arrived we still had ts->pchan_is=GSM_PCHAN_PDCH,
ts_for_each_lchan ends up calling
ts_as_pchan_for_each_lchan(GSM_PCHAN_PDCH), which in turns calls
pchan_subslots(GSM_PCHAN_PDCH) which returns 0, because we don't manage
lchans in that mode as explained in first paragraph. This means in this
case ts_for_each_lchan() is actually an empty loop while still any of
the TCH channels may be in use, and won't be advertised about the TS
entering in a broken state.
As a result, the lchan won't be released for a while, only after T23001
expires.
Related: OS#3708
Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
It will be used further in follow-up patches. It also provides a place
to document its (intricate) logic around it and its possible uses.
Change-Id: Ia1d4bdbfca6b9719f54ee609b6bfadf7f3a4bb43
Every DTAP message coming from the MSC has a header (see struct
dtap_header) that contains message type, length, and link ID.
The link ID indicates SAPI and channel type of a given message.
In dtap_rcvmsg() we allocate a new message buffer and copy the
received message into it. The old message buffer is freed by
the caller then.
The link ID value parsed from DTAP header is usually being stored
in the control buffer of a message buffer (i.e. msgb->cb). Due to
a mistake, it was stored in the old (to be freed) message, while
the new (to be forwarded) message always had link_id = 0x00!
This change resolves the problem with sending SMS during a voice
call, when MT signalling goes through FACCH, while MO signalling
goes through SACCH.
Change-Id: I7675e1ce4436fad836778261ac9d446fa8f81483
Related: OS#3716
follow-up to I9ad094d272254d7aee9b0a676201d4ed8cd727ca because it was merged
before fixeria's code review could be incorporated.
Change-Id: I474cf1a58d1f00ec5b0ae52bd095a60aad763975
If BTS is configured to have only TCH/F_PDCH and TCH/H and a call is
resolved to require TCH/F, don't return the TCH/H which have no use, but
instead let it allocate the TCH/F_PDCH.
20181128185013783 DRLL <0000> lchan_select.c:159 (bts=0) lchan_select_by_type(TCH_F)
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=3,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=4,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=5,pchan=TCH/H,state=UNUSED) is != TCH/F
20181128185013783 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=6,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/F: (bts=0,trx=0,ts=7,pchan_on_init=TCH/F_PDCH,pchan=PDCH,state=PDCH) is != TCH/F
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4,state=IN_USE) is != TCH/H
20181128185013784 DRLL <0000> lchan_select.c:71 looking for lchan TCH/H: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) is != TCH/H
20181128185013784 DRLL <0000> lchan_select.c:86 looking for lchan TCH/H: (bts=0,trx=0,ts=2,pchan=TCH/H,state=UNUSED) ss=0 is available
20181128185013784 DCHAN <0010> lchan_select.c:253 lchan(0-0-2-TCH_H-0)[0x6120000066a0]{UNUSED}: (type=TCH_H) Selected
Change-Id: I9a73beb0432fab16d5430e5b40d470694e09b189
Set flag lchan->activate.immediate_assignment_sent to true when sending, and
omit a reject after that.
lchan->activate gets completely zeroed in lchan_reset(), which sets that flag
back to false whenever an lchan becomes inactive.
Related: OS#3709
Change-Id: I9ad094d272254d7aee9b0a676201d4ed8cd727ca
Add following commands showing only TRX with appropriate RSL link
status:
* show trx connected
* show trx disconnected
This simplifies troubleshooting of complex setup with multiple BTS with
several TRX each.
Change-Id: I48866ce311a3e2c63235f60a497efe97bbd05a4a
This way only formated output is pinted to stdout when using -G and can
be used by other tools (osmo-gsm-tester) to get a json dictionary with interesting
information.
Related: OS#3624
Change-Id: I257bfc8d82b49a3641be6b6777e472ecf561a21e
Add LCLS variant where the loop is closed on BTS level instead of
MGW. The main difference is the handling of connection-related
messages (we use IPA RSL instead of MGCP), the configuration and
correlation logic remains the same.
Change-Id: I7e8379f31037f2c48da69a01919701919a3066a2
Related: OS#3659
In preparation for upcoming LCLS changes we have to split IPA RSL MDCX
generation into separate function with the ability to set destination
explicitly instead of just using the value from lchan which will be used
in follow-up patches.
Change-Id: Iffe2f4f10e841fc36965cce02b4e5f017a5ae6c8
Related: OS#3659
Same type of message parsing is already implemented in code, no need to
keep them.
Related: OS#3624
Change-Id: I715bd9582f9289b5674aaa8d8de1164ebef2fd11
This signal can be used for tools willing to request and parse Attribute Response
and do something with the information. ipaccess-config tool will use
this signal in later patch Change-Id Ida416a969a3309868d6f4e50f34b34f224c32dd6.
Related: OS#3624
Change-Id: I9a121bbfe1b96904d4e16845abc90bb6ef20d2c9
Before libosmocore Change-Id I780d452dcebce385469e32ef2fd844df6033393a,
it avoids stating arfcn 886-954 are compatible when operating under
DC1800. After that Change-Id, avoids aborting the program due to
unexpected behaviour.
Related: OS#3063
Depends: libosmocore Change-Id I780d452dcebce385469e32ef2fd844df6033393a
Change-Id: Ibf5d5ab50b6fc6597244eeedcd27d2ce245278a3
Some nanoBTS firmwares (if not all) are known to not work properly with
SI2ter. If BSC enables SI2ter through RSL, SI3 bit announcing SI2ter
available will be forwarded by nanoBTS to MS, but will still only send
SI2 message instead of expected SI2ter during TC=5 (see GSM 05.02 sec 6.3.4 "Mapping
of BCCH data"). As a result, some MS won't allow registering to the
network.
To avoid this kind of scenario, enable force-combined-si by default on
nanoBTS while still allowing to overwrite the feature through VTY. Other
BTS models are kept with force-combined-si disabled by default as
usually, since they seems to be working fine when SI2ter is enabled.
Related: OS#3063
Change-Id: Ide6e8967de0eedc9e2bcaf4414aaa537b009d72d
Neels Hofmeyr
Philipp Maier
Harald Welte
Pau Espin
Neels Hofmeyr
Sylvain Munaut
Daniel Willmann
Martin Hauke