I have an old Nvidia Nano. Using the standard jetson-nano-jp461-sd-image.zip (sd-blob-b01.img), I’ve successfully booted and completed the initial setup. After, I tried to setup jupyter or VNC. Neither works. Both seem to either timeout or the connection is refused, which is unclear to me.
I’m able to ping the Jetson Nano from any other computer on the network, but I cannot ping any computer from the Jetson Nano.
Any help is appreciated.
How is it connected to the network? Is it just the micro-B USB cable? Is wired or Wi-Fi connected? What do you see from the output of “ifconfig” and “route” and “iwconfig”?
Do note that if you use the USB connection, then it means the host PC which is connected to the USB is responsible for forwarding (which is often disabled unless you specifically enabled forwarding). For USB forwarding you’d also need to describe the host PC and if you’ve enabled forwarding.
Thank you linuxdev,
It’s connected via WiFi. Output is as follows:
ifconfig
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:60:be:68:44 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 00:e0:4c:68:01:4d 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 0xa000
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 10230 bytes 1288631 (1.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10230 bytes 1288631 (1.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether e6:f0:f5:9c:da:2d 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=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether e6:f0:f5:9c:da:2f 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
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.50.100 netmask 255.255.255.0 broadcast 192.168.50.255
inet6 fe80::9d79:4fa3:70e0:502d prefixlen 64 scopeid 0x20
ether 38:00:25:5e:d7:10 txqueuelen 1000 (Ethernet)
RX packets 427814 bytes 128421053 (128.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 190046 bytes 61596881 (61.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default RT-AX88U-DB78 0.0.0.0 UG 600 0 0 wlan0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 docker0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.50.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
iwconfig
lo no wireless extensions.
rndis0 no wireless extensions.
wlan0 IEEE 802.11 ESSID:“home-2.4”
Mode:Managed Frequency:2.432 GHz Access Point: B0:6E:BF:6A:FB:29
Bit Rate=144.4 Mb/s Tx-Power=22 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=70/70 Signal level=-27 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:788 Invalid misc:2237 Missed beacon:0
eth0 no wireless extensions.
usb0 no wireless extensions.
docker0 no wireless extensions.
dummy0 no wireless extensions.
l4tbr0 no wireless extensions.
I’ll quote some of the more relevant information:
192.168.50.100.wlan0 will be used when the Jetson tries to reach out to any networked device with an address between 192.168.50.0 and 192.168.50.255 (I’m ignoring the effects of broadcast and default routes, but they are part of that subnet).Tx excessive retries:788 Invalid misc:2237 Missed beacon:0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
...
RX packets 427814 bytes 128421053 (128.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 190046 bytes 61596881 (61.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Something you should know about ping is that it uses ICMP protocol. This means that if anything along the route does not support ICMP, then it will have 100% loss there, which might be by design, or it might be actual loss. Probably in this case it is actual loss. traceroute also uses ICMP. It is possible to reach some addresses with TCP or UDP, and yet not be able to reach it via ping or traceroute (or the reverse).
About route:
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 0.0.0.0 UG 600 0 0 wlan0
...
192.168.50.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
192.168.50.0/24 will go through the gateway, RT-AX88U-DB78. This is presumably the Wi-Fi router.default” route. In this case it is not telling you the router (Wi-Fi router) address. Instead it is just suggesting to broadcast to 0.0.0.0. This might be a problem. Normally I would expect the router address and not a general broadcast.Iface (interface) is listed for any route.I’m thinking that perhaps your router is not configured to allow this, although I couldn’t guarantee it (there is some RF loss too). It seems like the DHCP is not being completely honored, or else the router is not sending everything I would expect for setup. Do you have any other Linux systems connected to that Wi-Fi router? If so, you could show the “ifconfig” (or “ip -s a”) and “route” (or “ip route”) of that computer.
Tip: When you post logs on the forum, or copy and paste of command outputs, it is best to mark it as “code” (the “</>” icon) so as to preserve whitespace and not have issues with special characters. You can always edit an existing post with the pencil icon, highlight the log output, and click on the code icon to fix whitespace.
Thank you linuxdev,
Really helpful information. I learned a few new items. Much appreciated.
I have three Linux boxes and two Win11 on this network. In all cases, the Win11 boxes can ping each of the Linux but not the Win11 other box. And in all cases, the Linux cannot reach any of the boxes (Linux or Win) on the network.
Do this confirm your thought that something isn’t setup right on the router?
Here’s the output or ip -s a and ip -route from one of the Linux boxes on the network.
Hopefully I used the </> correctly.
I appreciate your help.
ip -s a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
RX: bytes packets errors dropped missed mcast
474812 2904 0 0 0 0
TX: bytes packets errors dropped carrier collsns
474812 2904 0 0 0 0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 8c:16:45:c9:af:27 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether d4:6d:6d:33:aa:31 brd ff:ff:ff:ff:ff:ff
inet 192.168.50.118/24 brd 192.168.50.255 scope global dynamic noprefixroute wlan0
valid_lft 66742sec preferred_lft 66742sec
inet6 fe80::d66d:6dff:fe33:aa31/64 scope link noprefixroute
valid_lft forever preferred_lft forever
RX: bytes packets errors dropped missed mcast
543653275 478416 0 30 0 0
TX: bytes packets errors dropped carrier collsns
76240933 180285 0 0 0 0
ip route
default via 192.168.50.1 dev wlan0 proto dhcp src 192.168.50.118 metric 600
192.168.50.0/24 dev wlan0 proto kernel scope link src 192.168.50.118 metric 600
There are basically three categories of possible issues:
A subtopic: IPv4 setup versus IPv6 setup. IPv6 is often problematic. Sometimes a given computer supports only IPv4, or it might support both that and IPv6. Similar for the router. Your simplest case is if everything IPv4. This isn’t necessarily a problem, but it does require extra drivers.
For each computer (node), one has to find out its combination of:
In the ifconfig you gave above, for the Wi-Fi (wlan0), 192.168.50.100 is non-routable IPv4 address to the public Internet. This is correct since it is a LAN behind a router. The router’s external IP address will differ (unless it is itself on another private LAN). On that particular computer’s Wi-Fi the netmask is 255.255.255.0. That means the subnet is 24 bits being constant on the left hand side, and 8 bits (total of 32 bits) being variable on the right hand side: 192.168.50.0 to 192.168.50.255 will be handled by that interface without needing to consult a default route.
The example route you gave indicates that wlan0 has a metric of 600:
Destination Gateway Genmask Flags Metric Ref Use Iface
default RT-AX88U-DB78 0.0.0.0 UG 600 0 0 wlan0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 docker0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.50.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
The metric is the “cost”, and if two interfaces provide the same route at different costs, the least costly (lowest metric) is used. Note that an exact match to a subnet will choose that subnet even when another route has the same cost. The adapter RT-AX88U-DB78 has the same cost as the wlan0 (Wi-Fi), and so it might be debatable as to which route would be taken if not for the “exact subnet match” rule. Something using an address between 192.168.50.0 and 192.168.50.255 will use the Wi-Fi, and any other address will use RT-AX88U-DB78. If you have a failure to an address in range 192.168.50.0 and 192.168.50.255, then Wi-Fi must be diagnosed; if the address is outside of that range (I’m assuming traffic originating from that node), then RT-AX88U-DB78 must be diagnosed.
Are all computers in question using an IP address (for failure or success) between 192.168.50.0 and 192.168.50.255? Do all computers in question have a route/mask in the same subnet of 192.168.50.0 and 192.168.50.255? Of those computer nodes which have traffic in that subnet, is the interface in question going to either the wireless part of the Wi-Fi or a wired connection to that router?
In terms of security, has this router been set up to require MAC addresses? Is it a higher end “managed” router, or just an appliance (hopefully it is just an appliance with no special setup)?
Hi linuxdev,
Again, very informative. Thanks,
Are all computers in question using an IP address (for failure or success) between 192.168.50.0 and 192.168.50.255? [JWB]: Yes.
Do all computers in question have a route/mask in the same subnet of 192.168.50.0 and 192.168.50.255? [JWB]: Yes.
Of those computer nodes which have traffic in that subnet, is the interface in question going to either the wireless part of the Wi-Fi or a wired connection to that router? **[JWB]: Four of the five are wireless, and one Win11 box is connected via ethernet. **
In terms of security, has this router been set up to require MAC addresses? [JWB]: No. I did change to Respond ICMP echo request from WAN, but this had no impact. So I changed it back to No.
Is it a higher end “managed” router, or just an appliance (hopefully it is just an appliance with no special setup)? [JWB]: Just a standard router. It is connected to the internet via another router.
Except for a denial of service attack I’d say ICMP is a very low risk protocol. At least during testing it wouldn’t hurt to have ICMP enabled, but it also might not be useful.
Do note that even a low end router might have different rules for Wi-Fi to internal LAN versus LAN-to-LAN, but I doubt this would be the case. On the other hand, not enabling ICMP is a 100% guarantee that ping will not show up in some cases. Basically, a router’s lack of ICMP might mean pinging the router itself does not work, but LAN-to-LAN might work. It just depends on the router setup. Depending on where the ICMP is blocked, disabling ICMP could cause ping loss even when the network is otherwise working as it should. So for this I recommend that ICMP be completely enabled if you want to use ping or traceroute for diagnostics. You might want to not only enable ICMP, but also reboot the router after doing so.
In all that follows I’m assuming traffic is from one computer to another on the same Wi-Fi router (regardless of being Wi-Fi or wired). You might specify in any list of failed or working connection if it is:
Note that any traffic going over the Nano via USB would have very different issues. If any of the traffic involves a USB adapter or USB type-B cable, then you should describe that. Often the Jupyter software is expected to use the USB virtual ethernet. Any host or router which talks to that USB virtual ethernet would have to have its own separate security setup in many cases.
From your last reply though it seems no USB is taking part in this, and that the basics are satisfied. That leaves ICMP so far as ping and traceroute go. When you enabled ICMP, did you also reboot the router?
Hi linuxdev,
I’ve re-enabled Respond ICMP echo request from WAN and rebooted both routers on my network. Same result, I cannot ping from a couple of the boxes.
I started this thread because I was trying to get an old Nvidia Nano Jet Bot working, specifically getting Jupyter running and accessible. I started fresh with a different iso image from Nvidia (jetbot-043_nano-4gb-jp45.img), and it now works. So I have resolved the original issue.
I appreciate all of your expert advice and for teaching me a few things about networking.
Best regards,
Jwb
ifconfig and route of one of the nodes which fails?This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.