Hello!
We purchased 2 Jetson TX2 dev kits. Everything was good with the first one, but the second one has problems with network. After flushing the OS, host PC failed to establish a connection with Jetson. I tried changing the ethernet cable and connecting directly to the router or through a network switch. Nothing worked. I could’nt access the web or do apt-get update either. ‘ifconfig’ shows that a connection was established. In some of the attempts i experienced ethernet connection loss and program crashes by nm-applet and gvfsd-dnssd.
I tried both Jetpack 3.1 and 3.0. I was able to ping devices in my office from the Jetson, but not ports.ubuntu.com nor www.google.com. When i switched to WiFi, the host computer could connect and internet connection worked on the Jetson.
I remind you that there were no such problems with the other Jetson TX2 installed and tested identically.
Is there a fix for this or should i file for an RMA?
Arvids
Perhaps it is just DNS, and not a general failure. Does local login to the Jetson from either a serial console or any other directly attached login work? If so, what are the permissions from:
ls -l /usr/bin/sudo
(it should be “-rwsr-xr-x 1 root root”)
Does everything show as ok from:
sha1sum -c /etc/nv_tegra_release
What is the output of “ifconfig”? Note that if networking is up but DNS failing you will see an address on the second line for the ethernet device as something similar to:
inet addr:192.168....
If an external PC can ping this or ssh to this (not using a named address, e.g., not using “linux-tegra” or any other alphabetic name), then it is purely a DNS issue. If two Jetsons both wanted name “linux-tegra” (or any same name), then the router would have to refuse to name one of the Jetsons what it asked for.
Successfully connected to the TX2 with ssh.
ls -l /usr/bin/sudo
does return “-rwsr-xr-x 1 root root”
sha1sum -c /etc/nv_tegra_release
there is one failure:
/usr/lib/xorg/modules/extensions/libglx.so: FAILED
sha1sum: WARNING: 1 computed checksum did NOT match
Edit: After an apt-get upgrade this failure disapeared. Problem remains.
Output from ifconfig shows the inet addr as usual.
Edit: This still doesn’t explain why the other identical Jetson TX2 with identical installation and setup does not experience this problem.
Is it safe to detach the modules from dev board and try switching them to see what is at fault?
Edit II: Tried with user ubuntu instead of nvidia - same result. Removed other Jetsons from the network - same result.
Update!
It was in fact some weird issue with ip address allocation. Is there any chance that this is is still somehow a problem with the TX2?
The GUI will fail with the libglx.so issue (probably unrelated to networking). To fix this:
sudo ln -sf /usr/lib/aarch64-linux-gnu/tegra/libglx.so /usr/lib/xorg/modules/extensions/libglx.so
(then run “sha1sum -c /etc/nv_tegra_release” again to see if all files are ok)
It is possible for networking to be up and functioning with DNS failing to resolve named addresses (this is not a network failure, but networking would look like it failed if DNS is failing). If “ifconfig” showed an address then when there is a failure you should first try a dotted-decimal format address for any testing. An example is that host lookup of “nvidia.com” (“host nvidia.com” command) shows as 216.228.121.209, so you could “ping 216.228.121.209” and see if this works; if this works then try “ping nvidia.com”; if this fails, then it is a DNS issue instead of a network up/down/fail issue. If ping of the dotted-decimal format address fails, then the issue is a true network failure. Can you “ping 216.228.121.209”? Can you see a response from the query command “host 216.228.121.209”?
Within a private network (addresses you see on your router which the outside world does not see), then you have some added complications if you use a named address such as “tegra-ubuntu”. Having more than one Jetson with each one trying to use “tegra-ubuntu” makes it mandatory that no more than one Jetson can respond to this (the router cannot give the same name to two devices). None of those issues are specific to a Jetson, or even to Linux. So without seeing “ifconfig”, and without knowing how dotted-decimal format addresses respond, it isn’t possible to know if it is a network issue or a DNS issue. If it is a DNS issue there are yet more debug steps compared to a plain network failure. Other computers on your private network depend on the router to convert “tegra-ubuntu” named addresses, so this is equivalent to DNS internal to the private network. Accessing a Jetson by anything but a dotted-decimal address implies a router issue when named addresses fail.
So far there is no information given as to whether a failure you’ve seen is from outside the Jetson to the Jetson, versus inside the Jetson to the outside, and whether named address format is used versus dotted-decimal format. In the case of going from Jetson to outside the Jetson debugging would also require knowing if the destination is part of the private network or if the destination is the outside world. For “apt-get upgrade” to work I will guess that the failures involve going from one computer to another within the private network, and that outside of the private network the internet works (which in turn implies a router issue with network being fully functional and DNS being functional).
Wi-Fi doesn’t have a hard cutoff as to when it will work and when it won’t. Sometimes you can get perfect reception in one place and then later not. That’s because the radio signals bounce off surfaces, pass through walls, and can be absorbed by people and materials.I aso check it from Verizon Routers Customer Service