Problems with new UDP multicast streams on Xavier

I am having problems with UDP multicast streams on Xavier. For some reason, Xavier does not see the UDP streams from the first shot. If I run gst-discoverer-1.0, first time it does not detect the stream, but if I run it once more, it detects it. Afterwards, Xavier sees that stream all the time.

nvidia@jetson-0423418009834:~$ gst-discoverer-1.0 udp://239.1.1.1:1111
Analyzing udp://239.1.1.1:1111
Done discovering udp://239.1.1.1:1111
Analyzing URI timed out

nvidia@jetson-0423418009834:~$ gst-discoverer-1.0 udp://239.1.1.1:1111
Analyzing udp://239.1.1.1:1111
NvMMLiteOpen : Block : BlockType = 261
NvMMLiteBlockCreate : Block : BlockType = 261
Allocating new output: 1920x1088 (x 9), ThumbnailMode = 0
Over-riding video dimension with display dimensionOPENMAX: HandleNewStreamFormat: 3528: Send OMX_EventPortSettingsChanged: nFrameWidth = 1920, nFrameHeight = 1080
NVMEDIA: cbDisplayPicture: 1738: Retunred NULL Frame Buffer
Done discovering udp://239.1.1.1:1111
Missing plugins

Topology:
  container: MPEG-2 Transport Stream
    audio: MPEG-2 AAC
      audio: MPEG-4 AAC
    video: H.264 (Main Profile)
    unknown: meta/x-klv

Properties:
  Duration: 99:99:99.999999999
  Seekable: no
  Live: yes
  Tags:
      audio codec: MPEG-2 AAC
      minimum bitrate: 64500
      maximum bitrate: 64500
      bitrate: 64537
      video codec: H.264

If I try udp://239.2.2.2:2222, same thing will happen, since this is a new stream for Xavier. Same thing happens with ffprobe and with my GStreamer pipeline that works with UDP multicast streams. I have no similar problems on other devices (one of them is Jetson TX2) on my local network.
This happens for all streams (different addresses, streaming different videos) that I tried.

When this happens, netstat -g shows that Xavier did join to the multicast group, but watch netstat -sanu shows that almost no UDP packets are reaching to the Xavier??

Here is my ifconfig output:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.200.223  netmask 255.255.255.0  broadcast 192.168.200.255
        inet6 fe80::1543:f2b2:c303:c519  prefixlen 64  scopeid 0x20<link>
        ether 00:04:4b:cb:a0:23  txqueuelen 1000  (Ethernet)
        RX packets 9215484  bytes 11289201138 (11.2 GB)
        RX errors 0  dropped 36  overruns 0  frame 0
        TX packets 752456  bytes 510674275 (510.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 40

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 3991  bytes 412584 (412.5 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3991  bytes 412584 (412.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I see the kernel does support multicast (it’s a Linux thing, not really dependent upon Jetsons). Looks like there would be other configuration on top of this. I don’t enough about the setup to say for sure, but this seems to be promising (sysctl.conf configuration):
https://serverfault.com/questions/163244/linux-kernel-not-passing-through-multicast-udp-packets

Incidentally, if you are not familiar with the sysctl.conf syntax, the entries refer the proc filesystem starting here:

/proc/sys/

An entry in sysctl.conf of “net.ipv4.conf” refers to:

/proc/sys/net/ipv4/conf/

Setings for this specific to eth0 can be found at:

/proc/sys/net/ipv4/conf/eth0/

This entry in sysctl.conf, if uncommented, “net.ipv4.conf.all.rp_filter=1”, could be verified via:

cat /proc/sys/net/ipv4/conf/all/rp_filter

For cases where a value can be changed at runtime (not all values can be changed while running), if rp_filter shows “1” and you wanted it to be “0” temporarily (good for testing…change disappears upon reboot, sysctl.conf can be used to keep a change):

sudo echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Note: There may be differences in setup between multicast UDP and TCP configuration, but I couldn’t tell you what those differences are.

This didn’t help. Same problem occurs.

This could be related to many things. Maybe your switch/router? Maybe the linux kernel? Maybe the network card drivers?
Can you join the same multicast group the first time from a Linux machine running Ubuntu 18.04 on a laptop/desktop?
(Note: you have to run on bare metal, and boot the machine directly; VMs rely on the virtualization layer network stack which is different.)

I can join the same multicast group the first time from all other devices on my local network, including a Ubuntu18.04 desktop.

I also have a Jetson TX2 (Ubuntu 18.04) that works without this problem.

I was able to reproduce this problem on another Xavier.

On the other side, this problem does not occur when using an extern PCI-E Ethernet Adapter on Xavier. Could it be that this is a bug in Xavier’s network driver?

I couldn’t say for certain, but I highly suspect it is just a configuration or setup issue.