AgeCommit message (Collapse)AuthorFilesLines
2019-01-24fix lchan modifications: switch off re-using lchan during assignmentneels/call_during_callNeels Hofmeyr1-0/+30
Always set up a fresh lchan for both SDCCH->TCH/* as well as call-during-call, which allows these scenarios to properly set up an RTP stream. Disable lchan re-use on repeated Assignment Requests: so far the lchan FSM does RTP handling properly *only* when it 'requires_voice_stream' from the start. The nicer way to support call-during-call, as well as Channel Mode Modify, would be to rather re-use the old lchan and implement FSM states to re-route the audio. This is currently not implemented (properly) nor tested. To really get call-during-call working, osmo-msc also needs a fix, see the change-id in 'Related' below. Related: OS#3735, osmo-msc I0ba216b737909e92080a722db26e3577726c63cb Change-Id: I0c00ec2c120e5008281755adcd4944a3ce4d8355
2019-01-22assignment_fsm: fix channel allocator preferencesPhilipp Maier7-108/+348
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 trys 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
2019-01-22bsc_vty: add features to disable specific lchans via vtyPhilipp Maier4-5/+43
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 to mark certain lchans as disabled and check that condition while doing the channel allocation Change-Id: I397e68e26d6a1727890353fa34f4897b54795866 Related: OS#3503
2019-01-22bsc_vty: add vty command to display all lchansPhilipp Maier1-14/+29
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
2019-01-22abis_rsl: Fix TCH-as-SDCCH allocation on Channel RequestNeels Hofmeyr1-14/+4
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
2019-01-22lchan_select: Do not unsolicitedly select a TCH/FPhilipp Maier1-17/+0
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
2019-01-21lchan_select: dont allow half rate EFR to be selectedPhilipp Maier1-1/+5
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
2019-01-21LCLS: constify helper parametersMax2-5/+5
Related: OS#2487 Change-Id: I341f4ea172432b94e8e96919926a5fb6870c2a30
2019-01-20Bump version: → Welte1-0/+322
Change-Id: Iaedf16a3a03868c5ca6b1afe9fbac7b042905d51
2019-01-17chan_alloc: remove references to lchan_alloc()Philipp Maier2-5/+0
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
2019-01-16Log MDCX ACK for established lchanMax1-1/+8
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
2019-01-14Print BTS number on GPRS options errorMax1-12/+12
Change-Id: Ia413bd1b375d874cd79a2bf06eb82477417ead1a
2019-01-14paging: fix nullpointer derefPhilipp Maier1-0/+5
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
2019-01-05use mgcp-client configured endpoint domain nameNeels Hofmeyr1-2/+3
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
2019-01-04LCLS: use enum values instead of magic numbersMax1-5/+5
Change-Id: I3f49f74edb5400df1b13bb75da3d524f234c8d03 Related: OS#3659
2019-01-03IPA: log OML/RSL link drop reasonMax5-17/+17
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
2018-12-21comments: describe some lchan detailsNeels Hofmeyr2-1/+4
(requested by pespin) Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
2018-12-21make sure early lchan act failure resets the lchanNeels Hofmeyr8-107/+105
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
2018-12-19LCLS: log config/control updateMax1-2/+6
Change-Id: Iac493014144ca0e5e1a83081e6e01ea7910deac2
2018-12-18LCLS: update parameter representationMax3-21/+15
* use osmo_lcls struct from libosmocore * use enum values instead of magic numbers Change-Id: I5e962d4fbb24bf1fb2398dc13e142a4a3304d858 Related: OS#3659
2018-12-14Add VTY option to avoid sending empty Full BCCH Info for disabled SIPau Espin Pedrol4-6/+50
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
2018-12-12bsc: bssap: Set subscr log context during pagingPau Espin Pedrol1-2/+8
Change-Id: I3998a35ff6ea29440882514bbb30cafed66f03fa
2018-12-11bsc: dtap: Set subscr log contextPau Espin Pedrol2-3/+11
Change-Id: I362a7d10f5ca9a95b594f7caafd7ed5b10fd059a
2018-12-11bsc: rsl: Set subscr log context during meas reportPau Espin Pedrol1-3/+9
Change-Id: Idc6af592e870d15491797ae6fcaffaac2b411766
2018-12-11bsc: Set subscr log context during complete_layer3Pau Espin Pedrol1-10/+16
Change-Id: I162a474f711248a3f64a0438967fa6f8a9a3e686
2018-12-11bsc_main: filter_fn: Compare imsi values instead of subscr pointersPau Espin Pedrol1-2/+5
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
2018-12-11paging: Properly enclose logging imsi filter scopePau Espin Pedrol1-0/+3
Otherwise all logging is kept enabled after passing through those code paths. Change-Id: I06a977d97e6ffea02ec7402d48410c0e7cc6c155
2018-12-11VTY: Allow logging filter imsi statements for IMSIs we haven't seen yetDaniel Willmann1-2/+8
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
2018-12-11paging: fix whitespacePau Espin Pedrol1-1/+1
Change-Id: I81c4a9f0dbd708df27a485ef764c9524a36d548a
2018-12-09set gscon FSM instances' log level to DEBUGNeels Hofmeyr1-1/+1
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
2018-12-07handover_fsm: send HANDOVER PERFORMED msg on internal hoPhilipp Maier2-0/+69
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
2018-12-06gsm_04_08: Free GSM subscr conn if paging response can't be matchedDaniel Willmann1-1/+1
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
2018-12-06contrib: fix makedistcheck with disabled systemdOliver Smith1-1/+2
EXTRA_DIST files need to be distributed, no matter if the systemd option is configured or not. Change-Id: Ide5de9383a2a3b957d182dca1187f73dbf1ce982
2018-12-05paging: Add VTY options to calculate T3113 timeout dynamicallyPau Espin Pedrol7-4/+86
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
2018-12-05bsc: lchan_fsm: Fix invalid duplicated transitionPau Espin Pedrol1-1/+4
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
2018-12-05bsc: timeslot_fsm: Handle and ignore tear down of lchan during PDCH DEACTPau Espin Pedrol1-0/+4
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
2018-12-05bsc: lchan_fsm: Add missing transition WAIT_TS_READY->WAIT_RLL_RTP_RELEASEDPau Espin Pedrol1-0/+1
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! Change-Id: I43aab5ed8ac369869b191b3b7c938ce4985ab849
2018-12-05bsc: lchan_rtp_fsm: Avoid duplicate LCHAN_EV_RTP_RELEASED eventPau Espin Pedrol1-1/+5
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
2018-12-05bsc: timeslot_fsm: Fix count in ts_lchans_waitingPau Espin Pedrol1-1/+1
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
2018-12-05bsc: timeslot_fsm: Fix possible skip of some lchans in ts_terminate_lchan_fsmsPau Espin Pedrol1-1/+1
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
2018-12-05bsc: ts_is_pchan_switching: Return correct IPA dyn TS target_pchanPau Espin Pedrol1-2/+15
Change-Id: Ie438b4efaa9832c44009a92c3df698875f1fa9ae
2018-12-05bsc: timeslot_fsm: Fix ts_is_lchan_waiting_for_pchanPau Espin Pedrol1-3/+5
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
2018-12-05bsc: timelost_fsm: Remove unneeded set of out variable on failurePau Espin Pedrol1-3/+0
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
2018-12-05bsc: Fix lchan iteration for dyn TS during PDCH DeactPau Espin Pedrol1-1/+1
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
2018-12-05bsc: Add define for ts_as_pchan_for_each_lchan with ts->pchan_on_initPau Espin Pedrol2-1/+14
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
2018-12-05contrib/jenkins.sh: build and publish manualsOliver Smith1-2/+19
Add new environment variables WITH_MANUALS and PUBLISH to control if the manuals should be built and uploaded. Describe all environment vars on top of the file. When WITH_MANUALS is set, install osmo-gsm-manuals like any other dependency and add --enable-manuals to the configure flags (for "make" and "make distcheck"). Add the bin subdir of the installed files to PATH, so osmo-gsm-manuals-check-depends can be used by ./configure. Related: OS#3385 Change-Id: Ief6ce94013612a968183e82abef421f116ed37c3
2018-12-04Fix DISTCHECK_CONFIGURE_FLAGS overrideOliver Smith1-1/+1
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the automake manual, as otherwise the flag can't be changed by the user anymore. Related: OS#3718 Change-Id: I38bd2bffa24c5b970aa4a42dcfc8d8766bb96046
2018-12-01osmo_bsc_bssap.c: fix incorrect link_id assignmentVadim Yanitskiy1-1/+1
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
2018-11-30follow-up: logging tweak for Immediate AssignmentNeels Hofmeyr1-6/+4
follow-up to I9ad094d272254d7aee9b0a676201d4ed8cd727ca because it was merged before fixeria's code review could be incorporated. Change-Id: I474cf1a58d1f00ec5b0ae52bd095a60aad763975
2018-11-29bsc: ts_for_each_lchan: Improve documentationPau Espin Pedrol1-2/+4
Change-Id: Id7c050087c14aae3f01c6d41d21cf861ff53621c