aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
2019-12-12osmoappdesc.py, tests: switch to python 3Oliver Smith3-59/+59
Make build and external tests work with python3, so we can drop the python2 dependency. This should be merged shortly after osmo-python-tests was migrated to python3, and the jenkins build slaves were (automatically) updated to have the new osmo-python-tests installed. Related: OS#2819 Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7 Change-Id: I53ccde96dd3785098df0f7d693c504c8b8302e90
2019-12-12gsup: indicate CN-Domain in SendAuthInfo RequestsNeels Hofmeyr21-146/+147
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS, set CN-Domain = CS in all SendAuthInfo Requests. In Milenage auth, it is highly desirable that osmo-hlr guarantees use of distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same time use the same IND bucket to generate Milenage SQN, that collision would rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each CS/PS Complete-Layer3. So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo Request, which was neither required nor evaluated. The CN-Domain is only sent for the UpdateLocation Request that usually follows later. Related: OS#4318 Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
2019-11-28msc_vlr_test_call: rename lu_utran_tmsiNeels Hofmeyr2-16/+16
Change-Id: I46a41321e6d1be3672a56a6e3cc36f013fdcd396
2019-11-28msc_vlr_tests: log descriptions in color with -vNeels Hofmeyr1-1/+4
Change-Id: I2b28a94a5b27932e343952ba82e7e11c46f5e87d
2019-11-28msc_vlr_test_call.c: add MNCC loggingNeels Hofmeyr2-5/+41
Change-Id: I03b25c134553c620d3fa9d23a67ad39414546861
2019-11-28msc_vlr_tests: better err logging for dtap msgsNeels Hofmeyr1-1/+3
Change-Id: I3edd90be40555dd648e9f16db5b6040665a19a95
2019-11-28MNCC v6: add optional SDP to the socket protocolNeels Hofmeyr6-0/+152
Add a char buffer of 1024 characters length as space for SDP to pass to / receive from MNCC. Actually support receiving MNCC without such an SDP tail. The main reason for this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would stop working for older osmo-msc. Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged (save the protocol number bump) without having to implement SDP. The SDP part in the MNCC protocol will be used in upcoming patch I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f. This patch must be merged at the same time as osmo-sip-connector patch Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching MNCC protocol version number. Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
2019-11-28add sdp_msg API: SDP parsing/compositionNeels Hofmeyr6-0/+1199
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP messages. Obviously, libosmo-mgcp-client already contains similar code, but that is unfortunately heavily glued to the actual MGCP implementation. The simplest solution is to create this separate implementation, copy-pasting from the existing libosmo-mgcp-client code as is convenient. This API is added here to probe whether it works well. When it does, the intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our MGCP client and MGCP server APIs using this same API. Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
2019-11-19Fix some typosMartin Hauke2-4/+4
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-05fix msc_vlr_test_call.cNeels Hofmeyr4-22/+432
Substantial parts of the CC / MNCC call establishment were so far completely missing from the msc_vlr_test_call.c tests. With my new insights on CC and MNCC procedures, complete the tests. Root reason: since I am going to re-order the sequence of events to enable codec negotiation via SDP in MNCC, I want to have comprehensive tests of the CC procedures to see the effect as diffs in the test output. Change-Id: Ie995e264eb1e3dd9558a1753ff6f9b55c1d084e1
2019-10-29also log MNCC_SETUP_REQNeels Hofmeyr1-0/+2
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early return so far skipped logging of that MNCC message. Add this logging. Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
2019-10-29tests: only check IU configs if IU is enabledOliver Smith1-2/+7
Fix vty tests that are failing since libosmocore change Ic225232fbfca49ba868427eaf898e1f6e34e1ca8. If OsmoMSC is built without IU support, it fails with "cs7-instance-iu" in the config. Change-Id: Ie56da9167badfd2399b566af91a345103f46c2a1
2019-10-21log which DTAP messages are sent to RANNeels Hofmeyr9-0/+84
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP message, which is in fact a very interesting detail when reading osmo-msc logs. Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
2019-10-21LOG_TRANS for CC: always log CC stateNeels Hofmeyr1-145/+145
For all CC type transaction logging, log the current trans->cc.state string for all LOG_TRANS*() logging. Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
2019-09-03msc_a fsm: ignore state chg to same stateNeels Hofmeyr4-11/+0
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-03Implement a global switch on the network to disable call waiting.Keith Whyte1-0/+2
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-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 Hofmeyr1-1/+1
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-29vlr_lu_fsm: ignore ID_IMEISV during VLR_ULA_S_WAIT_HLR_UPDNeels Hofmeyr1-1/+0
Change-Id: I2ea4f46efa013671d93892cb07bf830393289150
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr5-48/+78
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-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 Hofmeyr4-0/+36
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-02Set coding in mncc_set_cause()Keith Whyte2-2/+2
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-24vlr_lu_fsm.c: don't send LU reject twiceOliver Smith1-2/+0
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-18replace osmo_counter with stat_itemsAlexander Couzens13-118/+120
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-09Fix: add missing semicolons to OSMO_ASSERT statementsVadim Yanitskiy1-1/+1
Change-Id: I4fae5fbab5fdbcce35906601d4f1031d971f4931
2019-06-19tests/msc_vlr: fix: do not pass RAT type to expect_bssap_clear()Vadim Yanitskiy4-11/+11
The function name implies OSMO_RAT_GERAN_A, and it has nothing to do with other OSMO_RAT_* types. Found using clang: warning: too many arguments in call to 'expect_bssap_clear' expect_bssap_clear(OSMO_RAT_GERAN_A); ^^^^^^^^^^^^^^^^ Change-Id: Id3a3af33fcc5da4ca4c48a2f589a69f3568d2586
2019-06-17libmsc/gsm_09_11.c: fix broken reference counting for vsubVadim Yanitskiy1-21/+24
In gsm0911_gsup_rx() we do call vlr_subscr_find_by_imsi(), which increases subscriber's reference count by one using the function name as the token. However, we never release this token, so the reference count grows on every received GSUP PROC-SS message. Change-Id: I5540556b1c75f6873883e46b78656f31fc1ef186
2019-06-17libmsc/gsm_09_11.c: do not abuse LOG_TRANS() and early trans allocationVadim Yanitskiy1-2/+2
In case of network-originated SS/USSD session establishment, we need to verify the received GSUP PROC_SS_REQ message and make sure that all mandatory IEs are present. There is no sensible need to allocate a new transaction before doing all the checks, other than the ability to use LOG_TRANS(). This complicates the code, so let's avoid the early allocation. Change-Id: I4e027b19e8065a39324a1647957cef4066b82ce7
2019-06-15libmsc/gsm_09_11.c: fix: return trans from establish_nc_ss_trans()Vadim Yanitskiy1-1/+1
It is expected that establish_nc_ss_trans() returns an allocated transaction in successful case, or NULL in case of error. The function assumes two scenarios: - the subscriber already has an active RAN connection, - RAN connection needs to be established (Paging). In the first case, a pointer to the transaction is returned as expected, but in case of Paging, NULL has always been returned, even if there were no errors. Let's fix this. Change-Id: I9dcee64dd0b435ef29630c223132b81724701f93
2019-06-07libmsc/db.c: get rid of hard-coded SMS expiry thresholdVadim Yanitskiy1-2/+1
The initial idea of the SMS expiry threshold was to avoid storing SMS messages with too long validity time (e.g. 63 weeks). Unfortunately, neither this feature was properly documented, nor the expiry threshold is configurable. Moreover, it has been implemented in a wrong way, so instead of deleting the oldest expired message, it would delete the youngest one or nothing: SELECT ... FROM SMS ORDER BY created LIMIT 1; while it should be sorted by 'valid_until' in ascending order: SELECT .. FROM SMS ORDER BY valid_until LIMIT 1; Thus, if the oldest message is expired, it gets deleted. If the oldest message is not expired yet, there is nothing to delete. Change-Id: I0ce6b1ab50986dc69a2be4ea62b6a24c7f3f8f0a
2019-06-05db_sms_test: Remove libdbi expected driver load errorsPau Espin Pedrol3-76/+77
Newer versions of libdbi print to stderr unconditionally when trying to load drivers from /usr/lib/dbd. This makes test output to change depending on host/distro set up (installed modules). Let's get those messages out to make it easier for people having tests pass. We swap stderr/stdout instead of mixing to avoud future possible race conditions if both get content writen into them. Change-Id: Iec78826d28435f464be22e81b3776a6ae8326d59
2019-06-04db_sms_test: Do not print exact memcmp resultPau Espin Pedrol2-13/+11
man memcp doesn't define exact values for returned integer, it only specifices a meaning for the sign of it. So it happens that different versions/implementations actually return different values when this test is run, making it fail. Let's simply drop that info from logs since anyways it's not useful. Change-Id: I771fb8f4fc56f337b16561d005ff1803a386d1c6
2019-06-03libmsc/db.c: fix storing SMS with empty TP-User-DataVadim Yanitskiy2-3/+5
Thanks to db_sms_test, it was discovered that storing an SMS with empty TP-User-Data (TP-UDL=1) causes buffer overruns in libdbi and it's SQLite3 driver (libdbdsqlite3): DDB NOTICE test_db_sms_store('Empty TP-UD'): ==7791== Invalid write of size 2 ==7791== at 0x857DC60: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so) ==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0) ==7791== by 0x4073B1: db_sms_store (db.c:701) ==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310) ==7791== by 0x405BB5: main (db_sms_test.c:546) ==7791== Address 0x7ed1cf0 is 0 bytes after a block of size 0 alloc'd ==7791== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==7791== by 0x857DC4B: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so) ==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0) ==7791== by 0x4073B1: db_sms_store (db.c:701) ==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310) ==7791== by 0x405BB5: main (db_sms_test.c:546) ... DDB NOTICE test_db_sms_get('Empty TP-UD'): ==8051== Invalid read of size 1 ==8051== at 0x5B30510: _dbd_decode_binary (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0) ==8051== by 0x857D957: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so) ==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0) ==8051== by 0x40828F: next_row (db.c:188) ==8051== by 0x40828F: db_sms_get (db.c:805) ==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390) ==8051== by 0x405C14: main (db_sms_test.c:547) ==8051== Address 0x8f74641 is 0 bytes after a block of size 1 alloc'd ==8051== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8051== by 0x5DBEB49: strdup (strdup.c:42) ==8051== by 0x857D93C: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so) ==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0) ==8051== by 0x40828F: next_row (db.c:188) ==8051== by 0x40828F: db_sms_get (db.c:805) ==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390) ==8051== by 0x405C14: main (db_sms_test.c:547) ==8051== success, as expected DDB NOTICE verify_sms('Empty TP-UD'): user_data_len mismatch: E0 vs A3 Apparently, dbi_conn_quote_binary_copy() doesn't properly handle zero-length input. Let's guard against this. Observed with: - libdbi-dev 0.9.0-1 - libdbd-sqlite3:amd64 0.9.0-2ubuntu2 Change-Id: If0b2bb557118c5f0e520a2e6c2816336f6028661
2019-06-03Introduce initial unit test for db_sms_* APIVadim Yanitskiy6-0/+709
Since OsmoMSC has built-in SMSC, it needs to store the messages somewhere. Currently we use libdbi and SQLite3 back-end for that. For a long time, the db_sms_* API remained uncovered by unit tests. This change aims to fix that, and does cover the following calls: - db_sms_store(), - db_sms_get(), - db_sms_get_next_unsent(), - db_sms_mark_delivered(), - db_sms_delete_sent_message_by_id(), - db_sms_delete_by_msisdn(), - db_sms_delete_oldest_expired_message(). Due to performance reasons, the test database is initialized in RAM using the magic filename ':memory:'. This is a feature of SQLite3 (and not libdbi), see: https://www.sqlite.org/inmemorydb.html Of course, this unit test helped to discover some problems: 1) Storing an SMS with empty TP-User-Data (TP-UDL=0) causes buffer overruns in both db_sms_store() and db_sms_get(). 2) TP-User-Data-Length is always being interpreted in octets, regardless of DCS (Data Coding Scheme). This results in storing garbage in the database if the default 7-bit encoding is used. Fortunately, the 'user_data' buffer in structure 'gsm_sms' is large emough, so we don't experience buffer overruns. 3) db_sms_delete_oldest_expired_message() doesn't work as expected. Instead of removing the *oldest* expired message, it tries to remove the *newest* one. The current test expectations do reflect these problems. All of them will be fixed in the follow-up patches. Change-Id: Id94ad35b6f78f839137db2e17010fbf9b40111a3
2019-06-03tests: share stubs.h from msc_vlr_test as stubs.cVadim Yanitskiy14-13/+17
We also need stubs for the upcoming db_sms tests. Due to a known bug of automake [1], we cannot use 'subdir-objects', so as a side effect this change introduces some autoreconf warnings. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993 Change-Id: I8846c940f2695fd33e1007fecac83e73f508bb34
2019-05-29Use GSM23003_MSISDN_MAX_DIGITS from libosmogsmVadim Yanitskiy1-1/+1
Change-Id: If9eb46b83b6ad45f210b86b46dd416352adcc3ff Depends on: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1
2019-05-19vty: Add option to enable osmux towards BSCsPau Espin Pedrol1-0/+1
Change-Id: I6de1be0322ddbdc115074ebb6be2598ebf6c95db
2019-05-15vlr: optionally send IMEI early to HLROliver Smith13-164/+150
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to the HLR before doing the location update with the HLR. The OsmoHLR documentation referenced in the code will be added in osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9. Related: OS#2542 Change-Id: I88283cad23793b475445d814ff49db534cb41244
2019-05-15vlr: when setting IMEISV, also set IMEIOliver Smith2-0/+6
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will get cut off then. This is needed for the subscriber on demand use case, since we can get the IMEISV early (see [1]), but need to send the IMEI to the Check IMEI procedure. While adjusting the tests, I have noticed that there are code paths where we ask the MS for the IMEISV first, and later ask the MS for the IMEI, although we already have the IMEISV. This could be improved in a future patch. [1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f Related: OS#2542 Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
2019-05-15vlr: fix IMEI lengthOliver Smith6-50/+46
Set the length of vlr_subscr->imei to GSM23003_IMEI_NUM_DIGITS_NO_CHK (14) instead of GSM23003_IMEISV_NUM_DIGITS (16). Note that there is also GSM23003_IMEI_NUM_DIGITS (15), which includes an additional checksum digit. This digit is not intended for digital transmission, so we don't need to store it. Also by not storing it, we can simply copy the IMEI-part from the IMEISV to the IMEI without worrying about the checksum (will be done in a follow up patch). A good overview of the IMEI/IMEISV structure is here: https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_(IMEI_software_version) Related: OS#2542 Change-Id: Iaf2569c099874b55acbd748b776394726cc5ce54
2019-05-15vty: make retrieve-imeisv-early configurableOliver Smith1-1/+1
Prepare for Rhizomatica's subscriber on demand use case, in which the network access is disabled by default for new subscribers, but the IMEI is required in the HLR to find out which user has which IMSI. Due to the network access being disabled, the location update request towards the HLR fails and the MS gets rejected, so we need to get the IMEI early. Related: OS#2542, OS#3755 Change-Id: I256224194c3b8caf2b58a88d11dccd32c569201f
2019-05-13sms_queue_test: assert return value of osmo_use_count_get_put()Vadim Yanitskiy1-3/+4
Change-Id: I9381e88435ccd856ec619135ca9999c15c25d436 Fixes: CID#198416
2019-05-13tests/.../Makefile.am avoid redundant linkage with librtVadim Yanitskiy2-2/+0
The librt is required for old glibc < 2.17 to get clock_gettime(). Since we do check the availability of this function libosmocore and conditionally link it against librt, there is no need to do such unconditional and redundant linkage here. Change-Id: If587d16d2db677b97e3a0641027eb735af9c9c30
2019-05-12add DSS logging categoryNeels Hofmeyr2-9/+14
Change-Id: Id7e04c9f5088334cd5ec6cfdb6a9b3a2a7e7fda0
2019-05-12libmsc/gsm_04_11.c: fix double init of both SMR and SMC FSMsVadim Yanitskiy6-36/+0
Change-Id: I23700a2c575a96057ef22bc5d8ab6271104d619b
2019-05-10LOG_TRANS: store subsys in trans, unify USSD logging back to DMMNeels Hofmeyr1-8/+8
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather store in trans->log_subsys once on trans_alloc() and use that. Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little sense and may cause logging to switch subsystems depending on the RAN state. In trans_log_subsys(), add missing switch cases: - Log silent call transactions also on CC. - Log USSD on DMM. About USSD: we currently have no dedicated USSD logging category. As a result, after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC, depending on whether a RAN was associated with the trans or not. Before that change, USSD always logged on DMM, so, until we have a separate logging category for USSD, consistenly use DMM again. [1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7b62025473d8f1a950905ac2cb2f31c Related: coverity CID 198453 Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
2019-05-09vty/cfg: add missing write-back of inter-BSC and inter-MSC HO configNeels Hofmeyr1-0/+20
Add missing 'show running-config' test to test_neighbor_ident.vty transcript test. Change-Id: Ie3b084e169da9509b37f6ab91ade79440c1b36d2
2019-05-09fix regression: fix internal MNCC operationNeels Hofmeyr2-2/+2
While developing the inter-MSC handover refactoring, I was annoyed by the fact that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as well as a separate msg_type argument, which may deviate from each other. So, as a first step I wanted to make sure that all callers send identical values for both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going to remove the separate msg_type argument. I then forgot to - carry on to remove the argument and - to actually test with internal MNCC (it so happens that all of our ttcn3 tests also use external MNCC). As a result, the "large refactoring" patch for inter-MSC Handover breaks internal MNCC operation. Fix that: remove the separate msg_type argument and make sure that all callers of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence also remove the odd duality of arguments. Various functions in mncc_builtin.c also exhibit this separate msg_type argument, which are all unused and make absolutely no sense. Remove those as well. Related: OS#3989 Change-Id: I966ce764796982709ea3312e76988a95257acb8d
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr31-15486/+19853
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles: - MSC-A is responsible for managing subscribers, - MSC-I is the gateway to the RAN. - MSC-T is a second transitory gateway to another RAN during Handover. After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while the original MSC-A retains the responsibility of subscriber management. MSC-T exists in this patch but is not yet used, since Handover is only prepared for, not yet implemented. Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC roles. Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications: - all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc instance, - messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface (GSUP), - no call routing between MSC-A and -I via MNCC necessary. This is the largest code bomb I have submitted, ever. Out of principle, I apologize to everyone trying to read this as a whole. Unfortunately, I see no sense in trying to split this patch into smaller bits. It would be a huge amount of work to introduce these changes in separate chunks, especially if each should in turn be useful and pass all test suites. So, unfortunately, we are stuck with this code bomb. The following are some details and rationale for this rather huge refactoring: * separate MSC subscriber management from ran_conn struct ran_conn is reduced from the pivotal subscriber management entity it has been so far to a mere storage for an SCCP connection ID and an MSC subscriber reference. The new pivotal subscriber management entity is struct msc_a -- struct msub lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however use msc_a, since MSC-A is where all the interesting stuff happens. Before handover, msc_i is an FSM implementation that encodes to the local ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM implementation that instead forwards via/from GSUP. Same goes for the msc_a struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the msc_a->fi is an FSM implementation that merely forwards via/from GSUP. * New SCCP implementation for RAN access To be able to forward BSSAP and RANAP messages via the GSUP interface, the individual message layers need to be cleanly separated. The IuCS implementation used until now (iu_client from libosmo-ranap) did not provide this level of separation, and needed a complete rewrite. It was trivial to implement this in such a way that both BSSAP and RANAP can be handled by the same SCCP code, hence the new SCCP-RAN layer also replaces BSSAP handling. sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN connections. A set of callback functions provides implementation specific details. * RAN Abstraction (BSSAP vs. RANAP) The common SCCP implementation did set the theme for the remaining refactoring: make all other MSC code paths entirely RAN-implementation-agnostic. ran_infra.c provides data structures that list RAN implementation specifics, from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra pointer hence allows complete abstraction of RAN implementations: - managing connected RAN peers (BSC, RNC) in ran_peer.c, - classifying and de-/encoding RAN PDUs, - recording connected LACs and cell IDs and sending out Paging requests to matching RAN peers. * RAN RESET now also for RANAP ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide proper RESET handling, which it so far duly ignores. (TODO) * RAN de-/encoding abstraction The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP implementations transparently, but also to be able to optionally handle RAN on distinct levels. Before Handover, all RAN messages are handled by the MSC-A role. However, after an inter-MSC Handover, a standalone MSC-I will need to decode RAN PDUs, at least in order to manage Assignment of RTP streams between BSS/RNC and MNCC call forwarding. ran_msg.h provides a common API with abstraction for: - receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP or RANAP; - sending RAN events: ran_enc_msg is the counterpart to compose RAN messages that should be encoded to either BSSMAP or RANAP and passed down to the BSC/RNC and MS/UE. The RAN-specific implementations are completely contained by ran_msg_a.c and ran_msg_iu.c. In particular, Assignment and Ciphering have so far been distinct code paths for BSSAP and RANAP, with switch(via_ran){...} statements all over the place. Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified. Note that SGs does not qualify for RAN abstraction: the SGs interface always remains with the MSC-A role, and SGs messages follow quite distinct semantics from the fairly similar GERAN and UTRAN. * MGW and RTP stream management So far, managing MGW endpoints via MGCP was tightly glued in-between GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP streams between different RAN peers by moving to object-oriented implementations: implement struct call_leg and struct rtp_stream with distinct FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose. Instead of implementing a sequence of events with code duplication for the RAN and CN sides, the idea is to manage each RTP stream separately by firing and receiving events as soon as codecs and RTP ports are negotiated, and letting the individual FSMs take care of the MGW management "asynchronously". The caller provides event IDs and an FSM instance that should be notified of RTP stream setup progress. Hence it becomes possible to reconnect RTP streams from one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP peers (inter-MSC Handover) without duplicating the MGCP code for each transition. The number of FSM implementations used for MGCP handling may seem a bit of an overkill. But in fact, the number of perspectives on RTP forwarding are far from trivial: - an MGW endpoint is an entity with N connections, and MGCP "sessions" for configuring them by talking to the MGW; - an RTP stream is a remote peer connected to one of the endpoint's connections, which is asynchronously notified of codec and RTP port choices; - a call leg is the higher level view on either an MT or MO side of a voice call, a combination of two RTP streams to forward between two remote peers. BSC MGW PBX CI CI [MGW-endpoint] [--rtp_stream--] [--rtp_stream--] [----------------call_leg----------------] * Use counts Introduce using the new osmo_use_count API added to libosmocore for this purpose. Each use token has a distinct name in the logging, which can be a globally constant name or ad-hoc, like the local __func__ string constant. Use in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count API. * FSM Timeouts Introduce using the new osmo_tdef API, which provides a common VTY implementation for all timer numbers, and FSM state transitions with the correct timeout. Originated in osmo-bsc, recently moved to libosmocore. Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore) Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore) Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp) I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw) Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw) I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 23:44:03 +0000