aboutsummaryrefslogtreecommitdiffstats
path: root/tests/test_nodes.vty
AgeCommit message (Collapse)AuthorFilesLines
2019-02-28libmsc/sgs_vty.c: always write server address and VLR nameVadim Yanitskiy1-0/+1
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-20libmsc/gsm_09_11.c: implement guard timer for NCSS sessionsVadim Yanitskiy1-0/+8
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-04Add SGs InterfaceHarald Welte1-0/+16
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-01-09msc_vty.c: make check-imei-rqd configurableOliver Smith1-0/+1
Related: OS#3189 Change-Id: Iee516b9cd7877b21207ce9a6d954109f19558163
2019-01-04vty cfg: move 'ipa-name' from 'msc' to 'hlr' sectionNeels Hofmeyr1-1/+1
during code review, I completely overlooked this: We've added the 'ipa-name', which identifies the MSC on the GSUP link to the HLR, under the 'msc' section, while all other GSUP/HLR related config is under the 'hlr' section. Before we roll that out in a release, move it over to 'hlr'. Related: OS#3355 Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
2018-12-30libmsc/VTY: introduce kill-switch for routing SMS over GSUPVadim Yanitskiy1-0/+2
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS processing, storage (in SQLite DB), and routing (via SMPP). In real networks this is done by the external entity called SMSC (SMS Centre), while the MSC is doing re-encapsulation of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU) between SM-RL (Relay Layer) and MAP. Since OsmoMSC itself is not a 'Network in The Box' anymore, it makes sense to replicate the 'traditional' behaviour of MSC. The problem is that this behaviour cannot co-exist with the current implementation, so the key idea is to rip out the local SMS storage and routing from OsmoMSC, and (re)implement it in a separate process (OsmoSMSC?). As a temporary solution, this change introduces a 'kill-switch' VTY option that enables routing of SMS messages over GSUP towards ESME (through VLR and HLR), but breaks the local storage and routing. This is why it's disabled by default. As soon as we move the SMS processing and storage away from OsmoMSC, this behaviour would be enabled by default, and the VTY option would be hidden and deprecated. At the moment, this option basically does nothing, and will take an effect in the follow-up changes. Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b Related: OS#3587
2018-12-20fix test_nodes.vty after libosmo-mgcp-client vty changesNeels Hofmeyr1-2/+0
osmo-mgw I98a9f1f17a1c4ab20cea3b08c7d21663592134d6 broke the build here. Fix that. Change-Id: I20e37c5228928b67e67f16aef0eb2930d21ef60a
2018-12-11make gsup ipa name configurable in osmo-msc.cfgStefan Sperling1-0/+1
Add a 'ipa-name' VTY command which overrides the default IPA name used by the MSC. This is a prerequisite for inter-MSC handover. Related: OS#3355 Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
2018-12-05add VTY commands: mncc internal / external (== -M)Neels Hofmeyr1-0/+25
So far the only way to use external MNCC is to pass the -M cmdline arg: osmo-msc -M /path/to/socket However, the osmo-msc.service file for systemd is installed by 'make install', and hence it is quite impractical to depend on such a config item to be required in the service file: - It defies any scheme an operator may have in place to compose the osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs separate action to add to the installed service file. - After a make install or package upgrades / re-installations, this option will be plain overwritten silently, or lead to the need for resolving file conflicts. The initial spark for this came from configuring the 35c3 GSM from cfg templates. Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
2018-12-05vty: mncc cfg: separate the 'mncc' from 'mncc-guard-timeout'Neels Hofmeyr1-2/+2
I want to add 'mncc internal' and 'mncc external' commands, and IMHO makes most sense to have a common 'mncc' keyword to start MNCC config commands with. To put it in terms of VTY online help: OsmoMSC(config-msc)# mncc ? internal Use internal MNCC handler external Use internal MNCC handler guard-timeout Set global guard timeout So far only the 'guard-timeout' exists, I want to add 'internal' and 'external' in a subsequent commit. Keep the old command 'mncc-guard-timeout' as deprecated alias. That means it still works from old config files, but online documentation will omit it. On 'write', write back the new format instead. Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee Change-Id: I52d69af48e1ddc87b3fb54bf66a01b1b8cbf5abe
2018-12-05add test_nodes.vty transcript testNeels Hofmeyr1-0/+101
It needs to work whether SMPP,Iu are enable or disabled, hence a bit more wildcarding than one might expect. Change-Id: I3a8c50d8d555b6b948d97d6412e17594ee439de0