When connecting headless to the jetson nano via USB, windows is killing the ssh connection. This happens when using PowerShell / Terminal or PuTTY to connect to the SSH session. Has anyone had experience with this and know what processes are common for causing this to happen that I might be able to disable?
I am running Windows 10.0.17763
hello michael.party,
sorry, I don’t understand this clearly.
you’re accessing the target with 192.168.55.1? or, you’re having ethernet connected and ssh to the IP assigned by DHCP?
@JerryChang - I am connecting via USB and accessing at 192.168.55.1.
I have tried the KiTTY application as well and receive the same result. It seems like something in Windows (firewall or other) is killing the connection.
What is maybe even more weird, after reading your comment, I went and plugged the jetson nano into an ethernet port, found its assigned IP address and have connected over SSH that way, and it’s working fine! But I really need to be able to do this with the USB connection, so it doesn’t really solve my problem…
hello michael.party,
please share the steps in details to help us to reproduce your issue locally,
thanks
@JerryChang
Sure,
I connect the device via USB A / Micro USB to the Windows machine. I plug that barrel jack power port into the device (jumper in place for power by barrel jack). The device starts up and registers on the Windows machine. I initiate an ssh terminal using the PuTTY application (via 192.168.55.1). Typically, after I log in to the device using the credentials I set up, sometime between 15 - 45 seconds later the ssh connection is killed and the PuTTY application shows the following error: “network error: software caused connection abort.” Looking at the PuTTY logs and the logs on the device when the error occurs, it appears that something is killing the application outside of the ssh connection (nothing in the logs registers an error).
Can you “ping 192.168.55.1” from a DOS prompt? I’m thinking Windows is (by default) disabling that port and needs to be told to allow it (if ping fails, then it is probably that, and not just an ssh issue). I don’t know enough about Windows to suggest how to tell Windows to allow that network device.
The ping works… sometimes. We get some successful pings, some failed pings. Sometimes 0% loss, sometimes 100% loss. Usually about 50% or 75% loss. It’s really bizarre behavior.
It is possible that the USB itself is an issue. Are you using the micro-B USB cable which comes with the Jetson? Typical charger cables are very badly made so far as data is concerned (the supplied cable works quite well with data). Knowing if this has a similar unreliable nature with a different host PC running Linux would be useful information as well (or perhaps you could run your Windows PC booted to a Live Ubuntu 18.04 DVD/thumb drive…hardware would not be tested this way, but debug information might be better…testing from a different PC to get different hardware would be a better test).
Yeah I thought this might have been the case at first. We do have data USB cables and I can make this work on multiple machines but have a few machines where it is not working. I believe it is something firewall (or virus protect) related. I have disabled firewalls and security scans, but still something is happening.
Hi michael.party,
Are you connect micro-USB cable on J28 port?
Please connect micro-USB cable from host to target before system boot-up.
If this is a Windows setting issue, then probably that same machine, when booted to a live Linux distribution (meaning running from a thumb drive or DVD, so on, and not installed other than running in RAM), probably it will work from Linux (you could still monitor “dmesg --follow” as you plug in the USB to get more details), and you could infer hardware is functioning. If this fails even on Linux (using the live distribution on the same hardware), then probably this is a signal quality issue. The fact that this unit can work from some other machines tends to imply this is an issue with the particular machine(s) which it fails from (which tends to again imply signal quality, or else network/firewall settings).
That’s correct - Micro-USB to J28 port. I am connected before system boot-up.
I am pretty confident that it is network / firewall settings, but I can’t seem to figure out what is causing it to crash. Was hoping someone might have had a similar issue and had a list of some likely culprits. I’ve tried disabling all firewalls, still no success.
Sorry, I am not much of a Windows guy, so about all I can suggest is that if you unplug and replug the cable, perhaps the network setup applications in Windows might see the device again.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.