The TUN ue1 interface does not receive ping reply after ZeroMQ successful attach

[jrmejiaa]

Issue Description

I am using the release release_20_10_1 to make a ZeroMQ Application using a VM in Openstack with Ubuntu 18.04 LTS. I made all the compilation process without problems and I use the configuration files that an user share in the issue #342. I am using a commercial EPC and the Attach process is working and the TUN interface receives an IP from the EPC. However, when I make a ping that the EPC should be seeing through the SGi the ping does not receive a reply.

I made a tcpdump directly in the TUN interface and I see there the reply, but I don't see it as response of the ping command.

# The UE has receive the 45.45.0.14
ubuntu@srs-ran-emulator:~$ sudo tcpdump -i ue1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ue1, link-type RAW (Raw IP), capture size 262144 bytes
13:33:59.831601 IP 45.45.0.14 > 172.30.1.2: ICMP echo request, id 14553, seq 78, length 64
13:33:59.857486 IP 172.30.1.2 > 45.45.0.14: ICMP echo reply, id 14553, seq 78, length 64
13:34:00.855794 IP 45.45.0.14 > 172.30.1.2: ICMP echo request, id 14553, seq 79, length 64
13:34:00.868459 IP 172.30.1.2 > 45.45.0.14: ICMP echo reply, id 14553, seq 79, length 64

Setup Details

• ZeroMQ Application Notes
• VM on Openstack with Ubuntu 18.04LTS with generic kernel 4.15.0-143-generic
• the configuration file of the UE is the next

ubuntu@srs-ran-emulator:~$ cat ue.conf
[usim]
# Here is the information of USIM to attach to the EPC
opc=E734F8734007D6C5CE7A0508809E7E9E
imsi=901700100001113
k=8BAF473F2F8FD09487CCCBD7097C6864

[rf]
# Here we need the srsENB IP and the srsUE IP to communicate between them.
# In this file the tx_port is the UE IP and the rx_port is the srsENB
device_name=zmq
device_args="tx_port=tcp://*:2001,rx_port=tcp://localhost:2000,id=ue,base_srate=23.04e6"

[gw]
# The name of the virtual interface
ip_devname=ue1
ip_netmask = 255.255.255.0

[phy]
nof_phy_threads=1

[log]
# It needs to define those logs to avoid huge logs after being use the srsUE
all_level = error
phy_lib_level = none
all_hex_limit = 32
filename = /tmp/ue.log
file_max_size = -1

Expected Behavior

The ping command should receive the reply of the IP and we can use it to send traffic, when I can see a reply in the tcpdump command:

# The UE has receive the 45.45.0.14
ubuntu@srs-ran-emulator:~$ sudo tcpdump -i ue1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ue1, link-type RAW (Raw IP), capture size 262144 bytes
13:33:59.831601 IP 45.45.0.14 > 172.30.1.2: ICMP echo request, id 14553, seq 78, length 64
13:33:59.857486 IP 172.30.1.2 > 45.45.0.14: ICMP echo reply, id 14553, seq 78, length 64
13:34:00.855794 IP 45.45.0.14 > 172.30.1.2: ICMP echo request, id 14553, seq 79, length 64
13:34:00.868459 IP 172.30.1.2 > 45.45.0.14: ICMP echo reply, id 14553, seq 79, length 64

Actual Behaviour

PING 172.30.1.2 (172.30.1.2) from 45.45.0.14 ue1: 56(84) bytes of data.
^C
--- 172.30.1.2 ping statistics ---
174 packets transmitted, 0 received, 100% packet loss, time 177144ms

[jgiovatto]

Seems like the issue is not with the UE or tuntap but IP stack. I'd check the routing table for source route drops, iptables and the eth addrs match up.

[jrmejiaa]

Hi @jgiovatto thanks for your answer, I was also thinking that, but I am not sure where is the problem, because everything what I see is ok. Those are the outputs that I could add. Do you have any idea?

List of all Iptables in the machine

ubuntu@srs-ran-emulator:~$ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 930K packets, 27G bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 930K packets, 27G bytes)
 pkts bytes target     prot opt in     out     source               destination

my table of rooting with the TUN ue1

ubuntu@srs-ran-emulator:~$ ip route 
default via 192.168.248.1 dev ens4 
default via 192.168.1.1 dev ens3 proto dhcp src 192.168.1.143 metric 100 
45.45.0.0/24 dev ue1 proto kernel scope link src 45.45.0.18 
169.254.169.254 via 192.168.248.2 dev ens4 
169.254.169.254 via 192.168.1.1 dev ens3 proto dhcp src 192.168.1.143 metric 100 
192.168.1.0/24 dev ens3 proto kernel scope link src 192.168.1.143 
192.168.248.0/24 dev ens4 proto kernel scope link src 192.168.248.218

response of cat /etc/iproute2/rt_tables

ubuntu@srs-ran-emulator:~$ cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

Output of arp -n and check of ip forwarding

ubuntu@srs-ran-emulator:~$ sudo arp -n 
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.248.2            ether   fa:16:3e:26:20:66   C                     ens4
192.168.248.1                    (incomplete)                              ens4
192.168.1.114            ether   fa:16:3e:8c:4b:99   C                     ens3
192.168.248.30           ether   fa:16:3e:fd:98:60   C                     ens4
192.168.1.2              ether   fa:16:3e:75:c6:55   C                     ens3
192.168.1.1              ether   fa:16:3e:80:59:c9   C                     ens3
ubuntu@srs-ran-emulator:~$ cat /proc/sys/net/ipv4/ip_forward
1

[jgiovatto]

So it seems like there are 3 points of interest ue <---> epc <---> ping host. Im not sure which is which from the description above but check which interface 172.30.1.2 address is associated with according to the routing table from end to end so nothing is dropped due to src route check also that ip_forwarding is on at the epc.

[jrmejiaa]

Hi @jgiovatto , but the ping is that I show you and the tcpdump capture is directly in the TUN interface that the srsRAN creates. So what you are saying is that something in the middle (the EPC) is changing something that makes that the TUN interface does not match with the received packet?

Because the packet is arriving to the interface, but maybe it is not recognize from the TUN interface.

[modyngs]

@jgiovatto Hi,

Have you tested your setup with COTs UE?

[jrmejiaa]

Hi @modyngs I don't have a COTs UE to test, I am doing just without the Hardware because I don't have any SDR.

[jrmejiaa]

Close by inactivity.