Jetson Nano connecting to internet via host pc USB type-c

I have a Jetson Nano installed with NVIDIA JetPack version 4.6.1-b110 and I am wanting to connect to the internet via my host pc using a USB type-c cable. My host pc is a M1 MacBook Pro using Ventura 13.1

I have been able to follow the Linux 4 Tegra (L4T) “README-usb-dev-mode.txt” and “READ-me-wifi.txt” files that come preinstalled with JetPack to ssh into my Nano from my host PC:

ssh <username>@<IPv4_address>

Subsequently, I enable internet sharing via the “sharing” of system preferences. First, I check to see if I can send and receive data from the Nano from my host PC (not using ssh). Results are the following:

ping -c 10 192.168.55.1
PING 192.168.55.1 (192.168.55.1): 56 data bytes
64 bytes from 192.168.55.1: icmp_seq=0 ttl=64 time=2.079 ms
64 bytes from 192.168.55.1: icmp_seq=1 ttl=64 time=2.173 ms
64 bytes from 192.168.55.1: icmp_seq=2 ttl=64 time=2.232 ms
64 bytes from 192.168.55.1: icmp_seq=3 ttl=64 time=2.126 ms
64 bytes from 192.168.55.1: icmp_seq=4 ttl=64 time=2.324 ms
64 bytes from 192.168.55.1: icmp_seq=5 ttl=64 time=2.178 ms
64 bytes from 192.168.55.1: icmp_seq=6 ttl=64 time=2.176 ms
64 bytes from 192.168.55.1: icmp_seq=7 ttl=64 time=2.004 ms
64 bytes from 192.168.55.1: icmp_seq=8 ttl=64 time=2.091 ms
64 bytes from 192.168.55.1: icmp_seq=9 ttl=64 time=1.999 ms

--- 192.168.55.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.999/2.138/2.324/0.095 ms

This means my Mac is able to identify and send and receive data from the Nano through the USB type-c cable.

Next, I verify that I have enabled networking on the Nano. With this enabled, there are several options for “network connections”: (1) Ethernet, (2) Wi-Fi, and (3) Bridge. The Nano comes preinstalled with Linux, and consequently Linux 4 Tegra. Therefore, l4tbr0 is an option under (3). As my Nano is connected to my Mac via USB type-c and I have enabled internet sharing on my Mac, the l4tbr0 connection is automatically connected and listed as my “active connection” with the following information:

General: l4tbr0
Hardware Address:
Driver: bridge
Speed: unknown

IPv4
IP Address: 192.168.55.1
Broadcast Address: 192.168.55.255
Subset Mask: 255.255.255.0
Default Route: 192.168.55.100

IPv6
IP Address: fe80::1/128

Next, I notice my Mac is also connected to Wifi and Linux for Tegra. Indeed, looking at the Linux for Tegra network connection on my Mac results in the following information:

IPv4 Configured: Using DHCP
IP Address: 192.168.55.100
Subset Mask: 255.255.255.0
Router: Router
DNS Servers: DNS Servers

I notice that the IP address isn’t the same. It differs by the ending of .1 and .100.

Additionally, the command ifconfig in my ssh session returns:

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:3f:dd:d9:22  txqueuelen 0  (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

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 48:b0:2d:9b:0e:0f  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
        device interrupt 150  base 0x8000  

l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.55.1  netmask 255.255.255.0  broadcast 192.168.55.255
        inet6 fe80::1  prefixlen 128  scopeid 0x20<link>
        inet6 fe80::4c76:b4ff:fef6:8eb9  prefixlen 64  scopeid 0x20<link>
        ether 4e:76:b4:f6:8e:b9  txqueuelen 1000  (Ethernet)
        RX packets 1116  bytes 300949 (300.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3089  bytes 353173 (353.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 1  (Local Loopback)
        RX packets 5837  bytes 402341 (402.3 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5837  bytes 402341 (402.3 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rndis0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::4c76:b4ff:fef6:8eb9  prefixlen 64  scopeid 0x20<link>
        ether 4e:76:b4:f6:8e:b9  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

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::4c76:b4ff:fef6:8ebb  prefixlen 64  scopeid 0x20<link>
        ether 4e:76:b4:f6:8e:bb  txqueuelen 1000  (Ethernet)
        RX packets 1145  bytes 308868 (308.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2963  bytes 493084 (493.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

where l4tbr0 is indeed receiving data via the bridge to my Mac. However, when I attempt to launch Chromium and search www.google.com, it says there exist no internet connection.

I have searched extensively on how to connect the Jetson Nano to the internet via a host PC connected using USB type-c and have found no results. If someone could offer a solution or point me to a resource that would be great. Thanks for your help!

Hi,
Do you mean you have a USB micro-B to type-A adapter, and connect to micro-B port on Jetson Nano, type-A port on Mac? There is no type-C port on Jetson Nano developer kit and it is not clear how you connect the host PC and Jetson Nano.

Generally, we would expect host PC to be Linux Ubuntu system(16.04 or 180.04). Would suggest check if you can get this type of host PC and give it a try.

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