osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

1 participants
483 discussions

GSM, GPRS
by Сергей Егоров 20 Sep '20

20 Sep '20

Hi! I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE. While communication MS and Osmocom base station (BS) we've got the LLC-message: LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434 with the following parameters: Cipher Algorithm: GEA3 Kc_GPRS: A8FC3A996A80D000 SAPI: 1 NU: 3 IOV_UI: 0 OC: 0 After applying algorithm GEA3 we've got deciphered LLC-message: LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal. While communication MS and the real BS we've got the following LLC-message: LLC MESSAGE (ciphered) 41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35 with the following parameters: Cipher Algorithm: GEA3 KC_GPRS: 8f94a69c3d9bdf48 SAPI: 1 NU: 2 IOV_UI: 0x10000000 (got from XID) OC: from 0 to 8388608 So we tried to apply the OC parameter from 0 to 8388608 to decipher the message (other parameters were not been changed). In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success. Finally the question: Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how?? With regards, students of the telecommunication department. Thank you for your attention! Best regards, Sergei ----------------------------------------------------------------------

2 1

GSM, GPRS
by Сергей Егоров 18 Sep '20

18 Sep '20

Good afternoon! I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE. While communication MS and Osmocom base station (BS) we've got the LLC-message: LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434 with the following parameters: Cipher Algorithm: GEA3 Kc_GPRS: A8FC3A996A80D000 SAPI: 1 NU: 3 IOV_UI: 0 OC: 0 After applying algorithm GEA3 we've got deciphered LLC-message: LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal. While communication MS and the real BS we've got the following LLC-message: LLC MESSAGE (ciphered) 41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35 with the following parameters: Cipher Algorithm: GEA3 KC_GPRS: 8f94a69c3d9bdf48 SAPI: 1 NU: 2 IOV_UI: 0x10000000 (got from XID) OC: from 0 to 8388608 So we tried to apply the OC parameter from 0 to 8388608 to decipher the message (other parameters were not been changed). In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success. Finally the question: Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how?? With regards, students of the telecommunication department. Thank you for your attention! Best regards, Sergei ----------------------------------------------------------------------

1 0

OsmoDevCon / COVID-19
by Harald Welte 04 Sep '20

04 Sep '20

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)

1 0

[PATCH net-next 0/2] gtp: minor enhancements
by Nicolas Dichtel 31 Aug '20

31 Aug '20

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

2 3

[PATCH net-next] gtp: add notification mechnism
by Nicolas Dichtel 27 Aug '20

27 Aug '20

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

3 12

[PATCH net] gtp: add GTPA_LINK info to msg sent to userspace
by Nicolas Dichtel 25 Aug '20

25 Aug '20

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

2 1

GTP tunnel seems to exist, but No encapsulation when using libgtpnl
by Papa Tana 23 Aug '20

23 Aug '20

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,

3 11

Getting "Operation Not Permitted" When Running gtp-link
by Donal Crowley 21 Jul '20

21 Jul '20

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

1 0

Osmocom scheduled outage on *2020-07-19 9am CEST*
by Harald Welte 19 Jul '20

19 Jul '20

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)

1 1

Network is unreachable error for GTP interface
by avatli＠itu.edu.tr 18 Jul '20

18 Jul '20

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

3 3

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs