Multicast Ipv6

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
1.9.3.10904
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Hello,

We are trying to capture the ipv6 multicast traffic from a device.

Due to other reasons we configured a network bridge in netplan that includes the interfaces mgbe1_0, mgbe3_0, eqos_0 and also the USB interface (via an Ethernet to USB adapter).

This configuration works as expected when connecting devices that are sending ipv4 multicast messages, which are observable in wireshark.

When trying to detect ipv6 multicast messages from another device, wireshark reveals no messages at all for mgbe1_0, mgbe3_0 or eqos_0.

Only when connecting to USB via an USB to Ethernet adapter, the traffic is immediately captured, although the USB interface is apparently not configured differently than the other interfaces and is also included in the network bridge.

So we wondered if the internal switch might need additional configuration (already tried different ip configurations, ranges etc.).

Can you confirm this and/or please provide an instruction on how to properly do that?

Thank you very much for your support.

Dear @sebbe,
Could you share the details of config changes needed in netplan and configuring bridge?

Could you share details on how you are testing this? which device is connected ? Have you used any tool or command or application to send ipv4 multicast messages.

Dear @SivaRamaKrishnaNV ,

thank you very much for the fast reply.

The netplan configuration looks basically as follows:


network:
  version: 2
  renderer: networkd
  ethernets:
    eqos_0:
      dhcp4: false
      dhcp6: false
      mtu: ...

# The identical settings are used for mgbe1_0, mgbe3_0 and the USB interface enxa[...]...

# Bridge Configuration
# ---------------------

bridges:
  br0:
     dhcp4: false
     dhcp6: false
     interfaces:
       - eqos_0
       - mgbe1_0
       - mgbe3_0
       - enxa[...] ...
     addresses:
       - 192.XXX.XXX.XX0/24
     mtu: ...

I cannot reveal too many details about the connected devices, but referring to the working ones, it is simply broadcasting udp packages over the broadcast address 239.XXX… over the network, which are then observable in wireshark and further utilized in other applications of ours.

The other device is similar but using ipv6 multicast message to basically achieve the same.

Physically connecting its data output to one of the ethernet/mgbe interfaces (mgbe1_0, mgbe3_0, eqos_0) does not result in any observable udp traffic in wireshark.

Switching the connection to one of the USB ports (via Ethernet adapter) while everything is running, the desired udp packages are displayed in wireshark or tcpdump.

Additional question related to this topic:

Is it possible to reconfigure/access the internal switch directly to e.g. implement individual port rules?

Can Wireshack successfully capture IPv6 packets sent by the ping command? have you observed the IPv6 multicasting issue on the default setup, prior to implementing the netplan configuration?

Dear @VickNV

thanks for the reply.

Regardless of how I setup the interfaces in terms of Ipv6, I am not able to ping anything or observe the related messages in wireshark.

(i.e. cannot ping6 mgbe1_0 from eqos_0 although interfaces are up and in same ipv6 network).

Can you maybe please provide a minimal working configuration for ip (addresses and prefixes) so that at least the ping between interfaces (on Orin and/or connected external Linux PC) can be ultimately confirmed working/not working?

If I recall correctly, even before applying the netplan configuration, the same behaviour was observed.

IPv6 ping should be working on the default DRIVE OS 6.0.8.1 setup. Please try testing it immediately after flashing the system to ensure the basic configuration is functional.

We reflashed the Orin.

Connecting an external Linux PC we were able to ping6 using the link-local address.

In the meantime we figured out why the traffic from the device was not observable at all:

It seems to be configured for VLAN with a special ID.

Adding mgbe1_0 to a VLAN with this ID in the configuration yaml and applying the changes via netplan apply the desired traffic pops up in wireshark.

But keeping this exact configuration and restarting the Orin, the messages are not observable anymore.
Even when reapplying the netplan configuration.

It seems that it only works when starting the Orin without configuring vlan for the interface, manually adjusting the configuration file while running and then apply the changes made in the configuration file.

As mentioned, when using a USB-to-Ethernet Adapter and/or testing on other Linux machines by simply connecting, the traffic is visible without further manual configuration.

The latter also works quite reliably but is currently not an option for us.

We already checked and compared resulting configurations (working vs non-working | USB vs Ethernet) with ip and had a look at different sysctl net.X settings/files, but were not able to identify an obvious reason for the observed behavior.

Are there other sources left to be checked or configured?

Thank you very much for your support.

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Could you provide the steps and relevant configuration files needed to reproduce this issue? This information will help us better understand the problem and assist you more effectively. Thank you!