Jetson Xavier NX configuration:
Jetpack:5.1.4
Ubuntu version: 20.04
I have connected Jetson through ethernet which communicates to a remote TAB. On jetson(host), it has ip1 and the ip of the remote(destination) is ip2. When attempting to ping, “ping ip2” works on Ubuntu18(Jetpack 4.6) but fails in Jetpack5(Ubuntu20).
What can be the potential solutions to solve it?
Please run the commands “ifconfig” and “route” on both the one that works and the one which does not work. If you don’t have the old working one, that is ok, but try to post the output of both ends of the connection (make sure we know which ifconfig and which route goes with which end of the connection). Also post the output of “uname -r”.
Will post the results. I also checked with ifconfig. The ethernet is being detected in both setups.
Using cmd arp -an, am getting ip2 along with MAC address in Ubuntu18 but not in Ubuntu20. Both the connections, i.e. ip1 and ip2 are under the same subnet.
Using tcpdump, ARP request and reply being given with ip2 in Ubuntu 18 but no request nor reply with ip2 in Ubuntu20.
The ip2 is the remote device(TAB) with Android9.
Actual results right after booting would help. There are statistics for error information in the result, and knowing what shows up right after booting is the most valuable.
ubuntu18 log.txt (2.5 KB)
Ubuntu20 log.txt (2.3 KB)
Attached the results.
What I find interesting is that if I put the two side-by-side, then eth0 has the same IPv4 address for both; even so, the IPv6 (inet6) address differs. This sort of explains some statistics.
Note that both see transmit (TX) packets, but only the working unit receives packets (RX). Both are sending their DHCP request, but no traffic arrives at the Ubuntu 20.04 version. I would think that the issue is the router using IPv6 addresses for its reply, but that isn’t the case. Look closer, and note that the MAC address is different between those two:
48:b0:2d:69:ec:8c48:b0:2d:75:f7:17This implies different hardware between the two. I don’t know how that is possible. I will say that there is an EEPROM involved with obtaining the MAC address from the Jetson side, and it is possible that if the EEPROM is accessible in one case, but not the other, then a default might be generated in one case. Even so, I would think that the router should see that MAC address and send accordingly, but obviously it isn’t reaching the Jetson. [Note that i2c operations might also change this]
Maybe it is as simple as momentarily rebooting the router itself. You might unplug the Jetson with Ubuntu 20.04, and unplug the router for a few seconds, and then plug the Jetson in before plugging the router in. Then turn on the router and see if powering up with that MAC attached succeeds.
You might also include a full serial console boot log in the 20.04 case to see if there is any kind of EEPROM issue (attaching an 18.04 serial console boot log would be useful to compare against).
Is there anything unusual about the carrier board? Are you performing a full flash? I ask about the latter because there are times when the MAC address is used in “/etc/udev/”, and if this remains (or fails to remain), then various unique identifiers (including MAC) could fail.
Regarding the different MAC address it is because of different devices. Ubuntu18 is installed on Nano and Ubuntu 20 on Xavier. I had worked with Ubuntu18 on Xavier as well and there were no issues. When I upgraded to Ubuntu20, the issues regarding connectivity came.
The ethernet is actually not connected to a router. The ethernet is connected to my flight controller which then goes to my Tablet(via APP)
Something in devices is likely causing configuration to be an issue. Just to be clear though, most of what is provided is for the wired Ethernet. It is very important to know exactly which devices are used. If it worked in 18.04, but used a different device than 20.04, then that is quite important. If we are talking about a USB device, then this too is very important. Can you give a detailed description of which devices and interfaces are used (A) with the 18.04 setup, and a comparison with how used in the (B) 20.04 setup?
For both the devices, a flight controller is connected via USB and an ethernet cable is connected for RTSP streaming.
I saw data bytes out on both working and failing cases. Both had the same IPv4 information. Statistics on what was sent and/or received were drastically different, and in the case of failing, I see what I believe to be a DHCP request being sent out. Having no router would tend to confirm why there was no DHCP reply. Perhaps it was some other TX activity than DHCP, but I still suspect DHCP being sent (but not received). Exactly how is the eth0 network configuration achieved? I think this is high on the list of possibilities as to why 20.04 is not working.
Incidentally, looking at route, there are also differences there, and those differences would normally be related to what a router supplies. How was route configured? All of this has to be manually created since you don’t have a router, and it has to match with the flight controller. I am curious if the flight controller itself and/or tablet have any kind of manual setup?
I have set eth0 manually.
Did you set the eth0 address manually at both ends? I’m asking as I look at a conversion between IPv4 and IPv6 (see any IPv4 to IPv6 calculator):
192.168.144.25 is:::ffff:c0a8:9019Neither of your systems uses that as IPv6. One system (Ubuntu release) says fe80::8e99:ae6:8dda:7dd5, the other shows fe80::3133:343d:f954:21a2. I suspect that one of the systems is using the IPv6 address and not IPv4, although this might be completely wrong since much of the software is only naming IPv4. To be fair, (A) IPv6 has had lots of configuration issues associated with it as it began development, and (B) many systems don’t even use the IPv6 address. However, if anything you have uses IPv6, then there could be issues just from that.
When you say “a remote TAB”, what is the “TAB”? I know the following exist, let me know if this is correct or incorrect:
ping -6 <address>” or “ping6 <address>”. If that Jetson can ping its own IPv6, can it ping any of the remote IPv6? I’m basically drilling down on configuration since I think the software itself works, and part of IPv6 configuration is knowing if it is supported or enabled.Will get back you and post the results I got.
I apologize if I confused on the setup. Setup is sth like: the flight controller(usb) and the receiver(through eth0) is connected to the jetson. It transfers to GCS(Ground Control Station).
Some points:
Jetson Nano(Ubuntu18)
ip neigh
192.168.144.1 dev eth0 FAILED
192.168.144.20 dev eth0 lladdr 00:e0:99:aa:d4:21 REACHABLE
192.168.144.12 dev eth0 lladdr 60:18:94:37:c2:90 STALE
fe80::6295:47ff:fee0:469c dev eth0 lladdr 60:95:47:e0:46:9c router REACHABLE
fe80::6218:94ff:fe37:c290 dev eth0 lladdr 60:18:94:37:c2:90 router STALE
ping6 fe80::6295:47ff:fee0:469c -I eth0 → works
ping6 fe80::6218:94ff:fe37:c290 -I eth0 → works
(from fe80::3133:343d:f954:21a2%eth0)
ping6 fe80::3133:343d:f954:21a2 -I eth0 → doesn’t works
ping6 fe80::3133:343d:f954:21a2 → Invalid argument (Same done for Ubuntu 20 system as well)
For both devices:
ip -6 addr show
3: eth0 <BROADCAST,MULTICAST, UP, LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::3133:343d:f954:21a2/64 scope link noprefixroute
valid_lft forever preferred_lft forever
cat /proc/sys/net/ipv6/conf/eth0/disable_ipv6 = 0
Ensured for both devices(i.e. Ubuntu 18 Jetson Nano & Ubuntu 20 Jetson Xavier), the following config:
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6=1
Initially only Ubuntu 18 had it under /etc/sysctl.conf.
same config for both: cat /proc/sys/net/ipv6/conf/eth0/disable_ipv6 = 0
The point regarding “/proc/sys/net/ipv6/conf/eth0/disable_ipv6 = 0” is rather interesting (and useful). After you added the disable for IPv6 and rebooted, does the cat disable_ipv6 show as 1? If so, then we can ignore all IPv6 from this point forward. This would greatly simplify things, but you’ll need to post the output (with labels as to which system it applies to) for “ifconfig” and “route”. Is the receiver such that you can get that same information, or is the receiver more or less an appliance without command line?
A list of what to post, along with a label of which system it is on (the information needs to all be from after the removal of IPv6 through the /sys change; I’m trying to create a single picture of this rather than being spread out in the forum thread):
ip -s addrroute (I prefer the “route” format over “ip route”; if not available you can still use “ip route”).rfkill” and “iwconfig”. Ignore this if none of the this is wireless.You could also add the information from the working case again after removing IPv6 via /sys, but if you need to flash again, then don’t worry about it.
Also, include the content of this on the Jetson:
/etc/nv_tegra_release/etc/nv_boot_control.confWas the static IP address configuration performed any differently between the failing Xavier NX case and the earlier working Nano?
Tell me more about the Android device, e.g., what is its function, such as router, bridge, so on.
cat /proc/sys/net/ipv6/conf/eth0/disable_ipv6 = 0 after rebooting.
For Xavier(Ubuntu 20)
R35(release), REVISION: 6.1, GCID:39721438, BOARD:t186ref, EABI:aarch64
TNSPEC 3668-301-0003-B.0-1-2-jetson-xavier-nx-devkit-emmc-
COMPATIBLE_SPEC 3668-301—1–jetson-xavier-nx-devkit-emmc-
TEGRA_LEGACY_UPDATE false
TEGRA_BOOT_STORAGE nvme0n1
TEGRA_EMMC_ONLY false
TEGRA_CHIPID 0x19
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
Kernel IP routing table
For Nano(Ubuntu18)
R32(release), REVISION: 7.6, GCID:38171779, BOARD:t210ref, EABI:aarch64
TNSPEC 3448-401-0002-G.0.1-0-jetson-nano-devkit-emmc-mmcblk0p1
COMPATIBLE_SPEC 3448-300-0002–1–jetson-nano-devkit-emmc-
TEGRA_CHIPID 0x21
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
Kernel IP Routing table
Just going through this in order as I read it…
Does this include after adding to “/etc/sysctl.conf”? If one merely edits the IPv6 file directly I would expect this to go away:
You mentioned adding this:
After reboot, with that edit still in place, do they still reset to “0”? If so, then that shouldn’t happen, and I’d have to wonder if this is being changed somewhere else.
I see this in nv_boot_control.conf:
TNSPEC 3668-301-0003-B.0-1-2-jetson-xavier-nx-devkit-emmc-
COMPATIBLE_SPEC 3668-301—1–jetson-xavier-nx-devkit-emmc-
Is it correct that this is not a “developer’s kit” model of Xavier NX? If not, then the flash software most likely requires a third party device tree, although it looks mostly like the current problem does not depend on this (the port would be completely failing, although it is possible that some part of the Ethernet involved might still get in the way if firmware is incorrect…it is doubtful that this is the issue).
It is quite important to know if the manufacturer of the carrier board has exact instructions saying to use the NVIDIA flash software; if not, then using NVIDIA’s flash software would cause parts of the Jetson to mysteriously fail. That firmware is what tells the Jetson module about any customization of the layout of the carrier board.
I was hoping to see the specific ifconfig associated with this route. It is difficult to search through posts, and worse, that information might change (the two should always be provided in pairs as a set…ifconfig and route). I will make some assumptions.
Your default route goes to 192.168.144.1 from the Ubuntu 20.04. Specifically, which device is at 192.168.144.1? I’m assuming it is likely the tablet or some Android device you mentioned earlier. There is a strong possibility this is related to the issue, but due to route tables, this might not matter. What is the exact IP address of the device you are trying to ping? What is the exact IP address of the device you are pinging from (the Xavier NX)? If the default route is being used, and not something direct via the netmask, then it implies the device at 192.168.144.1 has to correctly forward.
As part of this, can the Xavier NX device using Ubuntu 20.04 ping 192.168.144.1? If the Xavier NX can ping 192.168.144.1, but cannot ping a device the default route is providing, then it is up to that device at 192.168.144.1. It is not uncommon for a device like an Android to require whitelisting of an incoming MAC address or other security detail before forwarding. If this is the case, then it means the Ubuntu 20.04 is in fact actually fully functional. Knowing the details of the device at 192.168.144.1 and the address/netmask of both the Xavier NX and the remote device would be quite useful.
Remember that a ping result is a combination of:
I came across a similar thread Communications issue with Xavier NX Ethernet - #15 by ben.steer. One thing was that in Ubuntu18, the speed was reconfigured to 100Mbps, which was different in Ubuntu20. So, when I forced it to 100 Mbps using sudo ethtool -s eth0 autoneg off speed 100, the entire setup worked.
If that works, then there might have been a limitation with the router. I know you are not using a standard router, but it sounded like the tablet might have been passing traffic, in which case incompatible Ethernet options could in fact have been the cause (which the changes would fix).