Hi Harald,
I’ve also noticed one unusual thing. I noticed, that the the gtp-link app must be running,
so the socket remains open. If I kill the application and I have gtp-tunnels set up, the
machine responds with and ICMP port unreachable message, but I suppose, this behaviour is
ok. Another issue I’ve noticed, I’ve enabled module debugging and I can clearly see, if
there is a GTP datagram arriving on the socket to a pdp context, which is not existing,
the log says that the datagram is going to be handled in the userspace. However, even if
the gtp-link tool is running, the datagrams are not passed to the userspace, they get
buffered in the Recieve-Q (checked via netstat). On each packet this queue gets larger,
what I assume is not the desired functionality. I guess there is something wrong with the
gtp-link tool. Did you encounter such situation? I’m using the latest kernel 4.15.3 and
the library is compiled from the osmocom repository.
root@gtpt:~# uname -ar
Linux gtpt 4.15.3-041503-generic #201802120730 SMP Mon Feb 12 07:31:14 UTC 2018 x86_64
x86_64 x86_64 GNU/Linux
Tomas
On 16 Feb 2018, at 08:24, Harald Welte
<laforge(a)gnumonks.org> wrote:
Hi Thomas,
On Thu, Feb 15, 2018 at 11:06:12AM +0100, Thomas Boros wrote:
+bin_PROGRAMS = gtp-link
\
+ gtp-tunnel
+
check_PROGRAMS = gtp-link \
gtp-tunnel
This would have them both in bin_PROGRAMS and in check_PROGRAMS, which is redundant.
In any case bin_PROGRAMS installs those tools, which are really only useful to
developers
and not for the typical users. I went for an alternative and included them in
noinst_PROGRAMS,
i.e. they are always being built during 'make' not only 'make check', but
they still aren't
installed during 'make install'.
See
https://gerrit.osmocom.org/6517
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)