<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’m attaching some logs to my previous mail:<div class=""><br class=""></div><div class=""><div class=""><font face="Courier" class="">Feb 16 09:26:01 gtpt kernel: [ 2044.151300] gtp0: encap_recv sk=000000005f3daa49</font></div><div class=""><font face="Courier" class="">Feb 16 09:26:01 gtpt kernel: [ 2044.151302] gtp0: received GTP1U packet</font></div><div class=""><font face="Courier" class="">Feb 16 09:26:01 gtpt kernel: [ 2044.151303] gtp0: No PDP ctx to decap skb=000000001be38557</font></div><div class=""><font face="Courier" class="">Feb 16 09:26:01 gtpt kernel: [ 2044.151304] gtp0: pass up to the process</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><div class=""><font face="Courier" class="">root@gtpt:~# gtp-link add gtp0</font></div><div class=""><font face="Courier" class="">WARNING: attaching dummy socket descriptors. Keep this process running for testing purposes.</font></div></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><div class=""><font face="Courier" class="">Every 1.0s: netstat -aup Fri Feb 16 09:27:29 2018</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">Active Internet connections (servers and established)</font></div><div class=""><font face="Courier" class="">Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name</font></div><div class=""><font face="Courier" class="">udp 0 0 *:3386 *:* 3338/gtp-link</font></div><div class=""><font face="Courier" class="">udp 0 0 *:bootpc *:* 741/dhclient</font></div><div class=""><font face="Courier" class="">udp 6144 0 *:2152 *:* 3338/gtp-link</font></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Tomas</div></div><div class=""><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 16 Feb 2018, at 09:00, Thomas Boros <<a href="mailto:tomas.boros92@gmail.com" class="">tomas.boros92@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Harald,<br class=""><br class="">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.<br class=""><br class="">root@gtpt:~# uname -ar<br class="">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<br class=""><br class="">Tomas<br class=""><br class=""><blockquote type="cite" class="">On 16 Feb 2018, at 08:24, Harald Welte <<a href="mailto:laforge@gnumonks.org" class="">laforge@gnumonks.org</a>> wrote:<br class=""><br class="">Hi Thomas,<br class=""><br class="">On Thu, Feb 15, 2018 at 11:06:12AM +0100, Thomas Boros wrote:<br class=""><blockquote type="cite" class="">+bin_PROGRAMS = gtp-link \<br class="">+ gtp-tunnel<br class="">+<br class="">check_PROGRAMS = gtp-link \<br class=""> gtp-tunnel<br class=""></blockquote><br class="">This would have them both in bin_PROGRAMS and in check_PROGRAMS, which is redundant.<br class=""><br class="">In any case bin_PROGRAMS installs those tools, which are really only useful to developers<br class="">and not for the typical users. I went for an alternative and included them in noinst_PROGRAMS,<br class="">i.e. they are always being built during 'make' not only 'make check', but they still aren't<br class="">installed during 'make install'.<br class=""><br class="">See <a href="https://gerrit.osmocom.org/6517" class="">https://gerrit.osmocom.org/6517</a><br class=""><br class="">-- <br class="">- Harald Welte <<a href="mailto:laforge@gnumonks.org" class="">laforge@gnumonks.org</a>> <a href="http://laforge.gnumonks.org/" class="">http://laforge.gnumonks.org/</a><br class="">============================================================================<br class="">"Privacy in residential applications is a desirable marketing option."<br class=""> (ETSI EN 300 175-7 Ch. A6)<br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>