ssh login

Greetings,
I just opened the box to my new TK1, connected a keyboaad, mouse, hdmi monitor, and connected a network cable to my existing network.

I quickly was assigned an IP, 192.168.1.240 which I was able to ping from various machines on the network. So far so good. But 2 problems exist.

  1. My hdmi monitor simply displays “INPUT NOT SUPPORTED”.
  2. I can’t ssh into the TK1:

On the ssh issue, I get a response from telnet 192.168.1.240 22 which is good.
But ssh -vv reports:

[ZSH_Shell - root@iomari:/current/docs -> ssh -vv ubuntu@192.168.1.240
OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.240 [192.168.1.240] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6p1 Ubuntu-2ubuntu1
debug1: match: OpenSSH_6.6p1 Ubuntu-2ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
[ZSH_Shell - root@iomari:/current/docs ->

I tried this from different machines using different flavors of Linux all with the same response.
I scoured the net for solutions but they all seem to boil down to changes on the TK1 which I can’t access locally because the display shows the above error and I can’t ssh into the box to resolve the issue. Probably some issue with the TK1 ssh settings.

Additionally, I don’t have access to a db9 cable at the moment nor another monitor.

Is there anyway around this dilemma?

Thanks in advance
iomari

Without that DB9/NULL-modem cable I can’t think of anything else to try. This is rather important.

You could use the micro-B USB cable that comes with Jetson and put it in recovery mode just to test if your host sees the device. This might verify some function, but wouldn’t do much more. If Jetson is in recovery mode (hold recovery button down and power up while holding the button down), a linux host would see this usb device come into existence as measured by an nVidia device showing up under:

lsusb -d 0955:7140

If that shows up you could try flashing to R21.3, but I would not advise this until you know what shows up on serial console (again, DB9 cable needed). Trying to flash could throw away useful debugging information.

Thanks,
Guess I’ll have to steal a db9 cable.

Ok I have a db9 connected and I’m seeing the ttyUSB0 port.

I ran as instructed from various sites:

screen -U /dev/ttyUSB0 115200

after which I get a blank screen. What am I suppose to do now. I imagined I would get some kind of prompt in which case I’d know what to do from there but that’s not the case.
I also tried minicom but again I didn’t see how to gain access to the tk1 prompt.

Any suggestions?

The full setting is 115200 8N1. The DB9 on the Jetson side does not involve USB, so this tells me you are using a serial USB UART on a USB connector of your host. It may still work, there is sometimes a “quirk” this way.

If you connect everything on Jetson to host with power off on the Jetson, and start your serial console program, followed by powering up Jetson, the UART may not work the first time. It may need power for Jetson reset once to see the enabled port via USB. So after starting Jetson once, do not power Jetson down; exit the serial console program (I use gtkterm), start the serial console program again…and then press the power reset button on Jetson. Having seen power once on the serial UART may allow it to initialize if it didn’t see the serial port activate previously. It is quite common for some serial UARTS that have been powered off for some time to require this.

Assuming this does not work, then there is a serious hardware issue. Serial console should always see something, provided the serial UART sees the DB9 data (and the power cycle trick should guarantee that).