Throughout osmo-hlr's code, the GSUP msgb allocation is duplicated as:
msgb_alloc_headroom(1024+16, 16, "foo");
Instead, use one common function to keep the magic numbers in one place.
Change-Id: I40e99b5bc4fd8f750da7643c03b2119ac3bfd95e
Apply the same headers structure that we keep in most Osmocom source trees:
Keep noinst_HEADERS in include/osmocom/hlr and include them using
#include <osmocom/hlr/*.h>
The only header kept in src/ is db_bootstrap.h, because it is generated during
build time. If it was built in include/osmocom/hlr, we would need db.o to
depend on db_bootstrap.h in a different subdir, which automake can't do well.
Change-Id: Ic912fe27f545b85443c5fb713d8c3c8aac23c9ad
The SS payload is mandatory for GSUP PROC_SS_{REQ,RSP} messages
with session state BEGIN or CONTINUE, and optional for the END.
Make sure that it's present for both BEGIN and CONTINUE, consider
received message as incorrect otherwise. In case of the END, call
handle_ussd() / handle_ss() only if SS payload is present.
Change-Id: Ia71cabbf396bd1388e764a1749e953ac1782e307
Fixes: CID#188841
We have nothing to do with GSM 04.80 at the HLR - it's only used to
encapsulate the SS payload between MS and MSC. This is not that
critical, but may be misleading.
Also, gsm0480_msgb_alloc_name() allocates a smaller buffer:
return msgb_alloc_headroom(1024, 128, name);
than osmo_gsup_client_msgb_alloc() does:
return msgb_alloc_headroom(4000, 64, __func__);
Change-Id: Icdab40c6a933888eb9f51bee9c5264c8919dbf7b
Save the source IPA name in ss_session, so we can send "invalid IMSI"
messages to the originating MSC.
Remove the fixed size from ss->vlr_number (we don't know the size of the
IPA name when it does not come from the database). Add
ss->vlr_number_len to give osmo_gsup_addr_send() the format it expects,
and to have one less place in the code where the IPA names are not
stored as blob.
Looking up the IPA name from struct osmo_gsup_conn could either be done
like in osmo_gsup_server_ccm_cb() by reading the IPA IEs (which has a
FIXME comment), or by finding the route associated with conn. I went
with the latter approach, because it seems cleaner to me.
Related: OS#3710
Change-Id: If5a65f471672949192061c5fe396603611123bc1
hlr_ussd.c so far hardcoded osmo-msc's default IPA-name and hence was
only able to negotiate USSD sessions to
- a single osmo-msc
- that has no custom IPA-name set.
Fix: correctly route USSD to any number of MSC with any custom IPA
names.
Resolve the right MSC's IPA name from the USSD session's IMSI, using
hlr_subscriber->vlr_number to determine the right GSUP peer. Cache it in
ss_session->vlr_number to have at most one db hit for routing per
session.
Related: OS#3710
Change-Id: I18067bfadd33a6bc59a9ee336b6937313826fce3
It may happen that either the MS or an ESME would become
unresponsive, e.g. due to a bug, or a dropped message. This
is why we have SS session timeout, that prevents keeping
'stalled' sessions forever.
For some reason, it wasn't properly resceduled in case of
subsequent SS/USSD activity, so the lifetime of a session
was limited. Let's properly (re)schedule it.
Change-Id: I11aeacf012b06d3d0b5cc6e64baecf857b645fda
Related: OS#3717
It may happen that either the MS or an ESME would become
unresponsive, e.g. due to a bug, or a dropped message.
This is why we have SS session timeout, that prevents
keeping 'stalled' sessions forever.
Let's introduce a VTY option, which can be used to configure
this timer (by default it's set to 30 seconds):
hlr
...
! Use 0 to disable this timer
ncss-guard-timeout 30
Change-Id: I971fc2cee6fd46d4d5d6dac6c634e0b22fff183d
Related: OS#3717
At the moment, all available IUSE handlers do assume a single
request-response operation, e.g. MS requests its MSISDN - IUSE
responds. No further nor intermediate communications is required.
Let's immediately terminate such SS sessions in order to avoid
waiting for the session inactivity watchdog (i.e. timeout).
Change-Id: Iaefe37512da79e10fbe92378236bfff0eae0f8b9
As we don't store any SS related information (e.g. call forwarding
preferences) in the database, we don't handle 'structured' SS
requests at all. Let's reject them by sending error message
with FACILITY_NOT_SUPPORTED code.
Change-Id: Ia1317c5d372a42473cce65c0c985103e43be77fd
Related: OS#3651
Before this patch, the default route logic was not implemented. The
user could specify a default-route, but it wouldn't be used by the
actual routing logic. Let's fix that.
Change-Id: I0b04a75dc297f088f13da413d08c52e0747e46e6
According to GSM TS 03.38, section 6.1.2.1, CR symbol at the end
is optional, and moreover libosmogsm encoding API will carry
about the bit padding itself.
Change-Id: I09e8a67758698f3b7a578eab956311e269d091ee
We need to distinguish between both EUSE and IUSE, and properly
print their names. Otherwise, garbage is printed in case of IUSE.
Change-Id: I497e7c1fe41279afdb1256ee69e166066a6462bb
There are some requests that are best served inside the HLR, as it
has access to subscriber information such as MSISDN and IMSI.
This unfortunately required quite some restructuring of the USSD
related structures including the VTY syntax for adding routes.
The default config file has been updated to replicate the *#100#
built-in behavior of old OsmoNITB.
Closes: OS#2566
Change-Id: I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9
We don't want any SS session to run for more than 30s. The timeout
is currently not refreshed.
If we need more comprehensive timeout handling, using osmo_fsm for SS
sessions might make sense.
Change-Id: I5c9fb6b619402d2a23fea9db99590143d85ac11a
Neels Hofmeyr
Oliver Smith
Harald Welte