At the user-visible level (advanced settings menus on phones,
GSM 07.05 AT commands, SIM programming) each SMSC is identified
by a numeric address that looks like a phone number, originally
meant to be a Global Title. OsmoMSC passes these SMSC addresses
through as-is to MO-forwardSM.req GSUP message - however, SMSCs
that connect to OsmoHLR via GSUP identify themselves by their
IPA names instead. Hence we need a mapping mechanism in OsmoHLR
config.
To accommodate different styles of network design ranging from
strict recreation of classic GSM architecture to guest roaming
arrangements, a two-level configuration is implemented, modeled
after EUSE/USSD configuration: first one defines which SMSCs exist
as entities, identified only by their IPA names, and then one
defines which numeric SMSC address (in SM-RP-DA) should go to which
configured SMSC, with the additional possibility of a default route.
Related: OS#6135
Change-Id: I1624dcd9d22b4efca965ccdd1c74f0063a94a33c
Previously the HLR sent in the Insert Subscriber Data call only the
wildcard APN as a single entry.
This violates the spec because the first entry (with the lowest context_id) is
always the default APN, but it is forbidden to have a wildcard APN as default apn.
Introduce a default template/profile which can contain multiple APNs.
This profile is always sent out to the SGSN/MME as part of Insert-Subscriber-Data.
In the future a subscriber might have a profile template name written into the
database which will resolve to a "pdp-profile premium" in the configuration.
To be backward compatible, if the pdp-profile default section is missing,
the HLR will send out only a wildcard APN.
Config example:
hlr
ps
pdp-profile default
profile 1
apn internet
profile 2
apn *
Changes to the apn list will be only handed out to subscribers
when the subscriber do a location update.
Related: SYS#6391
Change-Id: I540132ee5dcfd09f4816e02e702927e1074ca50f
Allow to set the LU reject cause independently for both of the
following cases; either when an IMSI is unknown to the HLR or
when the mslookup client does not a receive a timely response
to a GSUP request for the remote home HLR.
Original patchset modified by <keith@rhizomatica.org>
Change-Id: Icea39020c23fbbea9e92847df76af8986fdbf48a
This commit fixes the following errors:
Missing timeout param for mslookup.
Fails to start reading a written config if an msc node
is configured in the mslookup server.
Places the individual msc node services in the
top-level wildcard node due to incorrect indentation.
* Add missing timeout param.
* Add missing "ipa-name" part to mslookup-server-msc section.
* Add one extra space indentation for msc services.
This commit also adds a DEFINE for the default timeout value.
Change-Id: Ibb60e74a0803f05f37ac13ca529d77b4cb736025
In 89fda3024a I added a
vty command to show a summary of filtered subscribers by imsi
or msisdn. In practice there is a also need to be able to
filter on IMEI.
The idea here is not to replace every operation that could be
done directly on the sql database in the vty, but this one
is useful.
Change-Id: Ic4a11d3ebcf8909c68e9f4617e94dc822491e008
osmo-hlr would not read back written configuration due to
bad indentation in the mslookup->server->service section.
Also ipa-name was missing.
Change-Id: Ied4b9504f06a51c3895054a8b9d07a67eda3aeeb
Adds the following commands:
show subscribers all - Display summary of all entries in HLR
show subscribers (imsi|msisdn|cs|ps) ... As above but filter on search field/string
show subscribers last seen - Display only subscribers with data in
Last LU update field, and sorts by Last LU.
Change-Id: I7f0573381a6d0d13841ac6d42d50f0e8389decf4
Add mslookup client to find remote home HLRs of unknown IMSIs, and
proxy/forward GSUP for those to the right remote HLR instances.
Add remote_hlr.c to manage one GSUP client per remote HLR GSUP address.
Add proxy.c to keep state about remotely handled IMSIs (remote GSUP address,
MSISDN, and probably more in future patches). The mslookup_server that
determines whether a given MSISDN is attached locally now also needs to look in
the proxy record: it is always the osmo-hlr immediately peering for the MSC
that should respond to mslookup service address queries like SIP and SMPP.
(Only gsup.hlr service is always answered by the home HLR.)
Add dgsm.c to set up an mdns mslookup client, ask for IMSI homes, and to decide
which GSUP is handled locally and which needs to go to a remote HLR.
Add full VTY config and VTY tests.
For a detailed overview of the D-GSM and mslookup related files, please see the
elaborate comment at the top of mslookup.c (already added in an earlier patch).
Change-Id: I2fe453553c90e6ee527ed13a13089900efd488aa
Implement the mslookup server's mDNS responder, to actually service remote
mslookup requests:
- VTY mslookup/server config with service names,
- the mslookup_mdns_server listening for mslookup requests,
For a detailed overview of the D-GSM and mslookup related files, please see the
elaborate comment at the top of mslookup.c (already added in an earlier patch).
Change-Id: I5cae6459090588b4dd292be90a5e8903432669d2
These are seemingly orthogonal changes in one patch, because they are in fact
sufficiently intertwined that we are not willing to spend the time to separate
them. They are also refactoring changes, unlikely to make sense on their own.
** lu_fsm:
Attempting to make luop.c keep state about incoming GSUP requests made me find
shortcomings in several places:
- since it predates osmo_fsm, it is a state machine that does not strictly
enforce the order of state transitions or the right sequence of incoming
events.
- several places OSMO_ASSERT() on data received from the network.
- modifies the subscriber state before a LU is accepted.
- dead code about canceling a subscriber in a previous VLR. That would be a
good thing to actually do, which should also be trivial now that we record
vlr_name and sgsn_name, but I decided to remove the dead code for now.
To both step up the LU game *and* make it easier for me to integrate
osmo_gsup_req handling, I decided to create a lu_fsm, drawing from my, by now,
ample experience of writing osmo_fsms.
** osmo_gsup_req:
Prepare for D-GSM, where osmo-hlr will do proxy routing for remote HLRs /
communicate with remote MSCs via a proxy:
a) It is important that a response that osmo-hlr generates and that is sent
back to a requesting MSC contains all IEs that are needed to route it back to
the requester. Particularly source_name must become destination_name in the
response to be able to even reach the requesting MSC. Other fields are also
necessary to match, which were so far taken care of in individual numerous code
paths.
b) For some operations, the response to a GSUP request is generated
asynchronously (like Update Location Request -> Response, or taking the
response from an EUSE, or the upcoming proxying to a remote HLR). To be able to
feed a request message's information back into the response, we must thus keep
the request data around. Since struct osmo_gsup_message references a lot of
external data, usually with pointers directly into the received msgb, it is not
so trivial to pass GSUP message data around asynchronously, on its own.
osmo_gsup_req is the combined solution for both a and b: it keeps all data for
a GSUP message by taking ownership of the incoming msgb, and it provides an
explicit API "forcing" callers to respond with osmo_gsup_req_respond(), so that
all code paths trivially are definitely responding with the correct IEs set to
match the request's routing (by using osmo_gsup_make_response() recently added
to libosmocore).
Adjust all osmo-hlr code paths to use *only* osmo_gsup_req to respond to
incoming requests received on the GSUP server (above LU code being one of
them).
In fact, the same should be done on the client side. Hence osmo_gsup_req is
implemented in a server/client agnostic way, and is placed in
libosmo-gsupclient. As soon as we see routing errors in complex GSUP setups,
using osmo_gsup_req in the related GSUP client is likely to resolve those
problems without much thinking required beyond making all code paths use it.
libosmo-gsupclient is hence added to osmo-hlr binary's own library
dependencies. It would have been added by the D-GSM proxy routing anyway, we
are just doing it a little sooner.
** cni_peer_id.c / osmo_ipa_name:
We so far handle an IPA unit name as pointer + size, or as just pointer with
implicit talloc size. To ease working with GSUP peer identification data, I
require:
- a non-allocated storage of an IPA Name. It brings the drawback of being
size limited, but our current implementation is anyway only able to handle
MSC and SGSN names of 31 characters (see struct hlr_subscriber).
- a single-argument handle for IPA Name,
- easy to use utility functions like osmo_ipa_name_to_str(), osmo_ipa_name_cmp(), and copying
by simple assignment, a = b.
Hence this patch adds a osmo_ipa_name in cni_peer_id.h and cni_peer_id.c. Heavily
used in LU and osmo_gsup_req.
Depends: libosmocore Id9692880079ea0f219f52d81b1923a76fc640566
Change-Id: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9
I added these "by accident" when implementing D-GSM related VTY tests, now
submitting them separately.
Change-Id: I92a4245cae806270b00330403cc114017ab7af53
Use three dots to avoid checking for exact commands between help and
exit, which originate from libosmocore. This avoids test failues when
we slightly change the commands, like the change from "write file" to
"write file [PATH]" in [1] that is currently causing the vty tests to
fail.
[1] libosmocore I38edcf902a08b6bd0ebb9aa6fc1a7041421af525
Change-Id: I4a964b86195141e5a50705425206f3602f908999
Add a new vty option and allow to optionally generate a random msisdn,
as well as setting the default NAM:
subscriber-create-on-demand (no-msisdn|<3-15>) (none|cs|ps|both)
Thanks to Vadim for the random MSISDN patch [1], which was squashed into
this one.
[1] Change-Id: I475c71f9902950fa7498855a616e1ec231fad6ac
Depends on: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1 (libosmocore)
Change-Id: I0c9fe93f5c24b5e9fefb513c4d049fb7ebd47ecd
Related: OS#2542
So far, the cmdline argument was the only way to set a database config file.
Add a similar config to VTY as 'hlr' / 'database'. The cmdline arg is stronger
than the 'database' cfg item. DB is not reloaded from VTY command.
Change-Id: I87b8673324e1e6225afb758fb4963ff3279ea3d8
Display the IMEI in "subscriber ... show", allow showing and modifying
subscribers by their IMEI with: "subscriber imei ...". For debug
purposes (and to have proper VTY tests), make it possible to change the
IMEI with "subscriber ... update imei".
IMEIs are saved in the database without the 15th checksum number. When
the checksum gets passed, verify it and cut it off.
Related: OS#2541
Depends: I02b54cf01a674a1911c5c897fbec02240f88b521 (libosmocore)
Change-Id: I1af7b573ca2a1cb22497052665012d9c1acf3b30
Add VTY config option "store-imei". When it is set, store the IMEI
sent from the VLR with CHECK-IMEI in the database.
Related: OS#2541
Change-Id: I09274ecbed64224f7ae305e09ede773931da2a57
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
When I wrote the osmo-hlr subscriber command, I failed to heed the common
'show foo' scheme and instead created a 'subscriber [...] show' command.
Relieve that weirdness by creating an alias that has 'show' at the start.
Arrange string macros so that the 'show subscriber' cmd doesn't end in a space
(the SUBSCR macro ends in a space ' ' to implicitly include the space to
commands like 'create', 'show', 'update').
Add the new command to test_nodes.vty and test_subscriber.vty.
Change-Id: I01ce9b0868302d40ed05c6a588316a194d6071e4
In libosmocore Change-Id Ia75c7067284ea225cffe13ca71bad05a7747ae66
we fixed the generation (saving) of logging configuration to use
one level of indent, rather than the previous broken implementation
with two levels of indent. This means we have to adjust the VTY
test expectations here.
Change-Id: I9282a59bbfad4cfc86e86c1212c74cccfe187ff8
Remove 'logging level all' setting.
Tweak some more logging details (to my current favorite).
Add USSD example for showing the IMSI.
Change-Id: I8296832704d779df5f1b20a595b568c99780e64d
Since libosmocore
commit eb9284ba577d338f74653fcf09ebca0c397823eb
Change-Id I36f17c131cc70ce5a1aef62fd9693097de230cd4
"logging vty: deprecate 'all', introduce 'force-all'"
,
'logging level all' is replaced by 'force-all'.
Adjust the test script to not expect 'logging level all'.
While at it, remove some more expectations that aren't important.
Change-Id: Ia170f8416ebb60c499d2536078f43f28b61d0554
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
Ever since libosmocore Change-Id I1c931bff1f1723aa82bead9dfe548e4cc5b685e0
was merged, the VTY tests were broken. Let's fix that by adjusting
the expected test output.
Change-Id: I929ca7f366220b5d1238d43eddc96fa9dde916b6
Tweak unit test binaries to still used DEBUG loglevels, so that their expected
outputs remain unchanged (and nicely verbose).
Adjust test_nodes.vty, now expecting the 'notice' log levels upon
'show running-config'.
Change-Id: Ic061e61c9625b49cef8bc2a2c0b936e262c22268
Mychaela N. Falconia
Keith Whyte
Vadim Yanitskiy
Pau Espin
Philipp Maier
Oliver Smith
Harald Welte