aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-03-19a_iface_bssap: check bssmap length fieldpmaier/fixlengthPhilipp Maier1-0/+28
At the moment the length field of the bssmap header is not parsed. Instead the length is computed out of the known header length and the number of bytes received. This is prone to error, lets make sure that extranous data at the end of a message is ignored by parsing the bssmap length correctly. Change-Id: I3b89dd5a66ec83b03860b58b6b8eb58007f433a4 Related: OS#3806
2019-03-15silent_call: use osmo_strlcpy() instead of strncpy()Philipp Maier1-1/+2
If gsm_silent_call_start() is called with an over long string in traffic_dst_ip, then the target string might be left unterminated. Lets use osmo_strlcpy() so that we can be sure the result in scd->traffic_ip is always terminated. Fixes: CID#196068 Change-Id: Ic81842175e412ae7d97d023b612412f33411d60c
2019-03-14libmsc: Allow different channel types to be requested as silent callsSylvain Munaut3-21/+158
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
2019-03-08vty: add cmd subscriber ID sms delete-allNeels Hofmeyr1-0/+25
In ttcn3-msc-tests, so far we leave an intentionally failed MT SMS in the SMS queue, which may cause it to re-appear in subsequent tests. Allow removing all SMS for a given subscriber from the SMS database for good. (I dimly remember a user report where the SMS queue spams failed SMS attempts, and the only way to get rid of SMS for a given subscriber is to tamper with the sms.db file directly. This should no longer be necessary with this command.) Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks) Change-Id: I637cbd7adc075a192f49752b38779391472ff06d
2019-03-07SMS queue: properly log failed attempts numberNeels Hofmeyr1-1/+2
Change-Id: I16f2d29855eb715eccbdc5def225f43c110fab8e
2019-03-07gsm_04_11_gsup.c: drop unused conn lookupNeels Hofmeyr1-11/+0
An earlier code state used the conn to lookup the transaction, but this is now done by vsub. Hence the conn lookup is not used and not needed. conn is no longer used since 36c44b210059bd75059008913ad05976dfef7d7e, change-Id I093f36d63e671e50e54fc6236e97a777cc6da77b, "transaction: change arguments of trans_find_by_sm_rp_mr()" Change-Id: Ia878d70138c883cb1a1d983516aff83efa6488ce
2019-03-07use only accepted ran_conns for new transactionsNeels Hofmeyr2-3/+11
In connection_for_subscriber(), do not return a ran_conn that is not yet authenticated nor one that is already in release. Using a ran_conn that is not yet authenticated may cause an auth/ciph violation. Using a ran_conn that is already in release may cause a use-after-free, see OS#3842 for a description. To be paranoid, upon releasing a conn, go through the transaction freeing motions again by calling trans_conn_closed(), just in case some odd code path added another transaction while the conn was already in release. Related: OS#3842 Change-Id: Id957032e0ae1ff8ba055a75c3523447d3d06cbc3
2019-02-28Don't deliver alert notifications to ESME not yet bound. Keith1-0/+5
We create a new ESME in smsc->esme_list on establishment of a TCP connection, yet we do not know the system id or anything else, until the ESME identifies and authenticates. So do not send alert notifications until we know the bind status (and system_id) Change-Id: Iec92d4c145ca050c2e212139572eeaae581b99df
2019-02-28libmsc/msc_vty.c: drop dead comparison against nullVadim Yanitskiy1-1/+1
Since vsub->sgs.mme_name is allocated statically, comparing it to null doesn't make sense - it's always != NULL. Change-Id: Ib2933a20471ebff9dfe1d9fdddf39d177504c951 Fixes: CID#178166 Array compared against 0 (NO_EFFECT)
2019-02-28libmsc/sgs_vty.c: always write server address and VLR nameVadim Yanitskiy2-6/+4
Comparing an array to null is not useful, because the expression will always evaluate as true. Let's just always write SGs server address and VLR name, no mater whether default values are used or not, same as we do for the HLR address and port. Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
2019-02-26libmsc/sgs_iface.c: fix SGS_STATE_NS11 counter referenceVadim Yanitskiy1-1/+1
The SGS_STATE_TS11 is not for counters, it's for timers! Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b Fixes: CID#190872 Out-of-bounds read (OVERRUN)
2019-02-26libmsc/ran_conn.c: add missing 'break' to OSMO_RAT_EUTRAN_SGSVadim Yanitskiy1-0/+1
Change-Id: I18dfd08ea0857f2751164a295dd9de20a2024ac3 Fixes: CID#190874
2019-02-25debian: depend on libdbd-sqlite3Oliver Smith1-1/+1
Make sure that we don't fail at startup with: <0009> db.c:621 Failed to create database connection to sqlite3 db 'sms.db'; Is the sqlite3 database driver for libdbi installed on this system? Tested by building the Debian package and looking at its depends. Related: OS#3771 Change-Id: I7c099212a6ad7d87978c3dce63ce7385d8076bd1
2019-02-20libmsc/gsm_09_11.c: implement guard timer for NCSS sessionsVadim Yanitskiy6-0/+90
It may happen that either the MS or an EUSE would become unresponsive during a call independent SS session, e.g. due to a bug, or a dropped message. In such cases, the corresponding transaction would remain unfreed forever. This change introduces a guard timer, that prevents keeping 'stalled' NCSS sessions forever. As soon as it expires, both sides (i.e. MS and EUSE) are getting notified, and the transaction is being released. By default, the timer expires after 30 seconds. As soon as either the MS, or an EUSE initiates any activity, the watchdog timer is rescheduled. The timeout value can be configured from the VTY: msc ... ! Use 0 to disable this timer ncss guard-timeout 30 Please note that changing the timeout value at run-time doesn't affect the existing NCSS sessions, excepting the case when the timer is disabled at run-time. This change makes TC_lu_and_ss_session_timeout pass. Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f Related: OS#3655
2019-02-18a_iface: Fix hexdumping of N-DATA.reqHarald Welte3-5/+5
For some reason the existing code was using msgb_hexdump_l2() while the L2 header is not used by the BSSAP transmit code. Let's fix this. Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
2019-02-18a_iface: use 'const' qualifier for ran_conn whenever possibleHarald Welte2-4/+4
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
2019-02-18a_iface: Centralize/wrap BSSAP / N-DATA transmissionHarald Welte4-11/+27
We don't want multiple callers to osmo_sccp_tx_data_msg() each having to hex-dump a log message about the to-be-transmitted message, with half of the caller sitest missing that printing. Let's centralize all calls of osmo_sccp_tx_data_msg() in a wrapper function which takes care of the related OSMO_ASSERT() and the related printing. Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
2019-02-15transaction.h: use #pragma once as include guardVadim Yanitskiy1-4/+1
Change-Id: I52787120d5ec59897329d28eab28e0fda3d0f44f
2019-02-15transaction: fix description of trans_assign_trans_id()Vadim Yanitskiy1-2/+2
Change-Id: I80238d89e95b6fd791961c48de80aac69ff5b0e9
2019-02-15transaction: clarify magic 0xff transaction IDMax4-4/+8
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
2019-02-15transaction: drop meaningless ti_flag of trans_assign_trans_id()Max5-14/+9
According to GSM 04.07, the TI flag takes one bit and can be either of the following: '0'B - transaction is allocated by sender of a message, '1'B - transaction is allocated by receiver of a message. Since we store transaction ID in gsm_trans structure, we also store TI flag (as a part of transaction ID), which in this context means: '0'B - transaction is allocated by us (OsmoMSC), '1'B - transaction is allocated by some MS. In 100% cases, trans_assign_trans_id() is used to assign transaction IDs to transactions allocated by us (i.e. OsmoMSC) for MT connections. And there is no need to use it for MO transactions, because they basically already do contain a valid transaction ID assigned by the MS. Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
2019-02-14libmsc/osmo_msc.c: move connection ref-counting code to 'ran_conn.c'Vadim Yanitskiy2-111/+111
The connection ref-counting implementation is specific to RAN connections, and is not applicable for anything else. Moreover, the API of this code is declared in 'ran_conn.h', so let's move the code to a more logical place. Change-Id: I593675d9bf56eaef12afdaf596ee1337b9a44259
2019-02-13libmsc/gsm_04_80.c: add msc_send_ussd_release_complete_cause()Vadim Yanitskiy2-0/+31
According to GSM 04.80, section 2.5.1, Release complete message may have an optional Cause IE. Let's add a new function, that allows to specify cause location and value. This function will be used by the upcoming changes. Change-Id: I3b9e8e4f473d113d5b9e9e5d33f7914202077203 Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13libmsc/gsm_04_80.c: use gsm0480_create_release_complete()Vadim Yanitskiy3-4/+8
The previous implementation of msc_send_ussd_release_complete() was based on gsm0480_create_ussd_release_complete(), that doesn't allow to specify GSM 04.07 transaction identifier. The ability to specify particular transaction identifier is required for handling multiple SS/USSD transactions. Change-Id: Id2975c3383f18e83124ba38927c03980d67ddadb Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-07a_iface: Include CSFB Indication into BSSMAP CLEAR COMMANDPhilipp Maier1-1/+6
When a call ends that has been established in an CSFB context, we should add a CSFB Indication IE to the BSSMAP CLEAR COMMAND to instruct the BSC to add further CSFB related IEs into the RR RELEASE. - Check if an SGs association exists and add CSFB Indication IE Change-Id: I6cfa4b3becdd0138d74e2e1eddd83a0b1568c1de Related: OS#3778
2019-02-06configure.ac: Check for libsctpHarald Welte1-0/+11
Since we merged the SGs interface, we include <netinet/sctp.h>, which is provided by libsctp. Change-Id: Id2321e4cb3800929cea56785e5c5bd7480408806
2019-02-06debian: depend on libsctp-devHarald Welte1-0/+1
Since we merged the SGs interface, we include <netinet/sctp.h>, which is provided by libsctp-dev. This means that the Debian package should depend on this. It is expected that this will un-break the network:osmocom:nightly builds. Change-Id: I092e95ea970763c4008d3c7ff1b7028042574a64
2019-02-05VLR tests: use msgb_eq_data_print() for comparisonMax1-11/+12
This simplifies tests refactoring by showing exact byte where mismatch happened. It also makes code more readable. No changes in expected test output are necessary because the additional logging will be triggered iff the test fails so the result will be visible only during debugging of unit test issues. Change-Id: If9771c973f2bc55580f4c146bdbeeb1609d56786
2019-02-04Add SGs InterfaceHarald Welte48-22/+2939
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support SMS tunneling and Circuit Switched Fallback (CSFB) Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d Related: OS#3615
2019-02-01libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()Vadim Yanitskiy2-5/+29
Initially, it was assumed that if there is no active RAN connection, we can just start counting from 0x00, as there are no other SMS related transactions, and transaction itself is allocated using talloc_zero(). Until now it was looking good, but... As soon as we establish RAN connection with subscriber, we already have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also remains 0x00 - it isn't being increased! It means that we can face a SM-RP-MR conflict (or collision) if another MT SMS would arrive to the MSC (from SMSC over GSUP) when this transaction is still active, i.e. the first SMS is still being sent, because conn->next_rp_ref++ would return 0x00 again. Moreover, there might be already a MO SMS transaction, and using the conn->next_rp_ref counter wouldn't prevent us from having duplicate SM-RP-MR value. Let's get rid of this per-connection counter, and introduce a function instead, that would iterate over existing transactions and look for an unused SM-RP-MR value. This change makes the following test cases pass: - TC_gsup_mt_sms_rp_mr, - TC_gsup_mo_mt_sms_rp_mr. Discovered by: Neels Hofmeyr Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120 Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01libmsc/gsm_04_11.c: also assign SM-RP-MR to MO transactionsVadim Yanitskiy1-0/+2
Previously, SM-RP Message Reference was assigned to MT transactions only, but not to MO transactions. As a result, this could lead to having a few transactions with duplicate SM-RP-MR value, because in case of MO SMS, trans->sms.sm_rp_mr would remain 0x00. Let's parse SM-RP-MR from MO SMS messages in gsm0411_rcv_sms(), and assign it to the new transaction after allocation. Change-Id: I4d07354175444f9764fb0dd6ea188a64494d79fe
2019-02-01transaction: change arguments of trans_find_by_sm_rp_mr()Vadim Yanitskiy3-6/+7
The need to pass a pointer to RAN connection in order to find a transaction limits possible use cases of trans_find_by_sm_rp_mr(), e.g. when we need to find a transaction, but RAN connection is not established yet. Moreover, the pointer to RAN connection was only used to obtain pointers to gsm_network and vlr_subscr, so we can just pass them directly. Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
2019-01-26libmsc/ran_conn.c: cosmetic: use tabs instead of N * 8 spacesVadim Yanitskiy1-1/+1
Change-Id: I09515aea9da8e2b5836c5c6409f094fae05633d4
2019-01-26transaction.c: cosmetic: use 'default' branch in trans_free()Vadim Yanitskiy1-1/+4
Change-Id: Ia28ba52b0ea4771843a2a1faa346f7357604b8aa
2019-01-24Various logging fixesMax3-5/+5
Log transaction allocation errors as such. While at it, use proper subsystem to log missing VLR subscriber. Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
2019-01-24Handle LCLS-NOTIFICATION message from BSSMax1-0/+25
Change-Id: Ibf5f9cad1f70aee56d5bca8fe09a24ca417e7a63 Related: OS#2487
2019-01-22Bump version: 1.3.0 → 1.3.11.3.1Harald Welte1-0/+7
Change-Id: I624144d6f8919d1dd237cdffc9122f685a8e4d6b
2019-01-22fix build: apply msgb_wrap_with_TL() renameNeels Hofmeyr1-1/+1
After libosmocore commit If1e851ac605c8d2fde3da565b0bd674ea6350c2e b27e6feb699712345373e87a48187dc622e4fa92 the osmo-msc master build is broken. Apply the msgb_wrap_with_TL() rename to msgb_push_tl() to unbreak the build. Change-Id: I1d4675e0c907b2f92f2ec79b02356391a6d72aa8
2019-01-21Bump version: 1.2.0.199-45df98-dirty → 1.3.01.3.0Harald Welte2-10/+240
Change-Id: I59d032ad953438f12439ac3d6275ee78d0ebbb40
2019-01-17vty: make 'sh connect/transact' readable againMax1-9/+24
After recent changes to vlr_subscr_name() result became variable-length which messes up old vty code. Fix this by moving it to the very end and adjusting headers as necessary. While at it, make sure we don't print headers if we have nothing else to show. Change-Id: Id06b4277ff790d95457d0cc2f94ef6bf5366bb21
2019-01-17Cosmetic: Fix spelling in smpp vtyKeith1-2/+2
Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
2019-01-17Make alert notifications vty configurable per ESMEKeith4-2/+35
Adds (no) alert-notifications as a per-esme vty command, in order to allow some ESMEs to be excluded from alerts. The default is still to send alert notifications to all esme, so no changes are required to the config file to maintain identical operation after this patch. Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17SMS: remove code duplication in transaction initMax1-24/+27
Move code which allocates transaction for SMS and initializes corresponding FSM into separate function (shared by MT and MO code paths) to avoid code duplication and simplify further modifications. Change-Id: I3563e11bebb58e656592df2ff7db96f41deaf735
2019-01-16MNCC: use explicit struct type in gsm_callMax1-1/+1
There's no need to use 'void *' because we have forward declaration for 'struct gsm_network' in the very same header. Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
2019-01-16Enable SMS-related log in VLR testsMax8-3/+590
The likely reason why it was disabled is due to paging_cb_mmsms_est_req() logging pointers which results in unstable log output. Fixing this allows us to track SMS-related regressions properly. Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-16VLR: send CHECK-IMEI to EIR/HLROliver Smith10-57/+918
When check-imei-req is enabled in the VTY config, do not accept IMEIs sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait for its ACK or NACK. OsmoHLR also accepts all IMEIs at this point, but this allows to optionally store the IMEI in the HLR DB. Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr) Related: OS#3733 Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
2019-01-14Fix trans_has_conn() doxygen descriptionMax1-1/+1
Change-Id: Ica5e498e03d0a157a661e428dfd68739f572d073
2019-01-12gsm_04_08: Fix nullpointer derefPhilipp Maier1-2/+5
The pointers conn, conn->vsub and conn->vsub->last_tuple are checked, but before the check those pointers are already dereferenced during assignment. This defeats the purpose of the check. Lets dereference those pointers after the check. Fixes: CID#190404 Change-Id: Ice4992606f3799eac13154ec0b9f53e46d2e178e
2019-01-12gsm_04_08_cc.c: drop non-sensible error messagegsmevent admin1-2/+0
Change-Id: Icbf099e418281eb908e7916503f178ab7ea26ffe
2019-01-12msc_vlr_tests: tweak logging in verbose modeNeels Hofmeyr1-2/+7
Change-Id: Ia06245f3adc6cf4c483d9c12c387cd5169582353
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 19:30:53 +0000