unable to connect to internet in jetson nano Using "Ethernet Protocol host device as internet gateway"

after connecting usb to nano, it is getting detected , and connected via ssh .
But as said in the document

Linux for Tegra configures a very low priority default IPv4 route on the USB
Ethernet device(s), and configures Google's public DNS server (8.8.8.8) as the
fallback DNS server for use when no other network connection is available.
This allows your host machine to act as an Intranet or Internet gateway for
Jetson.

It is not getting access to the host gateway.
some more configurations need to be done??

Ok so after reading further I came across that the following should be done-

  1. echo 1 > /proc/sys/net/ipv4/ip_forward

  2. iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.1.100

    where:
    eth0 is the name of your host’s upstream Ethernet interface.
    192.168.1.100 is your host’s IP address on that interface.

so in my system:

enp4s0u1 Link encap:Ethernet HWaddr 26:23:25:c1:c6:c4
inet addr:192.168.55.100 Bcast:192.168.55.255 Mask:255.255.255.0
inet6 addr: fe80::9823:d0d0:def7:2f4d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:62285 errors:0 dropped:0 overruns:0 frame:0
TX packets:27985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:86746020 (86.7 MB) TX bytes:3604728 (3.6 MB)

host’s IP address on that interface will be 192.168.55.100
what is the eth0 ?

from ifconfig-

  • enp0s29u1u2i5 Link encap:Ethernet HWaddr ea:03:3b:84:ed:6a inet addr:192.168.55.100 Bcast:192.168.55.255 Mask:255.255.255.0 inet6 addr: fe80::761f:26f9:23a0:2410/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:252 errors:0 dropped:0 overruns:0 frame:0 TX packets:165 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:34321 (34.3 KB) TX bytes:26540 (26.5 KB)

so I modified it to

iptables -t nat -A POSTROUTING -o enp0s29u1u2i5 -j SNAT --to 192.168.55.100

Evenhough if I ping 192.168.55.100 from jetson it is showing packet transmission. But it is still not getting the access to internet.
Can anybody suggest me where I am going wrong?

I have not set up forwarding on an Ubuntu host, but basically the host setup for forwarding is what you have to complete. In the case of a removable interface (which USB is) you might need some extra step to make a temporary forwarding permanent. I’m only guessing, but this should probably be correct if there is no firewall involved:
https://tecadmin.net/enable-ip-forwarding-linux/

Your Nano would also have to have the default route set to “192.168.55.100”. If the above doesn’t work, then also post the Nano and PC’s outputs for:

ifconfig
route

PC
ifconfig:

enp0s29u1u2
Link encap:Ethernet HWaddr 66:a1:cf:c2:cd:fb
inet6 addr: fe80::3efc:e132:d1a2:79c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:149 errors:0 dropped:0 overruns:0 frame:0
TX packets:189 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17136 (17.1 KB) TX bytes:40992 (40.9 KB)

enp0s29u1u2i5
Link encap:Ethernet HWaddr ea:03:3b:23:26:6a
inet addr:192.168.55.100 Bcast:192.168.55.255 Mask:255.255.255.0
inet6 addr: fe80::761f:66f9:88a0:2410/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:824 errors:0 dropped:0 overruns:0 frame:0
TX packets:240 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89567 (89.5 KB) TX bytes:45912 (45.9 KB)

enp5s0
Link encap:Ethernet HWaddr c8:60:00:3e:d5:87
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:992 errors:0 dropped:0 overruns:0 frame:0
TX packets:992 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:91113 (91.1 KB) TX bytes:91113 (91.1 KB)

wlp3s0
Link encap:Ethernet HWaddr 00:08:ca:de:24:d3
inet addr:192.168.18.3 Bcast:192.168.18.255 Mask:255.255.255.0
inet6 addr: fe80::92fa:9eb9:5f46:25aa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8953 errors:0 dropped:0 overruns:0 frame:0
TX packets:7832 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5101822 (5.1 MB) TX bytes:1727175 (1.7 MB)

[b]<i>route</i>:
[/b]Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.18.1    0.0.0.0         UG    600    0        0 wlp3s0
link-local      *               255.255.0.0     U     1000   0        0 enp0s29u1u2i5
192.168.18.0    *               255.255.255.0   U     600    0        0 wlp3s0
192.168.55.0    *               255.255.255.0   U     100    0        0 enp0s29u1u2i5

and for nano,

NANO
ifconfig:

eth0:
flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:04:4b:e5:f4:c3 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 148 base 0xe000

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
inet6 fe80::14eb:4eff:fe01:2612 prefixlen 64 scopeid 0x20
ether ea:03:3b:94:fd:69 txqueuelen 1000 (Ethernet)
RX packets 573 bytes 92607 (92.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 861 bytes 82826 (82.8 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
loop txqueuelen 1 (Local Loopback)
RX packets 668 bytes 46624 (46.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 668 bytes 46624 (46.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rndis0:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::e803:3bff:fe94:fd69 prefixlen 64 scopeid 0x20
ether ea:03:3b:94:fd:69 txqueuelen 1000 (Ethernet)
RX packets 225 bytes 36185 (36.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 153 bytes 26691 (26.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::e803:3bff:fe94:fd6b prefixlen 64 scopeid 0x20
ether ea:03:3b:94:fd:6b txqueuelen 1000 (Ethernet)
RX packets 348 bytes 56422 (56.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1037 bytes 129005 (129.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

[b]<i>route</i>:
[/b]Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    32766  0        0 l4tbr0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 l4tbr0
192.168.55.0    0.0.0.0         255.255.255.0   U     0      0        0 l4tbr0

So on the Jetson side there won’t be a route unless through the USB virtual ethernet. Wired did not receive an address.

The host PC shows enp0s29u1u2i5 as the address for the host side of the USB virtual ethernet, 192.168.55.100. Your host also has a working gateway, so if forwarding is enabled, then your Jetson should be able to talk through the virtual USB ethernet.

Even if forwarding is not enabled, you should be able to “ping 192.168.55.100”. Can you verify this works? If it does, then what you are missing is forwarding on the host PC.

yes without forwarding I am able to ping at 192.168.55.100.
And forwarding via

echo 1 > /proc/sys/net/ipv4/ip_forward

cat /proc/sys/net/ipv4/ip_forward
1

And after that it becomes really confusing with the postrouting part,
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.1.100

I have tried with
iptables -t nat -A POSTROUTING -o enp0s29u1u2i5 -j SNAT --to 192.168.55.100

but still no luck!

One more thing to test before looking at NAT. The address used for nvidia.com is “216.228.121.209”. I assume you can ping this from the PC, but not the Nano. If you can ping this from the Nano, then forwarding and NAT are not the problems…it would be a DNS problem. If you can’t ping that from the Nano, then you would indeed need to configure NAT (and this probably is the issue, but I wouldn’t want to find out it isn’t after spending a lot of time trying to configure the host PC).

I have not spent a lot of time working on Ubuntu NAT (I tend to do that with Fedora), so someone else might jump in if there is NAT setup advice. However, the program “ufw” is for configuring the Ubuntu firewall. If you don’t have ufw, then:

sudo apt-get install ufw

Even if you have this, it might not be enabled. So (see https://askubuntu.com/questions/1050816/ubuntu-18-04-as-a-router, which is where this is from):

sudo ufw enable
sudo ufw logging on

I’ve used UFW before and find it easier than editing files, but you would still need to edit some non-firewall files. Logging is important because then you can run “dmesg --follow” while changing things and see what errors or successes occurred. Try to run “dmesg --follow” before starting any kind of configuration work. If you do see messages from any of the config steps, then post what you see (I’m not actually configuring NAT on an Ubuntu host, so it is a bit of going bump in the dark and stumbling around).

In the above URL I see more than just ip_forward is set to 1. You can probably ignore the IPv6, but some software may use this. As long as you use the test address I gave earlier to “ping 216.228.121.209”, then you know you are testing IPv4. For the most part you can ignore IPv6, but this may not always be the case. Try the Ubuntu NAT advice on that URL.

It’s possible to ping 216.228.121.209 from my pc, but
from nano with or without ipv4 ip_forward, I am not able to ping,

ping_216.228.121.209
 PING 216.228.121.209 (216.228.121.209) 56(84) bytes of data.
 ^C
216.228.121.209 ping statistics
 53 packets transmitted, 0 received, 100% packet loss, tine 53204ns

I am following the link, just a short advice needed
in the line

- A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

in my case ,
-o etho (through my pc public network through wifi) will be 192.168.18.3
-s eth1 (from nano) will be 192.168.55.100 ?

wlp3s0
Link encap:Ethernet HWaddr 00:08:ca:de:24:d3
inet addr:192.168.18.3 Bcast:192.168.18.255

enp0s29u1u2i5
Link encap:Ethernet HWaddr ea:03:3b:23:26:6a
inet addr:192.168.55.100 Bcast:192.168.55.255

.

by following the link,
from nano still ping to 216.228.121.209 is not possible, and below is the dump of dmesg

[  308.965886] wlp3s0: associated
[  309.057224] wlp3s0: Limiting TX power to 20 (20 - 0) dBm as advertised by 33:12:5b:23:cd:d2
[  593.941776] IPv6: ADDRCONF(NETDEV_UP): enp4s0u1i5: link is not ready

sudo ufw enable
sudo ufw logging on

 2404.396579] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 2404.506677] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[ 2404.565545] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 2422.708554] [UFW BLOCK] IN=wlp3s0 OUT= MAC=00:08:ca:cd:24:a2:35:1e:6c:31:cd:cb:08:00 SRC=198.251.203.23 DST=192.168.18.3 LEN=113 TOS=0x00 PREC=0x00 TTL=50 ID=31869 DF PROTO=TCP SPT=443 DPT=33594 WINDOW=61 RES=0x00 ACK PSH URGP=0 
[ 2423.196916] [UFW BLOCK] IN=wlp3s0 OUT= MAC=00:08:ca:cd:24:a2:35:1e:6c:31:cd:cb:08:00 SRC=198.251.203.23 DST=192.168.18.3 LEN=113 TOS=0x00 PREC=0x00 TTL=50 ID=24043 DF PROTO=TCP SPT=443 DPT=33598 WINDOW=61 RES=0x00 ACK PSH URGP=0 
[ 2423.851008] [UFW BLOCK] IN=wlp3s0 OUT= MAC=00:08:ca:cd:24:a2:35:1e:6c:31:cd:cb:08:00 SRC=198.251.203.23 DST=192.168.18.3 LEN=113 TOS=0x00 PREC=0x00 TTL=50 ID=24044 DF PROTO=TCP SPT=443 DPT=33598 WINDOW=61 RES=0x00 ACK PSH URGP=0 

sudo su
sudo iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain 
vi /etc/default/ufw &
vi /etc/ufw/sysctl.conf
vi  /etc/ufw/before.rules &
 
 
sudo ufw disable && sudo ufw enable
[ 3795.384036] [UFW BLOCK] IN=wlp3s0 OUT= MAC=00:08:ca:cd:24:a2:67:62:4b:e4:fb:c3:08:00 SRC=192.168.18.12 DST=221.0.0.251 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=25230 PROTO=2  
[ 5002.202573] [UFW BLOCK] IN=wlp3s0 OUT= MAC=00:08:ca:cd:24:a2:67:62:4b:e4:fb:c3:08:00 SRC=192.168.18.12 DST=221.0.0.251 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=59567 PROTO=2

So this verifies it isn’t just a DNS issue. I don’t know if I am reading this correctly (I’m using a Fedora host), but it looks like the firewall is blocking (the “[UFW BLOCK]”). Is wlp3s0 the PC’s connection to the outside world? The blocked networking could be a result of something other than the Nano, but if it is the Nano, then the solution would be opening the firewall. Run “dmesg --follow” and watch for new messages which occur as you try to use the Nano…if the messages occur from your attempts to talk to the outside world, then you’ve found the issue. If not, then it is something else (but be sure logging is on or you’ll definitely not see logs).

Basically it looks like once this is resolved it should work. Some info on the topic:
https://help.ubuntu.com/community/UFW

Note in that URL there is a section “Allow by Specific IP” (I tend to go by specific MAC when possible).

my host device is running ubuntu 16.04 lts

I dont know it is error in “README-usb-dev-mode Linux for Tegra USB Device Mode” manual or not, but a small change in the documentation worked like a charm for me.

document-

iptables -t nat -A POSTROUTING <b>-o</b> eth0 -j SNAT --to 192.168.1.100

where:
eth0 is the name of your host’s upstream Ethernet interface.
192.168.1.100 is your host’s IP address on that interface.

edited-

iptables -t nat -A POSTROUTING  <b>-s</b>  eth0 -j SNAT --to-source host

where:
eth0 is the ip of nano hooked to the host.
host is my laptop ip connected to internet(via wifi).

And for ssh into nano:
ssh nvidia@192.168.55.1; change nvidia to your respective username

And lastly to make to all the setup a little easier, made a script :
from your host add the followng in terminal:

touch ~/test23/nanoNAT.sh
add the following lines:
#/bin/bash
#check yours respectively
myASUS="192.168.18.3"
nano="192.168.55.1"
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s $nano -j SNAT --to-source $myASUS
echo "Forwarding done->nano"

make it executable by chmod +x ~/test23/nanoNAT.sh

now make an alias in the bashrc

vi ~/.bashrc
add the following line:
alias set@nano='sudo sh ~/test23/nanoNAT.sh'

reboot or source ~/.bashrc to make the changes

after that from host :

set@nano
[sudo] password for asus: *******
Forwarding done->nano
ssh flab@192.168.55.1
flab@192.168.55.1's password: ******
ping 216.228.121.209

now if ping from nano to 216.228.121.209 is possible, then the setup is successful and ready to go.

I too struggled a bit with this also. Here is a solution that worked for me, courtesy of https://elinux.org/Jetson/Remote_Access

#!/bin/sh
# Share one network's internet connection with another network.
# eg: If your Wifi adapter with internet is called wlan0
# and your local Ethernet adapter is called eth0,
# then run:
#    ./share_my_internet.sh wlan0 eth0
# This will only last until you reboot your computer.
sudo iptables --flush
sudo iptables --table nat --flush
sudo iptables --delete-chain
sudo iptables --table nat --delete-chain
sudo iptables --table nat --append POSTROUTING --out-interface $1 -j MASQUERADE
sudo iptables --append FORWARD --in-interface $2 -j ACCEPT
sudo sysctl -w net.ipv4.ip_forward=1
chmod +x share_my_internet.sh

Run by

./share_my_internet.sh <Host's internet interface name> <Host's nano's usb interface>

For me that’s sharing laptops wifi = wlp4s0 to usb interface enp0s20u3

Also if anyone figures out how to do the same on windows, that would be great :)

thank you for sharing it, I did not tried that but, with a little modification of documentation for Linux for Tegra also working good for me,

#/bin/bash-
#check yours respectively
myASUS="192.168.18.3"
nano="192.168.55.1"
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s $nano -j SNAT --to-source $myASUS

After a bit of struggle with window’s gui I got it working there too.
It’s rather trivial, but confusing gui had me lost for a while :D

Steps would go something like this (Win 8.1),

  1. On plugin Tegra driver should auto install, new ethernet RNDIS adapter is added. At this point 192.168.55.1 (:8888) is visible to host.

  2. Control panel -> Network and Internet -> Network and Sharing Center -> Change adapter settings -> Select host’s adaper with internet + Properties -> Sharing tab -> Check “Allow other network users to connect…” + Select new RNDIS adapter. Nice thing is that windows auto set up passthrough with nat, but also decide to set their own dhcp, disregarding jetson’s. Easy fix is to open RNDIS adapter’s Properties -> Scroll to IPV4 adapter item -> Properties -> Set either static ip, for example 192.168.55.100 with gateway at .1 or select automatically obtain IP.
    After that it should work.

  3. Can’t ping host from jetson, unless you change firewall rules on host. One way would be to chnage adapter from public to private, but not sure how to do that. Other way to manually change in public inbound firewall settings. Third easiest, maybe risky, exempt jetson’s adapter from public profile protected network connections list.