This reverts commit 0917ce4e22,
as it breaks building osmo-sgsn. This needs to be reworked to be
backwards compatible.
Related: OS#6373
Change-Id: I2c2b2ff0875217e041d94c8e2cef030d2a86c2d8
As discussed in Gerrit change I9c3bf64537ef2223e29f8082861fa32fde26bf68
remove defines that don't serve any purpose. These are defines for
reserved values and changing them later if a newer spec defined them
would break API.
Keep the comments to explain the missing values.
Change-Id: I8db0aa0ade59785443a407b51dea326144406dcf
In some cases the phone requests a PDP context type that isn't available
no the PGW/GGSN, e.g. phone requests a combined IPv4/v6 context, but
only IPv4 is supported.
In that case the GGSN can send a Create PDP Context Response with cause
"New PDP type due to network preference" or "New PDP type due to single
address bearer only". libgtp should continue handling these cause values
like the "Request Accepted" cause. Use the new gtp_cause_successful()
function for that.
Related: OS#6268
Change-Id: I7dd1e0aa185530e1e2d0402742df833c61a787a7
According to the spec the upf/pgw can accept a modified pdp context from
the request e.g. if an ipv4/6 context was requested, but only ipv4 is
availiable. Introduce a function that checks all cause values that are
considered successful.
See also: 3GPP TS 29.060 Ch 7.3.2
Related: OS#6268
Change-Id: I9c3bf64537ef2223e29f8082861fa32fde26bf68
When using built-in static_assert() [1], gcc v12.2.1 fails:
In file included from gsn.c:27:
gsn.c: In function 'gtp_new':
gsn.c:444:54: error: expression in static assertion is not constant
444 | osmo_static_assert(gtp_T_defs[0].default_val != 0, first_default_val_not_zero);
| ^
The reason is likely that gtp_T_defs[] is not const, so it cannot
be assert()ed statically. With the current osmo_static_assert()
implementation, this assert does nothing. One can change the
gtp_T_defs[0].default_val to 0 and the code will still compile.
Change-Id: Ia8af1736b63d501661046fe70befe5bbabc1045a
Related: [1] libosmocore.git I5ca34bc14c05e8c38c721d7df33feb1c6c41c76e
This timer controls the amount of time a resp message transmitted by the
local gsn is to be stored in the resp queue. This is used in order to
detect duplicate requests received, since GTP states the exact same
response should be answered if a duplicate request is received.
Prior to this patch, this timer was hardcoded to 60 seconds.
This patch actually should be set, in general, to a value
equal than (T3-RESPONSE * N3-REQUESTS) values configured at
the peer, since that is the maximum period during which the local gsn
expects to receive req retransmissions from the peer.
Hence, this value must be user configurable to adapt it to the peers
connected to the GSN.
The 60 seconds hardcoded value is therefore changed to default to our
local (T3-RESPONSE * N3-REQUESTS), since the most common scenario for
osmo-ggsn/osmo-sgsn is to run it against a peer osmo-sgsn/osmo-ggsn,
which will have the same values by default.
This way we avoid by default caching response messages for way too long,
potentially filling the queue.
Related: OS#5485
Change-Id: Ia15c1cfd201d7c43e9a1d6ceb6725ddf392d2c65
QUEUE_SIZE holds the number of pending transmitted messages
which can be handled concurrently.
Current value was 1024, same as PDP contexts (PDP_MAX). However, that
seems to be a quite low amount, which can be filled under certain
conditions, for instance if recovery procedure is triggered on the GSN
which is running full (around PDP_MAX pdp contexts created).
In this scenario, the GSN would need to send around PDP_MAX concurrent
messages (DeletePDPContextReq), which means the queue would very likely
end up being full.
Hence, let's define QUEUE_SIZE based on PDP_MAX, and set it to twice the
size to make sure it won't be filled in extreme conditions.
Change-Id: I6034b0fab2b2e5962314c2fca2f893246ce5cf4f
osmo-ggsn crashes when concurrent pdp context num 1024 is created, due to
the gsn->pdpa array (of size PDP_MAX, 1024) being full.
The crash happens because return code of gtp_pdp_newpdp was not checked,
and hence a pointer "pdp" pointing to a temporary not-fully-allocated
object was being passed to gsn->cb_create_context_ind() callback.
Let's avoid crashing and instead reject the PDP context.
Related: OS#5469
Change-Id: I0d94ffad97eb4fef477d981bf285bf99740592a3
The previous order of parsing lead to non-optimal information gathering
when pushing events to upper layers.
This patch rearranges parsing of packet data to always gather as much
info as possible for the benefit of the upper layer. This way it can
gather information such as the cause, which is important in the case of
"Non-existent", since user should then drop the context.
First we want to parse the recovery state, but delay cb to upper layers
until we tried to gather the pdp ctx (meaning all except that pdp ctx
should be freed).
Second, we want to parse the cause, in order to know if there's an
associated pdp ctx we can gather from TEID.
Third, once we know if we should expect a meaningul TEID, parse it.
Related: SYS#5435
Change-Id: Idd10b494e8fbac8703c49ecd8f9bbe4246e51c57
The PDP context is searched on the hash which is generated
on context creation from the IMSI in gtp format. - A hash
created from "human-readable" IMSI does not match.
Check user input for length then convert the IMSI to gtp format
before continuing.
Change-Id: Icd2e2bc6068c06fbf5d5fe905ebcda8954f33f04
Currently each user (application) of libgtp needs to manage its own
timers in order to call gtp_retrans_timeout() and gtp_retrans() and
maintain retransmit and duplicate queues working correctly. This adds
unnecesary complexity to applications since nowadays, as a libosmocore
user, libgtp can handle this internally in an easy way.
Furthermore, keeping the timers internal to the library allows for
easier extension of features as well as re-implementation of related
code in the future.
Last but not least, it was detected that existing known applications
(osmo-sgsn, osmo-ggsn, sgsnemu) are not using correctly the API, since
they should be updating their timers through gtp_retrans_timeout()
everytime a message is enqueued/transmitted, otherwise they may fire
gtp_retrans() for retransmition too late in some cases.
Related: OS#4178
Change-Id: Ife7cfd66d6356f413263fe5bda9e43091f5c9e98
This change fixes the following compiler warnings (found by Clang):
gtp.c:2747:13: warning: variable 'pdp' is used uninitialized
whenever 'if' condition is false
[-Wsometimes-uninitialized]
} else if (version == 1) {
gtp.c:2781:14: note: uninitialized use occurs here
OSMO_ASSERT(pdp);
^^^
Shall not happen in general, but let's make Clang happy.
Change-Id: Id471b22afd4c45435589a4edda0a804e66be3a7a
As stated in the comment above, we need to use the tunnel identifier
to find a GTP context, and derive both IMSI and NSAPI from that TID,
when speaking GTP version 0.
This change fixes the following warnings (found with Clang):
gtp.c:2115:22: warning: variable 'pdp' is uninitialized
when used here [-Wuninitialized]
pdp_set_imsi_nsapi(pdp, tid);
^^^
gtp.c:2118:34: warning: variable 'imsi' is uninitialized
when used here [-Wuninitialized]
if (gtp_pdp_getimsi(gsn, &pdp, imsi, nsapi))
^^^^
gtp.c:2118:40: warning: variable 'nsapi' is uninitialized
when used here [-Wuninitialized]
if (gtp_pdp_getimsi(gsn, &pdp, imsi, nsapi))
^^^^^
Change-Id: I8f1c8d0ba2e8189d97fe1bb5c872680e5ad1cd7a
Vadim Yanitskiy
Daniel Willmann
Oliver Smith
Pau Espin
Pau Espin Pedrol
Keith Whyte