The details of creation of data structures don't belong on the vty file.
While at it, split allocation code into its own function to quickly find
out where the allocation of the object happens.
Change-Id: Iaa4cd86c44957321c238d268ea62daafa1b79c69
The details of creation of data structures don't belong on the vty file.
While at it, split allocation code into its own function to quickly find
out where the allocation of the object happens.
Change-Id: If15a4158dd6599341017efd24dbf67ca565a7c34
Whenever the SGSN sends the GGSN a UpdatePDPCtxReq, it may offer a new
remote IP address or/and remote TEID, eg. because it wants to establish
a Direct Tunnel and point the GTPU towards the RNC, or to point it back
to itself.
If the gtpu kernel is used, osmo-ggsn lacked updating the kernel with
the new remote data.
The gtp kernel module doesn't provide an efficient/explicit way to
update a pdp context keeping the4 same local IP+TEID and changing only
the remote remote IP+TEID, hence first destroy the pdp ctx in the gtp
kernel module and then recreate it.
This fixes test GGSN_Tests_v4_only.TC_pdp4_act_update_teid in
ttcn3-ggsn-test-kernel-net-next.
Related: OS#6523
Change-Id: I1fc48be5c0f177ccf6fbe97c003b4df44809c0fe
This will be used by:
* SGSN: Get to know that RNC has gonne down according to GGSN (re-attempt
Direct Tunnel or go back to tun SGSN<->GGSN).
* GGSN: Maybe find out that Direct Flags are used (should be handled
internally directly in the rx path probably)
Related: OS#6512
Change-Id: Ic80a9a928c55b6ff85be96014920bb42793cb943
The Update PDP Context procedure can be initiated GGSN -> SGSN, as
described in TS 29.060 7.3.3.
Related: OS#6512
Change-Id: I1c3441c71b90c5bbf6f4545484586222e6180fe1
In Update PDP Ctx Response, only SGSN is expected to transmit Direct
Tunnel Flags in the message.
Related: SYS#5435
Change-Id: Ia3e360a35d30858eab1e438dc2508fd756c2e22e
In Update PDP Ctx Response, only SGSN is expected to transmit Direct
Tunnel Flags in the message.
Related: SYS#5435
Change-Id: I36d93619e2fe9cafd3092515df18b82d29099d2d
Remove SysV init scripts. These are not really maintained anymore and
this makes it consistent with other Osmocom projects.
Avoids synchronizing with SysV scripts on debian:
# systemctl enable osmo-ggsn
Synchronizing state of osmo-ggsn.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable osmo-ggsn
Change-Id: I11bfb5122344b54970b7f742470cb74b95fa37e0
Prepare to run osmo-ggsn as user with the systemd service. As with other
Osmocom service files, we will set StateDirectory= and WorkingDirectory=
options. This results in osmo-ggsn only being able to write to
/var/lib/osmocom, therefore let's change the state-dir from /tmp to
/var/lib/osmocom/osmo-ggsn to avoid:
gsn.c:411 fopen(path=/tmp/gsn_restart, mode=w) failed: Error = Permission denied
Having the state in /var/lib/osmocom also makes more sense, because then
it doesn't get deleted on reboot.
Change-Id: I5b51529b4f8bd2462e54f58a1ce2e2d7c76ff46a
Prepare to change the state-dir in the default config in a follow-up
commit. Create the directory if it does not exist.
Change-Id: I91349fb284336a9de6af41475f1b824eb0e021b0
While at it, move internal functions of gtp.h to a separate file too.
Make all functions that are only used inside gtp.c static.
The following APIs are unexpectedly public:
* imsi_gtp2str gets used by pdp.h
* gsna2in_addr, gtp_echo_req gets used by osmo-sgsn
Change-Id: I72c40cbdec33449ca8104fb3cad8df1a9e07dfd7
Move the conversion functions above the first user, so we can make
in_addr2gsna static in a follow-up commit and remove the extra
declaration.
Change-Id: I51e6a7c1161320fc54b0e8197ae57e4327976eb1
Remove ipv42eua and eua2ipv4, which are in the "internal functions"
section of gtp.h, but are not used anywhere in the code anymore. This is
in preparation of moving the internal functions that are used in
multiple .c files into a separate header file, and to make the other
internal functions static. (Compiler complains about unused static
functions.)
Change-Id: I90e2750f6a6e3e6122e9c562103fda77d7326932
Move gtp_create_context_resp below gtp_create_pdp_resp, which it calls.
In a follow-up commit, we can make gtp_create_pdp_resp static and
remove the additional declaration.
Change-Id: I34efe7592013a8423f4f280758272d81f24b65fa
Move all includes from /usr/include/….h to
/usr/include/osmocom/gtp/….h to be more consistent with other Osmocom
projects, and to not "pollute" the top include directory if we add more
header files.
Also the new directory structure makes more obvious, which headers are
public and which ones aren't.
Adjust libgtp.pc.in so both #include <gtp.h> (legacy)
and #include <osmocom/gtp/gtp.h> can be used.
Related: OS#6373
Change-Id: If7e01c61168819bf7120667344e40c857da5490b
Make it clear to the user, that if adding a tunnel fails with kernel GTP
and IPv6: the reason is that the kernel doesn't support IPv6 yet.
Related: OS#6096
Change-Id: I1d3c8cbb51212c91136292347dad9529a5c58a31
Fix -Werror=maybe-uninitialize found in Pau's build env:
/home/pespin/dev/sysmocom/git/osmo-ggsn/lib/gtp-kernel.c: In function ‘gtp_kernel_tunnel_add’:
/home/pespin/dev/sysmocom/git/osmo-ggsn/lib/gtp-kernel.c:111:13: error: ‘ret’ may be used uninitialized [-Werror=maybe-uninitialize]
111 | int ret;
| ^~~
/home/pespin/dev/sysmocom/git/osmo-ggsn/lib/gtp-kernel.c: In function ‘gtp_kernel_tunnel_del’:
/home/pespin/dev/sysmocom/git/osmo-ggsn/lib/gtp-kernel.c:167:13: error: ‘ret’ may be used uninitialized [-Werror=maybe-uninitialize]
167 | int ret;
| ^~~
Fixes: b17fe7bf ("kernel-gtp: support IPv6 on inner layer")
Change-Id: I19067ebe561d4c067b9ace7f5b201e15af6b342e
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
