aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
37 hoursvlr_auth_fsm: on SAI use the GSUP provided GMM cause codeHEADmasterAlexander Couzens1-7/+8
The HLR might respond with a specific GMM cause code. E.g. roaming not allowed which needs to be passed down the layers. Change-Id: I9af515dc52834b7c57c42fc3a76ee2c682734e2a
37 hoursmake vlr_gmm_cause_to_mm_cause publicAlexander Couzens2-3/+6
To be used by vlr_auth_fsm Change-Id: I9e13e756f359a9b9e6a2056ab37adf0af14afec1
2019-09-26catch GSUP auth result without auth_fsmNeels Hofmeyr1-0/+6
When a vlr_subscr receives an Send Auth Info result, properly check whether the subscriber has an auth_fsm. Before, a missing auth_fsm would crash osmo-msc with: vlr.c:762 Trying to dispatch event 1 to non-existent FSM instance! Related: OS#4191 Change-Id: I1995d8f68cfde1140968fb9a97bd054de950de2e
2019-09-26paging: Send SGsAP-SERVICE-ABORT-REQUEST on paging timeoutPhilipp Maier3-0/+27
When pagig for a CS-Call via SGs times out, the MME expects to be informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this message is sent, but only for CS-Fallback calls. Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877 Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a Related: OS#3614
2019-09-24sgs_iface: Accept messages with unknown TLV elementsPhilipp Maier1-4/+2
3GPP TS 29.118, chapter 7.5 states that unknown TLV elements should be ignored rather than that the whole message is discarded a STATUS message is sent. Lets turn the returncode check of the tlv_parse() call into a log message and continue normally. Change-Id: Ic6714451ad970043d4765f8420d753daf5294a44 Related: OS#4214
2019-09-18fix error on BSSMAP Cipher Mode Complete L3 msg IENeels Hofmeyr3-11/+16
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second time, but instead point to it from the ran_msg.cipher_mode_complete struct. When the MSC-A decodes the Ciphering Mode Complete message, it always wants to also decode the enclosed DTAP from the Layer 3 Message Contents IE. However, when the MSC-I preliminarily decodes messages, it often just wants to identify specific messages without fully acting on them, let alone dispatching RAN_UP_L2 events more than once. So leave it up to the supplied decode_cb passed to ran_dec_l2() implementations to decide whether to decode the DTAP. In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher Mode Complete's Layer 3 Message Contents IE. Particularly, the previous choice of calling the decode_cb a second time for the enclosed DTAP caused a header/length parsing error: the second decode_cb call tried to mimick DTAP by overwriting the l3h pointer and truncating the length of the msgb, but subsequently ran_a_decode_l2() would again derive the l3h from the l2h, obliterating the intended re-interpretation as DTAP, and hence the previous truncation caused error messages on each and every Cipher Mode Complete message, like: DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message This error was seen a lot at CCCamp2019. Modifying the msgb was a bad idea to begin with, the approach taken in this patch is much cleaner. Note that apparently many phones include the IMEISV in the Cipher Mode Complete message even though the BSSMAP Cipher Mode Command did not include the Cipher Response Mode IE. So, even though we did not specifically ask for the Cipher Mode Complete to include any identity, many MS default to including the IMEISV of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using a Samsung Galaxy S4mini. Related: OS#4168 Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
2019-09-16vlr: gmm_cause_to_fsm_and_mm_cause() drop fsm_cause_p argumentAlexander Couzens1-16/+6
It's always set to OSMO_TERM_ERROR. Move the assignment to the caller. In prepartion to use gmm_cause_to_fsm_and_mm_cause() in vlr_auth_fsm. Change-Id: Ie4720ad40ef7bcfc528d8d63bfc606c9c0545fb2
2019-09-16vty: fix access to wrong argv in paging response-timerPau Espin Pedrol1-1/+1
Fixes: 2ff5bcdc387a7eb5135e5a54d55027502952c86b Change-Id: I667cf4c8e3e7b6e77ea6ed8ae603727ad22a2ee2
2019-09-03msc_a fsm: ignore state chg to same stateNeels Hofmeyr5-13/+8
We sometimes see errors like libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted! i.e. changing state to the state msc_a is already in. Ignore re-entering the same state for most state changes. However, there is one state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary to start the timeout. Hence add msc_a_state_chg_always() and use that for re-entering MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes. This should silence all no-op state change error messages for msc_a. Related: OS#4169 Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
2019-09-03ran_dec logging: log message sizes on errorsNeels Hofmeyr1-3/+7
Change-Id: Id08e4ee5a4dbf552dbb107d8f0519110664f6acb
2019-09-03vlr: don't log about "gratuitous ID RESPONSE"Neels Hofmeyr1-2/+0
If an ID Response comes in during a non-LU L3 Complete (Paging or CM Service Request), no event needs to be dispatched. So far vlr_subscr_rx_id_resp() logged a NOTICE "gratuitous ID RESPONSE?!?" if no lu_fsm is present. An ID Response can come in particularly as payload with a BSSMAP Cipher Mode Complete message, even though osmo-msc didn't explicitly ask for it. It is not an error to get a Cipher Mode Complete containing an ID Response during Paging or CM Service Request, so remove the confusing log message. Related: OS#4168 (only loosely related) Change-Id: I8a5b8735eb41cd0976c7ab32cdd55440d3ef70ac
2019-09-03Implement a global switch on the network to disable call waiting.Keith Whyte5-3/+53
Add a network -> callwaiting VTY command as boolean. When this is enabled (default) there is no change to operation previous to this commit. When this switch is disabled with "no call-waiting" in vty then when a call arrives, we will check if we have an active call transaction for this subscriber, no matter if it is establishing, established, or alerting, in any of these cases we will return USER BUSY to the calling party. Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
2019-09-02cosmetic: fix call_leg_ensure_ci() decl. arg name to match impl.Neels Hofmeyr1-1/+1
Change-Id: I576bc5c1fd63fe8048a7a6a2d06763fc3221fa49
2019-09-02msc_a.c, CC trans: change a comment to a debug logNeels Hofmeyr1-1/+1
Change-Id: I5a3cc6219080910119b0c9ff11fc2b9eb96a06e5
2019-09-02gsm48_tch_rtp_create(): check against NULL mgcp_infoNeels Hofmeyr1-1/+4
osmo_mgcpc_ep_ci_get_rtp_info() might return a NULL mgcp_info, guard against that. Fixes: CID#203651 Change-Id: I98fe5860c49751ade1af10d99487aba259504f23
2019-09-02msc_vlr_tests: GSUP: don't care about extra IEsNeels Hofmeyr1-1/+9
To not break the msc_vlr tests by new GSUP IEs added to some of the GSUP messages, make msc_vlr_tests only match the start of the GSUP message and not care about extra IEs. The extra IEs are anyway seen in the expected logs. The reason to drop the msgb_eq_data_print() is because it is useless for mismatching lengths. It will always print only the length mismatch, instead we need to be able to compare with what was expected. Change-Id: I38d51eeafab04ece83e4bb87bfaa967506f97b11
2019-09-02log, cosmetic: add "RR" to "Ciphering Mode Complete"Neels Hofmeyr2-2/+2
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer BSSMAP Cipher Mode Complete message in the DEBUG log. Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
2019-08-29tweak CC cause for incoming call to unattached nrNeels Hofmeyr1-1/+1
So far we sent CC cause "Unassigned Number" But the MSC doesn't trivially know whether the HLR has the number assigned or not: any handset that is currently switched off would cause "Unassigned number" to be displayed on the caller's handset. Rather send a temporary failure cause code. Send this cause code for all cases, because claiming that an assigned number is unassigned is worse than rejecting an unassigned number with a temporary failure. Change-Id: Ia3d4f67b53fcc2654ff048fbc338e92cb763a095
2019-08-29vlr_lu_fsm: ignore ID_IMEISV during VLR_ULA_S_WAIT_HLR_UPDNeels Hofmeyr2-2/+7
Change-Id: I2ea4f46efa013671d93892cb07bf830393289150
2019-08-29fix segfault: don't send CC REL on NULL msc_aNeels Hofmeyr2-2/+19
Apparently, if a conn disappears during an ongoing call, the CC code tried to send a CC REL on a NULL msc_a during cleanup, which lead to a crash (cccamp2019). Guard against that. Crash: #0 msc_a_tx_dtap_to_i (msc_a=0x0, dtap=0x55a4bf2fa0f0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1565 #1 0x000055a4be1bb03c in trans_tx_gsm48 (trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, msg=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:82 #2 gsm48_cc_tx_release (trans=trans@entry=0x55a4bf2d52a0, arg=arg@entry=0x7ffdd731a0e0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1101 #3 0x000055a4be1bee65 in _gsm48_cc_trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:278 #4 0x000055a4be1ab654 in trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/transaction.c:170 #5 0x000055a4be1bd091 in mncc_tx_to_gsm_cc (net=<optimized out>, msg=msg@entry=0x55a4bf2d3b68) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1971 #6 0x000055a4be1bf1e5 in mncc_tx_to_cc (net=<optimized out>, arg=arg@entry=0x55a4bf2d3b68) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:2049 #7 0x000055a4be18ed63 in mncc_sock_read (bfd=0x55a4bf2563b8, bfd=0x55a4bf2563b8) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:121 #8 mncc_sock_cb (bfd=0x55a4bf2563b8, flags=1) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:189 #9 0x00007fcfad607ce1 in osmo_fd_disp_fds (_eset=0x7ffdd731a9a0, _wset=0x7ffdd731a920, _rset=0x7ffdd731a8a0) at ../../../src/libosmocore/src/select.c:223 #10 osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:263 #11 0x000055a4be17dd56 in main (argc=3, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:723 Change-Id: Ia1bb0410ad0618c182a5f6da06af342b6d483eff
2019-08-29cc trans: make sure bearer cap is emptyNeels Hofmeyr1-0/+4
Change-Id: I147f10f9258fc8685f2f666878dd2a655b8e4583
2019-08-29memleak on cc setup errorsNeels Hofmeyr1-0/+2
Change-Id: I3333b90064575b270627721ace7e07d085f4ad43
2019-08-28mncc: send payload type matching chosen codecNeels Hofmeyr2-13/+28
Change-Id: Id32f32d77d24b753adb96b5393c0363439e312c2
2019-08-23smpp_openbsc.c: check acl before deref itAlexander Couzens1-1/+1
All other calls check acl before deref because in a setup with no access policy, there won't be any acl structure Change-Id: Ibe0256535b40351594d79baa05a0147a9f89dc26
2019-08-19msc_a: switch RAN type back to SGs when a CSFB-Call is clearedPhilipp Maier1-0/+5
When a CSFB call is over the MS changes back to LTE after the call is cleared. However, at the moment the MSC does not change the cs.attached_via_ran flag. This may cause problems with the next call. Lets make sure that if there is an SGs association present, the ran type is set back to SGs when the call is cleared. Related: SYS#4624 Change-Id: I104adecb0645b81b90ee230c57bf8b463c9e7045
2019-08-18libvlr/vlr.c: cosmetic: move message_type assignmentVadim Yanitskiy1-2/+2
Change-Id: Ice7f98597b54f03069375fac56fb162f2669e7f0
2019-08-16sgs_iface: do not use SGsAP-MO-CSFB-INDICATION for CSFB returnPhilipp Maier1-4/+4
When the VLR/MSC receives an SGsAP-MO-CSFB-INDICATION message it sets the RAN type back to SGs. This is wrong, the message SGsAP-MO-CSFB-INDICATION has just an informative character. It informs the VLR that the UE has initiated an MO CSFB call (service request). Change-Id: I625574fc42fc915ba483db3bb406922ad6df370d Related: SYS#4624
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr10-62/+153
Recently, the ability to run UTRAN without encryption was added, but the config for it was tied to the A5 GERAN encryption configuration. This affected osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3 test suite sets A5 to 0 (no encryption) but still expects Iu to enable air encryption. Fix this "regression". Add a separate vty config option for UEA encryption, even if it does not provide full granularity to select individual UEA algorithms yet. As a result, Iu default behavior remains to enable encryption regardless of the A5 config. UTRAN encryption can be disabled by the new cfg option "encryption uea 0" alone. Even though the new vty command already allows passing various combinations of the UEA algorithm numbers, only '0' and '1 2' are accepted as valid combinations, to reflect current osmo-msc capabilities. Revert most changes to the msc_vlr test suite in commit "do not force encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new net->iu_encryption instead of net->a5_encryption_mask. Adjust/add to test_nodes.vty transcript tests. Related: OS#4144 Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
2019-08-12cosmetic: make function mncc_tx_to_gsm_cc staticPhilipp Maier1-1/+1
The function mncc_tx_to_gsm_cc() is declared as non static but only used from within gsm_04_08_cc.c. Lets declare it as static to increase readability of the code Change-Id: Icd02c669cfee6dd7e6b154e303cd0f4c148c83c4
2019-08-08Bump version: 1.4.0 → 1.5.01.5.0Pau Espin Pedrol1-0/+227
Change-Id: I9b79805c703f4bb860a07bf521ddbf8cb9b29d23
2019-08-08Fix dependency version requirementsPau Espin Pedrol2-20/+20
libosmocore 1.1.0 0e8df1c7e48bcae2285c7c138bd50f932049bd24 osmo_use_count() Fixes: 7c5346cd7005ad469702a2f74572b79de738fbbb libosmocore 1.2.0 cdac620579b5bf44970b5f4bb11734fdfdf5bf59 GSM23003_MSISDN_MAX_DIGITS Fixes: 8b0737fa71ea4b04cee8dc61c79a1f93779e66dc libosmo-sccp 1.1.0 21ff9ae4264de159784a59ce4421365007bde08d osmo_sccp_addr_ri_cmp() Fixes: c4628a3ad4d3c5f65782b152b771bf80357235d6 osmo-mgw 1.6.0 538d2c53d90074267e7a70a90c773baa03d6ec04 mgcp_client_endpoint_fsm.h Fixes: c4628a3ad4d3c5f65782b152b771bf80357235d6 libosmo-netif 0.6.0 needed by osmo-mgw 1.6.0 libsmpp34 1.14.0 required due to needed heap allocation function overrides from smpp34_heap.h Change-Id: I1cd2c7317933b416b74a412f10e4cad16ecd6e59
2019-08-08vlr_lu_fsm: fix missing event for IMEISVNeels Hofmeyr1-0/+1
Event VLR_ULA_E_ID_IMEISV is listed as permitted in VLR_ULA_S_WAIT_LU_COMPL, but is missing from the switch() on the incoming event. So, sending an IMEISV identity during the WAIT_LU_COMPL state would crash osmo-msc. When receiving an IMEISV, vlr_subscr_set_imeisv() in turn calls vlr_subscr_set_imei(), so as far as the lu_fsm is concerned, receiving an IMEISV is identical to receiving an IMEI, and it can continue to send a Check IMEI request to the HLR. Thus simply add VLR_ULA_E_ID_IMEISV to the VLR_ULA_E_ID_IMEI switch case. Change-Id: I11106cb108a4b1406ff9a8b8ff5761440a274dad
2019-08-05doc/sequence_charts: fix naming of mncc_fsm to mncc_callNeels Hofmeyr2-14/+14
mncc_fsm.[hc] were renamed to mncc_call.[hc] during patch review, which failed to carry through to this sequence chart. Also fix the MNCC_ST_* to MNCC_CALL_ST_* and MNCC_EV_* to MNCC_CALL_EV_*. Change-Id: I03ee1b43ab95dca3c43fdb9e92dc158aad5a4203
2019-08-05doc/sequence_charts/mncc_fsm.msc: add SIP messages, tweakNeels Hofmeyr1-35/+55
- add SIP messages, taken from OS#1683 - change some wording and clarify some message ordering - have a separate sipcon1 and sipcon2 for the MO and MT sides Change-Id: I6782e416dbd8ee88d093cbef722b0c5084f3865c
2019-08-05add msc_vlr tests for UMTS without cipheringNeels Hofmeyr2-79/+966
Following I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7, have tests for UMTS authentication both for cases with and without encryption. - Rename test_umts_authen_utran to test_umts_auth_ciph_utran() (uses encryption). - Again add test_umts_authen_utran() not using encryption. - Likewise with test_umts_authen_resync_utran(). Some permutations are still missing, like UMTS AKA on GERAN with encryption enabled; not bothering at the moment. Related: OS#2783 Change-Id: I54227f1f08c38c0bf69b9c48924669c4829b04b9
2019-08-05do not force encryption on UTRANNeels Hofmeyr7-5/+48
Remove the conditions that always enable encryption on UTRAN. We so far lack an explicit configuration for UTRAN encryption, and this patch does not add any either. Instead, whether UTRAN encryption is enabled is simply triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though GERAN and UTRAN encryption are not technically related at all, this makes UTRAN behave like GERAN for now, until we implement a proper separate configuration for UTRAN encryption. Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask such that the expected output remains unchanged. A subsequent patch (I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly cases of UTRAN without encryption. Adjust manual and vty doc. Related: OS#2783 Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
2019-08-05manual: adjust and fix auth and ciph docsNeels Hofmeyr1-14/+54
Change-Id: Iffe159d4c0e0e9439f8719e0ddd28f06d4c80d9f
2019-08-05Remove undefined param passed to logging_vty_add_cmdsPau Espin Pedrol1-1/+1
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. Change-Id: Ia2b24ffd7f9cbb271fcdb979b851f3a07b9d6d3e Related: OS#4138
2019-08-02Set coding in mncc_set_cause()Keith Whyte3-2/+3
GSM 04.08 10.5.4.11 The Release indication needs to have the Coding Standard set. For phones that would display a message on screen, such as "Number not in use", if the coding standard is not defined, the display may show "Error in Connection" Change-Id: Ib28b62a41d433e231cff5910d19455296b284df6
2019-07-29minor comments in msc_vty.cNeels Hofmeyr1-0/+2
Change-Id: I83d8c778190adb1e74debc8f8ddac6996de7c513
2019-07-25doc: Add Osmux documentation to User ManualPau Espin Pedrol2-1/+67
Depends: osmo-gsm-manuals.git f3a734e6777a902abfb03257277454c7a879aeb7 Change-Id: I70c488c3d9b05599b834a8608e6361c8aa43ef31
2019-07-24vlr_lu_fsm.c: don't send LU reject twiceOliver Smith2-15/+4
Don't call tx_lu_rej() in the "vlr_lu_compl" FSM. It is always getting called in the parent "lu" FSM and is therefore redundant: _vlr_lu_compl_fsm_done(fi, VLR_FSM_RESULT_FAILURE, cause) -> osmo_fsm_inst_state_chg(fi, LU_COMPL_VLR_S_DONE, 0, 0) -> vlr_lu_compl_fsm_dispatch_result() -> lu_fsm_wait_lu_compl()/lu_fsm_wait_lu_compl_standalone() -> lu_fsm_failure() -> lfp->vlr->ops.tx_lu_rej() I have noticed the bug with the TTCN3 tests. This patch fixes TC_lu_imsi_auth_tmsi_check_imei_{nack,err} after stricter checking in [1] and also TC_iu_mo_crcx_ran_reject. [1] I836f76242463789c4c003feec757714827f2a31b (osmo-ttcn3-hacks) Change-Id: I127b27937613ea0ff29d67991c0414fca6d441d9
2019-07-22turn -Werror=null-dereference into a warningEric Wild1-1/+1
There is unfortunately no way to suppres this witha pragma, and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed Related: OS#4123 Change-Id: I615bb5be3671022c6b821575a61f945b50e8f2a5
2019-07-18replace osmo_counter with stat_itemsAlexander Couzens17-127/+155
osmo_counter will be soon deprecated. Use the newer and more flexible osmo_stat_item instead. Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore) Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
2019-07-16fix spelling detected by lintianThorsten Alteholz4-6/+6
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-07-11contrib/jenkins.sh: run "make maintainer-clean"Oliver Smith1-0/+1
Related: OS#3047 Change-Id: Ifc91733c7fe0c5a002037523116014bf270997ef
2019-07-09libmsc/msc_vty.c: print subscriber expiration timeVadim Yanitskiy1-0/+17
Change-Id: I092691a8c443f4c5ed4d33de2e551fef592c1baf
2019-07-09Fix: add missing semicolons to OSMO_ASSERT statementsVadim Yanitskiy2-2/+2
Change-Id: I4fae5fbab5fdbcce35906601d4f1031d971f4931
2019-06-20libmsc/ran_msg_iu.c: fix: properly handle SAPI IE of RANAP_DirectTransferVadim Yanitskiy1-2/+12
The RANAP DirectTransfer message may contain an optional SAPI IE. Thanks to our TTCN-3 tests (and Wireshark!), it was discovered that this IE is ignored, so even if the MO SMS related messages arrive on SAPI 3 (as per GSM TS 04.11, section 2.3) OsmoMSC sends MT messages on SAPI 0. In ran_iu_decode_l3() we need to check if the SAPI IE is present, and tag the NAS PDU message buffer with a proper DLCI value. This change makes the failing SMS related test cases pass. Change-Id: I728b55b04e87fc23be6d4f8735e8cad82b6f640e
2019-06-20libmsc/gsm_04_11.c: do not abuse LOG_TRANS() in gsm411_alloc_mt_trans()Vadim Yanitskiy1-2/+2
This change is similar to I6b68a0f0b32eb126e0f7e914a314130254d28467. If we 100% sure that trans == NULL, it makes more sense to use generic LOGP(DLSMS, LOGL_*, ...) call, so the logs can reflect more information than such dummy prefix: trans(NULL NULL callref-0x0 tid-0) ... Change-Id: I3c1e633aee5dd7cd0d367404a3def9cffe0b3baa