aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc
AgeCommit message (Collapse)AuthorFilesLines
2019-05-08handover_fsm: copy old S15_S0 to new lchanPhilipp Maier1-0/+1
When a new lchan is selected during handover, some of the properties of the old lchan are inherited by the new lchan. At the moment S15-S0 is not not inherited so that the value for those bits will always be 0x0000 for the new lchan. Since those bits also define the active set AMR codec the channel activation will fail because 0x0000 is invalid (active set with zero rates) Change-Id: Ifd470397e99985394634da1bb13ccfc5041984d2 Related: OS#3503
2019-01-17chan_alloc: remove references to lchan_alloc()Philipp Maier1-2/+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 reasonMax4-15/+15
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 Hofmeyr1-1/+1
(requested by pespin) Change-Id: I04ec4ce1fd2b7b110bb496186aae39ecfbbc3628
2018-12-21make sure early lchan act failure resets the lchanNeels Hofmeyr6-89/+91
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 representationMax2-19/+13
* 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 Pedrol3-6/+47
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 Maier1-0/+68
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-05paging: Add VTY options to calculate T3113 timeout dynamicallyPau Espin Pedrol5-3/+84
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 Pedrol1-1/+1
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-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-28bsc: lchan_select: Avoid returning a TCH/H lchan when TCH/F is requestedPau Espin Pedrol1-16/+1
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
2018-11-28cosmetic: bsc: timeslot_fsm: Clean uneeded scope bracketsPau Espin Pedrol1-5/+4
Change-Id: I5140f98e23b8c8d16ce0cca0be66297aaf0b5653
2018-11-27send Immediate Assignment Reject only before Immediate AssignmentNeels Hofmeyr1-3/+12
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
2018-11-23vty: add command to show TRX selectivelyMax1-4/+46
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
2018-11-22LCLS: add bts-loop variantMax3-8/+53
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
2018-11-22RSL: restructure MDCX functionsMax1-6/+18
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
2018-11-21gsm0408_rcvmsg: Release lchan if L3 fails to completePau Espin Pedrol1-1/+6
gscon_release_lchans stub is added to gsm0408_test.c to make linker happy. Change-Id: I1743f9d5cd0fdbc0fb9afe7bcc0271c897915210
2018-11-21abis_nm: Introduce new signal S_NM_GET_ATTR_REPPau Espin Pedrol1-2/+7
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
2018-11-20bsc: vty: Verify and warn on invalid arfcn passedPau Espin Pedrol1-1/+31
Related: OS#3063 Depends: libosmocore Change-Id I780d452dcebce385469e32ef2fd844df6033393a Change-Id: Ib001501bf37289e824a1f72b62afde23892e88d2
2018-11-20bsc: band_compatible: Return band non-compatible for invalid arfcnPau Espin Pedrol1-1/+6
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
2018-11-20bsc: Enable force-combined-si on nanoBTS by defaultPau Espin Pedrol4-4/+15
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
2018-11-20bsc: si: Fix SI2ter L2 pseudo lengthPau Espin Pedrol1-1/+1
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
generated by cgit v1.2.1 (git 2.18.0) at 2021-01-23 15:18:30 +0000