From avatli at itu.edu.tr  Mon Jul  6 16:00:24 2020
From: avatli at itu.edu.tr (avatli at itu.edu.tr)
Date: Mon, 06 Jul 2020 19:00:24 +0300
Subject: Network is unreachable error for GTP interface
Message-ID: <20200706190024.Horde.A9x9JusmIIuO_9QOsdjLPRD@webmail.itu.edu.tr>


Hi

I'm trying to build a setup by using GTP module and libgtpnl tools on  
Centos 7 but I haven't been successful yet. Worse, I don't know how to  
debug the problem. I also stopped firewall and iptables.

How can I debug/solve, I will be very glad if you help. dmesg or  
system messages show show nothing. Why is GTP interface (link) is  
unreachable.

Thanks in advance

- Volkan


$ modinfo gtp
filename:        
/lib/modules/5.7.7-1.el7.elrepo.x86_64/kernel/drivers/net/gtp.ko
alias:          net-pf-16-proto-16-family-gtp
alias:          rtnl-link-gtp
description:    Interface driver for GTP encapsulated traffic
author:         Harald Welte <hwelte at sysmocom.de>
license:        GPL
srcversion:     191407DA5399304D93D62C7
depends:        udp_tunnel
retpoline:      Y
intree:         Y
name:           gtp
vermagic:       5.7.7-1.el7.elrepo.x86_64 SMP mod_unload modversions

$ modinfo udp_tunnel
filename:        
/lib/modules/5.7.7-1.el7.elrepo.x86_64/kernel/net/ipv4/udp_tunnel.ko
license:        GPL
srcversion:     0A315BA6124B0664F4D23FB
depends:
retpoline:      Y
intree:         Y
name:           udp_tunnel
vermagic:       5.7.7-1.el7.elrepo.x86_64 SMP mod_unload modversions

$ ip addr add 172.0.0.1/24 dev enp9s0
$ ip addr add 172.99.0.1/32 dev lo

$ ./gtp-link add gtp1
WARNING: attaching dummy socket descriptors. Keep this process running  
for testing purposes.

$ ./gtp-tunnel add gtp1 v1 200 100 172.99.0.2 172.0.0.2
$ ip route add 172.99.0.2/32 dev gtp1

$ ./gtp-tunnel list
version 1 tei 200/100 ms_addr 172.99.0.2 sgsn_addr 172.0.0.2

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN  
group default qlen 1000
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
     inet 172.99.0.1/32 scope global lo
        valid_lft forever preferred_lft forever
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
7: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state  
UP group default qlen 1000
     link/ether 08:35:71:ab:54:5f brd ff:ff:ff:ff:ff:ff
     inet 172.0.0.1/24 scope global enp9s0
        valid_lft forever preferred_lft forever
8: gtp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 0 qdisc noqueue  
state UNKNOWN group default qlen 1000
     link/none

$ ip route
default via 192.168.1.1 dev enp2s0 proto static metric 100
172.0.0.0/24 dev enp9s0 proto kernel scope link src 172.0.0.1
172.99.0.2 dev gtp1 scope link

$ ping 172.99.0.2
PING 172.99.0.2 (172.99.0.2) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable




From laforge at osmocom.org  Tue Jul  7 14:19:49 2020
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 7 Jul 2020 16:19:49 +0200
Subject: Network is unreachable error for GTP interface
In-Reply-To: <20200706190024.Horde.A9x9JusmIIuO_9QOsdjLPRD@webmail.itu.edu.tr>
References: <20200706190024.Horde.A9x9JusmIIuO_9QOsdjLPRD@webmail.itu.edu.tr>
Message-ID: <20200707141949.GD4411@nataraja>

Hi Avatli,

can you please explain what exactly you are trying to do?

What is your overall goal? Which software do you want to use as GGSN/P-GW?

In case you assume that GTP is symmetric and that you can simply establish GTP
tunnels with some command line tunnels between two linux machines: That's not the case.

GTP exists to dynamically manage [lots of] per-subscriber tunnels, all of which
are represented within one GTP "link" by the kernel GTP module.

You always need a userspace application implementing the control plane instance
(GTP-C v1 for GGSN, v2 for P-GW).  And even with that, it always only implements the
GGSN / P-GW side and not the SGSN / S-GW side.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From avatli at itu.edu.tr  Tue Jul  7 15:31:30 2020
From: avatli at itu.edu.tr (avatli at itu.edu.tr)
Date: Tue, 07 Jul 2020 18:31:30 +0300
Subject: Network is unreachable error for GTP interface
In-Reply-To: <20200707141949.GD4411@nataraja>
References: <20200706190024.Horde.A9x9JusmIIuO_9QOsdjLPRD@webmail.itu.edu.tr>
 <20200707141949.GD4411@nataraja>
Message-ID: <20200707183130.Horde.fKUDY0zrAzyyrd7Y8Vmpr3I@webmail.itu.edu.tr>

Hi Harald

I am not concerned with the control-plane. Briefly I want to run the  
setup on the link [1] on two different servers.

I tried to explain in the previous e-mail, but I think the ping  
packets do not reach the GTP module. I get error "network is  
unreachable" when I ping ms_addr on the other machine.

What I find difficult to understand is that I cannot see network  
packets in any interface, also there are no errors in the system. This  
problem probably has nothing to do with the GTP module. How can I  
solve this problem?

Thanks in advance

[1]  
https://www.slideshare.net/mobile/kentaroebisawa/using-gtp-on-linux-with-libgtpnl

- Volkan



From avatli at itu.edu.tr  Fri Jul 17 15:29:51 2020
From: avatli at itu.edu.tr (avatli at itu.edu.tr)
Date: Fri, 17 Jul 2020 18:29:51 +0300
Subject: Basic testing for Kernel GTP-U is not up to date
Message-ID: <20200717182951.Horde.SCRWaPhfXt3AnkA8s-Tl05G@webmail.itu.edu.tr>

Hello


I tried to follow the steps in the basic testing below but it is not  
up-to-date

https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing

To make the setup work, I execute the GGSN on the host by using  
osmo-ggsn/doc/examples/osmo-ggsn.cfg. I changed the "gtp bind-ip" to  
172.31.1.1, "ip prefix dynamic" to 192.168.71.0/24, "ip ifconfig" to  
192.168.71.0/24 and then execute the emulated SGSN inside the sgsn  
namespace (ip netns exec sgsn sgsnemu -d -r 172.31.1.1 -l 172.31.1.2  
--defaultroute --createif). In this case; GGSN can create PDP Context  
successful but there is not any GTP tunnel. How can I get the  
up-to-date version of this document? or how can I run the basic  
testing steps?

Thanks in advance.

- Volkan




From pespin at sysmocom.de  Fri Jul 17 16:06:06 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 17 Jul 2020 18:06:06 +0200
Subject: Basic testing for Kernel GTP-U is not up to date
In-Reply-To: <20200717182951.Horde.SCRWaPhfXt3AnkA8s-Tl05G@webmail.itu.edu.tr>
References: <20200717182951.Horde.SCRWaPhfXt3AnkA8s-Tl05G@webmail.itu.edu.tr>
Message-ID: <069b60bd-5208-b3d3-b272-32974af07d60@sysmocom.de>

Hi,

what to do mean with the "there is not any GTP tunel"?
How is the PDP context created if it is not negotiated inside the tunnel?

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From avatli at itu.edu.tr  Fri Jul 17 16:55:13 2020
From: avatli at itu.edu.tr (avatli at itu.edu.tr)
Date: Fri, 17 Jul 2020 19:55:13 +0300
Subject: Basic testing for Kernel GTP-U is not up to date
In-Reply-To: <069b60bd-5208-b3d3-b272-32974af07d60@sysmocom.de>
References: <20200717182951.Horde.SCRWaPhfXt3AnkA8s-Tl05G@webmail.itu.edu.tr>
 <069b60bd-5208-b3d3-b272-32974af07d60@sysmocom.de>
Message-ID: <20200717195513.Horde.0P6nrjG5sQItf76RbegUOAC@webmail.itu.edu.tr>

Hello

I tried to verify the existance of the GTP tunnel end of the steps  
with "gtp-tunnel list" but there is not any tunnel.

- Volkan

Al?nt? Pau Espin Pedrol <pespin at sysmocom.de>:

> Hi,
>
> what to do mean with the "there is not any GTP tunel"?
> How is the PDP context created if it is not negotiated inside the tunnel?
>
> --
> - Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
> =======================================================================
> * sysmocom - systems for mobile communications GmbH
> * Alt-Moabit 93
> * 10559 Berlin, Germany
> * Sitz / Registered office: Berlin, HRB 134158 B
> * Geschaeftsfuehrer / Managing Director: Harald Welte





From laforge at osmocom.org  Fri Jul 17 18:25:50 2020
From: laforge at osmocom.org (Harald Welte)
Date: Fri, 17 Jul 2020 20:25:50 +0200
Subject: Osmocom scheduled outage on *2020-07-19 9am CEST*
Message-ID: <20200717182550.GN132470@nataraja>

There is an urgent need to migrate our most important public
infrastructure to a new server, and I will be doing that on 
*Sunday, July 19 2020*, starting about 9am CEST.

The migration involves redmine (main osmocom.org website), jenkins, gerrit,
git, and cgit.

In theory, the migration should be quick. I would expect (significantly)
less than one hour of downtime.  However, we all know Murphys law.

Services not affected are mail (including mailman lists), ftp, dns.  So in case
of doubt, we can still use mailing lists to communicate.

In case anyone urgently needs osmocom source code on Sunday morning
during the downtime: There are public mirrors available on github.

Regards,
	Harald

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From ebiken.g at gmail.com  Sat Jul 18 10:55:00 2020
From: ebiken.g at gmail.com (Kentaro Ebisawa)
Date: Sat, 18 Jul 2020 19:55:00 +0900
Subject: Network is unreachable error for GTP interface
Message-ID: <b8ee07a8-ddae-99c2-94c1-766e7fff790d@gmail.com>

Hi,

http://lists.osmocom.org/pipermail/osmocom-net-gprs/2020-July/001151.html
(Sorry I could not respond to the original email to show this in thread)

I have confirmed that "ping: sendmsg: Network is unreachable" could be reproduced on Ubuntu 18.04.4 with Kernel 4.15.0-111-generic, while it does not (could ping through gtp tunnel) on 4.15.0-76-generic.

To be more specific, the issue is GTP packet would not be created even if I send packet with destination IP address matching <ms-addr> to gtp link using 4.15.0-111-generic. (and most likely on later versions)
However, when I switch kernel version to 4.15.0-76-generic on the same host, it will generate GTP packet with exactly the same rule configured to the GTP link.

I have created GTP tunnel using command below.
> ./gtp-link add gtp1
> ./gtp-tunnel add gtp1 v1 200 100 172.99.0.2 172.0.0.2
and sent packet with dst IP 172.99.0.2, which is same as the ms-addr in the above rule.

I have monitored veth1 using "tcpdump -n -i veth1" and GTP packet will be captured on 4.15.0-76-generic, but not on 4.15.0-111-generic.

Can anyone think of the difference between the two kernel or gtp module version?


### FYI: list of commands to create gtp link, tunnel rule and routing entry to route packet to gtp link.

# Create veth pair so GTP packet can flow within the host.
ip link add veth1 type veth peer name veth2
ip addr add 172.0.0.1/24 dev veth1
ip link set veth1 up
ip addr add 172.99.0.1/32 dev lo

# Create gtp link, gtp1
./gtp-link add gtp1
WARNING: attaching dummy socket descriptors. Keep this process running for testing purposes.

-- open new terminal --

# Create tunnel rule from netns default to ns2
./gtp-tunnel add gtp1 v1 200 100 172.99.0.2 172.0.0.2
./gtp-tunnel list
version 1 tei 200/100 ms_addr 172.99.0.2 sgsn_addr 172.0.0.2

# Add route to navigte packets to 172.99.0.2 (ms-addr) via gtp1
ip route add 172.99.0.2/32 dev gtp1

# Create netns ns2 to receive GTP packets.
ip netns add ns2
ip link set veth2 netns ns2
ip netns exec ns2 ip addr add 172.0.0.2/24 dev veth2
ip netns exec ns2 ip link set veth2 up
ip netns exec ns2 ip addr add 172.99.0.2/32 dev lo
ip netns exec ns2 ip link set lo up

# Create gtp link, gtp2
ip netns exec ns2 ./gtp-link add gtp2
WARNING: attaching dummy socket descriptors. Keep this process running for testing purposes.

-- open new terminal --

# Create tunnel rule from netns ns2 to default
ip netns exec ns2 ./gtp-tunnel add gtp2 v1 100 200 172.99.0.1 172.0.0.1

# Add route to navigte packets to 172.99.0.1 (ms-addr) via gtp2
ip netns exec ns2 ip route add 172.99.0.1/32 dev gtp2

# Send ping ...
$ ping 172.99.0.2

# error below will shown on Kernel 4.15.0-111-generic.
$ ping 172.99.0.2
PING 172.99.0.2 (172.99.0.2) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable

# GTP packet will be generated and ping success on Kernel 4.15.0-76-generic
$ ping 172.99.0.2
PING 172.99.0.2 (172.99.0.2) 56(84) bytes of data.
64 bytes from 172.99.0.2: icmp_seq=1 ttl=64 time=0.130 ms
64 bytes from 172.99.0.2: icmp_seq=2 ttl=64 time=0.035 ms

Thanks,
-- 
Kentaro Ebisawa <ebiken.g at gmail.com>


From laforge at osmocom.org  Sun Jul 19 10:54:23 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sun, 19 Jul 2020 12:54:23 +0200
Subject: Osmocom scheduled outage on *2020-07-21 7.30am CEST*
In-Reply-To: <20200717182550.GN132470@nataraja>
References: <20200717182550.GN132470@nataraja>
Message-ID: <20200719105423.GA132470@nataraja>

Dear Osmocom community,

the migration to the new server has completed today.  All services are up and running.

There will be another scheduled outage on
	Tuesday, July 21 at 7.30am CEST

This second outage is to migrate the old server IP addresses to the new server,
which appears to involve physical relocation between racks.

Happy hacking!

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From donal.crowley at onissolutions.com  Tue Jul 21 03:15:08 2020
From: donal.crowley at onissolutions.com (Donal  Crowley)
Date: Tue, 21 Jul 2020 03:15:08 +0000
Subject: Getting "Operation Not Permitted" When Running gtp-link
Message-ID: <BLAPR15MB37634B4A0122B42AB6D2A316FB780@BLAPR15MB3763.namprd15.prod.outlook.com>

Hi all,

I am running an opensource 5G Core however I cannot get my UPF up and running ads the GTP links and tunnels I am trying to create are failing with ?Operation Not Permitted?.

I?ll recompile again to run through GDB but would really like to hear back if you guys have seen this before on Ubuntu 18.04 (Kernel > 5)

Any help would be appreciated

Donal

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20200721/94b5ca2d/attachment.htm>