When SGSN pooling is enabled we need to route some responses based on
IMSI back to the correct SGSN, e.g. PAGING_PS_REJECT.
The IMSI cache keeps track of this IMSI <-> NSE(SGSN) mapping.
Change-Id: If0a8d6cc1d63f2fb2c395cc5d4373a915bc2cb87
Related: OS#4951, OS#4472
The range of SUSPEND/RESUME timers T3/T4 is up to 10s so we should keep
the cache entries valid for this time.
Fixes: OS#4895
Change-Id: I9e88e49981098831f3255938deb868f4503f650f
Related: SYS#5235
When routing a SUSPEND/RESUME we need to keep track of where it came
from so we can send the (N)ACK back to the correct BSS. Use the TLLI
which is present in both messages to cache and retrieve the correct BSS.
A timer runs every two seconds and expires entries that are older than
the timeout (hardcoded to 5 seconds for now).
Related: SYS#4865, OS#4472
Change-Id: I42adf70f560d2bb358a9e1c7614281e8d2967568
This is useful for logging and configuration to identify an SGSN by name
Change-Id: I2a3410dd9bebb242957e13a63ed70e447204203c
Related: SYS#5115, OS#4472
The new gprs_ns2 vty2 support ip-sns and reorganize the
network service configuration
Depends: I163279cf57e84198dc8c53e1c109f5a9474670e9 (libosmocore)
Change-Id: I2a18dcf035f1fc7304a0c7c7c83b5e8e15429d2b
The new NS2 api supports NSE with multiple NS-VC and contains a NS-VC
fsm. FR/GRE support is not working.
The configuration is compatible except for FR/GRE.
Relates: OS#4629
Depends-on: Iaad7b53d44338e5dd81dc2202f23bdcb715af804 (libosmocore)
Depends-on: I6cef42749555e577d5573f2ed8b8bce4cf842a98 (libosmocore)
Change-Id: I92a3bcaf166b091a22d74c7c1586964d33d7cc9d
[ 258s] CC gb_proxy.o
[ 258s] gb_proxy.c: In function 'gbproxy_select_sgsn_bvc':
[ 258s] gb_proxy.c:293:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 258s] for (int i = 0; i < ARRAY_SIZE(cell->sgsn_bvc); i++) {
[ 258s] ^
[ 258s] gb_proxy.c:293:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your
code
Change-Id: I717410b11f1ee38d49e9ca5af593cb59a244ae0a
In order to support SGSN pooling we need to configure the various NRI
parameters such as the bitlen, NULL NRI, and which NRIs are assigned to
which SGSN.
Related: OS#4890, OS#4472
Change-Id: Id67592aa7712e5e04e7264b2fb8f26d57eb7e69e
This function is now used to transmit messages in both directions,
BSS->SGSN and SGSN->BSS.
Print the actual direction in the logs
Change-Id: I31682156dfe88f7ca121a711968e625caed8bd5e
Related: OS#4472
gprs_subscr_get_or_create() can return NULL if no memory can
be allocated. Detected by the compiler on Ubuntu s390x.
Signed-off-by: Steve Langasek <steve.langasek@ubuntu.com>
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I86b3652d46bdd581fe6cbab16b52395a0daaa082
* allow to print not only BSS-side BVCs, but also SGSN-side
* differentiate between SIG and PTP BVC
* print the actual BVC FSM state name instead of just UNBLOCKED/nothing
Change-Id: I8e09a9dc296b15094d191b0451d04457c815d116
When there are multiple SGSNs inside a pool, we need to decide
how much of the per-BVC capacity advertised by the BSS in its
BVC-FLOW-CONTROL we should announce to each of the pool members.
A conservative approach would be to advertise 1/num_sgsn, but
there may also be use case where over-provisioning (announcing more
than an equal share of the capacity) is useful.
Hence, let's introduce "pool bvc-flow-control-ratio <1-100>" in order
to allow the administrator to decide.
Related: OS#4891
Change-Id: Ibe5addf657e7237499ca0205bacfe999ecd1e771
The 'nse' variable had been used both as the input argument of the
SGSN-side NSE, as well as a loop iteration variable. Let's separate
this clearly.
Closes: OS#4904
Change-Id: I375a219cd72eb11a9a0cb7d55a3efb7b83b771ac
After a SGSN-side RESET of the SIG-BVC, all PTP BVC on the SGSN side
are gone. However, the CELLs and the BSS side BVCs continue to exist
(as there may be other SGSNs).
So if a PTP-BVC RESET from the BSS side arrives in such a situation,
and we can find a matching CELL, we still need to check if we need
to create any SGSN-side PTP BVCs instead of simply being happy with
the CELLs already existing.
Change-Id: I1d1562e421082fa4399c73ac31290e4c95718e49
Closes: OS#4903
We must locally terminate + acknowledge any inbound BSSGP-FC-BVC,
and ourselves trigger the transmission of BSSGP-FC-BVC to each
SGSN in the pool.
Related: OS#4891
Depends: libosmcoore.git Ie59be6761177c43456898be9148727f15861a622
Change-Id: Ib6495e5de4bfcf748a98e08743d1a8f2565f8b69
That copy may have made sense while we were doing patching/buffering,
but we're not doing any of that anymore.
Related: OS#4472
Change-Id: I207a869ffac8bf60104f80f9ed58faf0021e5e95
As we now have gbproxy_bvc on both the SGSN and the BSS side
with the same BVCI, using the BVCI alone will no longer render
unique indexes.
Related: OS#4472
Change-Id: I13f3c9e69562a56ad7d3742fdeb2ba48f134fdaa
Rewrite of a large part of osmo-gbproxy in order to prepare
for SGSN pool support. The amount of changes are of such fundamental
nature that it doesn't make sense to try to split this into hundreds
of individual changesets.
Related: OS#4472
Change-Id: Ie0746f17927a9509c3806cc80dc1a31d25df7937
We recently introduced code to libosmocore which allows us to validate
the mandatory IE presence (and length) in a generic way. Let's use it.
Change-Id: I0ea3f5f9566d9bf5a8429c3ee748e3e90cda6cd7
Depends: libosmocore.git I7e4226463f3c935134b5c2c737696fbfd1dd5815
gbprox_relay2peer() is a small wrapper around gbprox_relay2nse(),
but as it manages the transmit error counter, we should use it whenever
possible.
Change-Id: I85ab49ca0a25dd7c54b88c4fdc8838843e6d2209
* ensure the BSSGP PDU header length before reading pdu_type field
* ensure we never process uplink PDUs in downlink and vice-versa
* ensure we never proceses PTP PDUs on SIGNALING BVCI and vice-versa
Change-Id: I6e40aed0283f1a0860ab273606605f7fb28717cf
Depends: libosmocore.git I7e4226463f3c935134b5c2c737696fbfd1dd5815
The test is actually performing invalid operations such as
sending empty NS packets without even a BSSGP header - and assumes
that gbproxy should route those.
Given that we have a much more comprehensive tset suite in
GBProxy_Tests.ttcn in osmo-ttch3-hacks.git, it makes sense to remove
the testsuite. It may contain many more wrong assumptions, or
assumptions that no longer hold true with the "gbproxy 2020".
Change-Id: I053aebab6bf5d0ee955f2221bf27925b36140cf3
Those features were introduced a long time ago for one specific use
case at one specific user, and they are not needed anymore. They
complicate the code base significantly and are hard to maintain with
all the upcoming modifications regarding SGSN pool supoprt.
Change-Id: Id9cc2e1c63486491ac5bb68876088a615075fde6
For the common lookup-by-bvci, this should reduce the computational
complexity significantly.
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Change-Id: Ic8e9279fd61a3c514fc3203429f36a468f0e81d3
For the common lookup-by-nsei, this should reduce the computational
complexity significantly.
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Change-Id: Idbb6a362332bb6e3ce22102e7409ae80d0980f44
Daniel Willmann
Oliver Smith
Alexander Couzens
Vadim Yanitskiy
Harald Welte