This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Thomas Boros tomas.boros92 at gmail.comI’m attaching some logs to my previous mail: Feb 16 09:26:01 gtpt kernel: [ 2044.151300] gtp0: encap_recv sk=000000005f3daa49 Feb 16 09:26:01 gtpt kernel: [ 2044.151302] gtp0: received GTP1U packet Feb 16 09:26:01 gtpt kernel: [ 2044.151303] gtp0: No PDP ctx to decap skb=000000001be38557 Feb 16 09:26:01 gtpt kernel: [ 2044.151304] gtp0: pass up to the process root at gtpt:~# gtp-link add gtp0 WARNING: attaching dummy socket descriptors. Keep this process running for testing purposes. Every 1.0s: netstat -aup Fri Feb 16 09:27:29 2018 Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 *:3386 *:* 3338/gtp-link udp 0 0 *:bootpc *:* 741/dhclient udp 6144 0 *:2152 *:* 3338/gtp-link Tomas > On 16 Feb 2018, at 09:00, Thomas Boros <tomas.boros92 at gmail.com> wrote: > > 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 at 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 at 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 at gnumonks.org> http://laforge.gnumonks.org/ >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20180216/09ca568f/attachment.htm>