my tx2 version is L4T R28.2.1，Using the development board.
I want to use network multicast,The server always sends data out, and the client never receives data for the first time. After the program is shutdown, it can be received normally after running again.
but in the R32.2.1 this situation did not appear, how should I solve this problem.
I won’t be able to answer, but you will need to give a detailed description of the devices on the network, and devices in-between the relevant devices. Multicast is kind of a specialty protocol where everything in the chain of devices must understand the protocol. Sometimes a related issue as simple as an ARP cache, or a delay in updating multicast subscriptions.
Two tx2 devices are directly connected.and the ip address are manually set to 192.168.1.11 and 192.168.1.22.
The multicast address range is 224.0.0.0 ~ 239.255.255.255.
What is the tx2 NIC chip?
This is a third party Broadcom chip. See:
https://devtalk.nvidia.com/default/topic/1043649/jetson-tx2/jetson-tx2-ethernet-controller-device-id/post/5294944/#5294944
Looks like by default multicast is enabled:
CONFIG_IP_MULTICAST=y
And since both devices are directly connected, then the problem has to be specifically in one of the two devices. Likely it is at the receive end, and I believe that when you said shutting down and restarting fails, that the receive end is the Jetson…can I verify this is correct? Can I also verify you did not have this problem in R28.2.1, but do have a problem with R32.2.1?
If so, then more details on exactly what happens on restart on the failing R32.2.1 would be useful.
Which network driver is used by the tx2 network port?
When I first started receiving, I couldn’t receive data. Then I run the receiver again and I can receive data normally.
Yes, the sender and receiver are two jetson tx2.
In R28.2.1 have this problem.
R32.2.1 don’t have this problem.
You can verify it.
I see “ether_qos”, but I couldn’t tell you what the driver name is (ether_qos is from “/proc/interrupts”, and the IRQ is from “ifconfig”). Someone else may have more details than that.
Ok, so I had it reversed before, and the newer release fixes the issue, but the older release has the problem. I don’t know if the “fix” from older to newer was intentional, or if it was some side effect of other updates which was simply luck. Someone at NVIDIA would have to tell you if it was one of their changes which caused the multicast fix.
I hope I can get a reply soon.
Because I want to continue to use the R28.2.1 version.
thank you！
Although I cannot give you a definite answer, if the Linux kernel has multicast support (and any ability to receive or send multicast would say it does), then I suspect there is a multicast setup issue involved which may not be specific to the Jetson. However, someone else would still need to verify the ethernet hardware and driver combination does not have some sort of restriction which would prevent multicast.
Someone from NVIDIA might be able to elaborate on any networking changes between R28.2.1 and R32.2.1 and say if R28.2.1 had something missing.
I used another carrier board, which has two network ports, one for the tx2 and the other for the pcie network port.
In the R28.2.1 version，tx2 network port have this problem，the other one don’t have.
You’ve proven the software for multicast is present in the kernel. What we still don’t know is if there is additional setup required for the NVIDIA PHY, or if the hardware itself is not capable of multicast. Someone from NVIDIA would be required to answer that question.
Hi.
Could you share the exact step to setup and reproduce this issue? Do you see any error log from dmesg when you hit error? I would suggest also try rel-28.3 to narrow down if this patch is only applied to rel-32 or not.
Please note that rel-28.2.1 has been released for almost 2 years…