During a dump, this attribute is essential, it enables the userspace to
know on which interface the context is linked to.
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com>
Tested-by: Gabriel Ganne <gabriel.ganne(a)6wind.com>
---
I target this to net, because I think this is a bug fix. The dump result cannot
be used if there is more than one gtp interface on the system.
drivers/net/gtp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c
index 21640a035d7d..8e47d0112e5d 100644
--- a/drivers/net/gtp.c
+++ b/drivers/net/gtp.c
@@ -1179,6 +1179,7 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq,
goto nlmsg_failure;
if (nla_put_u32(skb, GTPA_VERSION, pctx->gtp_version) ||
+ nla_put_u32(skb, GTPA_LINK, pctx->dev->ifindex) ||
nla_put_be32(skb, GTPA_PEER_ADDRESS, pctx->peer_addr_ip4.s_addr) ||
nla_put_be32(skb, GTPA_MS_ADDRESS, pctx->ms_addr_ip4.s_addr))
goto nla_put_failure;
--
2.26.2
Hi All,
This is my first post, I have a similar problem to the topic "Network
is unreachable error for GTP interface".
I followed all instructions, installed all needed dependencies,
upgrade my kernel version to 4.9.0-6 as stated in
https://osmocom.org/projects/openggsn/wiki/Kernel_GTP
Unfortunately, no GTP T-PDU encapsulation for my packets.
## Tunnel listing is OK
root@routeurA:/home/bob/libgtpnl/tools# ./gtp-tunnel list
version 1 tei 200/100 ms_addr 172.23.10.163 sgsn_addr 10.11.12.14
## I have upgraded my Kernel version to 4.9.0-6 as stated in
https://osmocom.org/projects/openggsn/wiki/Kernel_GTP
At the time of writing (2018-04-26) of this wiki, below listed
distributions have support of GTP kernels :
Debian
Debian 9 "stretch" (kernel 4.9.0-6)
root@routeurA:/home/bob/libgtpnl/tools# uname -r
4.9.0-6-amd64
## GTP module
root@routeurA:/home/bob/libgtpnl/tools# lsmod | grep gtp
gtp 28672 0
udp_tunnel 16384 1 gtp
## ping remote ms_addr is not ok
root@routeurA:/home/bob/libgtpnl/tools# ping 172.23.10.163
PING 172.23.10.163 (172.23.10.163) 56(84) bytes of data.
^C
--- 172.23.10.163 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
## remove the route using "gtpa" device
root@routeurA:/home/bob/libgtpnl/tools# ip route del 172.23.10.163/32 dev gtpa
## add new route using normal interface
root@routeurA:/home/bob/libgtpnl/tools# ip route add 172.23.10.163/32
via 10.11.12.14
## ping is OK
root@routeurA:/home/bob/libgtpnl/tools# ping 172.23.10.163
PING 172.23.10.163 (172.23.10.163) 56(84) bytes of data.
64 bytes from 172.23.10.163: icmp_seq=1 ttl=64 time=0.592 ms
64 bytes from 172.23.10.163: icmp_seq=2 ttl=64 time=0.713 ms
## remove again the route
root@routeurA:/home/bob/libgtpnl/tools# ip route del 172.23.10.163/32
## switch it to "gtpa" device
root@routeurA:/home/bob/libgtpnl/tools# ip route add 172.23.10.163/32 dev gtpa
root@routeurA:/home/bob/libgtpnl/tools# ping 172.23.10.163
PING 172.23.10.163 (172.23.10.163) 56(84) bytes of data.
^C
## tcpdump shows ICMP between the 2 ms_addr, no encapsulation at all
Am I missing something somewhere?
FYI, I'm not using openggsn or ergw, I have developped my small
userspace GTP-C ready, but I'm stuck at GTP-U side.
Thanks in advance,
Best Regards,
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
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(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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(a)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
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
*Hi, Osmocom-SGSN*
I have downloaded latest master branch sources for TTCN3 tests.
I followed instructions for compilations and dependencies.
In file :
*regen_makefile.sh *
If line with
../regen-makefile.sh SGSN_Tests.ttcn $FILES
is replaced with
../regen-makefile.sh $FILES
then this warning is not present
File `SGSN_Tests.ttcn' was given more than once for the Makefile.
Also,
after command
*make compile *
*(same with *
*make sgsn *
*from upper dir.)*
I got from output:
....
GSM_RR_Types.ttcn:404.2-408.2: In type definition `SecondPartAssign':
GSM_RR_Types.ttcn:409.18-20: error: in variant attribute, at or before
token `CSN': syntax error, unexpected XIdentifier, expecting $end
GSM_RR_Types.ttcn:510.2-512.2: In type definition `IaRestOctLL':
GSM_RR_Types.ttcn:513.42-44: error: in variant attribute, at or before
token `CSN': syntax error, unexpected XIdentifier, expecting $end
GSM_RR_Types.ttcn:588.2-594.2: In type definition `IaRestOctets':
GSM_RR_Types.ttcn:595.23-25: error: in variant attribute, at or before
token `CSN': syntax error, unexpected XIdentifier, expecting $end
........
Notify: Errors found in the input modules. Code will not be generated.
make: *** [Makefile:206: compile] Error 1
Last time in April, I played with TTCN3 for SGSN, everything was good.
Can you help me with this ?