ristsender/ristreceiver in tunnel mode has error with oob channel

I have been experimenting with the rist tools to utilize a tunnel like this video I found on youtube: https://www.youtube.com/watch?v=_WIeUo6jpLg. I am running into an issue with the oob channel that is used for the tunnel. I have tried ffmpeg test pattern, vlc with h.265 video, netcat and ICMP all hit the same error going through the oob channel.

I start the sender and receiver as such:

# on sender side
sudo ./ristsender -t tun11 -m 0 -i "tun://@" -o "rist://192.168.0.102:9995" -v 4 -p 1

# on receiver side
sudo ./ristreceiver -t tun11 -m 0 -i "rist://@0.0.0.0:9995" -o "tun://@" -v 6 -p 1

I added a few more debugging lines to the ristreceiver in the rist_validate_tun_data() and am seeing the following happen when the code looks at the IP header to validate the IP Version.

1712466315.296136|0.0|[INFO] Unknown ipv? payload 0
1712466315.296323|0.0|[INFO] Detected protocol 0 with payload length 16384 in buffer of size 1152

I tried this with Ubuntu and Centos 7, RHEL 8 and got the same results. It seems like from the log above that the IP header isn't actually being processed correctly. Please help me understand if this is not the case. I put details on my testing below

More details regarding tunnel and tcpdump data

Creating Tunnels:

• On sender side ./create_tunnel.sh 10.0.0.1 10.0.0.2 YOUR_INTERFACE
• On receiver side ./create_tunnel.sh 10.0.0.2 10.0.0.1 YOUR_INTERFACE

#!/bin/bash -x

IP_HOST=$1
IP_REMOTE=$2
NETWORK_INTERFACE=$3

ip tuntap add mode tun dev tun11
ip addr add $IP_HOST/24 dev tun11
ifconfig tun11 mtu 1400
ip link set dev tun11 up

# add proxy arp
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/tun11/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/$NETWORK_INTERFACE/proxy_arp

# Add route
ip route add $IP_REMOTE/32 via $IP_HOST

I used the following ffmpeg to play a test pattern through the oob channel

# on sender
sudo ffmpeg   -f lavfi   -i testsrc=size=800x600:rate=24   -c:v libx264   -tune zerolatency   -pix_fmt yuv420p   -profile:v baseline   -b:v 300K   -minrate 100K   -maxrate 1M   -bufsize 2M   -g 24   -f mpegts  udp://10.0.0.2:9996   

When doing a TCP dump on the video data I see the following.

# Video going into tunnel
IP length is between 1396 and 968
UDP length is between 1368 and 940

# Going across as rist
IP length is between 1428 and 1000 (with most being 1156)
UDP length  is between 1400 and 972

# On the receiver side as rist
Is the same as sender side. No data is written to the receiver side tunnel
1712466315.296136|0.0|[INFO] Unknown ipv? payload 0
1712466315.296323|0.0|[INFO] Detected protocol 0 with payload length 16384 in buffer of size 1152

When running this it looked like all the lengths were off by 4. (1156 vs 1152)
Example: 1392 in the logs on the receiver but 1396 from the tcpdump on the sender. 

The interesting thing is when doing the same test so udp is not going over the oob channel by using (-m 1 or -m 2) there is no error processing the data because the oob channel is not used.

# Video going into tunnel
IP length is between 1396 and 968
UDP length is between 1368 and 940

# Going across as rist
IP length is between 1452 and 1000
UDP length  is between 1400 and 972

# On the receiver side as rist
Is the same as sender side. 

# Data on the receiver side tun11 looking good. No error logs from rist_validate_tun_data
Matches the size of the original data going into the tunnel

However, when doing a ping across in any tunnel mode (since it goes through the oob channel). I see the same rist_validate_tun_data errors

# For Ping 10.0.0.2 from sender
22:31:56.889201 IP (tos 0x0, ttl 64, id 57193, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.0.1 > 10.0.0.2: ICMP echo request, id 22494, seq 35, length 64

# As sender
Ip length is 124
UDP length is 96

# Same is seen from from rist data on the receiver side
IP length is 124
UDP length is 96

1712468098.963076|0.0|[INFO] Unknown ipv? payload 0
1712468098.963174|0.0|[INFO] Detected protocol 0 with payload length 16384 in buffer of size 80

With the original ICMP IP packet of 84 and the seeing the ristreceiver log that the read packet into the buffer has a size of 80. It seems like 4 bytes from the original packet is being lost. This explains why the IP version is not 4.

changed title from ristsender/ristreceiver in tunnel mode has error with oob socket to ristsender/ristreceiver in tunnel mode has error with oob channel

changed the description

changed the description