Jetson Tx2 can only connect to non-secured sites over ethernet; SSL fine over wifi; ping fine on both

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I just received my Nvidia jetson TX2 and have been trying to use it. When I connect to the internet over wifi, the internet works as expected. However when I connect to it over an ethernet connection, only non-HTTPS sites seem to work. In addition, I can reliably ssh into my jetson via its Wifi address, but not over its ethernet address. However ifconfig reports that both interfaces are up and running correctly with zero dropped packets and they are in the correct subnet range for my router.

Here is a video:

Here is the output of ifconfig, with the wifi off:

docker0   Link encap:Ethernet  HWaddr 02:42:e0:da:a8:63  
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          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:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:04:4b:c5:80:2a  
          inet addr:192.168.0.28  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::1c62:58a6:e75:ae82/64 Scope:Link
          inet6 addr: 2607:fea8:1cdf:f227:f67:1b16:4846:445e/64 Scope:Global
          inet6 addr: 2607:fea8:1cdf:f227:fd5f:7152:52e4:d0e1/64 Scope:Global
          inet6 addr: fd00:f81d:fa2:b142:64d2:f544:3a04:f563/64 Scope:Global
          inet6 addr: 2607:fea8:1cdf:f227::6/128 Scope:Global
          inet6 addr: fd00:f81d:fa2:b142:fd5f:7152:52e4:d0e1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:35995 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15383 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:46448825 (46.4 MB)  TX bytes:1577389 (1.5 MB)
          Interrupt:42 

l4tbr0    Link encap:Ethernet  HWaddr ca:a1:b8:24:0a:66  
          inet addr:192.168.55.1  Bcast:192.168.55.255  Mask:255.255.255.0
          inet6 addr: fe80::a84b:cff:fe53:afeb/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:1003 (1.0 KB)

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:2016 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2016 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:181128 (181.1 KB)  TX bytes:181128 (181.1 KB)

usb0      Link encap:Ethernet  HWaddr ca:a1:b8:24:0a:66  
          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)

usb1      Link encap:Ethernet  HWaddr fa:58:21:87:7e:4e  
          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)

wlan0     Link encap:Ethernet  HWaddr 00:04:4b:c5:80:28  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:7542 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6723 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4039199 (4.0 MB)  TX bytes:1269025 (1.2 MB)

Here is the output of ethtool eth0:

Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: external
	Auto-negotiation: on
Cannot get wake-on-lan settings: Operation not permitted
	Link detected: yes
2

What is the output of “route” with and without WiFi?

3

you should use username nvidia when ssh
chrome in general depreciates use of non ssl websites, as far as I know google advocates the point that all websites should have ssl
what if you update the browser somehow ?
may be you have network filter devices that screen your network and allow only some particular internet access

4 
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         hitronhub.home  0.0.0.0         UG    100    0        0 eth0
default         hitronhub.home  0.0.0.0         UG    600    0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 l4tbr0
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0
192.168.0.0     *               255.255.255.0   U     100    0        0 eth0
192.168.0.0     *               255.255.255.0   U     600    0        0 wlan0
192.168.55.0    *               255.255.255.0   U     0      0        0 l4tbr0

Without the Wifi connected:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         hitronhub.home  0.0.0.0         UG    100    0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 l4tbr0
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0
192.168.0.0     *               255.255.255.0   U     100    0        0 eth0
192.168.55.0    *               255.255.255.0   U     0      0        0 l4tbr0

I’m pretty sure this is a hardware issue. I connected a laptop directly to it and pinged it with a big packet size. I repeatedly got corruptions:

ping 10.0.1.1 -s 10000
PING 10.0.1.1 (10.0.1.1) 10000(10028) bytes of data.
10008 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=1.35 ms
wrong data byte #4454 should be 0x66 but was 0x64
#16	10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
#48	30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
#80	50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
#112	70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 
...
#9904	b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf 
#9936	d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef 
#9968	f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff 0 1 2 3 4 5 6 7 8 9 a b c d e f 
10008 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=1.15 ms
wrong data byte #78 should be 0x4e but was 0x4c
#16	10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
#48	30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4c 4f 
#80	50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
...

I believe this is a hardware issue. Does anyone have any other suggestions?

1 Like
5

You have two default routes:

default         hitronhub.home  0.0.0.0         UG    100    0        0 eth0
default         hitronhub.home  0.0.0.0         UG    600    0        0 wlan0

Technically, since wlan0 is a higher metric than eth0, this isn’t a problem…if you want all default route traffic to go over eth0. Default route traffic is any traffic not providing an exact match to an interface address and mask combination. If wlan0 happens to be a private network, and eth0 is the internet, then this would be valid. On the other hand, I doubt it is 100% valid since both default routes cover the same “all” address range and both are up and running. Now if eth0 died, then wlan0 would transparently take over, which might actually be the way it should be. I’m just speculating, but what I am wondering is if for some reason two routes might somehow be interacting with ssh in some way that ssh does not like.

However, the story becomes more interesting when you consider both wired and WiFi are the same network:

192.168.0.0     *               255.255.255.0   U     100    0        0 eth0
192.168.0.0     *               255.255.255.0   U     600    0        0 wlan0

The implication is that wlan0 has no effect whatsoever. Having the higher metric implies nothing will traverse wlan0 unless eth0 goes down. As mentioned, this can be valid if wlan0 is to take over when eth0 dies, but why use wlan0 at all if you don’t have some purpose for it? Is there some traffic which you want to go over wlan0, or is that incidental to issues you have found?

Note that the outside device talking to the Jetson can have its own metric. If traffic originates on the Jetson, then it will use the lower metric eth0. Outside traffic could reach the Jetson over either interface, but the route which the Jetson replies to for the outside traffic would in theory always go over wired (incoming WiFi can return over eth0). Imagine you have ssl showing up from an outside source to the Jetson over WiFi, and that the response comes back over wired…I am speculating that this might be something ssl would complain about, or else the other host might not be configured to even listen over wired and could entirely miss the reply. Does your host listen to its wired interface on the same subnet as the WiFi? Is your host, when talking over WiFi, set up such that it is capable of hearing a response which switches to eth0 and does not reply on WiFi?

The inverse is also interesting. SSL traffic originating on the Jetson will always go out eth0, but an outside device might reply on WiFi. This could be an issue for SSL, don’t know. We do know the Jetson at least listens to WiFi even if the metric prevents WiFi from being the reply route.

Unfortunately I know nothing about docker, so if this is what it is for I don’t know how to interpret the network settings.

What is the exact layout of your wired router and the WiFi? Are they basically the same physical device, or are these two separate devices? Does the other computer in the SSL conversation also have both WiFi and wired? What is the route and ifconfig of the other computer?

Unfortunately, I don’t know enough about ICMP to say if that large of a packetsize is actually a mandatory requirement. You might be right about this showing corruption, but someone who knows more about ICMP might know if there is a guarantee that packet size is supported.

Normally I would suggest that you simply delete the default route to the interface which isn’t a gateway. However…both of your interfaces are the same subnet, so deleting a default route may not change much. I believe you should probably configure the WiFi to its own separate subnet unless it is to be treated as “never use unless wired dies”.