GTP-U doesn't seem to work on packets returned

[ikkag]

Hi, ueransim access successful

5: uesimtun0: <POINTOPOINT,PROMISC,NOTRAILERS,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.1.0.1/32 scope global uesimtun0 valid_lft forever preferred_lft forever

But can't access to internet

root@ueransim-ue-7fcb46b87c-6x2xx:/ueransim/build# ping -I uesimtun0 baidu.com PING baidu.com (110.242.68.66) from 10.1.0.1 uesimtun0: 56(84) bytes of data.

8 packets transmitted, 0 received, 100% packet loss, time 7162ms

And here is the tcpdump result in UPF

07:10:03.667048 IP 10.100.50.236.2152 > 10.100.50.233.2152: UDP, length 100 07:10:03.667048 IP 10.1.0.1 > 110.242.68.66: ICMP echo request, id 48, seq 8, length 64 07:10:03.667082 IP 192.168.179.12 > 110.242.68.66: ICMP echo request, id 48, seq 8, length 64 07:10:03.702681 IP 110.242.68.66 > 192.168.179.12: ICMP echo reply, id 48, seq 8, length 64 07:10:03.702724 IP 110.242.68.66 > 10.1.0.1: ICMP echo reply, id 48, seq 8, length 64 07:10:04.691158 IP 10.100.50.236.2152 > 10.100.50.233.2152: UDP, length 100 07:10:04.691158 IP 10.1.0.1 > 110.242.68.66: ICMP echo request, id 48, seq 9, length 64 07:10:04.691189 IP 192.168.179.12 > 110.242.68.66: ICMP echo request, id 48, seq 9, length 64 07:10:04.726920 IP 110.242.68.66 > 192.168.179.12: ICMP echo reply, id 48, seq 9, length 64 07:10:04.726969 IP 110.242.68.66 > 10.1.0.1: ICMP echo reply, id 48, seq 9, length 64

In which: 10.100.50.236 is the ip address of one network interface in gNb 10.100.50.233 is the ip address of one network interface in UPF, which is treated as GTP-U 10.1.01 is the ip address of UE. 192.168.179.12 is the ip address of upf.n6if.ipAddress 110.242.68.66 is the ip address of the website in DataNet We can see that packet can be transmitted from UPF to DataNet. So does the reply. But replay can't reach UE. I think the trace of icmp is like below: UE -> gNb -> GTP-U -> upf.n6if ->datanet -> upf.n6if And in pod UPF, seems like that the packet can't be handled by GTP-U

Below if the configuration of UPF

global: projectName: free5gc userPlaneArchitecture: single # possible values are "single" and "ulcl" uesubnet: 10.1.0.0/16

Global network parametes

n4network: name: n4network masterIf: ens33 subnetIP: 10.100.50.240 cidr: 29 gatewayIP: 10.100.50.246 excludeIP: 10.100.50.246 n3network: name: n3network masterIf: ens33 subnetIP: 10.100.50.232 cidr: 29 gatewayIP: 10.100.50.238 excludeIP: 10.100.50.238 n6network: name: n6network masterIf: ens33 subnetIP: 192.168.179.0 cidr: 24 gatewayIP: 192.168.179.2 excludeIP: 192.168.179.254 n9network: name: n9network masterIf: ens33 subnetIP: 10.100.50.224 cidr: 29 gatewayIP: 10.100.50.230 excludeIP: 10.100.50.230

upf: name: upf replicaCount: 1 image: name: towards5gs/free5gc-upf pullPolicy: Always configmap: name: upf-configmap volume: name: upf-volume mount: /free5gc/config/

n3if: # GTP-U ipAddress: 10.100.50.233 n4if: # PFCP ipAddress: 10.100.50.241 n6if: # DN ipAddress: 192.168.179.12

[ikkag]

I just find that all packets whose dst is ue will pass to upfgtp. And packets received by upfgtp are in state of error. I don't know how to handle the carrier error since all the interfaces run on virtual machine

upfgtp: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1464 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 57 bytes 4788 (4.7 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 57 dropped 0 overruns 0 carrier 57 collisions 0

[jmarkotic]

Hi, did you find solution ? I seem to have exactly the same issue. Although I had it working in similar <1yr ago without any problem.

[jmarkotic]

i downloaded helm chart 1.0.0 and it is working. I don't see problem with returned GTP-U traffic entering upfgtp in reverse direction. Which makes sense since this is version i sued some tiem ago and had it working from the start.

[pirog-spb]

@ikkag Could you please check dmesg log for upf container? Are there records like Unknown RAN address?

[pirog-spb]

Just FYI. In our case the problem was old gtp5g driver. And we encountered Tx carrier erros as well. You have to use gtp5g from free5gc project rather that from other repos.

[5glabadmin]

@pirog-spb AWESOME! you nailed it!!!

[raoufkh]

Hi @ikkag @jmarkotic

Does the installation of gtp module from free5GC's repo make it work?

Bests Abderaouf

[5glabadmin]

Hi Abderaouf,

Yes it did for me. I can now get ping replies on UE.

Raj

From: Abderaouf KHICHANE @.> Sent: Tuesday, February 28, 2023 8:19 AM To: Orange-OpenSource/towards5gs-helm @.> Cc: Kitindi, Rajabu @.>; Comment @.> Subject: [EXT] Re: [Orange-OpenSource/towards5gs-helm] GTP-U doesn't seem to work on packets returned (Issue #64)

Hi @ikkaghttps://github.com/ikkag @jmarkotichttps://github.com/jmarkotic

Does the installation of gtp module from free5GC's repo make it work?

Bests Abderaouf

— Reply to this email directly, view it on GitHubhttps://github.com/Orange-OpenSource/towards5gs-helm/issues/64#issuecomment-1448168624, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A32JTKRDLY7BIEXM67RT5TDWZX3OBANCNFSM6AAAAAASZATKEU. You are receiving this because you commented.Message ID: @.**@.>>

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.

Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see www.deloitte.com/about to learn more.

v.E.1

[raoufkh]

Great! I will close this issue

[5glabadmin]

Awesome!

Thank you! Raj

From: Abderaouf KHICHANE @.> Sent: Tuesday, February 28, 2023 9:32 AM To: Orange-OpenSource/towards5gs-helm @.> Cc: Kitindi, Rajabu @.>; Comment @.> Subject: [EXT] Re: [Orange-OpenSource/towards5gs-helm] GTP-U doesn't seem to work on packets returned (Issue #64)

Great! I will close this issue

— Reply to this email directly, view it on GitHubhttps://github.com/Orange-OpenSource/towards5gs-helm/issues/64#issuecomment-1448286352, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A32JTKTE7SZY3RCBTN4D3KTWZYD5NANCNFSM6AAAAAASZATKEU. You are receiving this because you commented.Message ID: @.**@.>>

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.

Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see www.deloitte.com/about to learn more.

v.E.1