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
Hi Neels,
On Thu, Mar 24, 2022 at 11:29:20PM +0100, Neels Hofmeyr wrote:
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.
yes, look at the license. It was specifically created to be used under permissive license (MIT) and hence cannot use the existing libosmo* infrastructure. This is also outlined in the commit message: https://gerrit.osmocom.org/c/osmo-ggsn/+/25652
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.
The latter part is likely a bug, and should be addressed.
Though, to be honest, I'm not 100% sure if the use of GTP-U on any other interface than that between GSNs (SGSN/SGW and GGSN/PGW) mandates GTP ECHO support...
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?
GTPv0 is not really relevant anymore in 99.9% of all situations. GTPv1C and GTPv2C are completely differnt protocols. GTP-U v1 is used by GTPv1C and GTPv2C as well as on many other interfaces that don't use GTP-C for the control plane.
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.
ACK.
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?
to be fair, responding to a GTP-U echo request is hardly a very complex task.
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.
I think libgtp is fundamentlaly un-osmocom-like due to its history and it doesn't make sense to spend time on it.
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.
I would say for the struct definitions it would make sense to put it in include/osmocom/gsm/protocol/ or even better include/osmocom/gprs/protocol/
osmo-hnodeb and osmo-upf could then use that code. But that's about it.
...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.
In general, I hear you, but in this case "partial" means 0.01% of what GTP is...
osmocom-net-gprs@lists.osmocom.org
-
Harald Welte -
Neels Hofmeyr