Interfering with the GTP-u Kernel module

Submitted by Thomas Boros on Feb. 15, 2018, 10:06 a.m.

Details

Message ID 0A0C4CCA-E884-4A6C-A555-665BB237F4C7@gmail.com
State New
Series "Interfering with the GTP-u Kernel module"
Headers show

Commit Message

Thomas Boros Feb. 15, 2018, 10:06 a.m.
Hello,

I found, that there are tools available for this purpose, however they are not compiled on build. By adding the bin_PROGRAMS to the makefile the tools are built. I was too lazy to set up the whole gerrit thing, so I’m sending the patch.


Tomas

> On 15 Feb 2018, at 00:11, Thomas Boros <tomas.boros92@gmail.com> wrote:
> 
> Hello,
> 
> I would like to implement a command line tool, which will be able to open / close , read / write to gtp tunnels. I was able to install the libgtpnl library, but due to lack of documentation I have no idea where to start. 
> 
> Is there some sort of documentation available for this library? 
> 
> I need to be able to create and delete tunnels without the GTP-C communication, so just basic command line tool like create-gtp-tunnel + arguments like IPs, version and teid. The GTP-U tunnels must be kernel based. I have the latest kernel with the gtp kernel module loaded. 
> 
> Any help is appreciated. 
> Thank you,
> Tomas

Patch hide | download patch | download mbox

diff --git a/tools/Makefile.am b/tools/Makefile.am
index 95aef86..3db095e 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -1,5 +1,8 @@ 
 include $(top_srcdir)/Make_global.am

+bin_PROGRAMS = gtp-link                        \
+               gtp-tunnel
+
 check_PROGRAMS = gtp-link              \
                 gtp-tunnel


Comments

Harald Welte Feb. 16, 2018, 7:24 a.m.
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
Thomas Boros Feb. 16, 2018, 8 a.m.
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@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@gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
Thomas Boros Feb. 16, 2018, 8:27 a.m.
I’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@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@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@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@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@gnumonks.org>           http://laforge.gnumonks.org/
>> ============================================================================
>> "Privacy in residential applications is a desirable marketing option."
>>                                                 (ETSI EN 300 175-7 Ch. A6)
>