Serial console is described here for a Nano:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
Do note that I am assuming you have the NVIDIA SD card model of developer kit. There are third parties who sell the eMMC model (eMMC versus root filesystem on SD card; an SD card model does not have eMMC, although it has QSPI memory for boot and BIOS type content), and information will change because the device tree, which routes optional pin functions, would differ. So the first thing is to state if this is a purely SD card model (the SD card slot is on the module itself), or if it is a third party design (on those the SD card slot would be on the carrier board instead of being on the module).
The serial console is important because it logs even in boot stages before Linux even starts. It can see things like driver setup even when the driver is loaded by boot software. No GUI is needed. There is a serial UART which simply streams content as it boots, and the serial UART is monitored by another running on a host PC with a serial console program looking at the UART of the PC side. Usually this is done with a “USB serial UART cable”, where it has at least three individual wires at one end (which connect to the Jetson’s ground, UART TX, and UART RX header pins), and runs with a 3.3V level at that end; the other end is just a USB cable which plugs into the host PC. You run the serial console program against that UART at speed 115200 (it isn’t plug-n-play, so the serial console program needs to know how fast to run), 8 bits (this is usually the default, but it is better to name it), 1 stop bit (this is also usually the default, but it is better to name it), and no parity bit (same thing on better to name it). Then you power on the Jetson, and the data will start flowing. If you tell the serial console program to log before applying power to the Jetson, then you get this wonderfully useful log. A bit later in boot, you get a chance to log in to the Jetson over that UART terminal in a text mode login. VERY powerful as it runs even if networking, monitor, and most all of the rest of the system dies. The video driver is on the host PC, not the Jetson. I think most USB serial UART cables (you need 3.3V, a.k.a., TTL level) run about $15, but some are less expensive or more expensive. Some have more than three wires, you simply ignore the extras (they can be useful in some cases, but you’ll probably just tape them off so they don’t get in the way if using it with a Nano).
5. If both wired and Wi-Fi run, and do not overlap, and neither of them have subnets for the destination of the address, then traffic goes to the default address. However, what happens if there is a default route for both wired and Wi-Fi? Then each default route will have a metric, and the default of the lowest metric wins. I would not be surprised if the Wi-F is a lower metric than wired (it really shouldn’t be), and I would not be surprised if the default route associated with the Wi-Fi has a lower metric than any wired default route.
In your case Wi-Fi is not active despite being in the GUI. Wired is in fact active and working. An outside computer, if not isolated by some security measure and not having to go through the outside world into the router’s DMZ, should be able to ping or ssh to 192.168.0.100.
Keep in mind that some of this is common to all of Linux, while other parts are specific to Ubuntu.
This is the long explanation (I feel an evil laugh coming on :) )…
This isn’t just about networking, it is about how networking is started. The boot stages are actually their own operating system, but the purpose is for the boot software to overwrite itself with the Linux kernel. The kernel is much like the proverbial kernel in popcorn. It is the kernel which directly talks to hardware and has the drivers, but a human doesn’t really talk to the kernel. I’m reminded of the anime series “Sword Art Online”, where the characters inside the cartoon say “system call”. It is in fact a “system call” any time something talks to the kernel.
Unlike Windows, the graphical interface is not part of the kernel. One has the choice to adapt or wrap the kernel in a number of different methods for humans to talk to the kernel. The purely text mode is called a shell. Just like the shell around popcorn wrapping its kernel. Humans might do something like list files, and this is using human readable commands. Those in turn get turned into system calls, and it is the kernel doing the real work. strace is interesting because it monitors system calls, and translates them into a human readable form which looks like the C programming language (because C is a standard for use with the kernel and calls to the kernel…it is part of the POSIX standard which originally defined the trade name UNIX…UNIX is a proprietary name, but anything with its own name that follows the right POSIX standards is interchangeable with that).
One can also wrap around the kernel with a graphical shell, although it is usually just called a graphical mode and not a shell. Really though, it is another form of a shell.
Once the kernel loads, it has only one job: To start the process or program named “init”. In Ubuntu (and many more modern Linux systems) this is actually a modular program called systemd (which is controlled via systemctl if a human interacts with it). systemd configuration will determine what it in turn runs. Note that everything running has a process ID. That PID for the kernel is PID 0. The PID for init is 1. All processes are child of systemd, which in turn is a child of the kernel. Killing a parent ID kills every child ID (usually, but things can be arranged for different behavior).
As such, networking itself is brought up at or just before what systemd refers to as “multi-user.target”. That’s the fancy way of saying the text mode shell becoming available for login. There is actually a possible rescue mode which is also text mode, but it is the only login in that case, and further logins are not possible. multi-user.target allows thousands of logins. Key bindings switch between perhaps 6 possible text mode terminals: F1 through F6 in most cases.
Then graphical.target runs, and normally it replaces the F1 key binding, and is the default you would see. If you are in graphical mode, and use the key binding ALT-F2 through ALT-F6 (if they are set up that way…usually they are), then you will switch to the text mode terminal at that binding. One could switch between text mode bindings with just the F2 through F6 (they’re all independent logins). Or one would go back from a text terminal to the GUI with F1. All run simultaneously, all are independent logins.
Wired networking begins due to configuration (most of the time) when you reach text mode (multi-user.target). Ubuntu does not normally start Wi-Fi until both of (A) graphical.target is reached, and (B) a user actually logs in. This alters (or “manages”) some network devices. Not all network devices are managed. A useful GUI tool for setting this up is by running the command “sudo nm-connection-editor” (if you don’t have this, then you can run the command “sudo apt-get install network-manager-gnome”). I don’t recommend changing things with this unless you know what you are doing (even so, I recommend this before editing files). It looks like this is used in your screenshot. Lots of other methods available though.
As you log in to GUI, Wi-Fi tries to run, and this disables wired (or usually, on Ubuntu, plus some other distributions; distributions don’t modify the kernel, they change which init is used, and is often similar among them, and they change what GUI is used to “wrap” around the kernel).
The ifconfig command will show you a few interesting things, especially in error conditions. Mostly the interest is in knowing if an IP address was issued and set up (or statically configured in some cases).
Containers like docker must talk via networking too, and forwarded through the host PC. You can ignore this. “lo” is loopback, and is used for network based communications when there is no actual network hardware (the GUI tends to use network protocols to talk to the kernel and init). Address 127.0.0.1 is what we call “loopback”. If you ping this, then you are pinging the local computer without touching actual network hardware. You can ignore this.
I don’t know all the details of Wi-Fi, I try to avoid it. I use wired in every case I can. The rndis0 is related to this. If you didn’t have Wi-Fi trying to run, I suspect (but am not certain) that rndis0 would not show up (although possibly the usb0 would cause this as well). The usb0 is a virtual wired ethernet over a USB cable whereby the micro-B cable plugging into the micro-OTG USB connector turns the Jetson into a USB network router (at least so far as the other end of that one cable thinks); the host PC with the USB type-A end of that cable causes the host PC to think that a router is on the USB cable, and the router offers an address to both ends of the connection. This in no way interferes the rest of networking, and can be ignored (but the fact that usb0 has no IP address says the micro-B USB cable is not plugged into the Jetson or the USB type-A of that is not plugged into a host PC).
We’re interested in rndis0 (sadly, since I know the least about this part of networking…I really do intentionally try to avoid Wi-Fi). The gist though is that plugging in Wi-Fi (it is wireless, but connections could be considered “plugged in” if it talks to a Wi-Fi router). Your Wi-Fi is not currently active. Your wired eth0 is active. This means you could talk to wired ethernet over its IP address of 192.168.0.100. If Wi-Fi were to activate, then I think the rndis0 would gain an IP address.
Then we have to talk about routing tables. Run the command “route”. I don’t know if you know what a netmask is (this is all networking, not just Linux), but when you talk about routes you have to know about a netmask (it would be useful to see your output from the command “route”). When the kernel decides which network device to send traffic over, then it has a hierarchy of choices with decreasing priority; the highest to lowest is something like this:
- Route to the IP address directly if the IP is an exact match to the device. Examples: Talking to
192.168.0.100 implies eth0 because this is its exact IP address; anything addressed to 127.0.0.1 will always go to that because this is the exact IP address.
- The term “subnet” is growing somewhat out of date if we include a newer IPv6 scheme, but we are only talking IPv4 with the above addresses. However, that address
192.168.0.100 shows a netmask of 255.255.255.0 (those are 8-bit binary masks superimposed over 192.168.0.100). This netmask says that anything in the range of 192.168.0.0 through 192.168.0.255 is in the same subnet; other addresses are outside of this subnet. If the exact address is not asked for, then all traffic then goes to that interface because it is the same subnet. Two devices do not normally overlap subnet (there are exceptions if the metric differs).
- There is a default route. If you attempt to talk to an address which is not the exact address, and no interface (
eth0 is one interface) has a subnet containing the address, then usually one of the routers which assigned that address is named as a “default route”. The traffic is then sent to the default route, and the default route decides where to send the traffic.
- If you talk to an address which overlaps two or more subnets, then it is the “metric” which decides which interface is used. A high metric is a “high cost”. A low metric is a “low cost”. Sometimes Wi-Fi and wired can overlap (not usually), and the one which is marked with the lowest metric is used. It seems backwards to me, but quite often you will see that bringing up the Wi-Fi sets a lower metric to the Wi-Fi compared to the wired; this tends to disable wired, although it isn’t really disabled. In that case traffic to the exact IP address of the ethernet would still go to the ethernet, and would function correctly. The usual case though is that Wi-Fi coming up will end up taking priority from wired; in some rare cases it will actually disable wired.
In the case of Wi-Fi, if it starts to connect, and then disconnects, it is likely due to the router itself having security settings. Sometimes the Wi-Fi router is set to allow only devices with an allowed MAC address. Sometimes the router requires a certain encryption standard. I can’t tell you much about that, but it has to be set up via login to the router itself, and matched in the Wi-Fi setup. When that happens, then Wi-Fi should stay up, and route and address setup will make Wi-Fi the priority.
Some commands to post for people setting up Wi-Fi:
rfkill list (or just rfkill)iwconfig
Wired currently works. Post the above Wi-Fi commands and I think someone could help with Wi-Fi setup, but you should still log in to your Wi-Fi router and check the logs. It might just tell you something like “rejected for unknown MAC address” (or something that could tell you exactly why Wi-Fi is dropped without any further effort).
