Dear Osmocom Community,
I hope this message finds you well.
I am currently setting up a testing environment to evaluate the performance of my Packet Gateway (PGW) in terms of maximum simultaneous active sessions and bandwidth.
The architecture of my test setup includes: VM osmo-ttcn3: Hosts the TTCN-3 framework, which initiates GTP-C session creation and integrates with the osmo-uecups solution to simulate user sessions by sending ICMP echo requests (pings) to public IP addresses (e.g., 8.8.8.8). VM osmo-uecups: Manages network namespaces (netns), each representing a simulated user session. VM pgw: My Packet Gateway, handling the routing and forwarding of packets between the simulated users and the external network via the GTP-U protocol.
Issue Encountered: While using the TTCN-3/PGW test suite scripts that execute ping tests inside each created GTP tunnel, I observed the following on the osmo-uecups VM: ICMP echo requests are successfully sent from the netns and are visible in tcpdump captures both inside each netns and on the physical interfaces of the osmo-uecups VM. ICMP echo replies are sent back by my PGW for each UE session, and I can see them when capturing traces on the physical interface of the osmo-uecups VM. However, these ICMP echo replies are not injected into each netns. When capturing tcpdump inside each netns, I can see the ICMP echo requests but no corresponding replies. This behavior results in ping test failures in the TTCN-3 test suite, as the echo replies do not reach the originating netns.
Additional Context: Initially, when running the test suite, I encountered the following error in the osmo-uecups-daemon logs: DEP NOTICE X.X.X.X:2152: Unexpected GTP Flags: 0x32 (gtp_endpoint.c:59) Upon investigation, I found that this was due to my PGW including a sequence number in the GTP-U header, resulting in a flag value of 0x32. To address this, I manually modified the gtp_endpoint.c file to accept this flag. After this adjustment, the "Unexpected GTP Flags: 0x32" message no longer appears. However, despite resolving this issue, the ping tests continue to fail because the ICMP echo replies are not being injected back into the respective netns. Additionally, I now receive the following message in the osmo-uecups-daemon log: DEP NOTICE X.X.X.X:2152: Short GTP Message: 98 < len=96 (gtp_endpoint.c:74)
I would greatly appreciate any guidance or suggestions you can provide to help resolve this issue.
Please find below the configuration changes I made in the gtp_endpoint.c file:: ************************************************************************************** /* check GTP header contents */ if (gtph->flags != 0x30 && gtph->flags != 0x32) { LOGEP(ep, LOGL_NOTICE, "Unexpected GTP Flags: 0x%02x\n", gtph->flags); continue; } ////////////////////////////// unsigned int hdr_len = sizeof(*gtph); if (gtph->flags & 0x02) { hdr_len += 2; // Si le flag Sequence est activé }
/* Vérifie que la longueur totale attendue (header + payload) est présente */ if (hdr_len + ntohs(gtph->length) > nread) { LOGEP(ep, LOGL_NOTICE, "Shotr GTP Message: %u < len=%d\n", hdr_len + ntohs(gtph->length), nread); continue; }
/* Transmission du payload au TUN device à partir de l'offset hdr_len */ rc = write(outfd, buffer+hdr_len, ntohs(gtph->length)); ***********************************************************************************
Thank you for your time and assistance.
Best regards, Imen Boufares
Hi Imen,
osmo-uecups is a very niche tool, which sysmocom developed internally as a tool for testing. It is doing what we needed it to do, and it gets used continuously for what we wrote it.
sysmocom does not earn any money with that tool, nor the test suite, yet both are developed as open source and available to the wider community "as-is".
I doubt it is used widely (or at all) by anyone else so far, and it's sadly highly unlikely that you would find someone here who would be willing to investigate any issues you encounter in their spare time, sorry.
In case this is a commercial requirement, feel free to reach out to sales@sysmocom.de to acquire paid support services.
Having said that, we're of course happy to review and merge any patches you might want to submit to help us improve the tool.
Kind regards, Harald
osmocom-net-gprs@lists.osmocom.org