osmocom-net-gprs March 2022

osmocom-net-gprs@lists.osmocom.org

10 participants
7 discussions

RFC: unit tests for kernel GTP module
by Harald Welte 01 Jan '26

01 Jan '26

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

GTP echo implementation
by Neels Hofmeyr 27 Mar '22

27 Mar '22

I am currently adding GTP echo handling to osmo-upf, which uses the GTP kernel module to handle GTP G-PDUs. What I need is a GTPv1-U ECHO response when an GTPv1-U ECHO request comes in on the user land GTP socket. We already have GTP implementations in - libgtp (osmo-ggsn.git/gtp/) - gtp_echo_responder.c (osmo-ggsn.git/utils/) - osmo-hnodeb/gtp.c I first used libgtp to do GTP ECHO handling in osmo-upf, but that basically includes all of the GTP-C GSN code, in a rather inflexible way. It seems to work, but we don't want to include this clunky dependency. Looking at gtp_echo_responder.c, I see that the code uses none of the Osmocom structures (osmo_fd, logging, osmo_select, osmocom/core/endian.h), and it implements GTPv1-C and GTPv2-C, but I need GTPv1-U. osmo-hnodeb/gtp.c does use Osmocom structures. It has its own struct gtp1u_hdr. But apparently osmo-hnodeb doesn't do any GTP ECHO handling at all. So I need to dig deeper to understand the GTP Echo landscape... IIUC, there are GTPv0, GTPv1-C, GTPv1-U, GTPv2-C. 3GPP TS 29.281 is GTPv1-U. Is 29.060 GTPv1-C? Any others? I am now only concerned with GTPv1-U, so TS 29.281 should be all I need. Still interesting to know, do the echos differ between the protocol versions and planes? Can I use the GTPv1-C code from gtp_echo_responder.c for GTPv1-U? The fact that the GTPv1-U header contains a TEID confused me at first, then I found in 29.281 that the TEID shall be all zeros in the ECHO req + resp messages. So, yes, ECHO is done between GSNs as a whole, not on each tunnel. I think I am ok solving these questions, but am writing this specifically because it feels like I or at least the next person shouldn't have to re-invent this wheel yet again. Will we spawn all-new GTP implementations in every osmocom repository that touches GTP, or should I rather implement a re-usable GTP echo response now? One proper (TM) way seems to be to rearrange libgtp in such a way that a caller can just use the msg coding part for specific messages, and can use UDP sockets without having to set up a complete struct gsn_t. That's some work. Another way that comes to mind is opening a libosmo-gtp section in libosmocore, absorb protocol definitions across the various GTP versions there, and use them in the places where we do GTP coding now. Seems a lot of work. ...or I go the apparently quickest, easiest way, do a copy/paste/reimplement from scratch of GTP echo coding, so that we have yet another partial GTP implementation in osmo-upf.git. That's what I'm doing now, but it feels wrong. Any thoughts? ~N

2 1

[PATCH net-next] gtp: Remove a bogus tab
by Dan Carpenter 18 Mar '22

18 Mar '22

The "kfree_skb(skb_to_send);" is not supposed to be indented that far. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 756714d4ad92..a208e2b1a9af 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1793,7 +1793,7 @@ static int gtp_genl_send_echo_req(struct sk_buff *skb, struct genl_info *info) if (IS_ERR(rt)) { netdev_dbg(gtp->dev, "no route for echo request to %pI4\n", &dst_ip); - kfree_skb(skb_to_send); + kfree_skb(skb_to_send); return -ENODEV; } -- 2.20.1

3 2

[PATCH net-next 0/4][pull request] 100GbE Intel Wired LAN Driver Updates 2022-03-16
by Tony Nguyen 18 Mar '22

18 Mar '22

This series contains updates to gtp and ice driver. Wojciech fixes smatch reported inconsistent indenting for gtp and ice. Yang Yingliang fixes a couple of return value checks for GNSS to IS_PTR instead of null. Jacob adds support for trace events on tx timestamps. The following are changes since commit 49045b9c810cd9b4ac5f8f235ad8ef17553a00fa: Merge branch 'mediatek-next' and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE Jacob Keller (1): ice: add trace events for tx timestamps Wojciech Drewek (2): gtp: Fix inconsistent indenting ice: Fix inconsistent indenting in ice_switch Yang Yingliang (1): ice: fix return value check in ice_gnss.c drivers/net/ethernet/intel/ice/ice_gnss.c | 4 ++-- drivers/net/ethernet/intel/ice/ice_ptp.c | 8 +++++++ drivers/net/ethernet/intel/ice/ice_switch.c | 2 +- drivers/net/ethernet/intel/ice/ice_trace.h | 24 +++++++++++++++++++++ drivers/net/gtp.c | 2 +- 5 files changed, 36 insertions(+), 4 deletions(-) -- 2.31.1

3 6

[PATCH net-next v11 0/7][pull request] ice: GTP support in switchdev
by Tony Nguyen 12 Mar '22

12 Mar '22

Marcin Szycik says: Add support for adding GTP-C and GTP-U filters in switchdev mode. To create a filter for GTP, create a GTP-type netdev with ip tool, enable hardware offload, add qdisc and add a filter in tc: ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize> ethtool -K $PF0 hw-tc-offload on tc qdisc add dev $GTP0 ingress tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \ action mirred egress redirect dev $VF1_PR By default, a filter for GTP-U will be added. To add a filter for GTP-C, specify enc_dst_port = 2123, e.g.: tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \ enc_dst_port 2123 action mirred egress redirect dev $VF1_PR Note: outer IPv6 offload is not supported yet. Note: GTP-U with no payload offload is not supported yet. ICE COMMS package is required to create a filter as it contains GTP profiles. Changes in iproute2 [1] are required to be able to add GTP netdev and use GTP-specific options (QFI and PDU type). [1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel… --- v2: Add more CC v3: Fix mail thread, sorry for spam v4: Add GTP echo response in gtp module v5: Change patch order v6: Add GTP echo request in gtp module v7: Fix kernel-docs in ice v8: Remove handling of GTP Echo Response v9: Add sending of multicast message on GTP Echo Response, fix GTP-C dummy packet selection v10: Rebase, fixed most 80 char line limits v11: Rebase, collect Harald's Reviewed-by on patch 3 The following are changes since commit 59d5923536ac8640f4ff20d011a4851a3c143764: Merge branch 'ptp-ocp-new-firmware-support' and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue 100GbE Marcin Szycik (1): ice: Support GTP-U and GTP-C offload in switchdev Michal Swiatkowski (1): ice: Fix FV offset searching Wojciech Drewek (5): gtp: Allow to create GTP device without FDs gtp: Implement GTP echo response gtp: Implement GTP echo request net/sched: Allow flower to match on GTP options gtp: Add support for checking GTP device type drivers/net/ethernet/intel/ice/ice.h | 1 + .../net/ethernet/intel/ice/ice_flex_pipe.c | 53 +- .../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +- .../net/ethernet/intel/ice/ice_flex_type.h | 6 +- .../ethernet/intel/ice/ice_protocol_type.h | 19 + drivers/net/ethernet/intel/ice/ice_switch.c | 654 ++++++++++++++++-- drivers/net/ethernet/intel/ice/ice_switch.h | 9 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++- drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 + drivers/net/gtp.c | 565 +++++++++++++-- include/net/gtp.h | 42 ++ include/uapi/linux/gtp.h | 1 + include/uapi/linux/if_link.h | 2 + include/uapi/linux/if_tunnel.h | 4 +- include/uapi/linux/pkt_cls.h | 15 + net/sched/cls_flower.c | 116 ++++ 16 files changed, 1478 insertions(+), 119 deletions(-) -- 2.31.1

2 8

OsmoDevCon 2022 ?
by Harald Welte 11 Mar '22

11 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

[PATCH net-next v10 0/7] ice: GTP support in switchdev
by Marcin Szycik 10 Mar '22

10 Mar '22

Add support for adding GTP-C and GTP-U filters in switchdev mode. To create a filter for GTP, create a GTP-type netdev with ip tool, enable hardware offload, add qdisc and add a filter in tc: ip link add $GTP0 type gtp role <sgsn/ggsn> hsize <hsize> ethtool -K $PF0 hw-tc-offload on tc qdisc add dev $GTP0 ingress tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \ action mirred egress redirect dev $VF1_PR By default, a filter for GTP-U will be added. To add a filter for GTP-C, specify enc_dst_port = 2123, e.g.: tc filter add dev $GTP0 ingress prio 1 flower enc_key_id 1337 \ enc_dst_port 2123 action mirred egress redirect dev $VF1_PR Note: outer IPv6 offload is not supported yet. Note: GTP-U with no payload offload is not supported yet. ICE COMMS package is required to create a filter as it contains GTP profiles. Changes in iproute2 [1] are required to be able to add GTP netdev and use GTP-specific options (QFI and PDU type). [1] https://lore.kernel.org/netdev/20220211182902.11542-1-wojciech.drewek@intel… --- v2: Add more CC v3: Fix mail thread, sorry for spam v4: Add GTP echo response in gtp module v5: Change patch order v6: Add GTP echo request in gtp module v7: Fix kernel-docs in ice v8: Remove handling of GTP Echo Response v9: Add sending of multicast message on GTP Echo Response, fix GTP-C dummy packet selection v10: Rebase, fixed most 80 char line limits Marcin Szycik (1): ice: Support GTP-U and GTP-C offload in switchdev Michal Swiatkowski (1): ice: Fix FV offset searching Wojciech Drewek (5): gtp: Allow to create GTP device without FDs gtp: Implement GTP echo response gtp: Implement GTP echo request net/sched: Allow flower to match on GTP options gtp: Add support for checking GTP device type drivers/net/ethernet/intel/ice/ice.h | 1 + .../net/ethernet/intel/ice/ice_flex_pipe.c | 53 +- .../net/ethernet/intel/ice/ice_flex_pipe.h | 2 +- .../net/ethernet/intel/ice/ice_flex_type.h | 6 +- .../ethernet/intel/ice/ice_protocol_type.h | 19 + drivers/net/ethernet/intel/ice/ice_switch.c | 643 ++++++++++++++++-- drivers/net/ethernet/intel/ice/ice_switch.h | 9 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 105 ++- drivers/net/ethernet/intel/ice/ice_tc_lib.h | 3 + drivers/net/gtp.c | 565 +++++++++++++-- include/net/gtp.h | 42 ++ include/uapi/linux/gtp.h | 1 + include/uapi/linux/if_link.h | 2 + include/uapi/linux/if_tunnel.h | 4 +- include/uapi/linux/pkt_cls.h | 15 + net/sched/cls_flower.c | 116 ++++ 16 files changed, 1473 insertions(+), 113 deletions(-) -- 2.35.1

3 10

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs March 2022