aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-09-08fix crash for unknown MI during Paging Responseneels/1.6.2Neels Hofmeyr1-1/+6
Related: OS#4724 Related: I40496bbccbbd9c496cfa57df49e26f124a2b1554 (osmo-ttcn3-hacks) Change-Id: Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11
2020-01-09Bump version: 1.6.0.3-02dd2 → 1.6.11.6.1Pau Espin Pedrol1-0/+11
Change-Id: I3ac4ca12139230863607980cd29250c12df319b7
2020-01-06vlr.c: fix condition to check MSISDN presenceNeels Hofmeyr1-1/+1
msisdn_enc is a buffer, its address is always != 0 Change-Id: Ib2294d2cd339c36df599d7d134f979a572ac308a
2020-01-06vlr_gsup_rx: fix uninitialized rcNeels Hofmeyr1-1/+1
Change-Id: Id7776a473b8356d1d136d78736698f20accc7a36
2020-01-05libmsc/gsm_04_08.c: fix: verify MI before calling vlr_subscr_rx_id_resp()Vadim Yanitskiy2-0/+39
During the last congress, we have noticed that OsmoMSC crashes on receipt of malformed MM Identity Response messages: BSSAP Message Type: Direct Transfer (0x01) Data Link Connection Identifier 00.. .... = Control Channel: not further specified (0x0) ..00 0... = Spare: 0x0 .... .000 = SAPI: RR/MM/CC (0x0) Length: 11 GSM A-I/F DTAP - Identity Response Protocol Discriminator: Mobility Management messages (5) .... 0101 = Protocol discriminator: Mobility Management messages (0x5) 0000 .... = Skip Indicator: No indication of selected PLMN (0) 01.. .... = Sequence number: 1 ..01 1001 = DTAP Mobility Management Message Type: Identity Response (0x19) Mobile Identity - Format Unknown Length: 8 .... 1... = Odd/even indication: Odd number of identity digits .... .111 = Mobile Identity Type: Unknown (7) <-- This makes OsmoMSC crash [Expert Info (Warning/Protocol): Unknown format 7] [Unknown format 7] [Severity level: Warning] [Group: Protocol] The value '111'B is not a valid Mobile Identity type, and shall be considered as reserved according to 3GPP TS 24.008, section 10.5.1.4. Later on it was discovered that '000'B also crashes OsmoMSC in the same way. The crash itself is provoked by OSMO_ASSERT(0) in vlr_subscr_rx_id_resp(). Let's keep that assert in there, and make sure that: - on receipt of MM Identity Response, Mobile Identity type matches the one in MM Identity Request; - on receipt of RR Ciphering Mode Complete, Mobile Identity contains IMEI(SV) if present. Change-Id: Ica4c90b8eb4d90325313c6eb400fa4a6bc5df825 TTCN-3 test case: I62f23355eb91df2edf9dc837c928cb86b530b743 Fixes: OS#4340
2020-01-03Bump version: 1.5.0.72-6e72-dirty → 1.6.01.6.0Pau Espin Pedrol3-7/+101
Change-Id: I315ba8c67fbb5bec520f1bc42aedd25d47e4ca95
2019-12-19libmsc/gsm_04_11_gsup.c: fix SM-RP-OA encoding for MO SMS over GSUPVadim Yanitskiy1-6/+12
We shall not include additional BCD length octet into the value part of SM-RP-OA (Originating Address) IE. Instead, there should be ToA/NPI header (1 octet). Since we do not get ToN/NPI fields from the VLR/HLR, let's assume the following default values: 1... .... = Extension: No extension .001 .... = Type of number: International (1) .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1) Change-Id: I0f32e2af0ed2d2fea6addf45efbdfee120c2425d TTCN-3 test case: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9 Related: OS#4324
2019-12-19libmsc/gsm_04_11_gsup.c: do not init a buffer in gsm411_gsup_mo_fwd_sm_req()Vadim Yanitskiy1-1/+1
Because there is no real need for that. Change-Id: I19d4d0de0d5a46bf1de194b966f18ea8a84ced94
2019-12-12sms log tweakNeels Hofmeyr1-1/+1
Change-Id: I77e7a1501f74b9045f032c5b6c2322025a11fd59
2019-12-12sms db: when storing an SMS, retrieve the IDNeels Hofmeyr1-0/+3
seemed like a good idea, but not sure if we need it at all. Change-Id: I5fa55307a6abb8bbfe56619235d7b79fbbda6caf
2019-12-12osmoappdesc.py, tests: switch to python 3Oliver Smith4-60/+60
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 Hofmeyr22-146/+148
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-12-03msc: exit(2) on unsupported positional arguments on command lineHarald Welte1-0/+5
Change-Id: Iad858974e9d97ae14f3da6dc21267aafafcda0ef
2019-12-02libmsc: fix potential NULL-pointer dereferences detected by GCC's LTOVadim Yanitskiy2-1/+9
Change-Id: Ib7ba8909dce64d1b8ff3a53495fe3eefc446ed8e
2019-12-02counters: polish documentation of cm_service_request / paging_respVadim Yanitskiy2-8/+8
Change-Id: I273bc4165c70cd54ed94ff5f99377189f3306f51
2019-12-02counters: clarify documentation for MSC_CTR_CALL_* entriesVadim Yanitskiy2-14/+14
Change-Id: Iad1ef917a229c3be51bd8fbe155f009f81e7d72a
2019-12-02counters: clarify documentation for MSC_CTR_LOC_UPDATE_* entriesVadim Yanitskiy2-12/+12
Change-Id: I4f4a0d644db0a2dd7c8eefd846ea6913c0b780ce
2019-12-02counters: clarify documentation for MSC_CTR_SMS_* entriesVadim Yanitskiy2-13/+14
Please note that counter "sms:delivered" assumes "Delivered MT SMS", but actually counts total number MT SMS delivery attempts. This change describes its _actual_ (erroneous) behaviour. Change-Id: I081cf962ce2658ceab02699f3cdee19658d00939 Related: OS#4273
2019-12-01Check for osmo_fsm_register() error return valueHarald Welte2-2/+2
Change-Id: I4cce3d6798fe3184a3085d114b749b4645620978
2019-12-01manual: Fix copy+paste errorHarald Welte1-1/+1
Change-Id: I2c03d8424c218155dae9038dd7cc5660a290c5c8
2019-12-01check for osmo_ss7_init() error return valueHarald Welte1-1/+1
Change-Id: I2bc34f3962ca7355f20757e36a86ab2fd1a7aef6
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 Hofmeyr9-9/+189
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 Hofmeyr11-0/+1846
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-28fix incoming call while PagingNeels Hofmeyr1-10/+2
Do not free the CC transaction when an MT subscriber is already being Paged. Instead, invoke another paging request, which paging.c will correctly add to the list of pending paging response callbacks to run. A ttcn3 test is linked in the related patch (s.b.). Related: OS#4240 Related: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46 Change-Id: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
2019-11-28msc_a CC: add some basic sanity testsNeels Hofmeyr1-0/+10
Change-Id: I9d7d7d4073282abc6c02a6a297c807dc70c5154c
2019-11-28fail on invalid RTP address from MGWNeels Hofmeyr1-0/+6
When the CRCX OK returns an invalid RTP address, abort the call; fixes MSC_Tests.TC_invalid_mgcp_crash. The original crash happened when adding this error handling without this commit I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require new fsm deferred dealloc, check for term"). With this error handling added, even though avoiding a crash, the test does not pass yet, because instead of rejecting the call, it currently composes an Assignment Command without a Transport Layer Address. Fix that. Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
2019-11-19Fix some typosMartin Hauke27-50/+50
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-05BSSMAP: decode Codec List (BSS Supported)Neels Hofmeyr2-0/+32
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete Layer 3 Information and the Assignment Complete messages. An upcoming patch improves codec negotiation and requires the BSS supported codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great lengths to compose those IEs). Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
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-11-05cc trans: remove unused tch_rtp_createNeels Hofmeyr2-18/+0
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover support, I forgot to remove it. Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
2019-11-01charts: add full MO and MT voice call diagramNeels Hofmeyr2-1/+126
Add voice_call_full.msc, generated from a real 2G<->3G voice call log fed to msc_log_to_ladder.py. The idea is to document how the voice call sequence of events changes in upcoming patches. Change-Id: I8a907d6a4ece1f3ad78da75a8c3e3e76afd5418d
2019-11-01add msc_log_to_ladder.pyNeels Hofmeyr1-0/+724
Add script that reads in an osmo-msc log output and extracts the interesting information for displaying a sequence chart of voice call log, in mscgen format. I want to visualize how the sequence of messages changes across patches. It is error prone to do it manually, and re-doing the sequence chart for every patch (and patch rework) would be prohibitively time consuming. Change-Id: I2e4d8778f7b83dee558517a9b23450b817ee325d
2019-11-01CC: add error handling for CRCX responsesNeels Hofmeyr1-3/+3
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the MGW providing (or failing to provide) an RTP port for the RAN side. From an earlier stage of the code, the cleanup for this situation was extremely complex, and hence the choice was to simply wait for the call to time out and fail. But since we have implemented safe deallocation of nested FSMs in libosmocore, the situation has become rather trivial: simply free the CC transactions, and all the rest will immediately release, and terminate correctly without crashing. A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP message ends up causing a failure in the on_success() branch of mgcp_client_endpoint_fsm.c. Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
2019-11-01use osmo_sockaddr_str_is_nonzero()Neels Hofmeyr6-19/+19
Also regard an RTP port as invalid if the IP address is 0.0.0.0. Achieve this by using osmo_sockaddr_str_is_nonzero() instead of osmo_sockaddr_str_is_set(). Depends: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550 (libosmocore) Change-Id: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd
2019-11-01rtp_stream: sanely cancel MGW endpoint FSM notifyNeels Hofmeyr1-0/+1
libosmo-mgcp-client recently introduced osmo_mgcpc_ep_cancel_notify() to cancel notification if a notify target FSM deallocates. Use it for sanity in rtp_stream FSM cleanup, the notify target for endpoint FSMs. Depends: I41687d7f3a808587ab7f7520f46dcc3c29cff92d (osmo-mgw) I14f7a46031327fb2b2047b998eae6ad0bb7324ad (osmo-mgw) Change-Id: I351bb8e8fbc46eb629bcd599f6453e2c84c15015
2019-11-01fsm: use deferred deallocationNeels Hofmeyr1-2/+2
Since osmo-bsc uses the MGCP client FSMs, it is required to enable this new feature to guarantee safe operation. The issue is described in detail in commit logs linked below. Notably, osmo-msc currently chooses to omit error handling during MGCP events (marked "FIXME"). An upcoming patch implements this error handling, and would make osmo-msc vulnerable to crash from unexpected MGCP messages without this. Deferred FSM deallocation is a more general, simpler approach to osmo_fsm_term_safely(), so we can switch that off now. Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore), I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore) Related: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 (osmo-mgw) Change-Id: I08c03946605aa12e0a5ce8b3c773704ef5327a7a
2019-10-29send MNCC REL only if MNCC has actually startedNeels Hofmeyr2-3/+9
Change-Id: I07b2b6c0ee33f5d3e0a060c10cf36d5c7c9f0d9b
2019-10-29log: ran_msg_a: tweak a message nameNeels Hofmeyr1-1/+1
Change-Id: I691025cb957e9b87c8af2dc8eb741dcba6ca26e2
2019-10-29log: RANAP encode: use RANAP message names instead of BSSAPNeels Hofmeyr1-2/+5
Change-Id: Ib0e0630d775a28958ea86802f70cbeec07087f91
2019-10-29BSSMAP log tweakNeels Hofmeyr1-1/+1
Before: RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3 After: RAN decode: BSSMAP: COMPLETE LAYER 3 This caught my attention while I was writing up a script to parse osmo-msc logging to produce ladder diagrams. Change-Id: I387dde8f2eb3edb35d22ce52dc0ed580978dea36
2019-10-29also log MNCC_SETUP_REQNeels Hofmeyr2-0/+5
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 Smith2-6/+14
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: drop duplicate MNCC logNeels Hofmeyr1-2/+0
Change-Id: I46055a4f7a6ae517772c6794faad8c775454974a
2019-10-21log which DTAP messages are sent to RANNeels Hofmeyr10-2/+89
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 Hofmeyr3-146/+164
For all CC type transaction logging, log the current trans->cc.state string for all LOG_TRANS*() logging. Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
2019-10-17vlr_auth_fsm: on SAI use the GSUP provided GMM cause codeAlexander 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-23 19:32:43 +0000