Installing JETPACK on TX2 without finding IP address

Hello

I tried to install JETPACK on tx2

But finally, the task of finding the IP address between the host pc and tx2 failed.

Strangely, tx2 seems to work normally.

What is the correct way to check if the Jetpack is properly installed?

And is it okay to use this without ip connection?

I have connected both host and tx2 to one router, so I want to know why can not find ip.

JSYOO,

If only IP is lost during installation, your board should have been flashed successfully. Could you power on your tx2 and see if IP address is there or not?
It sounds the error only happens during Jetpack installation. Could you describe your host environment? Are you using ubuntu16.04 host?

Hello WayneWWW,

Now i’m using ubuntu 16.04 on VMWARE

And I connected the host pc and tx2 to one router through a LAN.

How do you check ip in tx2 ??

Does that mean I can have internet access via tx2 ?? Or what data should I check through ifconfig?

JSYOO,

According to previous comment, I guess your board has been flashed successfully. Is it right?

If so, the system should be able to up. What you miss are those packages or apps like mmapi_sample or cuda toolkit. Those won’t affect system boot.

You can connect a HDMI monitor to your tx2 and see if it can show the gnome desktop and use it to check IP.

I am facing the same issue but possibly worse, the reason for the failure to determine the IP address seems to be because the wired ethernet is not working on my device. I am hoping it is not a fault on the board, as the lights on the rear side of the ethernet connector are not illuminating when I plug in the cable to the router. However the wifi works just fine. I inspected the pins on the connector and checked the board for obvious soldering issues but couldn’t see any sign of a defect.

Could this be a problem with the latest version of JetPack, JetPack-L4T-3.2-linux-x64_b196.run ? I am really hoping that I don’t have to return my new Jetson TX2!

My host is running ubuntu 16.04.

If you use a VM for host it is expected to fail.

JetPack itself installs only to the host. If JetPack is flashing the Jetson, then this goes through the micro-B USB cable. If JetPack is adding additional packages, then this is going through the wired ethernet. Package installs would occur after flash and reboot (this assumes you had flash checked…you don’t have to flash). The mechanism for autodiscover of wired ethernet works only if you flashed. If you didn’t flash (and many people use JetPack just to install packages instead of flashing), then you will need to manually add the IP address during flash.

Assuming packages are being installed it is possible to use either a dedicated router appliance, or to use the host as a router. Debugging would depend on knowing which of these setups you use. Either method would imply a need to check the router to see what address was given when the Jetson requests it. This becomes even more difficult in the case of a VM…don’t use a VM.

The world is full of impostors.

I am using a physical desktop not a VM and flashing the target device successfully with JetPack, the first sign of a problem is when JetPack tries to determine the IP address of the target, it gets stuck because the wired ethernet is not working.

In order to complete the Jetpack installation, I was able to do this by connecting the Wifi and selecting retry after the Jetpack timed out in it’s inital attempt to determine the IP address. However I still need the wired ethernet to work for my project.

I am hoping this is a firmware issue but maybe my Jetson is defective. I can successfully connect another device to my router using the same cable, which rules out a cable or router issue and as far as I can tell (after checking the logs on the router), when I connect the Jetson to the router there are no requests from the Jetson to require an IP address.

If I run ifconfig on the Jetson I get the following…

eth0 Link encap:Ethernet HWaddr 00:04:4b:a8:4b:bb
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:42

l4tbr0 Link encap:Ethernet HWaddr 16:6f:b0:e9:99:5b
inet addr:192.168.55.1 Bcast:192.168.55.255 Mask:255.255.255.0
inet6 addr: fe80::60de:feff:fe97:1359/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:49 errors:0 dropped:0 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8518 (8.5 KB) TX bytes:4431 (4.4 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:202 errors:0 dropped:0 overruns:0 frame:0
TX packets:202 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:14907 (14.9 KB) TX bytes:14907 (14.9 KB)

usb0 Link encap:Ethernet HWaddr 62:c8:9f:11:9b:b6
inet6 addr: fe80::60c8:9fff:fe11:9bb6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:24 errors:24 dropped:0 overruns:0 frame:24
TX packets:95 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4221 (4.2 KB) TX bytes:16612 (16.6 KB)

usb1 Link encap:Ethernet HWaddr 16:6f:b0:e9:99:5b
inet6 addr: fe80::146f:b0ff:fee9:995b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25 errors:0 dropped:0 overruns:0 frame:0
TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4297 (4.2 KB) TX bytes:12252 (12.2 KB)

wlan0 Link encap:Ethernet HWaddr 00:04:4b:a8:4b:b9
inet addr:192.168.11.15 Bcast:192.168.11.255 Mask:255.255.255.0
inet6 addr: fe80::9fc2:3dc6:4b28:f164/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50 errors:0 dropped:0 overruns:0 frame:0
TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20409 (20.4 KB) TX bytes:8294 (8.2 KB)

I would really appreciate confirmation that there are no issues with the latest version of JetPack using the ethernet connector.

Hello WayneWWW,

I think My board flashed successfully, it’s working well

I connected the HDMi monitor to my tx2

but I do not know what it means to use the gnome to check the ip address. What exactly does it mean?

Does it simply mean good internet access?

Or is it possible to communicate with the host PC?

If not, does it mean that an ip address is written?

type on the command line,

ip addr

check to see if there is an ip address entry for eth0 (wired ethernet) or wlan0 (wifi).

JSYOO,

Because I don’t know if you have a UART debugger or not, one fast way to check the IP on your device after flashing is to check it with GUI.

Any advice on how to fix my ethernet issue?

@dan185742: You need to use the wired ethernet for package installs. In the ifconfig output it looks as though eth0 never got an IP address. Is your PC a router, or do you use a router appliance? You’ll need to check the logs on either to find out if the Jetson actually sent out a DHCP request.

I checked ifconfig and confirmed that eth0 never got an IP address, the Jetson TX2 is connected to a router, the same router as my host pc is connected to. I checked the logs on the router and the Jetson never sent a DHCP address for the wired ethernet, (though it did send one for the wireless network, which is working).

I verified that there is no issue with my ethernet cable or the router. I intended to use the wired ethernet in my project, so I am really stuck if I can’t get it working, I would appreciate any help or suggestions anybody out there might have.

BTW is there any way to verify if the device driver for the wired ethernet is working correctly?

dan185742, WayneWWW

This is output of ip addr(using wired ethernet)

Please check it

ThankS!!

nvidia@tegra-ubuntu:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 62:7f:79:ba:44:57 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:04:4b:8d:06:92 brd ff:ff:ff:ff:ff:ff
    inet 175.209.49.72/24 brd 175.209.49.255 scope global dynamic eth0
       valid_lft 3592sec preferred_lft 3592sec
    inet6 fe80::93c5:5bfc:f4fe:6f5d/64 scope link 
       valid_lft forever preferred_lft forever
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
    link/ipip 0.0.0.0 brd 0.0.0.0
5: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state DORMANT group default qlen 1000
    link/ether 00:04:4b:8d:06:90 brd ff:ff:ff:ff:ff:ff
6: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000
    link/ether e6:2c:dc:74:d3:38 brd ff:ff:ff:ff:ff:ff
7: usb1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master l4tbr0 state DOWN group default qlen 1000
    link/ether 76:a5:8f:7e:46:c5 brd ff:ff:ff:ff:ff:ff
8: l4tbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 76:a5:8f:7e:46:c5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.55.1/24 brd 192.168.55.255 scope global l4tbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::4cdd:67ff:fea5:c6a5/64 scope link 
       valid_lft forever preferred_lft forever

Note that if “ifconfig” lists the settings of eth0, then the driver is present and working. The presence of WiFi address, but lack of wired address, tends to make me believe NetworkManager has considered your WiFi as taking priority over wired and disabled wired…but this is just guessing. If you can, then perhaps go into the GUI login and disable WiFi (at least until wired works for package installs). No WiFi might allow wired if it is a NetworkManager config issue.

I tried disabling wifi already and it didn’t make any difference, should I conclude my board is defective? or can I dig deeper, is there a way to reinstall the drivers for the ethernet? I have flashed my board several times in attempts to fix this issue but that didn’t work.

The board is most likely working without any hardware failure. eth0 would not be listed at all from ifconfig if this were not the case. I very strongly feel that there is a configuration issue or interaction with the router.

If, from a local console or serial console you run these commands, what happens? Monitor your router log as you do this.

sudo dhclient -r
sudo dhclient

You might also want to reboot the router.

If you need to know if the port is kind of working you may open the router dhcp statistics and see if it has ip or mac addresses of the Jetson device.
I would say that
inet 175.209.49.72/24 brd 175.209.49.255 scope global dynamic eth0
is a primary ethernet,
but the following a bit perplexes me:
inet 192.168.55.1/24 brd 192.168.55.255 scope global l4tbr0
Will I be correct saying that l4tbr0 is the wifi implementation?