This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgOn 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 at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)