[Attempting To Do] :
Transmit a video feed over multicast message from a device to my Tx2 without having to set promisc or allmulti on
[What is the issue?]
If my interface is in promisc, the multicast data for my video feed is received correctly by my application, else it’s just discarded silently at NIC level. I have tried to plug a USB-Ethernet adapter to replace the NIC logic and the multicast works as expected so I was wondering why the native NIC firmware refuses automatically these packets.
I have also tried with a Raspberry Pi with a different Linux release and it was working correctly.
My multicast streaming is using protocol udp.mp2t.
It seems specific to that protocol messages (a bunch of packets being remerged after).
I have made a small program that just send a basic multicast and everything works perfectly so it’s really related to that mp2t protocol.
Any clues why these messages are just refused by NIC when not in promisc?
sorry, no experience with the usecase you are running now.
Maybe other user can share their case.
My main concern is do you have an idea of what are the reasons this board NIC refuses silently those packets but they are working just fine when received through an Ethernet-Usb adapter or a RaspberryPi instead.
I tried investigating some Linux features like sysctl filters, ignore, etc but none worked . I attempted to use ethtool to monitor my NIC status and all I could get is that my NIC driver is Gigabit Ethernet Driver 5.4.0-k
and with ethtool -i ethX the driver is eqos and could see that the packets are not even incremented because they are discarded silently which leaded me to figure out the NIC was the issue.
Maybe in max performance mode it will improve. Try “
sudo jetson_clocks” (you could also make sure your
nvpmodel is maxed out).
I tried both, sudo jetson_clocks only printed “Can’t access fans” and my multicast was still not working.
Whereas to make sure my nvpmodel is maxed out, I saw on another page that I had to do
“sudo nvpmodel -m 0” which I did and to call the previous script which also printed the same text “Can’t access fans”
Is there a way to see packets that are received at NIC level but silently discarded? I could maybe find why it does so like wrong checksum or too many packets at once. I tried
netstat -i Display per-interfaces
netstat -s Display per-protocol statistics
ip -s link show eth0 Showing dropped packets statistics per network interface
ethtool -S eth0 Queries the specified network device for NIC- and driver-specific statistics
None of them actually showed dropped packets because I’m pretty sure NIC don’t even process them and are discarded as they attempt to enter NIC.
I would have though ethtool -S eth0 would show me multicast packets correctly but mmc_rx_multicastframe_g: is only incremented correctly when promisc is active.
If the fans cannot be accessed, then I am suspicious of the device tree. If the device tree is incorrect, then I am suspicious that the carrier board is not the NVIDIA developer’s kit (which would mean it requires a modified device tree). Is this a third party carrier board, or is it an actual TX2 dev kit?
In fact, it is not the tx2 dev kit. I have carried board plugged on some other third party carrier board
The device tree needs to be edited for any carrier board other than the ones which have the same exact layout as the reference design (the dev kits have this design).
A plug-n-play component has the ability to announce not only what it is, but also where it is. Extra hardware is involved in this, and the most common examples of plug-n-play are PCIe and USB. Other hardware, such as the fan, might route to specific pins of the SoC/module; that routing is flexible, and it is the device tree which assigns a given function to a particular pin or set of pins when the routing is optional. It is the developer of the third party carrier board who knows what that routing is, and so this is where one of the following will occur:
- The third party manufacturer might give you a patch to the dev kit flash software, and this is almost always nothing but a device tree.
- The third party manufacturer might provide the entire flash software; in this case, likely it is the same underlying flash software and content, although the device tree would differ.
- The third party manufacturer might state that their carrier board is a match to the dev kits, and thus that it is ok to use the dev kit flash software.
Until you have the correct device tree the only parts of the carrier board which will function are those which are in common with the dev kit. Thus your networking and fan software probably cannot find the correct pins to work with, and those will fail until told where to find that hardware (that hardware is not plug-n-play and cannot self-describe).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.