AgeCommit message (Collapse)AuthorFilesLines
2019-03-11osmo_bsc_msc: Use meaningful amr rate configuration on BTS levelpmaier/defaultPhilipp Maier1-18/+17
The current configuration for permittet AMR rates on BTS level contradicts the default settings of the AMR rates for MSC level. Lets make sure that the BTS default matches the default config on MSC level. Change-Id: I916953e3fdb54168671dd13b359e78662fa31059 Related: SYS#4470
2019-03-11osmo_bsc_msc: Use meaningful amr rate configuration on MSC levelPhilipp Maier1-1/+5
The current default configuration for permitted AMR rates on MSC level is not very useful since it only supports a single rate and neglects Config-NB-Code = 1, which includes the four most common AMR rates (12.2, 7.4, 5.9, 4.75) Lets make sure that those rates are are the default for the MSC configuration. Change-Id: I8b2a62879755a8a5edfa1aa36c748968a56aad0d Related: SYS#4470
2019-03-08assignment_fsm: use activate.info.s15_s0 for ASS. COMPL.Philipp Maier1-1/+1
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
2019-03-04cosmetic: drop unused struct mgcp_ctx shadowNeels Hofmeyr1-1/+0
Change-Id: If9c705e9fe6dba9225f7dec045e790af7a875ee8
2019-02-21assignment_fsm: fix channel allocator preferencesPhilipp Maier8-115/+323
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
2019-02-07bsc_vty: add features to disable specific lchans via vtyPhilipp Maier2-0/+48
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
2019-02-06comments: clarify usage of conn.assignment and .handover scopesNeels Hofmeyr1-2/+13
Change-Id: I7ef602c3ce086aecbc3ae3ae6d3fd33ad2b9f85c
2019-02-06handover_fsm: do not access conn->assignment.req, it may be outdatedNeels Hofmeyr3-1/+4
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
2019-02-05Implement CSFB "Fast Return" Handling at RR RELEASEHarald Welte4-1/+89
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
2019-02-05manual: Remove bogus "Control interface" sub-section in overviewHarald Welte1-22/+0
We meanwhile have chapters about the CTRL interface protocol as well as the auto-generated list of CTRL interface commands/values, so let's remove the somewhat redundant information. Change-Id: I062d7eec3b3fc53c31726be3b3a407a2dd3b8b56
2019-02-05manual: s/OsmoNITB/OsmoBSC/ in examples; remove E1 based BTSsHarald Welte1-99/+6
We still haven't re-introduced support for E1 based BTSs, so let's remove the relevant chapters from the manuals. Also, make sure we don't call anything OsmoNITB in this manual anymore. Change-Id: I834d65836731958b6be823a18e35407183398715
2019-02-05manual: Re-order chapters in more logical orderHarald Welte1-6/+6
It makes a lot of sense to first describe the VTY interface before going on using it to configure something. Also, configuration related topics relevant to operators/sysadmins should precede other content only relevant to developers, like the details of the CTRL or Abis/IP protocol. Change-Id: I0872d072bbb06f9409a72b93133d136167f03b38
2019-02-05manual: Add sections on 3G/4G neighbor cellsHarald Welte1-1/+102
This adds some instructions on how to configure 3G/4G neighbor cells within osmo-bsc. I didn't want to add a new top-level chapter but instead chose to add it to the handover section which describes also the configuration of 2G neighbors. Change-Id: I81df1a453858b6fca80c8adf234b1d5b8bf5283d
2019-02-05manual: It's not "A over SCCP" but "BSSAP over SCCP"Harald Welte1-14/+14
In GSM specs, the entire interface between two elements is designated with some letter, like the A interface between BSC and MSC. The interface uses a variety of protocols stacked on each other. In the specific case of A, there is no "A" on top of SCCP, but there's "BSSAP" on top of SCCP. This is followed somewhat un-orthodox by 3GPP, as "A over IP" is a violation of that principle. It should have been called "A utilizing IP", "A based on IP", "A with IP" or something the like. In any case, at no point do the specs ever claim that "A" is stacked on top of SCCP, so let's fix this. Change-Id: Ieb0d8f6c71debe1234aff343a994c2096326da1b
2019-02-05gsm_data: Add gsm_bts_name() just like we have gsm_{trx,ts,lchan}_name()Harald Welte2-0/+11
Change-Id: Icd7fd6273396026c5fe2da600f35631b1bac1614
2019-01-31bsc_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-28LCLS: use libosmocore function to add statusMax3-41/+4
* 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
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