Hello,
I am testing the documented srsRAN 4G 5G SA E2E setup with:
srsENB + srsUE- Open5GS 5GC
- ZMQ RF
- loopback addressing
The control plane works correctly:
- UE attaches successfully
- PDU session is created
- UE receives an IPv4 address
- NGAP procedures complete successfully
However, the user plane fails. The issue appears to be that srsENB creates the GTP-U tunnel with the TEID assigned by the core, but later sends UL traffic using TEID 0x1 instead of the created UL TEID. As a result, the Open5GS UPF replies with GTP-U Error Indication, and IPv4 traffic such as ping 10.45.0.1 never succeeds.
Environment
- Ubuntu 24.04
- Open5GS
v2.7.7
srsRAN_4G tested from a clean tree- Also reproduced after switching away from
master
- ZMQ transport
- Loopback-based setup
Open5GS addresses
- AMF:
127.0.0.5
- SMF:
127.0.0.4
- UPF PFCP/GTP-U:
127.0.0.7
srsENB config
mme_addr = 127.0.0.5
gtp_bind_addr = 127.0.1.1
s1c_bind_addr = 127.0.1.1
Observed behavior
1. UPF creates session successfully
[upf] INFO: [Added] Number of UPF-Sessions is now 1
[upf] INFO: UE F-SEID[UP:0x4b5 CP:0xdec] APN[srsapn] PDN-Type[1] IPv4[10.45.0.2] IPv6[]
[gtp] INFO: gtp_connect() [127.0.1.1]:2152
2. UPF then reports Error Indication for the session TEID
[upf] ERROR: [127.0.0.7] Send Error Indication [TEID:0xc3b8] to [127.0.1.1]
3. srsENB says the tunnel was created with TEID Out=0xc3b8
[GTPU] New tunnel created - TEID In=0x1, TEID Out=0xc3b8, rnti=0x4601, eps-BearerID=1, remote addr=127.0.0.7
4. But when UL traffic is actually sent, srsENB logs:
[GTPU] Tx S1-U SDU, UL > 127.0.0.7:0x1, rnti=0x4601, eps-BearerID=1, n_bytes=84, IPv4 10.45.0.2 > 10.45.0.1
So the tunnel is created with TEID Out=0xc3b8, but the UL packet appears to be sent using 0x1.
tcpdump evidence
A capture on loopback shows UL traffic from 127.0.1.1:2152 to 127.0.0.7:2152, followed immediately by a short response from the UPF consistent with GTP-U Error Indication.
Example:
127.0.1.1.2152 > 127.0.0.7.2152 UDP, length 92
127.0.0.7.2152 > 127.0.1.1.2152 UDP, length 28
In the captured GTP-U packet, the encapsulated payload is a normal IPv4 ICMP Echo Request from the UE IP toward the gateway, so the problem is not the inner payload itself.
Reproduction summary
- Start Open5GS 5GC
- Start
srsENB
- Start
srsUE
- Wait for attach + PDU session establishment
- From UE namespace, run:
-
Observe:
- session establishment succeeds
- UL user-plane traffic is sent
- UPF sends Error Indication
- ping fails
Expected behavior
After tunnel setup with TEID Out=<assigned_teid>, uplink GTP-U traffic should be sent using that assigned UL TEID, and UE traffic such as ping 10.45.0.1 should pass.
Actual behavior
srsENB creates a tunnel with one TEID, but uplink traffic appears to use 0x1, causing the UPF to reject it.
Additional note
At this point, AMF/SMF/UPF addressing and PFCP association look correct. The failure only appears when the first real UL user-plane packet is sent.
Please let me know if you want the full logs, packet capture, exact commit hash, or a minimal reproducer.
Thanks.
Hello,
I am testing the documented srsRAN 4G 5G SA E2E setup with:
srsENB+srsUEThe control plane works correctly:
However, the user plane fails. The issue appears to be that
srsENBcreates the GTP-U tunnel with the TEID assigned by the core, but later sends UL traffic using TEID0x1instead of the created UL TEID. As a result, the Open5GS UPF replies with GTP-U Error Indication, and IPv4 traffic such asping 10.45.0.1never succeeds.Environment
v2.7.7srsRAN_4Gtested from a clean treemasterOpen5GS addresses
127.0.0.5127.0.0.4127.0.0.7srsENB config
Observed behavior
1. UPF creates session successfully
2. UPF then reports Error Indication for the session TEID
3. srsENB says the tunnel was created with
TEID Out=0xc3b84. But when UL traffic is actually sent, srsENB logs:
So the tunnel is created with
TEID Out=0xc3b8, but the UL packet appears to be sent using0x1.tcpdump evidence
A capture on loopback shows UL traffic from
127.0.1.1:2152to127.0.0.7:2152, followed immediately by a short response from the UPF consistent with GTP-U Error Indication.Example:
In the captured GTP-U packet, the encapsulated payload is a normal IPv4 ICMP Echo Request from the UE IP toward the gateway, so the problem is not the inner payload itself.
Reproduction summary
srsENBsrsUEObserve:
Expected behavior
After tunnel setup with
TEID Out=<assigned_teid>, uplink GTP-U traffic should be sent using that assigned UL TEID, and UE traffic such asping 10.45.0.1should pass.Actual behavior
srsENBcreates a tunnel with one TEID, but uplink traffic appears to use0x1, causing the UPF to reject it.Additional note
At this point, AMF/SMF/UPF addressing and PFCP association look correct. The failure only appears when the first real UL user-plane packet is sent.
Please let me know if you want the full logs, packet capture, exact commit hash, or a minimal reproducer.
Thanks.