On Wed, Jun 21, 2017 at 05:12:37AM +0200, Neels Hofmeyr wrote:
It seems overkill that a "client" like
osmo-hnbgw should be capable of routing
in the first place. It could switch off routing entirely and receive & handle
every message it receives itself. But assuming that this were nonsense:
I would rather not restrict this. There are many possible useful
configurations, and disabling PC routing "by force" completely right
now, before we have any actual practical deployments of this could bite
us in the back.
Apparently this global primary_pc is set in
osmo_sccp_simple_client().
it is not truly global, but speciic to the SS7 instance.
Since in the osmo-hnbgw I'm (so far) creating two
simple clients with
distinct PCs (IuCS is 23, IuPS is 24), the primary_pc is overwritten
with 24.
This is where I think it is broken. The simple_client API is intended
for a simple use case, and not for more complex configurations.
I think you have the following options:
a) use different ss7_instances, which is probably the right thing if you
really want to assume that MSC and SGSN live in completely separate
SS7 networks with no routing/STP in between. At that point, even the
point codes may very well be no longer unique, so having two SS7
instances would compltely isolate the two parts.
b) add the missing 'secondary point codes' and then have 23 as primary
and 24 as secondary, or whatever
c) do away with the two separate signaling connections for PS and CS
domain. I would assume that an operator typically has one signaling
network, with unique point codes and routing in place. So the HNB-GW
establishes M3UA to some kind of STP (or multiple STPs in fail-over
mode) and then simply let SCCP take care of its job to route the
respective messages to either SGSN or MSC. The HNB-GW then only has
a single point code in that scenario
d) move away from simple-client and introduce the ss7_vty with all its
related configuration into the hnb-gw. This is required sooner or
later anyway, as even a "simple" client in a real-world scenario
would normally have M3UA links to multiple STPs for redundancy or
load-sharing reasons.
The hack of having two simple clients (and two separate M3UA connections
at all) was introduced as we didn't have an STP at the time and we still
wanted to make progress on IuCS+IuPS. So my favorite would be option
'c', and if not that, option 'a' and only as a last resort go to option
'b'. 'd' can be done as incremental step to either of the three above.
A "matching" route is recognised by
osmo_ss7_route_find_dpc():
if ((dpc & rt->cfg.mask) == rt->cfg.pc)
My own local client gets entered as route, with rt->cfg.mask == 0 and
rt->cfg.pc == 0, so an arbitrary dpc & 0 == 0, matches always. It seems
awfully easy to create a fatal infinite loop flooding the network and CPU --
simply send a message to a DPC neither side sees as local. Anyway...
that's good to point out and should certainly be adressed.
Unfortuantely I think the hop counter information element is not mandatory :/
Which way to go to serve more than one PC in a
program? It appears that either
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)