Unable to install SDK components post flashing my Jetson TX2 module

Hi All,
I am unable to install the SDK components using the latest SDK Manager for Jetpack 4.2 on my Jetson TX2 device.
The error shown is :
Could not connect to the target device. Verify that:

  1. The device is connected to this host machine with a USB cable.
  2. Ubuntu ‘System configuration wizard’ is completed on the device.
  3. Jetson’s Ubuntu OS is up and running.
  4. Jetson usb device mode service is started successfully.
  • See readme file in the auto-mounted “L4T-README” folder for more details.

I can see the device ON in network settings, I made sure the USB is connected properly (this was used for flashing), the first three steps are done and verified, I do not understand step 4. Any help would be appreciated.

P.S. I am unable to connect the jetson using “ssh username@192.168.55.1

Can you “ping 192.168.55.1”? If so, have you logged in locally to the GUI on the TX2? I ask because in that release the accounts were not installed during the flash…you’d have to actually create the username from the local TX2 keyboard/monitor on first boot. If you can ping, then it implies it is an account issue.

Hey, thanks for the quick response. No, I am unable to ping 192.168.55.1, and I am unable to see any device on ifconfig with that ip. The Jetson device in ifconfig is shown as 192.168.1.77 and I am not able to ssh that device aswell. I can ping 192.168.1.77
As far as jetson TX2 goes, the Ubuntu is up and running on the Jetson device (with the username/pwd).

When I change the IP from 192.168.55.1 to 192.168.77.1 in the SDK manager, the error changes to “Cannot connect to the device via SSH”

The basic process is that TX2 creates a “virtual ethernet adapter” by means of the micro-B USB cable after flash and boot is complete. The host PC should see that as a virtual ethernet device with address 192.168.55.1. The host itself would be configured (via SDK Manager) to have a virtual address of 192.168.55.100. If you can “ping 192.168.55.100”, then it means this was set up on the host side. If not, then there would probably be no route to 192.168.55.1.

If you monitor “dmesg --follow” on the host PC, and the Jetson is up and running (but not connected via micro-B USB), then what does the log show as you connect the micro-B USB?

Hey,
I am unable to ping 192.168.55.100 too, so no connection possble to 192.168.55.1 (no route)

On Disconnecting the USB Cable:
[122891.051167] usb 1-2: USB disconnect, device number 41
[122891.051402] rndis_host 1-2:1.0 enp0s20f0u2: unregister ‘rndis_host’ usb-0000:00:14.0-2, RNDIS device
[122891.143559] cdc_ether 1-2:1.5 enp0s20f0u2i5: unregister ‘cdc_ether’ usb-0000:00:14.0-2, CDC Ethernet Device

On Connecting the USB Cable:
[122966.964364] usb 1-2: new high-speed USB device number 42 using xhci_hcd
[122967.115091] usb 1-2: New USB device found, idVendor=0955, idProduct=7020
[122967.115101] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[122967.115107] usb 1-2: Product: Linux for Tegra
[122967.115113] usb 1-2: Manufacturer: NVIDIA
[122967.115119] usb 1-2: SerialNumber: 0420919029096
[122967.121008] rndis_host 1-2:1.0 usb0: register ‘rndis_host’ at usb-0000:00:14.0-2, RNDIS device, 8e:04:3a:ea:d9:c0
[122967.121926] cdc_acm 1-2:1.2: ttyACM0: USB ACM device
[122967.123231] usb-storage 1-2:1.4: USB Mass Storage device detected
[122967.132327] scsi host0: usb-storage 1-2:1.4
[122967.133724] cdc_ether 1-2:1.5 usb1: register ‘cdc_ether’ at usb-0000:00:14.0-2, CDC Ethernet Device, e6:bf:b2:a6:64:1a
[122967.161878] rndis_host 1-2:1.0 enp0s20f0u2: renamed from usb0
[122967.184820] cdc_ether 1-2:1.5 enp0s20f0u2i5: renamed from usb1
[122967.209274] IPv6: ADDRCONF(NETDEV_UP): enp0s20f0u2: link is not ready
[122967.227269] IPv6: ADDRCONF(NETDEV_UP): enp0s20f0u2i5: link is not ready
[122968.141174] scsi 0:0:0:0: Direct-Access Linux File-Stor Gadget 0409 PQ: 0 ANSI: 2
[122968.143595] sd 0:0:0:0: Attached scsi generic sg0 type 0
[122968.145947] sd 0:0:0:0: Power-on or device reset occurred
[122968.146826] sd 0:0:0:0: [sda] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[122968.147012] sd 0:0:0:0: [sda] Write Protect is on
[122968.147020] sd 0:0:0:0: [sda] Mode Sense: 0f 00 80 00
[122968.147212] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
[122968.157884] sda:
[122968.159918] sd 0:0:0:0: [sda] Attached SCSI removable disk

I can also see NViDiA Corp in lsusb list of active ports.

So what this indicates is that both the TX2 and host are working correctly, but the host was not configured to add a route which uses the virtual USB ethernet. You will probably need to write down the MAC address (I think it is the e6:bf:b2:a6:64:1a address for cdc_ether, but there is also an rndis which I think you can ignore), then go into your host’s network GUI config and tell it to use that MAC address device. This should associate a route to 192.168.55.1, and then ping would work. If ping works, then ssh should work.

In the network settings at Host Network, the device wired “e6:bf:b2:a6:64:1a” is ON and working already

ping is working on 192.168.1.77, ssh ain’t.
192.168.55.1 is not there in the list, so neither is working.

when I tried using ssh to connect to 192.168.1.77 (corresponding to MAC of Jetson), the error is
“ssh: connect to host 192.168.1.77 port 22: Connection refused”

The ifconfig list on Jetson TX2 says the usb “l4tbr0” is configured to ip address 192.168.1.77
and on the host too.

The tail output on Jetson for dmesg --follow on re-connecting the usb port says:
l4tbr0: port 2(usb0) entered blocking state
l4tbr0: port 2(usb0) entered forwarding state
tegra-xudc-new 3550000.xudc: setup request failed: -22

If the Jetson is booted, and connected to the PC via the micro-B USB, what is the exact output for each from:

ifconfig
route

I have a similar issue. When it should install the SDK components it says Incorrect username or password. I can ssh with the same username and password into the TX2. Any suggestions?

you may need to make sure that the device is in recovery mode;
moreover, as far as I remember, when flashing you are presented with two choices - automatic and manual;
It seems to me that you are trying the automatic method, that presumes availability of the board through 192.168.55.1. However you should be able to set the mode as manual, I believe, and after the device been put into the recovery mode it should got flashed via the manual scenario, if my assumption is correct.

Thank you for the reply. I did the manual method and I think it must have been in force recoverymode because it flashed the OS ok. After that it starts the Ubuntu configuration wizard on the TX2. There I put in a username and password for the TX2. I then get asked to put in the same username and password in the SDKmanager. It should then load the rest of the SDK. However it fails at this point saying the username or password is incorrect. I have now tried some reboots etc so maybe the TX2 is not in teh correct mode any longer.

R32.1 (from JetPack4.2) does not create a user account upon flash. You need a keyboard and monitor connected and then you add the account on first boot. Not sure yet on JetPack4.2.1, haven’t had a chance to flash from that yet. However, if you didn’t boot up once and add the account, then there won’t be either an “ubuntu” or “nvidia” account to log in to. Did you log in manually after the flash?

Thank you for theresponse. Yes I did log on and create an account using the Ubuntu wizard that comes up after first boot.

So there are basically two things left to consider (I’m assuming there is still an issue). The first is the IP address which JetPack/SDKM wants to use, the second is the host configuration to find the route to that address. To answer more we really need the output of these two commands from both the Jetson and the host PC (this is with the Jetson connected via the micro-B USB and the Jetson fully booted):

ifconfig
route

on host$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:49:61:39:e6 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.137 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::b59a:85e7:3364:5fe1 prefixlen 64 scopeid 0x20
ether 30:9c:23:d1:ef:31 txqueuelen 1000 (Ethernet)
RX packets 437113 bytes 657539936 (657.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 223711 bytes 15759934 (15.7 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xa3300000-a3320000

enp0s20f0u6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::761d:a765:8eb2:4282 prefixlen 64 scopeid 0x20
ether 3a:c3:22:44:97:28 txqueuelen 1000 (Ethernet)
RX packets 157 bytes 19899 (19.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 719 bytes 165210 (165.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp0s20f0u6i5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.100 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::c0eb:835f:8705:3b7 prefixlen 64 scopeid 0x20
ether 1e:9c:cd:2b:6e:1a txqueuelen 1000 (Ethernet)
RX packets 2442 bytes 309751 (309.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2425 bytes 2420744 (2.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 2146 bytes 202735 (202.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2146 bytes 202735 (202.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 100 0 0 eno1
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 eno1
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eno1
192.168.55.0 0.0.0.0 255.255.255.0 U 102 0 0 enp0s20f0u6i5

On Jetson
$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:34:85:52:55 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:04:4b:66:a4:59 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::1c9c:cdff:fe2b:6e19 prefixlen 64 scopeid 0x20
inet6 fe80::1 prefixlen 128 scopeid 0x20
ether 1e:9c:cd:2b:6e:19 txqueuelen 1000 (Ethernet)
RX packets 3188 bytes 2521134 (2.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1881 bytes 237559 (237.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 436 bytes 32333 (32.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 436 bytes 32333 (32.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rndis0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::1c9c:cdff:fe2b:6e19 prefixlen 64 scopeid 0x20
ether 1e:9c:cd:2b:6e:19 txqueuelen 1000 (Ethernet)
RX packets 753 bytes 129321 (129.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 159 bytes 29491 (29.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::1c9c:cdff:fe2b:6e1b prefixlen 64 scopeid 0x20
ether 1e:9c:cd:2b:6e:1b txqueuelen 1000 (Ethernet)
RX packets 2474 bytes 2398265 (2.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2517 bytes 359781 (359.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:04:4b:66:a4:57 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 32766 0 0 l4tbr0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 l4tbr0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 l4tbr0

By the way this is posted from the Jetson without a network cable and without WIFI configured. It should therefore be through the host. This should mean part of the networking works?

I see docker on the host, so I want to first verify that JetPack/SDKM is not running in any kind of special container or VM environment. Those environments tend to not work and greatly complicates both networking and USB configuration. Docker can show up for a lot of reasons, but I want to be sure the host itself is not a container.


In this case the question of whether basic networking works is whether or not the ethernet has the ability to function over the micro-B USB virtual ethernet, and whether the system has a route which acknowledges and uses that device.

When an interface has an address and netmask combination, then any request for traffic over an address within that address/netmask combination will go directly to it. Some examples:

# Jetson itself is 192.168.55.1, and any address requested from 192.168.55.0 through 192.168.55.255
# will go to this interface. In the specific case of 192.168.55.1 this is the Jetson itself. In other
# cases the traffic will be referred to the router (if there is no router, then the traffic fails for
# any 192.168.55.x which is not specifically 192.168.55.1). A user logged in to the Jetson should be
# able to ping 192.168.55.1 even if nothing on the outside world exists. Ping of any other
# 192.168.55.x address will work if and only if an outside host has that address either directly or
# indirectly through a router. If you were to ping 192.168.55.100, then the outside world would have to
# respond.
net 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255

# On your host I see the expected 192.168.55.100. A login to your host PC would be able to ping
# 192.168.55.100 even if nothing on the outside world talks to it. With the netmask shown any traffic
# to any address within 192.168.55.0 through 192.168.55.255 will go to this interface, but require an
# outside world system to respond to that address. If you were to ping 192.168.55.1, then you would get
# a response only if the network finds that host.
inet 192.168.55.100 netmask 255.255.255.0 broadcast 192.168.55.255

The “route” command shows information about which interfaces to use. In the case of no two network interfaces overlapping the default is that traffic requesting an address within an address/netmask combination goes to that interface…it’s a no-brainer. “route” information becomes important when traffic is requested outside of that interface or when two interfaces overlap.

It’s actually easier to start with the more complicated “overlap” case. Imagine you have two interfaces configured to the same address/netmask. Which one would the kernel choose? If you are using a high reliability failover system, then one interface would be listed with a lower “metric” than the other, and so long as that lower cost metric is available the traffic would always go to that…but if that failed, and another interface exists with a higher metric, then traffic would automatically reroute to the other matching interface. If you have bandwidth sharing software, then if two interfaces have the same metric, you might find traffic is split evenly across both interfaces to double the available bandwidth. In the case of WiFi overlapping wired you might find WiFi is given a higher metric and the system switches to the wired interface when the ethernet wire is connected.

The gateway in “route” tells where the system forwards requests which are outside of all existing interface address/netmask combinations. The gateway itself must be directly accessible within one of the interfaces. The gateway is known destination address just like any other, but it is expected to have knowledge of how to reach the outside world for non-local interfaces.


For your case the Jetson’s WiFi and wired ethernet won’t be required. The host can self-ping to 192.168.55.100, the Jetson can self-ping to 192.168.55.1. If you can verify this, then you know basic networking is ok on both Jetson and host. What it doesn’t guarantee is whether address/netmask and router configuration will actually send the traffic to the right location.

The host does need to access the outside world, but it doesn’t matter by what mechanism, e.g., wired or WiFi.

Here is what I find interesting on the host “route” information:

192.168.55.0 0.0.0.0 255.255.255.0 U 102 0 0 <b>enp0s20f0u6i5</b>

That information says to use interface enp0s20f0u6i5 (what an awful naming convention!) will be used for all traffic within the range of addresses between 192.168.55.0 and 192.168.55.255. Now take a look at the host for interface enp0s20f0u6i5:

inet 192.168.55.100 netmask 255.255.255.0 broadcast 192.168.55.255

If traffic is to 192.168.55.100, then the traffic will go directly to the host. Other traffic will go to the outside world across the USB virtual ethernet interface. Should the host request address 192.168.55.1, then if that host exists in the outside world this outside host should respond.

Exceptions are cases of firewalls or routers which might block (or not allow) certain traffic. If running through a VM extra bridging might be required and there would be a gap in the route where everything disappears if not configured. Firewalls are a similar gap.


Can you verify no VM is involved, and that a login to the host can ping 192.168.55.100, while logins to the Jetson can ping 192.168.55.1?