I connected to host ps via if micro usb.
I finished completely flashing. There is no error.
But I did not continiue.
It is searching the ip address of target.
Jetpach is unable ip address. I tried one more times.
In my first try, It found ip address but it says reset by peer. I canceled it.
Now.
It asks retry, manuaaly?
Coul you please answer it?
How is the ethernet connected? Do you have host and Jetson connected through a switch? Are host and Jetson connected to a router and the router replaces a switch?
I have university network.
My first try, I have two switches in my room. I used them.
My second try, I connected to reuter with one switch. I received two outputs. One is hot, the other is jetson.
Both of them did not work.
Basically the flash uses only the micro USB cable. Once flash is done, extra packages depend on the networking…so your flash was probably successful, but network setup needs work. There are essentially two ways to describe the network for this use.
First method, a router responds to all DHCP network address queries, including from both Jetson and host. Through some mechanism, host knows what the address is for Jetson for further software installs (e.g., CUDA). The traffic goes through the router between Jetson and host.
Second method, the host is connected to Jetson through a switch (not a router). The host must have DHCP server software installed on it so that the host acts like it is a router, and the Jetson does its same DHCP request as before, but it just happens that it is the host responding instead of a router. JetPack should be setting up the host for DHCP server use using this latter method.
Unlisted third method not covered in JetPack: Custom static address assignment without a router, directly connecting host and Jetson through a switch. I use this method most of the time on a private network.
Under both methods any security (such as a firewall) needs to allow the DHCP requests and responses. Once addresses are assigned, the method of communications also needs to be open, e.g., ssh ports must not be blocked. In the case of host doing DHCP response this is easy to control. In the case of a university router, someone else determines if ssh ports are open. A lot of universities just open up everything within the university, but this is not always the case. In the case of a home router, there may be a requirement to enter a MAC address before the router allows the connection, or there may be a limited number of connections allowed.
In all types of router setup addresses are initially accessed only with a dotted-decimal format, e.g., “192.168.1.2”. For access via a name (a named address format), e.g., ssh to “tegra-ubuntu” instead of “192.168.1.2”, further setup is required. This may require cooperation on both the part of the host and the router, and a router may ignore the named address and reply with a different name or no name at all. Imagine if in your university more than one Jetson were connected to their router…they couldn’t all be named “tegra-ubuntu”. By some mechanism JetPack would have to know what the actual response was and relay this to your host for further setup, else your host would not be able to reach the Jetson (if a different Jetson had already logged in as “tegra-ubuntu”, then the keys and such loaded onto your Jetson would not work on the other Jetson, but “tegra-ubuntu” would still exist in the eyes of the router).
In cases where ssh is open, but denied, realize that there are several ways for an ssh connection to be allowed or rejected in an otherwise working system. If there is an ssh key for a machine as a whole or for an individual login name which changes…after previously being allowed…then ssh rejects the machine or account as a possible impersonation or invalid key. A machine as a whole can be rejected even if the individual account key is valid. For password access, no individual account key is required, but machine keys still matter. I am not positive, but I think JetPack tries to set up keys for non-password authentication (my host is Fedora, so I don’t use JetPack…JetPack requires Ubuntu).
I suspect install was correct, but there was either a key issue or a host name setup issue. Your Jetson may be running correctly and it just cannot be seen. In the case of your host being the DHCP router responder there are logs you can look at as the Jetson boots to see if Jetson requested an address, and to see what address was assigned. In the case of the DHCP router response from the university’s router, you won’t have access to the router logs and will need to login locally to the Jetson without a network to see what the Jetson has done.
If you can attach a monitor/keyboard/mouse directly to the Jetson, then run the console command “ifconfig” to see what network settings are. If this fails it may be a video issue and not a failed install. If local keyboard/monitor/mouse cannot be used, you’ll want a serial console, which is immune to network and video failures. Somehow you need the output of “ifconfig”. For serial console, see:
[url]http://elinux.org/Jetson/TX1_Serial_Console[/url]
If your host PC is acting as router, run “dmesg | tail -n 150” just before starting the Jetson. Wait a couple of minutes, then run “dmesg | tail -n 150” again, see if there is something about DHCP to name an address…if there is an address, this is proof the Jetson is alive on the network.
