Set static IP before flashing?

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

I am working with a XavierAGX Industrial,
We want to be able to access the Xavier from a NUC after flashing either through usb or ethernet. During the image creation of the sdk mananger there is no menu to set an IP address for the xavier, just one to set username and password. The instructions that I follow are through connect tech

kdb375: CTI-L4T Board Support Package Installation Archive for NVIDIA JetPack with Connect Tech Jetson™ Carriers - Connect Tech Inc.

which states to download board support packages into the linux_for_tegra location. In there there is a directory called cti which houses a cti-flash.sh that we run ./cti-flash.sh. THis script prompts you to pick board and module.
The exception to the instructions above are that we choose jetpack 5.1.2

after this flash is complete it exits FR mode. I need to be able to connect to the Xavier directly after the flash without it being on a network, so either through usb connection or ethernet so that i can install my software on it through a python script.
I am aware that i need to put it in FR to be detected as USB. However, I want to know if there is anyway pre-flash to setup a static IP that goes with the image? or if there is some other way to connect to the xavier after it has been flashed?
Again this all has to be done off of a network so it will not obtain a dynamic IP. Additionally I am not connecting any kind of keyboard, mouse, or display directly to the Xavier.

2

For USB that address you would use is 192.168.55.1. If you really felt you wanted to modify this (it is already static), then you could find where that address is listed in this file:
/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-config.ssh

The host PC gets assigned address 192.168.55.100. As long as any edit to the 192.168.55.1 is in the same subnet you won’t need to change that. If you change the 192.168.55.1 to something else just be sure to set the 192.168.55.100 to the same new subnet with a non-conflicting address. Make sure this does not violate any other route or interface.

To aid in editing, know that in the host PC, within the flash software at “Linux_for_Tegra/rootfs/”, that almost all of this is flashed verbatim to the Jetson. Some boot related content, including the kernel and device tree and extlinux.conf will be copied into that just before flash based on the flash parameters, but content in “/etc/” and almost every location will remain exactly as you edit. If you happen to know which files edit the wired ethernet and/or any Wi-Fi in “/etc” to achieve your desired static networking, then editing in the host PC “rootfs/” will do what you want.

Note that there are differences between setting things up in a “managed” network versus an “unmanaged” network (e.g., Wi-Fi which triggers upon GUI login might cause wired to temporarily not be used). Often it is best to simply set up your Jetson the way you like it, and then clone. Clone provides both a raw clone and a sparse clone. The sparse clone is only useful for flashing, but the raw clone can be used in either flashing or editing (in fact a sparse clone can be created from a raw clone after editing if desired). Using the proper flash parameters one can flash that clone to the rootfs. If that clone has had all updates and any customizations, then the unit being flashed will have all those updates and edits as well.

A raw clone can also be loopback mounted and examined on the host PC. You could copy content in specific locations into “rootfs/”, or you could even copy everything into rootfs. Then that content would be the basis for flash.

The distinction between flashing a clone directly versus first putting it in “rootfs/” is that a clone flash is 100% exact, including kernel and device tree. If you copy that content into “rootfs/”, then this is true except for the few items which get updated, e.g., kernel, device tree, and extlinux.conf. Either will preserve login names and passwords.

If for some reason the USB virtual wired network is not working, then it is very likely security on the host PC rejecting it until you ok using that interface. Note that the virtual wired ethernet is in fact a simulated router, and the host PC sends a DHCP request, but the assigned address (at the host PC side) is always 192.168.55.100. The Jetson itself always has address 192.168.55.1 on that particular interface.

If you are using a home router, then if you know the MAC address of the wired ethernet you can tell the router what address to assign when that MAC requests an address. Then that device will always get that address, and no other device will ever get that address. There would be no need to go through all of that effort since DHCP would have a known assignment.

3

What i have resorted to attempting is to create a new connection under ~/nvidia/nvidia_sdk/JetPack_…version…/Linux_for_Tegra/rootfs/etc/NetworkMananger/system-connections

This is the image that was created using the sdk mananger. I am trying to configure it to have a static network connection for eth1 prior to flashing from my NUC to the Xavier INdustrial.

However, even with creating the proper configuration in this location for a static external connection i still cannot connect from the nuc to the xavier via ssh.

I have had success when i connect the Xavier to a network, ssh into it, then run nmcli connection add then removing the xavier off the network and reconnecting directly to the nuc via ethernet. but this iis not how we want it done.

I want to be able to have the Xavier and the NUC completely off of a network and flash a preconfigured image from the nuc Xavier that contains a static IP. After the flash I want to be able to ssh into the Xavier from the NUC using the IP address in the configuration.

4

Are you sure that file edit is correct? If you run this manually directly on the Jetson, does this set up networking correctly? Managed networks deprecate many of the older methods of setting up wired networking.

On the Jetson itself, if you login name is “user” (adjust for your case), can you ssh locally? Example:
ssh user@127.0.0.1

…or…
ssh user@localhost

If those do not work, then the ssh server is not running. If they do work, then we need to find out more about the network between the two computers.

5

This is essentially what the system connection file looks like under system-connections within the LInux_for_tegra image…

FileName: External-Connection.nmconnection

[connection]
id=my-eth1
uuid=
type=ethernet
autoconnect=yes

[ethernet]
interface-name=eth1

[ipv4]
method=manual
address1=169.254.116.1/24

To your point about the ssh server, When I have the headless xavier on our local network and the computer on the same network i can ssh in using the dynamic IP. But we want to be able to ssh in without being on a network.

To test my configuration above to ensure it is set properly i,
SSH into the Xavier while its on a network. Run nmcli connection add command from within the Xavier and set my static IP and other properties. Then remove the Xavier and the computer from the network. Connect the computer and xavier together via direct ethernet. Change IP on the computer to be in the same subnet as the Xavier, At this point I can SSH in to the xavier with the static IP. I find it on then when i run the nmcli connection add command directly on the xavier the static IP works, but it doesnt work if i manually add the .nmconnection file before flashing from the computer to the xavier.

However, What I want to be able to do is preset these configurations before the image is flashed onto the Xavier so that when the flash is complete I can ssh into the Xavier using the preset static IP through direct ethernet connection.

I have already attempted to do this by adding the configuration file under the Linux_for_tegra/…/…/… image location prior to flashing. The configuration copies over to the Xavier in the write location but I am unable to get a connection to the static IP. I have tried to ping and ssh the static IP with no luck.

I recall you mentioning that the USB port itself has an IP that is a default for flashing the image. However, I am unsure of how to go that route to connect to the Xavier to perform the tasks I need to perform.

To simplify my requirements, I need a way to be able to SSH into the Xavier so i can run my Python script to install my software and make some other configuration changes. THe method in which to connect to the Xavier does not matter to me.

6

The reason for asking about ssh to 127.0.0.1 (or localhost) is to examine the function of the ssh server itself. It sounds like basics do function.

Is there a switch between the host PC and the Jetson? Or is it directly wired? If directly wired, is a crossover cable used?

On both host PC and Jetson, what do you see from “route” and “ifconfig”?

Incidentally, if you use public/private ssh key pairs, this is quite easy to use for manual remote update.

7

On the Xavier, SSH to 127.0.0.1 works.

When it is connected to the network yes, it is connected to a switch.

However, What I am trying to do is ssh through direct wire connection from the Xavier to my NUC. When doing direct wire, there is no cross over used just a cat5e.

on Jetson (connected to network)
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 101 0 0 eth1
IP 0.0.0.0 255.255.255.0 U 101 0 0 eth1
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 eth1

ifconfig
eth0: details
eth1: details
lo: details

On NUC (host)
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 100 0 0 enp3s0
IP 0.0.0.0 255.255.255.0 U 100 0 0 enp3s0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp3s0

ifconfig
enp3s0: details

lo: details

wlp2s0: Details

8

I am guessing that crossover is not mandatory, but beware that not all ethernet auto detects the need for crossover cables.

Note that log output or copy and paste can have whitespace preserved if you highlight this in the forum and then click on the “code” icon (which looks like “</>” when editing a post). You can also click on the pencil icon in the lower right of your own posts to edit, e.g., you could go in and mouse highlight route output and click on the code icon to cause it to preserve white space and to prevent odd character sequences from being misinterpreted.

Please note that the reason for wanting both route and ifconfig details is to examine if subnets are being used directly, or if a gateway is used. If the former, and if both systems have a valid idea of being on the same subnet, then it should work; if not, then you don’t have a router and gateways will fail. There is no way to know with the details removed. If these are behind a router or not connected to the internet, then that information would not be harmful to publish since anything behind a router is a non-routable address (and having no wiring to the internet could be considered non-routable to the internet as well).

Additionally, if there are two networks on one computer, then those addresses also need to be considered for conflicts.

With what I know, you are seeing the login attempt on the Jetson via the auth.log. Networking must be functioning, but I don’t know if it is entirely correct. Maybe it is.

We know that you can log in locally from the Jetson to the Jetson, with the correct behavior for name and password. I am assuming you have used copy and paste to be certain that the password used is correct from the remote end where it fails with the claim of incorrect password.

One possibility is that what is being sent is not what you think is being sent. I could see a character set difference causing this, although it shouldn’t. On both Jetson and the host PC, what do you see from:
echo $LANG

If there is a difference, then what you are sending from one computer to the other might be interpreted differently (it shouldn’t, but it could).

9

Ok here are the actal details of the outputs

this is for the NUC (Host)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 enp3s0
10.10.51.0      0.0.0.0         255.255.255.0   U     100    0        0 enp3s0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp3s0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.51.83  netmask 255.255.255.0  broadcast 10.10.51.255
        inet6 fe80::344f:a63c:323a:f0d4  prefixlen 64  scopeid 0x20<link>
        ether 94:c6:91:ab:7b:bc  txqueuelen 1000  (Ethernet)
        RX packets 111  bytes 36183 (36.1 KB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 150  bytes 20397 (20.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 159  bytes 13313 (13.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 159  bytes 13313 (13.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether a0:a4:c5:7a:6a:b6  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

this is for the Jetson

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    101    0        0 eth1
10.10.51.0      0.0.0.0         255.255.255.0   U     101    0        0 eth1
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 eth1

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::224f:cc94:c27d:37e3  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:8b:b8:1b:7f  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 46  bytes 7265 (7.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x1230000000-123007ffff

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.51.92  netmask 255.255.255.0  broadcast 10.10.51.255
        inet6 fe80::fc45:2d2:65ed:89ea  prefixlen 64  scopeid 0x20<link>
        ether 48:b0:2d:55:b9:a6  txqueuelen 1000  (Ethernet)
        RX packets 198  bytes 130663 (130.6 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 183  bytes 24430 (24.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 220  bytes 18474 (18.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 220  bytes 18474 (18.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

keep in mind these are while they are wired into a switch to a network so i can actually ssh into the Jetson.

The login I have used so far has not been from Jetson to Jetson. It is from any PC, in this case a NUC with Ubuntu 20.04 installed via ssh through a network that is assigning IP.

echo $LANG from Jetson
en_US.UTF-8

from NUC
en_US.UTF-8

10

For the network setup in your reply, this is the 10.0.0.0/24 network on the NUC. On the Jetson you have the same subnet, so this is so far compatible and correct. I do see though that the Jetson has two ethernet cards, the integrated one plus something else (the integrated one is not configured). The address the Jetson would be reached at in this configuration is 10.10.51.92 (this is a non-routable address, and so it cannot be reached over the internet…this is private to your LAN).

I have some concern on the NUC enp3s0 interface. It has two dropped packets, which is unusual, especially on a LAN. This isn’t necessarily a problem if you don’t get dropped packets in normal operation, e.g., if you were hot plugging cables, then there might be a drop. Normally though there would be zero dropped packets. There are no overruns, collisions, or other errors, so I would say that this network is correctly configured.

  • The eth0 interface of the Jetson is not configured, but something resulted in 46 packets sent. This would be an attempt to configure by DHCP, and so this is correct and not an issue.
  • The eth1 interface of the Jetson is doing well, nothing to care about.
  • Default routes will do as expected.

It is quite odd that ssh works from the Jetson to the Jetson, but that the same password gets marked as incorrect when coming from the outside world. There is a possibility of rejecting ssh for any number of reasons, but the reason in the auth log is specific to the password. Are you able to ssh to the NUC from the Jetson? Do you see any increase in dropped packets on the NUC’s enp3s0 after an ssh login attempt from NUC to Jetson?

11

Yes I can ssh from the Jetson to the NUC with no issue and vice versa. There was an increase in dropped packets when ssh from jetson to NUC

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.51.83  netmask 255.255.255.0  broadcast 10.10.51.255
        inet6 fe80::344f:a63c:323a:f0d4  prefixlen 64  scopeid 0x20<link>
        ether 94:c6:91:ab:7b:bc  txqueuelen 1000  (Ethernet)
        RX packets 1335  bytes 509473 (509.4 KB)
        RX errors 0  dropped 67  overruns 0  frame 0
        TX packets 1305  bytes 116185 (116.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 260  bytes 26408 (26.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 260  bytes 26408 (26.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether a0:a4:c5:7a:6a:b6  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

To your point about the eth’s on the jetson.
eth0 is being used by another device that is inaccessible. So, I want to ssh into the xavier via eth1 but with direct connection from the nuc to the jetson.

I am also open to doing a serial connection if necessary. I am currently following some tutorials on it to try and see if that will allow me a connection to go in and set a static IP.

12

I would say the issue is from dropped packets. You’ve demonstrated that the network is correctly configured, that ssh works correctly on both ends, and that the password is correct. The dropped packets should not be occurring, or at least this should be very rare. Dropped packets across the internet is not uncommon, but on a LAN it is a concern.

If the Jetson end is not showing errors at the same time that the NUC has increasing errors, then it tends to imply the issue is the NUC, the cable from NUC to switch/router, or both. The router or switch itself might be at fault, but likely, if this is the case, it is one particular port. If this is a switch, then try moving the RJ-45 connector to a different port and resetting power on the switch; if it is a router, then the same thing is suggested if the NUC goes directly to the router and not via a switch.

13

So you think that the dropped packets issue is causing the problem of direct connection between the nuc and the Jetson via ethernet? The tests you had me run are from it being hooked up to my LAN.

Is there some kind of configuration i can do when creating the flash image that will allow me to set a static IP on the Jetson?
On the jetson XAvier Industrial, which port is used for serial connection/debugging? Is this a route that i can consider using to set a static IP on the Jetson?

The original problem is that I need a way to be able to access the Jetson directly after flashing to set a static IP so install my software. Whether this is done through serial usb or through ethernet makes no difference to me.

14

I typically don’t do this since managed networks have their fingers in too many places and don’t respond the way you might expect if not an expert on the configuration. But…static configuration may not fix this if there is an issue with dropped packets. By cutting out the middle of the connection (the switch or router) it might help if one of the “middle” components was causing the lost packets. Don’t know, but it is worth trying.

Do you have “nm-connection-editor” on your Jetson? There are the usual Ubuntu mechanisms for setting this up in the GUI, but I almost always test with adjusting via nm-connection-editor. If you don’t have this, then “sudo apt-get install nm-connection-editor”. Then start this with “sudo nm-connection-editor”, select that interface, and follow the tabs. If that works, then you can examine the configuration file changes made by nm-connection-editor, and copy those into your mirror of content on the host PC at “Linux_for_Tegra/rootfs/” (be sure to maintain file permissions). However, don’t bother unless testing shows this as working. The issue is quite possibly not related to the Jetson itself.

I don’t know on the Xavier Industrial which port is for serial console. This would depend on the carrier board, and I have neither industrial module nor a carrier board for an industrial module. The non-industrial AGX Xavier uses the smaller USB connector on the left side of the 40-pin header, while the Xavier Nano and Xavier NX use header pins (usually pins 9 and 10, plus ground). Third party carrier board manufacturers are free to change the layout and available ports along with a modified device tree for that layout change.

Depending on the board (and I don’t know on your model) the USB port used for flash should also produce a static virtual wired ethernet device over the USB. In the flash software you would name that address as 192.168.55.1, but it won’t work until the first boot account setup is complete (there needs to be an account before ssh will work).

I do recommend using serial console during flash and watching to see if it asks for first boot account setup, but I have no idea on your model which port that might be. There is an alternative though whereby you can create first account login setup in the “rootfs/” of the host PC prior to flash…all of that first boot setup will be complete the moment the Jetson boots normally. You would not want to do this with a shipping unit for retail sales (due to California law), but it works quite well for developing and for your own devices.

For setting up the rootfs first boot details ahead of flash, on the host PC, from Linux_for_Tegra/, run this:
sudo ./tools/l4t_create_default_user.sh

Your host PC can reject the virtual wired ethernet if security setup does not allow it, but normally 192.168.55.1 will “just work”. Combine that with the default user setup script prior to flash, and you should be able to add software over that link.

15

I was able to find a solution to my problem.
I created a shell script in Linux_for_tegra/rootfs/etc/init.d/add-static-ip.sh
I then had to create manual symbolic links to the proper locations within the image.

Within the script I run the nmcli con add command with my set parameters, this adds the system connection and i am able to ssh into the xavier using the set static IP.

I flash the image onto the Jetson, the system connection is there and im able to ssh into it.

I want to thank you for all of your help and information.

16

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