osmocom-net-gprs January 2022

osmocom-net-gprs@lists.osmocom.org

5 participants
12 discussions

RFC: unit tests for kernel GTP module
by Harald Welte 31 Dec '25

31 Dec '25

Dear GTP-interested folks, I would love to somehow get towards some degree of unit testing (or even "continuous integration") for teh kernel GTP code. We currently have the original code in the kernel, we had some recent small fixes and now are getting more patches into place. With relatively few active users out there (and probably none of them in production yet), it's particularly easy to introduce regressions while working on the code. Also, having tested new code even against a test set with limited covrage could help to get more confidence in new patches and thus get them merged sooner. Using tools like sgsnemu of OpenGGSN and the command line tools included in libgtpnl, it should be possibel to cook up some scripts for testing. Even the most basic set of tests would be an improvement over what we have now. One could also think about pcap replay to test with hand-crafted or real-world packets from other GTP implementations. As much as I'd like to put something like this into place myself, I don't think I will be able to work much on this in the near future. The GTP module at this point is a pure hobby and contrary to some years ago while I started it, I don't have any contract work in the GTP area at this point, so other projects currently unfortunately get more attention. So in case somebody among the GTP-interested parties (Travelping, OAI, ...) would want to do something in terms of testing, I'd be more than happy if somebody would step ahead. Otherwise it's all just vapourware going to end up on my ever-growing TODO list :/ Also, if netdev folks have some ideas/pointers about possible frameworks/tools for this kind of testing [it must exist for at least some other kernel networking code?]: Please let me know. I'd be interested to have a look if there's something that can be used as a basis (starting network namespaces, sending/transmitting packets, test case startup/teardown, ...) My "old school" approach would have been to start one or multiple user-mode-linux kernels (those that are to be tested), and then have scripts that set up a gtp socket and gtp tunnels via the libgtp command line tools, and throw packets at that. But I'm sure there must be quite powerful frameworks for that kind of testing in the 21st century? How do other tunneling implementations handle this? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 5

OsmoDevCon 2022 ?
by Harald Welte 10 Mar '22

10 Mar '22

Dear fellow Osmocom developers, as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021, trying to compensate it at least to some extent with our OsmoDevCall every two weeks. The COVID-19 pandemic is far from over, and we don't know what the upcoming winter season will bring. Nevertheless, I think it would be a good idea to start a discussion of whether we should plan for an OsmoDevCon in 2022. I personally would say let's plan for the usual late April 2022 time frame, and if the pandemic situation deteriorates, we can still cancel it with something like one month lead time. I would also personally suggest to limit attendance to people who are fully vaccinated, and in addition do a self-test for all participants every morning. In terms of venue, we might also consider to move to a venue that allows better ventilation. Irrespective of the above we can also bring the air filters from the sysmocom office. So with that as an input statement, I would like to hear your opinion on the above proposals. Who would want to attend? Any complaints against the "vaccinated only plus daily self-tests in the morning" approach? 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 7

[RFC PATCH net-next v3 1/5] gtp: Allow to create GTP device without FDs
by Marcin Szycik 12 Feb '22

12 Feb '22

From: Wojciech Drewek <wojciech.drewek(a)intel.com> Currently, when the user wants to create GTP device, he has to provide file handles to the sockets created in userspace (IFLA_GTP_FD0, IFLA_GTP_FD1). This behaviour is not ideal, considering the option of adding support for GTP device creation through ip link. Ip link application is not a good place to create such sockets. This patch allows to create GTP device without providing IFLA_GTP_FD0 and IFLA_GTP_FD1 arguments. If the user does not provide file handles to the sockets, then GTP module takes care of creating UDP sockets by itself. Sockets are created with the commonly known UDP ports used for GTP protocol (GTP0_PORT and GTP1U_PORT). In this case we don't have to provide encap_destroy because no extra deinitialization is needed, everything is covered by udp_tunnel_sock_release. Signed-off-by: Wojciech Drewek <wojciech.drewek(a)intel.com> --- drivers/net/gtp.c | 74 ++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 67 insertions(+), 7 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 24e5c54d06c1..a2ad0af913cb 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -66,8 +66,10 @@ struct gtp_dev { struct sock *sk0; struct sock *sk1u; + u8 sk_created; struct net_device *dev; + struct net *net; unsigned int role; unsigned int hash_size; @@ -320,8 +322,16 @@ static void gtp_encap_disable_sock(struct sock *sk) static void gtp_encap_disable(struct gtp_dev *gtp) { - gtp_encap_disable_sock(gtp->sk0); - gtp_encap_disable_sock(gtp->sk1u); + if (gtp->sk_created) { + udp_tunnel_sock_release(gtp->sk0->sk_socket); + udp_tunnel_sock_release(gtp->sk1u->sk_socket); + gtp->sk_created = false; + gtp->sk0 = NULL; + gtp->sk1u = NULL; + } else { + gtp_encap_disable_sock(gtp->sk0); + gtp_encap_disable_sock(gtp->sk1u); + } } /* UDP encapsulation receive handler. See net/ipv4/udp.c. @@ -664,9 +674,6 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, struct gtp_net *gn; int hashsize, err; - if (!data[IFLA_GTP_FD0] && !data[IFLA_GTP_FD1]) - return -EINVAL; - gtp = netdev_priv(dev); if (!data[IFLA_GTP_PDP_HASHSIZE]) { @@ -677,6 +684,8 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, hashsize = 1024; } + gtp->net = src_net; + err = gtp_hashtable_new(gtp, hashsize); if (err < 0) return err; @@ -844,6 +853,38 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, return sk; } +static struct sock *gtp_encap_create_sock(int type, struct gtp_dev *gtp) +{ + struct udp_tunnel_sock_cfg tuncfg = {}; + struct udp_port_cfg udp_conf = { + .local_ip.s_addr = htonl(INADDR_ANY), + .family = AF_INET, + }; + struct net *net = gtp->net; + struct socket *sock; + int err; + + if (type == UDP_ENCAP_GTP0) + udp_conf.local_udp_port = GTP0_PORT; + else if (type == UDP_ENCAP_GTP1U) + udp_conf.local_udp_port = GTP1U_PORT; + else + return ERR_PTR(-EINVAL); + + err = udp_sock_create(net, &udp_conf, &sock); + if (err) + return ERR_PTR(err); + + tuncfg.sk_user_data = gtp; + tuncfg.encap_type = type; + tuncfg.encap_rcv = gtp_encap_recv; + tuncfg.encap_destroy = NULL; + + setup_udp_tunnel_sock(net, sock, &tuncfg); + + return sock->sk; +} + static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) { struct sock *sk1u = NULL; @@ -868,11 +909,30 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) } } + if (!data[IFLA_GTP_FD0] && !data[IFLA_GTP_FD1]) { + sk0 = gtp_encap_create_sock(UDP_ENCAP_GTP0, gtp); + if (IS_ERR(sk0)) + return PTR_ERR(sk0); + + sk1u = gtp_encap_create_sock(UDP_ENCAP_GTP1U, gtp); + if (IS_ERR(sk1u)) { + udp_tunnel_sock_release(sk0->sk_socket); + return PTR_ERR(sk1u); + } + gtp->sk_created = true; + } + if (data[IFLA_GTP_ROLE]) { role = nla_get_u32(data[IFLA_GTP_ROLE]); if (role > GTP_ROLE_SGSN) { - gtp_encap_disable_sock(sk0); - gtp_encap_disable_sock(sk1u); + if (gtp->sk_created) { + udp_tunnel_sock_release(sk0->sk_socket); + udp_tunnel_sock_release(sk1u->sk_socket); + gtp->sk_created = false; + } else { + gtp_encap_disable_sock(sk0); + gtp_encap_disable_sock(sk1u); + } return -EINVAL; } } -- 2.31.1

4 7

[RFC PATCH net-next v2 1/5] gtp: Allow to create GTP device without FDs
by Marcin Szycik 27 Jan '22

27 Jan '22

3 2

[RFC PATCH net-next v3 2/5] gtp: Add support for checking GTP device type
by Marcin Szycik 27 Jan '22

27 Jan '22

From: Wojciech Drewek <wojciech.drewek(a)intel.com> Add a function that checks if a net device type is GTP. Signed-off-by: Wojciech Drewek <wojciech.drewek(a)intel.com> --- include/net/gtp.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/net/gtp.h b/include/net/gtp.h index 0e16ebb2a82d..ae915dd33d20 100644 --- a/include/net/gtp.h +++ b/include/net/gtp.h @@ -27,6 +27,12 @@ struct gtp1_header { /* According to 3GPP TS 29.060. */ __be32 tid; } __attribute__ ((packed)); +static inline bool netif_is_gtp(const struct net_device *dev) +{ + return dev->rtnl_link_ops && + !strcmp(dev->rtnl_link_ops->kind, "gtp"); +} + #define GTP1_F_NPDU 0x01 #define GTP1_F_SEQ 0x02 #define GTP1_F_EXTHDR 0x04 -- 2.31.1

1 0

[RFC PATCH net-next v2 2/5] gtp: Add support for checking GTP device type
by Marcin Szycik 27 Jan '22

27 Jan '22

1 0

lists.osmocom.org migrated to mailman3
by Harald Welte 03 Jan '22

03 Jan '22

Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, 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

None
by None 03 Jan '22

03 Jan '22

RLC/MAC layer in real networks is always used in acknowledged/reliable mode, and LLC is always only used in unreliable (UI) mode. The reason for this is that TCP cannot deal with the enormous packet loss that GPRS or similar radio links pose. If TCP would be exposed to the real packet loss, it would stall way too much. So my rationale was to use the same while creating osmo-sgsn. We use LLC in UI mode. Or are we talking about something completely else? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

None
by None 03 Jan '22

03 Jan '22

* With multiple TBF assignment the tbf_by_tlli will return a list =A0 anyway. * For the multiple RACH cases we could it probably handle it more =A0 nicely. E.g. avoid this: <0005> bts.cpp:1035 Got RACH from TLLI=3D0xcf7611f6 while TBF(TFI=3D0= TLLI=3D0xcf7611f6 DIR=3DDL) still exists. Killing pending DL TBF <0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=3Dcf7611f6 does not = exit -- - Holger Freyther <<a href=3D"mailto:hfreyther@sysmocom.de">hfreyther@sy= smocom.de</a>> =A0 =A0 =A0 <a href=3D"http://www.sysmocom.de/" target=3D= "_blank">http://www.sysmocom.de/</a> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte </blockquote></div> </div> --20cf301d42625eb38c04ea05cbef--

1 0

None
by None 03 Jan '22

03 Jan '22

* With multiple TBF assignment the tbf_by_tlli will return a list anyway. * For the multiple RACH cases we could it probably handle it more nicely. E.g. avoid this: <0005> bts.cpp:1035 Got RACH from TLLI=0xcf7611f6 while TBF(TFI=0 TLLI=0xcf7611f6 DIR=DL) still exists. Killing pending DL TBF <0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=cf7611f6 does not exit -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs January 2022