FYI, I consider 192.168.55.1
to merely be a convenience. Long ago this did not exist, and in order to add optional packages (during a flash) one had to have the wired ethernet connected to the same router as the host PC. Once this virtual (“fake/synthetic”) network was added it became possible to add optional packages over ssh
with nothing more than the same micro-B USB cable used for the original flash. Flash takes place in recovery mode, and then the unit self-reboots and further package additions then take place over ssh
.
In JetPack/SDKM, when you get past the first boot account setup, it then offers to allow the network-based install of things like CUDA. It happens that the default IP address offered to do this over is 192.168.55.1
(the host PC is itself assigned address 192.168.55.100
, so they are on the same subnet). You can still customize this, e.g, you can still plug host and Jetson into the same router, and if you know the IP of the wired ethernet, then you can use this instead of 192.168.55.1
.
Pinging 192.168.55.100
from the host PC pings itself. Pinging 192.168.55.1
from the Jetson pings itself.
The setup which creates this virtual network (along with a mass storage with a README file) is located at:
/opt/nvidia/l4t-usb-device-mode
Some of the files there are used for starting/stopping this, including making this available as a service. The file nv-l4t-device-mode-config.sh
is the file which actually sets up details of both the mass storage README file and the virtual network device details.
If you want this network to be disabled (and the README file in bulk storage), but still exist such that it can be reenabled at a later date, then see the output of this:
systemctl status nv-l4t-usb-device-mode.service
To disable (but not erase) this:
sudo systemctl stop nv-l4t-usb-device-mode.service
sudo systemctl disable nv-l4t-usb-device-mode.service
To later reenable this:
sudo systemctl enable nv-l4t-usb-device-mode.service