I see docker on the host, so I want to first verify that JetPack/SDKM is not running in any kind of special container or VM environment. Those environments tend to not work and greatly complicates both networking and USB configuration. Docker can show up for a lot of reasons, but I want to be sure the host itself is not a container.
In this case the question of whether basic networking works is whether or not the ethernet has the ability to function over the micro-B USB virtual ethernet, and whether the system has a route which acknowledges and uses that device.
When an interface has an address and netmask combination, then any request for traffic over an address within that address/netmask combination will go directly to it. Some examples:
# Jetson itself is 192.168.55.1, and any address requested from 192.168.55.0 through 192.168.55.255
# will go to this interface. In the specific case of 192.168.55.1 this is the Jetson itself. In other
# cases the traffic will be referred to the router (if there is no router, then the traffic fails for
# any 192.168.55.x which is not specifically 192.168.55.1). A user logged in to the Jetson should be
# able to ping 192.168.55.1 even if nothing on the outside world exists. Ping of any other
# 192.168.55.x address will work if and only if an outside host has that address either directly or
# indirectly through a router. If you were to ping 192.168.55.100, then the outside world would have to
# respond.
net 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
# On your host I see the expected 192.168.55.100. A login to your host PC would be able to ping
# 192.168.55.100 even if nothing on the outside world talks to it. With the netmask shown any traffic
# to any address within 192.168.55.0 through 192.168.55.255 will go to this interface, but require an
# outside world system to respond to that address. If you were to ping 192.168.55.1, then you would get
# a response only if the network finds that host.
inet 192.168.55.100 netmask 255.255.255.0 broadcast 192.168.55.255
The “route” command shows information about which interfaces to use. In the case of no two network interfaces overlapping the default is that traffic requesting an address within an address/netmask combination goes to that interface…it’s a no-brainer. “route” information becomes important when traffic is requested outside of that interface or when two interfaces overlap.
It’s actually easier to start with the more complicated “overlap” case. Imagine you have two interfaces configured to the same address/netmask. Which one would the kernel choose? If you are using a high reliability failover system, then one interface would be listed with a lower “metric” than the other, and so long as that lower cost metric is available the traffic would always go to that…but if that failed, and another interface exists with a higher metric, then traffic would automatically reroute to the other matching interface. If you have bandwidth sharing software, then if two interfaces have the same metric, you might find traffic is split evenly across both interfaces to double the available bandwidth. In the case of WiFi overlapping wired you might find WiFi is given a higher metric and the system switches to the wired interface when the ethernet wire is connected.
The gateway in “route” tells where the system forwards requests which are outside of all existing interface address/netmask combinations. The gateway itself must be directly accessible within one of the interfaces. The gateway is known destination address just like any other, but it is expected to have knowledge of how to reach the outside world for non-local interfaces.
For your case the Jetson’s WiFi and wired ethernet won’t be required. The host can self-ping to 192.168.55.100, the Jetson can self-ping to 192.168.55.1. If you can verify this, then you know basic networking is ok on both Jetson and host. What it doesn’t guarantee is whether address/netmask and router configuration will actually send the traffic to the right location.
The host does need to access the outside world, but it doesn’t matter by what mechanism, e.g., wired or WiFi.
Here is what I find interesting on the host “route” information:
192.168.55.0 0.0.0.0 255.255.255.0 U 102 0 0 <b>enp0s20f0u6i5</b>
That information says to use interface enp0s20f0u6i5 (what an awful naming convention!) will be used for all traffic within the range of addresses between 192.168.55.0 and 192.168.55.255. Now take a look at the host for interface enp0s20f0u6i5:
inet 192.168.55.100 netmask 255.255.255.0 broadcast 192.168.55.255
If traffic is to 192.168.55.100, then the traffic will go directly to the host. Other traffic will go to the outside world across the USB virtual ethernet interface. Should the host request address 192.168.55.1, then if that host exists in the outside world this outside host should respond.
Exceptions are cases of firewalls or routers which might block (or not allow) certain traffic. If running through a VM extra bridging might be required and there would be a gap in the route where everything disappears if not configured. Firewalls are a similar gap.
Can you verify no VM is involved, and that a login to the host can ping 192.168.55.100, while logins to the Jetson can ping 192.168.55.1?