osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

482 discussions

by Harald Welte

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. 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)

4 years, 11 months

[PATCH net-next 0/2] gtp: minor enhancements

by Nicolas Dichtel

The first patch removes a useless rcu lock and the second relax alloc constraints when a PDP context is added. drivers/net/gtp.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) Comments are welcomed, Nicolas

4 years, 11 months

[PATCH net-next] gtp: add notification mechnism

by Nicolas Dichtel

Like all other network functions, let's notify gtp context on creation and deletion. Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Tested-by: Gabriel Ganne <gabriel.ganne(a)6wind.com> --- drivers/net/gtp.c | 58 +++++++++++++++++++++++++++++++++------- include/uapi/linux/gtp.h | 2 ++ 2 files changed, 51 insertions(+), 9 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 8e47d0112e5d..360c1dc9381e 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -928,8 +928,8 @@ static void ipv4_pdp_fill(struct pdp_ctx *pctx, struct genl_info *info) } } -static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, - struct genl_info *info) +static struct pdp_ctx *gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, + struct genl_info *info) { struct pdp_ctx *pctx, *pctx_tid = NULL; struct net_device *dev = gtp->dev; @@ -956,12 +956,12 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, if (found) { if (info->nlhdr->nlmsg_flags & NLM_F_EXCL) - return -EEXIST; + return ERR_PTR(-EEXIST); if (info->nlhdr->nlmsg_flags & NLM_F_REPLACE) - return -EOPNOTSUPP; + return ERR_PTR(-EOPNOTSUPP); if (pctx && pctx_tid) - return -EEXIST; + return ERR_PTR(-EEXIST); if (!pctx) pctx = pctx_tid; @@ -974,13 +974,13 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, netdev_dbg(dev, "GTPv1-U: update tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); - return 0; + return pctx; } pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) - return -ENOMEM; + return ERR_PTR(-ENOMEM); sock_hold(sk); pctx->sk = sk; @@ -1018,7 +1018,7 @@ static int gtp_pdp_add(struct gtp_dev *gtp, struct sock *sk, break; } - return 0; + return pctx; } static void pdp_context_free(struct rcu_head *head) @@ -1036,9 +1036,12 @@ static void pdp_context_delete(struct pdp_ctx *pctx) call_rcu(&pctx->rcu_head, pdp_context_free); } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd); + static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) { unsigned int version; + struct pdp_ctx *pctx; struct gtp_dev *gtp; struct sock *sk; int err; @@ -1088,7 +1091,13 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } - err = gtp_pdp_add(gtp, sk, info); + pctx = gtp_pdp_add(gtp, sk, info); + if (IS_ERR(pctx)) { + err = PTR_ERR(pctx); + } else { + gtp_tunnel_notify(pctx, GTP_CMD_NEWPDP); + err = 0; + } out_unlock: rcu_read_unlock(); @@ -1159,6 +1168,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) netdev_dbg(pctx->dev, "GTPv1-U: deleting tunnel id = %x/%x (pdp %p)\n", pctx->u.v1.i_tei, pctx->u.v1.o_tei, pctx); + gtp_tunnel_notify(pctx, GTP_CMD_DELPDP); pdp_context_delete(pctx); out_unlock: @@ -1168,6 +1178,14 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) static struct genl_family gtp_genl_family; +enum gtp_multicast_groups { + GTP_GENL_MCGRP, +}; + +static const struct genl_multicast_group gtp_genl_mcgrps[] = { + [GTP_GENL_MCGRP] = { .name = GTP_GENL_MCGRP_NAME }, +}; + static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, int flags, u32 type, struct pdp_ctx *pctx) { @@ -1205,6 +1223,26 @@ static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, return -EMSGSIZE; } +static int gtp_tunnel_notify(struct pdp_ctx *pctx, u8 cmd) +{ + struct sk_buff *msg; + int ret; + + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); + if (!msg) + return -ENOMEM; + + ret = gtp_genl_fill_info(msg, 0, 0, 0, cmd, pctx); + if (ret < 0) { + nlmsg_free(msg); + return ret; + } + + ret = genlmsg_multicast_netns(&gtp_genl_family, dev_net(pctx->dev), msg, + 0, GTP_GENL_MCGRP, GFP_ATOMIC); + return ret; +} + static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx = NULL; @@ -1335,6 +1373,8 @@ static struct genl_family gtp_genl_family __ro_after_init = { .module = THIS_MODULE, .ops = gtp_genl_ops, .n_ops = ARRAY_SIZE(gtp_genl_ops), + .mcgrps = gtp_genl_mcgrps, + .n_mcgrps = ARRAY_SIZE(gtp_genl_mcgrps), }; static int __net_init gtp_net_init(struct net *net) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index c7d66755d212..79f9191bbb24 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -2,6 +2,8 @@ #ifndef _UAPI_LINUX_GTP_H_ #define _UAPI_LINUX_GTP_H_ +#define GTP_GENL_MCGRP_NAME "gtp" + enum gtp_genl_cmds { GTP_CMD_NEWPDP, GTP_CMD_DELPDP, -- 2.26.2

4 years, 11 months

[PATCH net] gtp: add GTPA_LINK info to msg sent to userspace

by Nicolas Dichtel

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

4 years, 11 months

GTP tunnel seems to exist, but No encapsulation when using libgtpnl

by Papa Tana

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,

4 years, 11 months

Getting "Operation Not Permitted" When Running gtp-link

by Donal Crowley

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

5 years

Osmocom scheduled outage on *2020-07-19 9am CEST*

by Harald Welte

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)

5 years

Network is unreachable error for GTP interface

by avatli＠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(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

5 years

Basic testing for Kernel GTP-U is not up to date

by avatli＠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

5 years

[PATCH AUTOSEL 5.6 121/606] gtp: set NLM_F_MULTI flag in gtp_genl_dump_pdp()

by Sasha Levin

From: Yoshiyuki Kurauchi <ahochauwaaaaa(a)gmail.com> [ Upstream commit 846c68f7f1ac82c797a2f1db3344a2966c0fe2e1 ] In drivers/net/gtp.c, gtp_genl_dump_pdp() should set NLM_F_MULTI flag since it returns multipart message. This patch adds a new arg "flags" in gtp_genl_fill_info() so that flags can be set by the callers. Signed-off-by: Yoshiyuki Kurauchi <ahochauwaaaaa(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 672cd2caf2fb..21640a035d7d 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1169,11 +1169,11 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) static struct genl_family gtp_genl_family; static int gtp_genl_fill_info(struct sk_buff *skb, u32 snd_portid, u32 snd_seq, - u32 type, struct pdp_ctx *pctx) + int flags, u32 type, struct pdp_ctx *pctx) { void *genlh; - genlh = genlmsg_put(skb, snd_portid, snd_seq, &gtp_genl_family, 0, + genlh = genlmsg_put(skb, snd_portid, snd_seq, &gtp_genl_family, flags, type); if (genlh == NULL) goto nlmsg_failure; @@ -1227,8 +1227,8 @@ static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) goto err_unlock; } - err = gtp_genl_fill_info(skb2, NETLINK_CB(skb).portid, - info->snd_seq, info->nlhdr->nlmsg_type, pctx); + err = gtp_genl_fill_info(skb2, NETLINK_CB(skb).portid, info->snd_seq, + 0, info->nlhdr->nlmsg_type, pctx); if (err < 0) goto err_unlock_free; @@ -1271,6 +1271,7 @@ static int gtp_genl_dump_pdp(struct sk_buff *skb, gtp_genl_fill_info(skb, NETLINK_CB(cb->skb).portid, cb->nlh->nlmsg_seq, + NLM_F_MULTI, cb->nlh->nlmsg_type, pctx)) { cb->args[0] = i; cb->args[1] = j; -- 2.25.1

5 years, 1 month

← Newer
1
...
10
11
12
13
14
15
16
...
49
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs