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
3GPP TS 04.08 V7.21.0, section "9.1.34 System information type 2ter"
states:
"""
This message has a L2 pseudo length of 18. This message may be sent
by the network with either a L2 pseudo length of 18 or some other
value. A mobile station that does not ignore this message shall not
discard the message due to a received L2 pseudo length different
from 18.
"""
Change-Id: I45cb217ebdf89b82b0f37f38eef7a1e3a651f541
3GPP TS 04.08 V7.21.0, section "9.1.33 System information type 2bis"
states: "This message has a L2 pseudo length of 21.".
Change-Id: I623c64c446c0973e939e9f1cba0a4d4d2f4f7237
In commit 65c62e5033 a call
to unlink() was erroneously moved up. Since then unlink()
has been called with an uninitialized path variable. The
problem went unnoticed because the return value of unlink()
was never checked.
Ensure that unlink() is called with an initialized argument and
verify success of the unlink() operation if the socket exists.
Related: CID#188836
Change-Id: Ia0c873da305cbb47aef0562f61ec21057363f294
Fixes: 65c62e5033
Before closing or breaking the loop in LCLS we do preliminary
checks. To facilitate adding new LCLS modes it's restructured as
follows:
* move check into dedicated static function
* explicitly check for MGW mode in endpoint check
* check for mode mismatch
Change-Id: I32ba232ad802625d97a0ad9d0511edc6ac7f251c
Related: OS#3659
Coverity points out that abis_nm_rcvmsg_sw() contains a switch
statement with suspicious looking missing break statements.
It is unclear to me if the code intends to process some
types of messages in more than one state, or of all messages
which affect a particular state already appear in the state's
corresponding switch block.
Can someone else tell what is supposed to happen here?
If this code is falling through intentionally, I will suggest
a patch adding /* fallthrough */ comments for clarity.
Change-Id: I1ea4221fadf30074156e9d17d94a5cb065242584
Related: CID#57703
Related: CID#57704
When a gscon wants to send a BSSMAP Clear Request, it makes no sense to do it
conditionally depending on the current conn state. Just send it: don't call
gscon_sigtran_send(), directly go for osmo_bsc_sigtran_send().
In particular, if an incoming inter-BSC handover ends in failure, the gscon
state is still ST_INIT, but if the MSC fails to give us a Clear Command, we may
want to ask with a BSSMAP Clear Request.
Change-Id: I39fae24260a4bb7a6af704ebe760f93fff566536
Otherwise any use of functions in gsm_timers_vty.c will fail because
g_vty_T_defs is never set (so it is NULL).
Change-Id: Ieeb27fdb06c965fa6b70aeb0f3b3f5169b1f2012
Check the return value of gsm48_multirate_config() in function
lchan_set_single_amr_mode(). This prevents an invalid AMR mode
from being configured for a logical channel.
Because the VTY parsier limits the AMR mode range to 0-7 this
is just a theoretical issue. However, this fact is beyond the
understanding of a static code analyzer, and the absence of
error handling was indeed setting a bad example.
Change-Id: I61153a44e8b7a38332bf38718397be9b339d5f25
Related: CID#188940
complete_layer3 returns true if everything succeeded, false otherwise.
However, its caller bsc_compl_l3 returns unix style (0 sucess,
negative error).
This commit has no real effect since only caller of bsc_compl_l3 never
checks return code, but will check it in the future.
Change-Id: I722696c3f6402288b51d6fcf51f478b3b0c9f0f0
The 'show lchan' command already shows details about timeslot
state, indicating whether a channel is currently being switched
to a different channel type.
However, this information was not shown by 'show timeslot' yet.
There are TTCN3 BSC tests which use 'show timeslot' and are
seeing sporadic failures when 'show timeout' is invoked during a
channel type transition. With this change, VTY sessions recorded
in pcap files for these tests will contain information about the
current channel type transition state.
Change-Id: Ib854945756fb54c0e1c7d4212ea7b8746eec0db5
Related: OS#3690
conn->fi should actually never be NULL, they are allocated and discarded
simultaneously. So check its null from the start and remove some conditions
below, to remove the coverity warning.
Related: CID 189671
Change-Id: I62354aa998832131c86535f39a29294000114adc
Put all lchan release related flags and settings in a sub-struct named
'release' to better indicate what those fields are for. There is no functional
change.
Change-Id: Icfddc6010e5d7c309f1a7ed3526b5b635ffeaf11
If an lchan is being released and had a SACCH active, there is no reason to
omit the Deact SACCH message ever. All of the callers that passed
do_deact_sacch = false did so for no good reason.
Drop the do_deact_sacch flag everywhere and, when the lchan type matches and
SAPI[0] is still active, simply always send a Deact SACCH message.
The do_deact_sacch flag was carried over from legacy code, by me, mainly
because I never really understood why it was there. I do hope I'm correct now,
asserting that having this flag makes no sense.
Change-Id: Id3301df059582da2377ef82feae554e94fa42035
In the case where there is a release in error and we skip immediately to the RF
Release state, send all of Deact SACCH, RR Release messages and also signal the
lchan_rtp_fsm as appropriate.
Move that code to static lchan_do_release() and call from both
lchan_fsm_wait_rll_rtp_released_onenter() in the normal case, as well as
lchan_release() when skipping that.
When releasing in error, but we're already in LCHAN_ST_WAIT_RLL_RTP_RELEASED,
those messages have already been sent and we can skip them.
Change-Id: I648a9826ce56b611359f81462ca03e4ab4c736aa
After commit [1], the code makes sure to disassociate lchan and conn before
invoking the lchan release. However, we only send RR Release if a conn is
present, which clearly is nonsense after [1].
[1] commit 8b818a01b0
"subscr conn: properly forget lchan before release"
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Manage sending of RR Release via a flag, set during invoking lchan release.
Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In
lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care
whether a conn is still associated (because it won't ever be since [1]).
That way we can intelligently decide what release process makes sense (whether
the lchan terminates the subscriber connection or whether the connection goes
on at another lchan), and still disassociate lchan and conn early.
BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the
f_expect_chan_rel() don't care whether an RR Release happens or not. This is
being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845.
So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear.
Related: OS#3413
Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
When reading the log of OS#3686, I wished for explicit logging of when exactly
an lchan disassociates from a conn. Here is the debug logging I would have
liked to see.
I'm not sure whether we really need to merge this patch...
Change-Id: I97558b899e7f2578ba98287e7352dc072d02ce44
lchan_fsm_wait_rf_release_ack_onenter() calls gscon_forget_lchan(). At the
point where the conn has no lchan, the lchan must not have a conn. Make sure
that conn is NULL after gscon_forget_lchan().
I hope this fixes OS#3686, it is the only situation I could find where the
disassociation is potentially one-sided.
I get the feeling that this should be hardcoded in gscon_forget_lchan(), but I
dimly remember other situations that are less trivial, where it doesn't
necessarily make sense to forget reciprocically. So only fixing this one now.
Related: OS#3686
Change-Id: If0c6e495e419b9dbb44443c3fc3f54dd4b714aa5
Right below this call, we invoke lchan_reset(), and the first thing it does is
gscon_forget_lchan(). Drop this redundant invocation.
Change-Id: I503efceb6d34c8df0cdfef3dfc83fa1e61271c47
See following specs for related information:
* 3GPP TS 52.021 §8.11.3 Get Attribute Response
* 3GPP TS 52.021 §9.4.64 Get Attribute Response Info
Related: OS#3624
Change-Id: Ie61d70bc28427d5d879638516a36f590ce98bdc7
Spec compliant format is defined in:
* 3GPP TS 52.021 §8.11.3 "Get Attribute Response"
* 3GPP TS 52.021 §9.4.64 "Get Attribute Response Info".
On nanoBTS, however, reported attribute list is provided directly inside/after
the foh header instead of being enveloped inside the Get Attributes Response Info.
Furthermore, The Get Attributes Response Info can still appear and be at any position
in the reported attribute list, and it only contains the unreported
attribute ID list inside.
Change-Id: I81a613d53bddf432a79fa5cb0bf9d847b4bdee37
nanoBTS actually supports regular formatting. There are a few differences
with spec though:
* The attributes are listed directly in the message instead of being inside
the Get Attributes Response Info after the unsupported attribute ID list.
* The Get Attributes Response Info can be at any position in the
attribute list, and it only contains the unsupported attribute ID list.
As a result, parsing is currently split into 3 main parts or functions:
* Parsing regular (per spec) Get Attributes Response Info attr and get a
pointer to the list of attributes.
* A function that parses the list of attributes, called directly in case
of nanoBTS, and called by the former parser of Get Attributes Response
Info for regular (per spec) OML endpoints.
* A function to parse the unsupported attribute ID list, also used in the
first function to get a pointer to the list of attributes.
Related: OS#3624
Change-Id: I52e9f177c14fec1ec3f5c4ddb244594409008357
* Allow sending Get Attributes message in abis_nm_get_attr.
* Don't try to decode Get Attribute Response Info for nanoBTS, since it
uses a different formatting than the one defined in specs.
Related: OS#3624
Change-Id: I53d01e73791cf5450aa34b1ac8f051730e3a70f9
nanoBTS uses same format for the attribute list from Attribute Response
Info, but without using the later as an evelope. By splitting we can
later reuse the code handling the Attribute list.
While at it, take the chance to remove functions parse_attr_resp_info_*
which expect TLVs following an specific order, which is not mandatory.
Related: OS#3624
Change-Id: Iec7a6e4d27639d0e5adc0d9a01cd3c3e7a46f558
In future commits, nanoBTS support will be added, which implements its
own format not exactly equal to specs Attribute Response Info.
Related: OS#3624
Change-Id: I346dacc58faac70e6d224ca49484f9211cb8a046
This function will be merged into another using a "len" variable. This
change makes diffs easier to follow in future patches.
Change-Id: I1be03e31901ccf284e31237a04bb7448d1f22c07
The function cgi_for_msc() provides an easy way to get a cell global id
for an msc/bts combination. This function is currently statically
defined in gsm_08_08.c. Lets move it to gsm_data.c and make it publicly
available.
Change-Id: I301fac6e83a429ae59b5c586aa283ad7ba54053d
Related: OS#3645
Coverity points out that conditional checks in set_net_timezone()
depend on each other: The value of 'override' depends on 'hourstr'
being non-NULL. Nest these conditional checks such that this
dependency becomes obvious.
No functional change.
Change-Id: I10dece1e1d9e039fb9f03be89b3a202cb077b026
Related: CID#148208
Move code using MDCX via MGCP into separate function to make adding
alternative MDCX variants easier.
Change-Id: I5fafa3b12a39c83bdf64e16e192dd2454d069cf4
Related: OS#3659
These indicators are a legacy of early handover_decision_2.c work, where there
were no separate handover1 and handover2 config commands. No need to restate
the abundantly obvious anymore.
Change-Id: Id4d29542f7dd5bd125d6f10c7783569f13092612
Print IDs and IPs of recently rejected BTS devices. Example output:
OsmoBSC> show rejected-bts
Date Site ID BTS ID IP
------------------- ------- ------ ---------------
2018-10-25 09:36:28 1234 0 192.168.1.37
Related: OS#2841
Change-Id: Iba3bfe8fc9432b7ae8f819df8bd71b35b3ec507e
The chan mode is figured out per-BTS, but may remain uninitialized. Rather log
info about the channel request, like further above.
Change-Id: I07b89b6101879fb7c070c87be9bd38cc05ffa0b1
Separate the cause value passed to further functions from the log string.
The code tried to be nice by composing the RSL cause string and returning the
RSL cause at the same time, which falls on its face when the string composition
happens only within conditional logging.
Change-Id: Ibadd06102f162bca9182c39b77b0651568d3e6f8
bssmap_handle_cipher_mode() had code paths doing "goto reject" without
setting a meaningful cause value.
Related: OS#3186
Change-Id: Ia608fa34a6a2d3035a66d05fbc38553ac5186804
During the generation of the multirate configuration IE in the channel
activation message that is sent over RSL, all AMR rates except the
highest one are trimmed. This was to ensure that the multirate
configuration IE only contains one codec rate per active set. Lets fix
that and generate a proper IE with threshold and hysteresis values.
- extend lchan_mr_config so that it can generate a full multirate
configuration IE
Change-Id: I7f9f8e8d9e2724cbe3ce2f3599bc0e5185fd8453
Related: OS#3529
The vty already has a well working interface to configure the AMR
mode, threshold and hysteresis parameters. However there are no checks
yet to prevent against misconfiguration.
- Use gsm48_multirate_config() to perform a global check of the overall
configuration
- Add check AMR modes during input (order, duplicates)
Change-Id: I8b9f69b89a39bbf4800d9790f7abe43ce66aeb71
Related: OS#3529
The function gsm48_multirate_config() generates the multirate
configuration IE, that is sent via RSL to configure the active set of
AMR codecs inside the BTS. The function already works, but it does not
check the input data for consistancy. Lets add some consistancy check to
make sure that inconsistant parameters are rejected. Also allow the
output pointer to be NULL, so that the function can be used to perform
a dry run to be able to verify parameters.
- Check for invalid / inconsistant configuration parameters
- Perform a dry-run when lv pointer is set to NULL
Change-Id: I06beb7dd7236c81c3a91af4d09c31891f4b910a4
Related: OS#3529
The function check_codec_pref() currently only does a basic check over
the general codec configuration of bts and msc. However, it does not yet
check if the amr codec rate settings for the BTSs contradict the
allowed/forbidden amr codec rates of the MSC. When the two settings do
contradict AMR would not work, even when everything else is correctly
configured. We need to check this on startup to spot configuration
problems quickly.
- Add function to calculate intersections of struct
gsm48_multi_rate_conf variables.
- Calculate the intersection between the multi rate config of
each BTS with the one of the MSC
Change-Id: I3537d1c89e2520d35cc0e150ba8e6d3693e06710
Related: OS#3529
The function gsm_bts_alloc() does set default values for the amr rates
for a newly allocated bts, but it does not populate the ms_mode and
bts_mode flags which contain hysteresis and threshold. Those values are
currently set to 0 by default, which does not make much sense. Lets
popluate some appropriate default values.
- Make sure that .mode .hysteresis and .threshold are populated for
MS and BTS in full and halfrate
Change-Id: If14843feeeea6584e5991d5c0abb765611dfaa57
Related: OS#3529
Implement basic support for inter-BSC HO from handover_decision_2: do inter-BSC
handover only when rxlev / rxqual / ta drop below the minimum requirements.
I considered adding a vty config flag to disable/enable remote-BSS handover,
but to avoid inter-BSC HO the user can simply refrain from configuring
neighbors for a particular cell.
In collect_assignment_candidate(), it is important to clear out any new
candidate entry. Hence adopt the same pattern as below: first compose a new
(cleared) candidate, then write the entry into the list.
Related: OS#3638
Change-Id: Id78ac1b2016998a2931a23d62ec7a3f37bb764c6
a) Prepare for triggering handover for any candidate, remote or local.
b) drop redundant arguments.
Change-Id: I5ba8b556703010c8e232b516285a837c999f87ef
When COMPLETE LAYER 3 INFORMATION is generated, it may include a speech
codec list that contains 0 elements (which is legal). The specification
requires the speech to be include if the network supports an IP based
user plane interface. It could be argumented that if no codecs are
available, the ip based user plane interface is not supported and
therefore the spec does not require the speech codec list IE to be
included for those cases. Lets check if the speech codec list has 0
elements and if its zero length, lets omit it completely.
- check for zero length speech codec list.
- omit speech codec list if it has zero elements
Change-Id: I07339322a71376e986a2d75b7bc1f552eafd02b5
Related: OS#3657
The COMPLETE LAYER 3 INFORMATION message contains a an Codec List (BSS
Supported). When generating the compl l3 info msg, we check if the
speech codec list that we have generated before has at least one
element. If it has 0 elements we abort immediately. However, speech
codec lists with 0 elements are permitted by the spec, so we should
remove the checks as there are corner cases where voice support is
intentionally unavailable.
- Remove check for zero length speech codec lists.
Change-Id: Id7332e5273ff0efb85043dd1e1bb804cfe2db944
Depends: libosmocore I1eb1f4466b98bdd26d765b0e4cc690b5e89e9dd6
Related: OS#3657
This quickly allows knowing which IP a BTS is using in order to SSH
into it. Example output:
OsmoBSC> show trx
...
Baseband Transceiver NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
ip.access stream ID: 0x00 (r=192.168.1.178:34090<->l=192.168.1.37:3003)
...
OsmoBSC> show bts
...
Paging: 0 pending requests, 50 free slots
OML Link: (r=192.168.1.178:57692<->l=192.168.1.37:3002)
OML Link state: connected 0 days 0 hours 0 min. 17 sec.
...
Related: OS#3145
Change-Id: I37f020fcdb68cafcdbdb621808483d1dd996354f
I believe I have initially misinterpreted the idea behind sending a Cell
Identifier List in BSSMAP Handover Required messages. Instead of associating N
Cell Identifiers with one ARFCN+BSIC, the idea is to add up N separate
ARFCN+BSIC's Cell Identifiers into a list. To keep the door open for future
code simplification, make sure to allow only one Cell Identifier per remote
ARFCN+BSIC on the VTY UI.
Related: OS#3656
Change-Id: Ifb9212fede2333ad68db94188b5cda4fcabe02f8
Inter-BSC outgoing lacked the required BSSMAP HO Failure dispatch.
Not all cases should send BSSMAP HO Failure, name the relevant spec paragraphs
in comments and adjust handling.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I0980cacb9713e41a1eef3a0a7f6cc892e8a20da5
Usually, conn->lchan is set to NULL before/upon releasing it. However, if the
lchan is still associated with a conn upon/after release, make sure the conn
realizes it has no lchan and sends a BSSMAP Clear Request to the MSC.
lchan_reset() is the last step before an lchan is fully unused. In there, make
sure to notify any conn that might still be associated, with
gscon_forget_lchan().
lchan_cleanup() does the same, but in fact this is only called when an lchan is
*deallocated*, but instead it usually merely goes to the UNUSED state.
It may make sense to call gscon_forget_lchan() sooner, e.g. when entering a
releasing state. This here nevertheless is a final safeguard.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I88337a18246c44ba48da64bb611a3cbb647a750e
Clear all lchan->conn pointers when the subscr conn code is choosing to release
an lchan, with gscon_release_lchan().
Rationale: when an lchan releases in error, it should trigger the conn to be
notified and cause a BSSMAP Clear. However, if the conn is actively requesting
for an lchan release, it is already taking care of the situation.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db
Send a BSSMAP Clear Request only if absolutely no lchan remains associated to
the conn, anywhere (Assignment, Handover as well as primary lchan).
Conceivable would be a situation where e.g. we're in handover and a new lchan
is ready, when just at a time where it doesn't matter anymore the old lchan
fails. We could just carry on with the new one then.
Change-Id: Ibd8e38ccf7759b8834efdedf742c46c227b26e91
Send a BSSMAP Clear Request only if we are not already in ST_CLEARING, i.e.
haven't received a BSSMAP Clear Command yet.
Related: osmo-ttcn3-hacks If772dbbc5f9790d3f911465e1303dd0a99811154
Change-Id: Idc749068580da45e821e0af04cfa14cc7ce5c432
At the moment codec_pref only checks the codec configuration, but it
does not check if there is actually a matching physical channel
available. This should be checked too we must make sure that the codec
we select fits the physical channels available on the BTS.
Change-Id: I2d29dfed450e5ef93c26ed5ec9fdc0730eb3d7dd
Related: OS#3503
The function match_codec_pref determines whether a permitted speech
value belongs to a half-rate or full-rate codec. Lets seperate this into
a separate function.
Change-Id: Iec1db4621ba5a09bc0e3fc40b66f3a3bc5f54add
Related: OS#3503
In networks with a couple of different BTSs it may be likely that one
accidently sets up a codec configuration (codec-support)) that will be
mutually exclusive towards the codec configuration for the MSC
(codec-list). We need a check that validates the configuration before
start to catch such configuration flaws quickly.
- Add a check that checks each MSC codec-list against each BTS
codec-support setting.
Change-Id: Ice827896bab1a2330741e0fccc731a04f1a07d38
Related: OS#3625
When the user sets no codec-list in the msc node, the configuration will
end up with an empty codec list. This is a useless configuration. There
should be a sane default setting.
- Set all possible codecs as default for codec-list
Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed
Related: OS#3625
The COMPLETE LAYER 3 INFORMATION message should contain a Codec List
(BSS Supported) IE. The contents of this list depend on the BTS
capabilities and of the MSC configuration (allowed codecs). There may
be cases where (due to miss-configuration) the list is empty. In those
cases the BSC hits an assertion because the encoding of the overall
message fails when the codec list is empty. A check is needed.
- Check codec list before message generation, abort if the coded
list is empty.
Change-Id: I119607047a132b75b3077bbe56c97936d8ae6c96
Related: OS#3625
Opposed to all other codecs that are common in GSM, AMR requires a codec
configuration that is expressed by a bitmask (S0 to S15) in the speech
codec list in the ASSIGNMENT REQUEST. Also the BSC acknowledges those
configuration in the ASSIGNMENT COMPLETE message.
At the moment osmo-bsc ignores all incoming configuration bits. The bits
in the ASSIGNMENT COMPLETE speech codec (choosen) field are hardcoded.
- Store the configuration bits while parsing the ASSIGNMENT COMPLETE
- Create an intersection with the configuration that is actually
supported by the BSS
- Return the resulting (chosen) configuration bits with the assignment
complete message.
- Use the (highest of the) agreed codec rates in RSL channel activation.
Change-Id: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
main() was missing a call to rate_ctr_init(). Without it, the counters
increased properly, but the times per second / minute / hour etc. values
would always stay at zero.
Change-Id: I4466a7aec51673c79b67614c9dde987633e379e0
Related: OS#3579
Seen while operating a setup with 2 TRX (2 nanobts):
DNM <0004> abis_nm.c:703 OC=CHANNEL(03) INST=(00,01,04): bts=0 trx=0 Opstart ACK
DTS <0011> bts_ipaccess_nanobts.c:308 timeslot(0-0-4-TCH_F)[0x612000008aa0]{UNUSED}: Received Event TS_EV_OML_READY
DTS <0011> bts_ipaccess_nanobts.c:308 timeslot(0-0-4-TCH_F)[0x612000008aa0]{UNUSED}: Event TS_EV_OML_READY not permitte
As it can be seen, OML log header state correctly it comes from TRX1,
but later content in line expresses TRX0, and that failure is forwarded
up the stack and channels for TRX different than TRX0 are never
initialized.
Related: OS#3560
Fixes: f0ff9a6711
Change-Id: I27e992e419422051247777b048175b724c05323e
After commit https://gerrit.osmocom.org/#/c/libosmo-abis/+/11207/
(Iaa33b793f89f2d16c9d949503c5ecc195bbcd2a4),
input_signal_data->link_type exposes proper enum type, and compiler can
warn about missing cases:
osmo-bsc/bts_ericsson_rbs2000.c: In function ‘inp_sig_cb’:
osmo-bsc/bts_ericsson_rbs2000.c:124:3: error: enumeration value ‘E1INP_SIGN_NONE’ not handled in switch [-Werror=switch]
switch (isd->link_type) {
^~~~~~
Change-Id: Ia407a5072896377b68e914e2a05b5e01292ee8ee
Add missing item in the landscape of VTY commands: allow identifying a local
cell by CGI (besides BTS nr, LAC or LAC+CI, which already exist).
Change-Id: I2d03de6b695904c4a86025bf250358d04f6e47de
When writing the neighbor configuration documentation, I noticed that 'neighbor
add' and 'neighbor del' make sense from an interactive VTY POV, but when
looking at a static config file, it makes more sense to simply name the
neighbors without the 'add' keyword, and to use the 'no' prefix instead of the
'del' keyword. It still makes sense to tweak cosmetics like this before
inter-bsc handover is used anywhere.
First, remove 'add' from all 'neighbor add ...' commands.
Instead, prepend "Add" to the doc string for the cell identification argument
in commands that add a neighbor:
-OsmoBSC(config-net-bts)# neighbor add ?
- bts Neighbor cell by local BTS number
+OsmoBSC(config-net-bts)# neighbor ?
+ bts Add Neighbor cell by local BTS number
(A subsequent patch will rename 'neighbor del' to 'no neighbor'.)
Change-Id: I143f21f6069d1a86096cc8240cf69eb7ea9c8ac8
After previous patch I8dd561d744d8081b5ac5ffa7635f17ac19bcda45, all callers
pass conn->lchan to send_assignment_complete(), so there is no need to pass it
separately from conn.
Change-Id: I3c038d91a53c81d9fcf4ec62f853b59bb1ecd244
In assignment_success(), don't trigger lcls_apply_config() before the
conn->lchan points at the actual new voice lchan. The entire LCLS code relies
on conn->lchan.
The assignment FSM wants to point conn->lchan to the new lchan only after it is
sure that sending the Assignment Complete to the MSC was successful. However, a
failure is a) very unlikely and b) if sending to the MSC fails we might as well
tear the whole conn down anyway. Now, if sending to the MSC fails, release the
lchan and the conn should clean itself up.
Related: OS#1602
Change-Id: I8dd561d744d8081b5ac5ffa7635f17ac19bcda45
When a codec mismatch (lchan type or tch_mode does not match) occurs, we
do not know which of the two lchan had which type or tch_mode. Lets
print that information as well to make debugging easier.
Change-Id: I3fd22fef50d8944ca8c003c6114fdda37417b2ea
Related: OS#1602
Neels Hofmeyr
Pau Espin
Daniel Willmann
Philipp Maier
Martin Hauke
Oliver Smith
Harald Welte