aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2017-08-15LIBMSC: Use sms->text, not sms->user_data to construct report bodyKeith1-1/+1
gsm_04_11.c sms_report_alloc() Use the sms->text, not the sms->user_data to construct the report body. This also prevents the potential output of non printable characters to the log and or vty. Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
2017-08-15LIBMSC: Place correct dst address in status reportKeith1-1/+1
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu() When we construct the status report PDU, use sms->src instead of sms->dst as the destination address This way we tell the MS that the message was delivered to the destination and not to itself. This is relevant for phones that display a textual representation of the delivery report. Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
2017-08-15libmsc: use SMPP34_DELIVERY_RECEIPT_* in libsmpp34Pablo Neira Ayuso1-7/+1
Use new definitions in libsmpp34 to set the registered_delivery field accordingly, as provided by I5b3afff1b3b77cccd949e0606914c7ac3ba6114c. Moreover, do not set this header field to zero if status reports are off, the deliver_t structure has been already zeroed so this not required. Change-Id: Ie78e17323796120f576b9c0e1bc5ccc32da8ee12
2017-08-14increase libsmpp34 version requirement to 1.12Harald Welte1-1/+1
Only 1.12 contains some of the #defines that we're using with recent commits. Change-Id: I3743b10a1a5d2f1d42a61204273c1d00dc22b600
2017-08-14Migrate from gprs_apn_to_str() to libosmocore osmo_apn_to_str()Harald Welte11-148/+19
In 2015, Jacob moved/copied related functions to libosmocore, but for some reason didn't remove the copies here. Let's follow-up on that and remove duplicated code. The libosmocore commit introducing osmo_apn_to_str() was 8114294bf29ac6e44822c0ae43d4b0819f11b022 Change-Id: I7315ffcbed8a54cca2056f313bb7783ad82d0ee9
2017-08-14sgsn_vty: Don't assume pdp->lib is always validHarald Welte1-14/+16
We can only print libgtp pdp information if a library context is attached to this pdp context. This is not always the case, particuarly during some teardown scenarios. Change-Id: Ia3184877f9709db65f5f93a98403f2ef5b04a8ca
2017-08-14Fix gsm_pchan2chan_nr() to use RSL_CHAN_OSMO_PDCHHarald Welte2-2/+5
When converting from GSM_PCHAN_PDCH, we should generate a RSL channel number IE with the osmocom extension RSL_CHAN_OSMO_PDCH rather than claiming it is a regular TCH/F channel. This is important as this function is used by osmo-bts, too - and it decides which channel number IE is put in the GSMTAP header for both GSMTAP tracing as well as the GSMTAP based osmo-bts-virtual. In order to avoid any unintended effect on libbsc, we make sure to modify rsl_ipacc_pdch_activate() to always use GSM_PCHAN_TCH_F in related RSL message. Change-Id: Ie34219e64a6d89da4a79f2db8ec73d1909fb8280
2017-08-14SGSN: Fix RAN information exposed on GTP during PDP CTX CREATEHarald Welte1-4/+14
In the PDP Context Create from SGSN to GGSN, we include information about the RAN type (GERAN/UTRAN) and the Cell of the MS. This was all hard-coded to GERAN, and wasn't updated when we added UTRAN support to the SGSN. Change-Id: I6c79e42c5e08b28fe8182555302a5505fbbaa313
2017-08-14mgcp: Fix uplink activation of Osmux streamPau Espin Pedrol1-2/+4
Commit 575420637981828b64c1292ada015d7170b89390 introduced OSMUX_STATE_NEGOTIATING to fix a race condition present in osmo-bsc_nat. However, after this change osmo-bsc_mgcp cannot switch to OSMUX_STATE_ACTIVATING anymore, which means during osmux_send_dummy time it won't call osmux_enable_endpoint(), which in turn won't set endp type to MGCP_OSMUX_BSC. If MGCP_OSMUX_BSC is not set, uplink streams are sent using regular RTP instead of Osmux not matter it is enabled in config or not. Change-Id: Ibcb59aa1ca25408f82cc88c2d5b81177b5f276dc
2017-08-13handover_logic: set correct link to bts for subscriber_connection in case of ↵Ivan Kluchnikov1-0/+1
moving this connection to another bts In case of successful completion of handover gsm_subscriber_connection could be moved from one bts to another, so connection link to bts should be replaced by link to bts, which owns new_lchan. This bug was detected, because conn->bts->nr is used in call control log messages and wrong number of bts was observed in these messages after handover. Change-Id: Idc7dd412b7580c451e716b73ef7549826c60b0d9
2017-08-13mgcp_osmux: Remove unused parameterPau Espin Pedrol2-8/+4
Change-Id: Icb1e7cb15fe04642578f5292124ebc1eac9c9aa3
2017-08-13libcommon: Fix log output for bts>0.Alexander Chemeris6-10/+44
Fixes regression probably introduced in c696cc28. For bts>0 logging doesn't show bts number correctly when printing lchan identification string - it will always show it as "bts=0". The reason for this is that the identification string is cached before bts->nr value is set to a proper value. This patch sets bts->nr as part of the first step of the bts structure initialization, before caching happens thus making sure the cached identification string is cached with the correct values. Change-Id: I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
2017-08-13libmsc: use new smpp34 esm_class definitionsPablo Neira Ayuso1-10/+8
Replace magic numbers by esm_class definitions, which have been added to latest libsmpp34 in Change-Id I91afd8b462b8fd3b2c4c5b54f4eeb7ec5b730b65 Change-Id: I6c458690da60c8f3637680efbd718f6e8c6feb4c
2017-08-12libmsc: use smpp34_tlv_for_each() to avoid suboptimal TLV handlingPablo Neira Ayuso1-30/+40
submit_to_sms() now handles two TLVs, so find_tlv() is suboptiomal and it can be removed, since it would result in two passes on the TLV list. Use new smpp34_tlv_for_each() helper to iterate over the list of TLVs that is available since I446929feed049d0411e1629ca263e2bc41f714cc. Change-Id: I53a65164a6cc4abc6bf57d9a8dc275cf21c90222
2017-08-10libmsc: Remove comment not applying anymorePau Espin Pedrol1-1/+0
The change-id I7276d356d805a83ebeec72b02c8563b7135ea0b6 added msg_ref to the databse but forgot to remove the comment stating it's not being stored. Change-Id: I204f098c8f2a480405446113e2181b2c53700cf3
2017-08-10libmsc: gsm340_gen_oa_sub() may return negative valuePablo Neira Ayuso1-2/+9
gsm340_gen_oa() returns a negative value if the output buffer that the caller passes is too small, so we have to check the return value of this function. Fixes: CID 174178 Fixes: CID 174179 Change-Id: I47215d7d89771730a7f84efa8aeeb187a0911fdb
2017-08-09libmsc: support GSM 03.40 status report for nitbPablo Neira Ayuso1-0/+5
This patch adds support for GSM 03.40 in nitb mode. MS GSM 03.40 SMSC | | | SMS-SUBMIT | |--------------------------->| | GSM 04.11 RP-ACK | |<---------------------------| | SMS-DELIVER | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | SMS-STATUS-REPORT | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | | Change-Id: I5cc7bb4ebadde0940f44d10c3df34707b0615160
2017-08-09libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status reportPablo Neira Ayuso2-2/+54
This patch adds gsm340_sms_send_status_report_tpdu() to build a status-report. Moreover, set sms->report field if we see a SMPP SUBMIT_SM with Delivery Acknowledgment esm_class, so this identifies that this is a delivery report. MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | | SUBMIT-SM | | | esm_class = Delivery Ack | | |<-------------------------------| | | SUBMIT-SM-RESP | | |------------------------------->| | | | | SMS-STATUS-REPORT | | |<----------------------------| | | GSM 04.11 RP-ACK | | |---------------------------->| | | | | There is a FIXME message in this patch, that I just copied from gsm340_gen_sms_deliver_tpdu() since TP-MMS is not supported by OpenBSC. Change-Id: Ib70e534840308ed315f7add440351e649de3f907
2017-08-09utils: smpp_mirror: bounce Delivery Receipts as Delivery AcknowledgmentsPablo Neira Ayuso1-9/+8
Simple patch to test the new status-report support code, remove previous code before Delivery Acknowledgement support was in place. Use LOGL_DEBUG for logging messages here as suggested by Neels and Harald. Change-Id: I877e228d8e174430f700631edbf9955972da7892
2017-08-09libmsc: update database to accomodate SMS status-report fieldsPablo Neira Ayuso2-6/+163
SMPP DELIVER_SM messages with esm_class = Delivery Receipt need to send this message reference (that the mobile phone allocates) to the ESME. Thus, the ESME propagates it via SUBMIT_SM with esm_class = Delivery Acknoledgment so that the SMSC sends the GSM 03.40 status-report to the origin including this. Given this field is useful for status-reports, we need to store it in the HLR database. Moreover, we need a new field that specifies if the entry represents a SMS status-report, to do the right handling from the gsm411_send_sms() - such new handling comes in a follow up patch entitled "libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report". This patch includes the migration routines to the new database schema revision 5, it's quite a bit of dbi boilerplate code - copied-pasted and adapted. Change-Id: I7276d356d805a83ebeec72b02c8563b7135ea0b6
2017-08-09libmsc: add support for SMPP delivery receiptsPablo Neira Ayuso4-1/+76
If the mobile phone requests a status report via SMS, send a DELIVER_SM with esm_class = Delivery Receipt to ESME to indicate that the SMS has been already delivered to its destination. MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-DELIVER | | |<----------------------------| | | GSM 04.11 RP-ACK | | |---------------------------->| | | | DELIVER-SM | | | esm_class = Delivery Receipt | | |------------------------------->| | | DELIVER-SM-RESP | | |<-------------------------------| | | | This patch implements "Appendix B. Delivery Receipt Format" as specified in the SMPP 3.4 specs. This string is conveyed in the SMS message as data, and it is only meaningful to the ESME, for logging purposes. The "submit date" and "done date" are not yet set, and other fields are just sent with dummy values, so they are left to be finished as future work. The new SMPP TLV tag TLVID_user_message_reference is added to the SMPP messages inconditionally now since this information is required by delivery-reports to associate the status-report with the original SMS. Change-Id: Ic1a9023074bfa938099377980b6aff9b262fab2a
2017-08-09utils: smpp_mirror: reflect message reference TLVPablo Neira Ayuso1-1/+23
Useful to test the delivery receipt support. This TLV contains the GSM03.40 message reference. Change-Id: I1b0abaa7e06ffe1bd2242c70813d8b70e9fa954f
2017-08-09utils: smpp_mirror: temporarily munch SMPP delivery receiptsPablo Neira Ayuso1-0/+8
Just munch and log SMPP delivery receipts by now, don't mirror this, it is going to break things in openbsc. Follow up patch removes this and mirrors this SMPP message as a SUBMIT_SM with esm_class = Delivery Acknowledgement. Change-Id: I78e93bc4034679e238c8642ccf6a0e844b1d6d8b
2017-08-09utils: smpp_mirror: set registered_delivery field in SMPP SUBMIT_SMPablo Neira Ayuso1-0/+1
To test delivery reports using this utility. Change-Id: I0e477407531fdd4d906e53c9b5a48a79a239966f
2017-08-09libmsc: missing bit shift in status report flag when stored in sms objectPablo Neira Ayuso1-1/+1
So we just store 0 or 1 depending on what the mobile phone requests. Change-Id: Idb7d5594219c0e458ccb561383a59604bc1a4201
2017-08-09libmsc: report status report request flag from SMPP SUBMIT_SMPablo Neira Ayuso1-0/+1
Restore the sms status report request flag from SUBMIT_SM. Change-Id: Iac05252253f8933a3875b4904599b7a225191a4b
2017-08-09libmsc: set registered_delivery field in SMPP 3.4 DELIVER_SM messagesPablo Neira Ayuso1-1/+8
Propagate the status report request field to the SMPP message through the registered_delivery field, so the ESME knows that the mobile phone is asking for explicit delivery acknowledgment is required. See SMPP 3.4 specs section 5.2.17. Change-Id: I59af60fa89cd10ae973c5e122789e3e03e3728ee
2017-08-09timer vty: also print the default value in cmd docNeels Hofmeyr1-13/+13
Rationale: allows seeing all timer defaults at once by doing OsmoBSC(config-net)# timer ? Before, defaults are visible only by doing on each timer: OsmoBSC(config-net)# timer t1234 <tab> Change-Id: I8259234e5c62e058dde56d531071440bbab11462
2017-08-09vty: add 'default' keyword to timer configNeels Hofmeyr1-3/+14
Change-Id: I4e837e8bedfad7ac4fd50048ecb016ddb37c2397
2017-08-09cosmetic: vty for timers: remove obsolete range checkNeels Hofmeyr1-6/+0
The VTY parsing already ensures the parameter range being 1..65535, no need to check the range again. Change-Id: I1cffa5b01cd5c589f1e42998e32135f1da8c960b
2017-08-08libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms()Pablo Neira Ayuso1-19/+22
Move the sms message-type-identifier (mti) handling away from the routing logic. This patch allows us to reuse the sms_route_mt_sms() function in a follow up patch for sms reports send through SMPP DELIVER_SM with esm_class = Delivery Receipt whose Change-Id is Ic1a9023074bfa938099377980b6aff9b262fab2a. Change-Id: I3f3d30e0762b91e2099243b0be1a4b67cbb5e9c0
2017-08-08libmsc: remove 'deferred' parameter in sms_route_mt_sms()Pablo Neira Ayuso3-30/+24
No need to cache the sms object, just cache what we need into the smpp_cmd structure. This simplifies what that I introduced in 93ffbd0029d1 ("libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP"). Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
2017-08-08libmsc: remove duplicate lines in deliver_to_esme()Pablo Neira Ayuso1-2/+0
This code is accidentally doing the same thing twice, remove it. Change-Id: I68087a850399e22951d2407e4d8a09c671a775c9
2017-08-08libmsc: remove dead code in sms_route_mt_sms()Pablo Neira Ayuso1-3/+0
The following branch: if (!rc && !gsms->receiver) rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; at the end of sms_route_mt_sms() always evaluates false. Just a bit before, in such function, we have this: if (!gsms->receiver) { ... #ifdef BUILD_SMPP ... #else ... #endif return rc; } So, if there is no receiver, we just stop running code and return the RP cause via the rc variable. Same applies to the smpp_first check under the BUILD_SMPP ifdef (that I have removed in this snippet to keep this commit message small). Change-Id: Ic3502b5b169bc7a73a67fd6ff53d8b6c0dc045c8
2017-08-08libmsc: do not leak pending SMPP command object on error pathPablo Neira Ayuso1-5/+6
Make sure the SMPP command object is released on errors. Change-Id: I474584425d23fb379a9d71b33e29ac0e24f01e61
2017-08-08gsm_04_11: get rid of unused parameter in sms_route_mt_sms()Pablo Neira Ayuso1-5/+6
This parameter is unused, remove it. Change-Id: I797abce3f91447e8f397c7cf726db7425479fe0e
2017-07-21sgsn: Convert cch_pdp to host order for libgtpHolger Hans Peter Freyther1-5/+2
libgtp is calling gtpie_tv2 which will convert this uint16_t from host to network order. So far libosmogsm and the sgsn treated the charging characteristics as opaque data. So when moving from byte array to the uint16_t do the swapping. Change-Id: I977aec2e2f8d57802e45f591754e5733562d5c2a
2017-07-20remove code disabling T3109 if configured to 0Harald Welte1-4/+0
We no longer permit timers with a 0 value, so this case can never happen. Also, if it should happen, I'd rather have a timter expiring immediately (and breaking something) than not being started in the first place. Change-Id: Ibfcdd3ddc0155caee89c501498329bde247621a0
2017-07-20bsc_vty: Don't allow timers of zero (0)Harald Welte1-2/+2
It typically doesn't make sense to configure any of the GSM RR timer to 0 (Seconds). In fact, accidentially configuring any of the timers to zero might have severe side effects, such as "stuck channels" described in https://osmocom.org/issues/2380 Change-Id: I517828f2f0c80ec01cb63648db2626f17a67fe57
2017-07-20GSM timers: User reasonable defaults; don't save if equal defaultHarald Welte13-91/+35
A number of the GSM timers (including T3109) had no reasonable default values if not specified in the VTY / config file. Together with unconditional writing to the config file, this created config files with a persistent setting for important timers as '0'. To make things worse, many of our example cofig files suffered from the same problem. Let's avoid this from happening by * having reasonable defaults if nothing specified in the config file * conditionally savingg timers only if they differ from default * reject any timer values that state zero during start-up (see previous commit) Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8 Closes: OS#2380
2017-07-19bsc_vty: Add VTY command to test CTRL TRAP featureHarald Welte1-0/+16
Using this new command (introduced in OsmoBSC + OsmoNITB), you can simulate the generation of TRAP events for testin purposes. start the control interface monitor as an example client program: ./openbsc/contrib/bsc_control.py -m -d localhost -p 4249 then start OsmoBSC or OsmoNITB, telnet to the VTY and enter 'enable' mode and issue the following (example) command: ctrl-interface generate-trap my.foo.var 2342 As a result, on the bsc_control.py you will see: Got message: TRAP 0 my.foo.var 2342 Change-Id: Ib1d2ec38290dc94797c1b365d9b733e5215ab7d1
2017-07-18gtphob: check for missing result of rate_ctr_group_alloc()Harald Welte1-0/+4
In case the counter group allocation fails, we must handle this gracefully and fail the allocation of the parent object, too. The recent change (Id I7dad4a4d52fe05f6b990359841b4408df5990e21) seems to have missed one instance, so let's follow-up. Change-Id: I1ee9e3d26dcc18e7f979fd9a786162cbcc50942c Related: OS#2361
2017-07-16gsm_bts_trx_set_system_infos(): Disable non-existing SIHarald Welte1-6/+17
If we previously had a given SI present/active, we must send a zero-length BCCH FILLING for that SI type to the BTS to stop it from further transmitting this SI. Change-Id: I33e356e2fa3a69efac9080813e3e9ef4e6438ed1 Closes: OS#2368
2017-07-15RSL: Allow disabling of BCCH/SACCH filling for given SI typeHarald Welte1-4/+8
If we want to instruct the BTS to stop sending a given SI, we must be able to send the respective BCCH INFO / SACCH FILLING with a header but without any L3 data IE. This patch enables the related functions to do this whenever their data argument points to NULL. Change-Id: I88b85614951a108574f05db3b706884afe7e87a9
2017-07-15Fix regression causing loss of static system-information messagesHarald Welte1-2/+2
In commit 8b1a2f8cd7a81c6b8c7cdb0963dcf89de7c46100 we started to initialize bts->si_valid to 0. This means we are skipping the manually configured static system information. Instead, we have to initialize bts->si_valid to bts->si_mode_static, i.e. start with those that are static and not to be auto-generated. Found while developing http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo Change-Id: Iab9cc93cf6d54560a72cc393cc3721a8d10e04bf Closes: #2367
2017-07-12check for missing result of rate_ctr_group_alloc()Harald Welte5-0/+32
In case the counter group allocation fails, we must handle this gracefully and fail the allocation of the parent object, too. RelateD: OS#2361 Change-Id: I7dad4a4d52fe05f6b990359841b4408df5990e21
2017-07-11libbsc: Add VTY command to re-send the SYSTEM INFORMATION to BTSHarald Welte1-0/+33
This is useful if you are updating some configuration parameters which affect the content of the SYSTEM INFORMATION messages. Currently, we only send them at the time the RSL connection is established (i.e. when the BTS is initialized), so if you change something, you need to bring down and re-start the BTS. Using the newly-introduced "bts <0-255> resend-system-information" command, you can re-generate + re-send SYSTEM INFORMATION without bringing the BTS down, i.e. without any radio carrier downtime. Change-Id: I326df47de98f6d36c9a4d2d5475225d1e62bafb5
2017-07-11bsc_api: Fix copy+paste error in printing name of RR STATUS PDUHarald Welte1-1/+1
Change-Id: I0ef78ef046e4850346569f750693e12938b50ab5
2017-07-11transaction: reject calls from unidentified subscribersBenoit Bolsee1-0/+7
A valid subscriber is indespensible when allocating a new transaction. Return NULL if no subscriber is supplied. This will cause unidentified subscribers to be rejected. Note: Under normal conditions, the problem does not occour, but it is still possible that a misbehaving MS might trigger the problem by sending a SETUP command before authenticating the subscriber. (unencrypted networks) Change-Id: Ia8739b6e329ab02c0064270d02ad1d6ee245520d
2017-07-10Fix BTS attribute requestsMax2-3/+10
* fix BTS numbers: use 0 to indicate given BTS and 0xFF to indicate all BTS' as it's explained in 3GPP TS 52.021 §9.3. * only request attributes from supported (OsmoBTS) types Change-Id: I8f43055c38000248033a8ff9ddaf0910d68d794b Related: OS#2317