Unable to ping the TX2 but the TX2 can ping the host PC

[khobbs]

Hello,

I am working on implementing a basic server/client between the TX2 and a host PC using seL4. There appears to be an issue pinging the board from the host PC, even though the board is able to ping the PC. They are both connected to the same network with ethernet cables. When I try to ping the board, here is the terminal input/output:

kevin@swarm6:~$ ping 192.168.2.50
PING 192.168.2.50 (192.168.2.50) 56(84) bytes of data.
From 192.168.2.125 icmp_seq=1 Destination Host Unreachable
From 192.168.2.125 icmp_seq=2 Destination Host Unreachable
From 192.168.2.125 icmp_seq=3 Destination Host Unreachable

However, if I try pinging the host PC from the board in UBoot, this is the input/output:

Tegra186 (P2771-0000-500) # ping 192.168.2.125
ethernet@2490000 Waiting for PHY auto negotiation to complete… done
Using ethernet@2490000 device
host 192.168.2.125 is alive

This may be helpful. This is what I see when requesting the IP address on both devices:
Host PC:

kevin@swarm6:~$ ip r
default via 192.168.2.1 dev eno1 proto dhcp metric 100
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.2.0/24 dev eno1 proto kernel scope link src 192.168.2.125 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

TX2:

Tegra186 (P2771-0000-500) # print serverip
serverip=192.168.2.125
Tegra186 (P2771-0000-500) # print ipaddr
ipaddr=192.168.2.50

Is there something I need to change to make it possible to ping the board? I have looked at other forums, and it seems this is not generally a problem for people.

[linuxdev]

This suggests the route or firewall is getting in the way on the host PC side. The actual “route” command is a bit easier to read. I’ll recommend posting the output of “route” and “ifconfig” from the host PC side (it would be nice to see the full output). You can gather both as a file via:

route | tee host_net.txt
ifconfig | tee -a host_net.txt

…then either attach the log, or else copy and paste it as code (code formatting preserves table layout in route).

[khobbs]

Yes thank you I will attach the log here:
host_net.txt (2.7 KB)

[linuxdev]

For reference, here is an excerpt of the logs:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    100    0        0 eno1
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 virbr0
192.168.2.0     0.0.0.0         255.255.255.0   U     100    0        0 eno1
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.2.125  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::9818:4428:c8d9:10b9  prefixlen 64  scopeid 0x20<link>
        ether f8:32:e4:bb:50:3e  txqueuelen 1000  (Ethernet)
        RX packets 2981406  bytes 3207753109 (3.2 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1475933  bytes 398915415 (398.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf7200000-f7220000  

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:90:0e:4a  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

No traffic is occurring on virbr0, all traffic is over en01. eno1 has address 192.168.2.125". When you ping from the Jetson side, you are pinging 192.168.2.125, which matches the eno1 interface.

If you wish to ping the Jetson (192.168.2.50) from the PC, then in theory this should also occur through eno1 without any requirement for ever looking at a default route (it is already a match to the subnet, so no default route would matter). Normally this should work.

Jetsons will by default have ICMP protocol enabled (this is what ping uses), and so I know ping of the Jetson will not fail for reasons of lack of ICMP support (unless you’ve modified the kernel and did not enable ICMP).

I am thinking perhaps it is a firewall issue on the host PC side, but I’m not sure how to check. This might get a log message, but only if firewalling is both enabled and set to log denied outgoing traffic. It would be rather rare for the PC to actually deny outgoing traffic, and so I’d be surprised if this were the case. However, do you have any kind of added firewall to your PC?

If the router were high end and has some sort of firewall function, then this too might cause the problem. Does your firewall have any kind of admin setup for security which you’ve worked on?

Also, what do you see, from the host PC side, from:
traceroute 192.168.2.50

Plus, can you "ssh 192.168.2.50from the PC to talk tosshon the Jetson? I ask becausessh` is using a TCP protocol, and differs from ping’s ICMP, and thus firewalling (if the issue) might behave differently.