TX2 ssh session disconnects after ~2 minutes

Windows host machine connected directly to TX2 using Ethernet cable, with port on Windows machine set to be dynamic. Initial attempt to connect to TX2 by “ssh @.local” is successful but connection closes after about two minutes regardless of activity. When session closes the print statement is “Connection reset by port 22”. On occasion, the connection holds for several hours but this is rare and I still experience lags.

If I attempt to ssh immediately after the connection is closed I get:
“ssh: Could not resolve hostname .local: No such host is known.”

If I unplug the cable and plug it back in I can connect again but the connection still closes.

I have tried “sharing” the host Wifi (which sets the Ethernet port to a set static IPV4 address), connecting both machines to a router (that is not connected to the LAN), connecting both to LAN (Note: The TX2 Ethernet port works). I’ve also switched the cable & host machine and tried deleting the “known_host” file. There is no change with any configuration.

Something I noticed, that may or may not be related, is when the TX2 is connected to a monitor under “Network” where it shows the Ethernet connection it seems to ssh successfully while “Connecting” but when it switches to “Disconnected” I get kicked off.

The only similar topic I found was this:
https://devtalk.nvidia.com/default/topic/1043360/jetson-tx2/issue-reliably-ssh-ing-into-tx2

I am very reluctant to re-flash, so hopefully there is some other fix.

Hi,
Please try

ssh <user>@[Eth0 IP address]

We usually login with this command. I see .local in your command. Not sure if it makes difference but play try the command without it. For information, please share your release version($ head -1 /etc/nv_tegra_release)

When you are logged in to the Jetson, what do you see for the output of “ifconfig”? IPv6 addresses may have some quirks associated with them, and the IPv4 address may work better. “ifconfig” should point out an IPv4 address in most cases.

Note that when you use a named address there is a DNS lookup performed (or some variant…not sure of the significance of the “.local”). One can skip DNS by using a dotted decimal address directly. I’m thinking that perhaps things will work if you know that particular variation of the address and skip using any named address (and I assume it is the named to dotted-decimal process which is producing IPv6).

The known_host file is good for customization if you know of an IP address which works, and wish to provide a nickname for (sorry…bit of a lame joke…NIC name). Linux does the same thing with the “/etc/hosts” file if you wish to provide a custom name for a dotted-decimal address. However, unless you know of a consistently working IP address, then that file will fail you as soon as an address changes.

‘head -1 /etc/nv_tegra_release’ yeilds:
#R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu Msy 17 07:29:06 UTC 2018

I agree the IPv6 address is most likely the problem and I would like to ssh using the IPv4 address but there doesn’t seem to be one. Pinging ‘tegra-ubuntu.local’ shows me the IPv6 address. It has been suggested to me to use the -4 flag to get the IPv4 address but it fails to find the TX2 every time.

The output of “ifconfig” does not show an IPv4 address for “eth0” only the IPv6 address. And this is the same IPv6 address I receive when I ping the TX2.

I used “.local” because it had been suggested to me as something to try. I am able to ssh whether I use “.local” or not and still encounter the same problem. But I can’t seem to ping the TX2 unless I use the “.local”

Can you post the output of “ifconfig” and “route”? Those will be what the Jetson thinks its network interface is, while the host’s idea of the “.local” requires either a DNS lookup or a host file lookup. If we can nail down a dotted-decimal address, then that should be the acid test of where the failure is really occurring…DNS or other.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
link-local      *               255.255.0.0     U     1000   0        0 l4tbr0
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0
192.168.55.0    *               255.255.255.0   U     0      0        0 l4tbr0
__________________________________________________________________________________

docker0   Link encap:Ethernet  HWaddr 02:42:fe:11:1a:5c
          inet addr:172.17.0.1  Bcast:172.17.255.255  Mask:255.255.0.0
          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:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:04:4b:a7:dd:5f
          inet6 addr: fe80::204:4bff:fea7:dd5f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1710 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1299 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:149362 (149.3 KB)  TX bytes:265131 (265.1 KB)
          Interrupt:42

l4tbr0    Link encap:Ethernet  HWaddr 8e:68:2e:1a:99:b5
          inet addr:192.168.55.1  Bcast:192.168.55.255  Mask:255.255.255.0
          inet6 addr: fe80::d42d:98ff:feaf:15a4/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:555 (555.0 B)

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:18836 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18836 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:1132032 (1.1 MB)  TX bytes:1132032 (1.1 MB)

usb0      Link encap:Ethernet  HWaddr da:19:62:09:eb:64
          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)

usb1      Link encap:Ethernet  HWaddr 8e:68:2e:1a:99:b5
          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)

wlan0     Link encap:Ethernet  HWaddr 00:04:4b:a7:dd:5d
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:792 (792.0 B)  TX bytes:1080 (1.0 KB)

The regular ethernet connection, “eth0”, has only an IPv6 address (“fe80::204:4bff:fea7:dd5f”). From previous posts it seems you want to connect through the wired ethernet, and not the micro-B USB cable. Is this correct? If so, then the Jetson is listening at “fe80::204:4bff:fea7:dd5f” (an IPv6 address). What I am going to suggest is to disable IPv6 on the Jetson to get it to use an IPv4 address (I’m not very good at debugging IPv6, and many applications are still confused by IPv6).

If you edit file “/etc/sysctl.conf”, and add two lines to it, followed by reboot, then it should stick to IPv4. Using your favorite editor (using “nano” as an example):

sudo nano /etc/sysctl.conf
# Go to the end of the file, add these two lines:
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
# Reboot, e.g., "sudo shutdown -r now".

If this does not help, then it is easy to remove those two lines. If for some reason there is still an IPv6 address, then you could add " ipv6.disable=1" in “/boot/extlinux/extlinux.conf” at the end of the “APPEND” key/value pair (this probably is not necessary):

APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 <b>ipv6.disable=1</b>

When you run “ifconfig” you should see an eth0 address like “192.168.1.2” instead of “fe80::204:4bff:fea7:dd5f”. Whatever that address is, then your windows PC should be able to connect to that address. At a DOS prompt you should also be able to “ping” that address.

Does the IPv4 address work for you?

I tried editing the /etc/sysctl.conf and the /boot/extlinux/exlinux.conf and now I do not see either an IPv4 or IPv6 address.

eth0      Link encap:Ethernet  HWaddr 00:04:4b:a7:dd:5f  
          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

Is your router set to only allow IPv6? Is there any kind of a web login to your router such that you can check logs? If so, then look at the logs, then boot the Jetson, and then check the logs to see what is said about the DHCP reply.

It isn’t a guarantee that an IPv4 address would fix things, but this usually simplifies life and often gets rid of any possibility of non-IPv6 software getting in the way.

Incidentally, do you have another Linux computer? If you do, then from the other computer, can you ssh to the Jetson using the IPv6 address, and does this remain connected?

If not, then consider something which might at first seem odd…log in locally to the Jetson, and ssh to the Jetson at the IPv6 address. The address would still be assigned by the router, but the route would end up with the Jetson talking to itself (and I am thinking avoiding any router issues).

I am not currently using a router. The Windows machine and the TX are connected with an Ethernet cable. Eventually, the TX will be aboard a ROV and outside I will not have access to a power supply for a router, so I need to ssh reliably without a router. Currently in the ROV, I am using a raspberry pi in the same configuration with no problems (so I know it can be done). If using a router is my only option, I will have to figure that configuration out but I am not yet at that point.

I do have a linux machine but because it is a newer machine it doesn’t have an Ethernet port so I can’t connect it to the TX. I could purchase an adapter and give it a try tomorrow. It would be interesting to see if a Linux computer fixes the missing IPv4 address problem.

I ssh-ed from the Jetson to the Jetson when I first encountered this problem to make sure the TX could ssh at all and that worked, but I can’t remember what IP address I used… That said I just tried it with the IPv6 address when the Jetson was connected to the Windows computer via an Ethernet cord and the connection timed out several times. I don’t know if this will give you the information you were looking for since I wasn’t using a router but I tried it anyway.

By default the only way the address will be assigned is via the DHCP protocol. This is normally via a DHCP server, and that server is traditionally part of the router. If your Windows machine is acting as a router, then this means you’ve added a DHCP server to the Windows machine (Windows won’t have a DHCP server by default…perhaps for a server edition, but not normally). It is the DHCP server which is configured to give out IPv4 or IPv6 addresses. Do you have DHCP server configuration options on your Windows host?

Incidentally, a Linux system would work well, but would need to be configured for DHCP server setup. It doesn’t cost anything and is simple (relatively) on Linux, but would still require some setup.

A router would remove the need for any setup of the DHCP server (even so it often helps to tell a router what subnet or IP range you want to use).

Optionally the Windows PC or a Linux PC can forward DHCP requests, and this would imply that whatever router the Windows PC is connected to would be the one which the TX2 is using to get its address. If you’ve never added a DHCP server to the Windows PC, then perhaps this is what is happening.

If for some reason there was an assigned address on the TX2, and you then connected to ethernet without a router or DHCP server, then once the DHCP lease goes to renew the TX2 would then lose its address (address assignments on DHCP typically renew after some period of time). An example of this might be if the TX2 was plugged in to a router elsewhere, and then the cable was moved to the Windows PC…after some time a lease renewal (DHCP request) would occur, and the failure of no DHCP response would erase the address.

I have set up my Windows machine to “share” the internet (I did this in the Network & Sharing Center in Windows 10), which I believe allows the Windows computer to act as a DHCP server. So when the TX is connected to the Windows machine by an Ethernet cable the Windows machine will assign an IP address to the TX.

Or at least that’s the idea…

When sharing it implies that the DHCP is forwarded between Jetson and router with Windows as a middle man. The router your Windows system is using would also become the router for your Jetson. If for some reason the router does not want to reply to the Jetson (and security can do this), or if some sort of firewall rule within Windows is required to allow passing through DNS or DHCP, then this would be an issue (and there is a strong chance Windows would have a security setting or forwarding configuration requirement before DNS and/or DHCP is allowed through).

I could be mistaken, but I think that before Windows can become a router itself (and directly provide DHCP without passing through to a real router), that you would have to add software for this purpose (and probably pay money for it).

If the address is valid, but DNS is not working, then you should still be able to use the numeric address. However, there is yet another trick to get past: Your Windows host would need the address in its routing table. If routing is not correct, then there would still be no route to host (in this case a route from Windows to the Jetson) using a valid numeric address. I do not have the knowledge in Windows, especially under IPv6, to know how to test this, but it is almost certain that the Windows sharing will itself need some adjustments.

Anyone here who can suggest how to debug network sharing between Jetson/Windows/router under IPv6?

Alternatively, can you connect the actual ethernet of the TX2 directly to the router?