This approach has several benefits:
* We end up with ip/tun setup output in the same log file as
open5gs-upfd process output.
* We configure all ip/tun *before* the open5gs-upfd process starts.
Furthermore, we have same procedure as in ttcn3-ggsn-tests-ogs, which
simplifies maintainment/use.
The IP address pool for UEs is still different in pgw-tests and
ggsn-tests-ogs. We can make them the same in subsequent patches.
Change-Id: I94219abbeb5e004ce707407b5aa5ee8ad6c3a80e
Some specific gdb commands need to be run in open5gs-smfd to get the
desired result (some signals need to be ignored).
gdb use is not enabled by default. Furthermore, if one wants to use it,
editing the Dockerfile to install gdb is required.
Change-Id: I1ac8b77e84d57040fc09964356bc8a01e5d721e3
Unlike osmo-ggsn, open5gs-upfd does not configure the tun interface
itself. All IPv4/IPv6 addresses must be assigned manually. This
is exactly why both PGW_Tests.TC_createSession_ping4[_256] fail:
[sock] ERROR: ogs_write() failed (5:Input/outputerror) (../lib/tun/tunio.c:84)
[upf] WARNING: ogs_tun_write() failed (../src/upf/gtp-path.c:448)
Take Harald's setup.sh from open5gs-master and execute it in the
container running open5gs-upfd. This fixes the ogs_write() errors.
Change-Id: I0730b1f69285484a0aa0ebd664dafd8e476b294f
Related: SYS#5602
On some systems /bin/sh is a symbolic link to bash, so everything
works fine. On systems where /bin/sh is a real sh, copy fails:
cp: cannot access 'open5gs-{smf,upf,nrf}.yaml': No such file or directory
Change-Id: I64e9ddefdb6deb21b3bce3bc1af875a92919e6c9
Related: SYS#5602