Pinging 192.168.55.1 works inconsistently

I am setting up headless device mode. I am running this from powershell as an administrator. When I try using ssh, with host@ip, the output varies between timing out or connection refused. On the occasion it allows me to connect, my connection will be reset. Does this have to do with the quality of the micro-usb connection?

Connection quality can be connection quality, but that won’t have anything to do with quality of network in the usual way. When the internal signal on the USB is too low, it will often (depending on device capabilities) just slow down to a slower USB speed standard. It isn’t likely that it would be like the internet whereby you get a certain percent of packets lost as a moving target. If USB quality goes a bit lower, then the USB would be completely missing. USB2 is pretty easy to support in comparison to USB3, so the micro-B USB cable (which is USB2), if it is the NVIDIA-provided cable, will usually just work; if it is a charger cable, then their quality is terrible, and they might seem to connect, but then lose USB connection entirely after a short time.

If USB is lost, you will have no route to host. Timing out won’t be the clue. However, firewalls and security can also get in the way. This might show up as no route to host, or it might show up as timing out. It just depends on the host and firewall setup. Normally I would run these commands on a Linux host, as the Windows version is a bit odd and not quite as useful, but you might try to see the output of these (sorry, some might require a “/a” option):

  • route (does it show the 192.168.55.x subnet?)
  • ipconfig /a (does it show a device set up for 192.168.55.1?)
  • ping 192.168.55.100 (pings from Windows to Windows with the USB local address for the USB virtual device)
  • ping 192.168.55.1 (pings from Windows to the Jetson over the USB remote virtual device)

With Windows it can be hard to tell when a firewall is in the way.

1 Like

I believe the symptoms closely follow a charger cable issue, as I have misplaced the original NVIDIA cable. I have tested the newer cable on a kindle, which showed that the cable was capable of transferring information. Is there any way to purchase the original NVIDIA-provided cable?

Hi,
Do you connect to a host PC in Ubuntu 16.04 or 18.04? This is a stable setup and shall work fine.

I don’t think you can buy the NVIDIA cable separately, but it would be very very useful to a lot of people (hint to NVIDIA!).

Many of the charger cables detect data, but they tend to fail with any significant data transfer. About all I can suggest, if that is the issue, is to try about three different brands.

We still don’t know for sure if it is the cable. If flash succeeds with the cable, then it is probably good, but you likely don’t want to flash anything just to find out. What were your ping results? What was the route and ipconfig /a during a failure (useful to compare to when it works, and useful to compare the result on the Jetson and on the Windows host PC)? There could still be issues like Windows security getting in the way at times.

Serial console would be nice to get a log from when it fails. Even if the host PC is difficult get logs from, running “dmesg --follow” on the Jetson to watch logs would indicate something if the USB itself fails. The Nano would note disconnect and reconnect and errors.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.