Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever"
Using a system that is connected to the wireless on the ISP router can ping the Arch system with the ipv4 address.
ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112) 56(84) bytes of data. From 192.168.1.185 icmp_seq=1 Destination Host Unreachable From 192.168.1.185 icmp_seq=2 Destination Host Unreachable From 192.168.1.185 icmp_seq=3 Destination Host Unreachable From 192.168.1.185 icmp_seq=4 Destination Host Unreachable From 192.168.1.185 icmp_seq=5 Destination Host Unreachable From 192.168.1.185 icmp_seq=6 Destination Host Unreachable ^
PING 2600:1702:4860:9dd0:210:75ff:fe28:5e30(2600:1702:4860:9dd0:210:75ff:fe28:5e30) 56 data bytes 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=1 ttl=64 time=0.301 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=2 ttl=64 time=0.292 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=3 ttl=64 time=0.298 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=4 ttl=64 time=0.288 ms
Knew just enough of ipv4 to almost get around but this is beating me.
On 11/05/2021 12:52, Robert McBroom via users wrote:
Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever"
Could you elaborate on what "Installed Arch Linux on my Goflex Home NAS" means? Does it mean you replaced the normal O/S of the NAS or does the NAS support running VM's?
Using a system that is connected to the wireless on the ISP router can ping the Arch system with the ipv4 address.
You mean "can not" ping, yes?
What is the supposed IPv4 address of the Arch Linux, 192.168.1.112? And what has the IP address of 192.168.1.185?
ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112) 56(84) bytes of data. From 192.168.1.185 icmp_seq=1 Destination Host Unreachable From 192.168.1.185 icmp_seq=2 Destination Host Unreachable From 192.168.1.185 icmp_seq=3 Destination Host Unreachable From 192.168.1.185 icmp_seq=4 Destination Host Unreachable From 192.168.1.185 icmp_seq=5 Destination Host Unreachable From 192.168.1.185 icmp_seq=6 Destination Host Unreachable ^
PING 2600:1702:4860:9dd0:210:75ff:fe28:5e30(2600:1702:4860:9dd0:210:75ff:fe28:5e30) 56 data bytes 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=1 ttl=64 time=0.301 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=2 ttl=64 time=0.292 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=3 ttl=64 time=0.298 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=4 ttl=64 time=0.288 ms
Knew just enough of ipv4 to almost get around but this is beating me.
On 5/11/21 1:37 AM, Ed Greshko wrote:
On 11/05/2021 12:52, Robert McBroom via users wrote:
Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever"
Could you elaborate on what "Installed Arch Linux on my Goflex Home NAS" means? Does it mean you replaced the normal O/S of the NAS or does the NAS support running VM's
Replaced as Seagate no longer supports the device and it required Flash for the Web access. The original OS was in ROM the replacement is hybrid with the ROM flashed to boot the system on disk. there is not enough memory for VM.
On 11/05/2021 20:40, Robert McBroom via users wrote:
On 5/11/21 1:37 AM, Ed Greshko wrote:
On 11/05/2021 12:52, Robert McBroom via users wrote:
Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever"
Could you elaborate on what "Installed Arch Linux on my Goflex Home NAS" means? Does it mean you replaced the normal O/S of the NAS or does the NAS support running VM's
Replaced as Seagate no longer supports the device and it required Flash for the Web access. The original OS was in ROM the replacement is hybrid with the ROM flashed to boot the system on disk. there is not enough memory for VM.
And....
What is the supposed IPv4 address of the Arch Linux, 192.168.1.112? And what has the IP address of 192.168.1.185?
ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112) 56(84) bytes of data. From 192.168.1.185 icmp_seq=1 Destination Host Unreachable From 192.168.1.185 icmp_seq=2 Destination Host Unreachable From 192.168.1.185 icmp_seq=3 Destination Host Unreachable From 192.168.1.185 icmp_seq=4 Destination Host Unreachable From 192.168.1.185 icmp_seq=5 Destination Host Unreachable From 192.168.1.185 icmp_seq=6 Destination Host Unreachable
I assume you're running ping from another 192.168.1.X address?
On 5/11/21 9:35 AM, Ed Greshko wrote:
On 11/05/2021 20:40, Robert McBroom via users wrote:
On 5/11/21 1:37 AM, Ed Greshko wrote:
On 11/05/2021 12:52, Robert McBroom via users wrote:
Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever"
Could you elaborate on what "Installed Arch Linux on my Goflex Home NAS" means? Does it mean you replaced the normal O/S of the NAS or does the NAS support running VM's
Replaced as Seagate no longer supports the device and it required Flash for the Web access. The original OS was in ROM the replacement is hybrid with the ROM flashed to boot the system on disk. there is not enough memory for VM.
And....
What is the supposed IPv4 address of the Arch Linux, 192.168.1.112? And what has the IP address of
192.168.1.185?
198.168.1.112 is what is shown by the router and by ifconfig on the Arch
192.168.1.185 is the ipv4 address of the machine accessing the Arch system with ssh and the ipv6 address
ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112) 56(84) bytes of data. From 192.168.1.185 icmp_seq=1 Destination Host Unreachable From 192.168.1.185 icmp_seq=2 Destination Host Unreachable From 192.168.1.185 icmp_seq=3 Destination Host Unreachable From 192.168.1.185 icmp_seq=4 Destination Host Unreachable From 192.168.1.185 icmp_seq=5 Destination Host Unreachable From 192.168.1.185 icmp_seq=6 Destination Host Unreachable
I assume you're running ping from another 192.168.1.X address?
On 5/11/21 12:52 AM, Robert McBroom via users wrote:
Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever"
Using a system that is connected to the wireless on the ISP router can ping the Arch system with the ipv4 address.
ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112) 56(84) bytes of data. From 192.168.1.185 icmp_seq=1 Destination Host Unreachable From 192.168.1.185 icmp_seq=2 Destination Host Unreachable From 192.168.1.185 icmp_seq=3 Destination Host Unreachable From 192.168.1.185 icmp_seq=4 Destination Host Unreachable From 192.168.1.185 icmp_seq=5 Destination Host Unreachable From 192.168.1.185 icmp_seq=6 Destination Host Unreachable ^
PING 2600:1702:4860:9dd0:210:75ff:fe28:5e30(2600:1702:4860:9dd0:210:75ff:fe28:5e30) 56 data bytes 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=1 ttl=64 time=0.301 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=2 ttl=64 time=0.292 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=3 ttl=64 time=0.298 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=4 ttl=64 time=0.288 ms
Knew just enough of ipv4 to almost get around but this is beating me. _______________________________________________
I see two addresses listed as ipv6
The one used to ping 2600:1702:4860:9dd0:210:75ff:fe28:5e30 and
fe80::210:75ff:fe28:5e30 Trying this one
ping fe80::210:75ff:fe28:5e30 PING fe80::210:75ff:fe28:5e30(fe80::210:75ff:fe28:5e30) 56 data bytes ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
from f33 but both work fine from a Windows 10 system all systems on my local network
On 5/12/21 12:39 PM, Mike Wright wrote:
On 5/12/21 9:14 AM, Robert McBroom via users wrote:
On 5/11/21 12:52 AM, Robert McBroom via users wrote:
fe80::210:75ff:fe28:5e30 Trying this one
ping fe80::210:75ff:fe28:5e30
ping6 _______________________________________________
Same on f33, but both work from as Windows 10 system
ping6 fe80::210:75ff:fe28:5e30 PING fe80::210:75ff:fe28:5e30(fe80::210:75ff:fe28:5e30) 56 data bytes ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
On 13/05/2021 01:08, Robert McBroom via users wrote:
On 5/12/21 12:39 PM, Mike Wright wrote:
On 5/12/21 9:14 AM, Robert McBroom via users wrote:
On 5/11/21 12:52 AM, Robert McBroom via users wrote:
fe80::210:75ff:fe28:5e30 Trying this one
ping fe80::210:75ff:fe28:5e30
ping6 _______________________________________________
Same on f33, but both work from as Windows 10 system
ping6 fe80::210:75ff:fe28:5e30 PING fe80::210:75ff:fe28:5e30(fe80::210:75ff:fe28:5e30) 56 data bytes ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
I am only awake for a few moments to answer that particular question.
The fe80.... addresses are "link-local" addresses. They are non-routeable. You need to tell the ping command on what interface that address is valid/reachable.
For example. My system (meimei) has 5 interfaces. A remote system (nas) has 2 interfaces. One of nas's link-local addresses is fe80::211:32ff:feb8:6b41. I need to know which physical link is common to meimei and nas. I know this to be enp2s0 on meimei. So the format of the ping6 command would be
[egreshko@meimei ~]$ ping6 fe80::211:32ff:feb8:6b41%enp2s0 PING fe80::211:32ff:feb8:6b41%enp2s0(fe80::211:32ff:feb8:6b41%enp2s0) 56 data bytes 64 bytes from fe80::211:32ff:feb8:6b41%enp2s0: icmp_seq=1 ttl=64 time=0.173 ms 64 bytes from fe80::211:32ff:feb8:6b41%enp2s0: icmp_seq=2 ttl=64 time=0.178 ms 64 bytes from fe80::211:32ff:feb8:6b41%enp2s0: icmp_seq=3 ttl=64 time=0.211 ms
As for you IPv4 issue......
It doesn't make sense to me at the moment since I still don't have a clear picture of your network topology. If all your systems are on the same LAN the connection between the host from which the ping command is issued should go direct to the target.
When you ping 192.168.1.112 from a system (you've not revealed local system IP) there should be no mention of another system. Yet, it would seem that 192.168.1.185 is somehow physically between the 2 systems and is informing you that it can't/won't route to the endpoint.
Do an "ip route" on both the source and destination nodes.
also do an "ip neigh" on both.
And an "ip link" on both.
On Wed, May 12, 2021 at 1:20 PM Ed Greshko ed.greshko@greshko.com wrote:
On 13/05/2021 01:08, Robert McBroom via users wrote:
On 5/12/21 12:39 PM, Mike Wright wrote:
On 5/12/21 9:14 AM, Robert McBroom via users wrote:
On 5/11/21 12:52 AM, Robert McBroom via users wrote:
fe80::210:75ff:fe28:5e30 Trying this one
ping fe80::210:75ff:fe28:5e30
ping6 _______________________________________________
Same on f33, but both work from as Windows 10 system
ping6 fe80::210:75ff:fe28:5e30 PING fe80::210:75ff:fe28:5e30(fe80::210:75ff:fe28:5e30) 56 data bytes ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument
I am only awake for a few moments to answer that particular question.
The fe80.... addresses are "link-local" addresses. They are non-routeable. You need to tell the ping command on what interface that address is valid/reachable.
For example. My system (meimei) has 5 interfaces. A remote system (nas) has 2 interfaces. One of nas's link-local addresses is fe80::211:32ff:feb8:6b41. I need to know which physical link is common to meimei and nas. I know this to be enp2s0 on meimei. So the format of the ping6 command would be
[egreshko@meimei ~]$ ping6 fe80::211:32ff:feb8:6b41%enp2s0 PING fe80::211:32ff:feb8:6b41%enp2s0(fe80::211:32ff:feb8:6b41%enp2s0) 56 data bytes 64 bytes from fe80::211:32ff:feb8:6b41%enp2s0: icmp_seq=1 ttl=64 time=0.173 ms 64 bytes from fe80::211:32ff:feb8:6b41%enp2s0: icmp_seq=2 ttl=64 time=0.178 ms 64 bytes from fe80::211:32ff:feb8:6b41%enp2s0: icmp_seq=3 ttl=64 time=0.211 ms
As for you IPv4 issue......
It doesn't make sense to me at the moment since I still don't have a clear picture of your network topology. If all your systems are on the same LAN the connection between the host from which the ping command is issued should go direct to the target.
When you ping 192.168.1.112 from a system (you've not revealed local system IP) there should be no mention of another system. Yet, it would seem that 192.168.1.185 is somehow physically between the 2 systems and is informing you that it can't/won't route to the endpoint.
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 13/05/2021 04:05, Roger Heflin wrote:
Do an "ip route" on both the source and destination nodes.
also do an "ip neigh" on both.
And an "ip link" on both.
Yes, that would be very helpful if Robert would supply that information. Thanks for making that suggestion.
On 5/12/21 6:46 PM, Ed Greshko wrote:
On 13/05/2021 04:05, Roger Heflin wrote:
Do an "ip route" on both the source and destination nodes.
also do an "ip neigh" on both.
And an "ip link" on both.
Yes, that would be very helpful if Robert would supply that information. Thanks for making that suggestion
Have to apologize. Cockpit error. The address should have been
192.168.1.211 instead of 192.168.1.112
From the host system
[rm3]RobertPC ~]$ ip route default via 192.168.1.254 dev enp2s0 proto dhcp metric 100 10.237.214.0/24 via 192.168.1.254 dev enp2s0 proto static metric 100 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.185 metric 100 [rm3@RobertPC ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:1d:60:35:b8:13 brd ff:ff:ff:ff:ff:ff [rm3@RobertPC ~]$ ip neigh 192.168.1.254 dev enp2s0 lladdr 8c:5a:25:e4:56:b0 REACHABLE 192.168.1.111 dev enp2s0 FAILED 192.168.1.239 dev enp2s0 lladdr 00:00:c0:33:7b:6f STALE 192.168.1.112 dev enp2s0 FAILED fe80::6038:e0ff:fec2:54a8 dev enp2s0 lladdr 62:38:e0:c2:54:a8 router STALE 2600:1702:4860:9dd0:210:75ff:fe28:5e30 dev enp2s0 lladdr 00:10:75:28:5e:30 STALE fe80::8e5a:25ff:fee4:56b0 dev enp2s0 lladdr 8c:5a:25:e4:56:b0 router REACHABLE fe80::210:75ff:fe28:5e30 dev enp2s0 lladdr 00:10:75:28:5e:30 STALE
from the target system
[rm3@RobertPC ~]# ssh alarm@2600:1702:4860:9dd0:210:75ff:fe28:5e30 alarm@2600:1702:4860:9dd0:210:75ff:fe28:5e30's password: Last login: Wed May 12 15:59:14 2021 from fe80::c466:3bc6:17fa:9268%eth0 [alarm@alarm ~]$ ip route default via 192.168.1.253 dev eth0 proto dhcp src 192.168.1.211 metric 1024 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.211 192.168.1.253 dev eth0 proto dhcp scope link src 192.168.1.211 metric 1024 [alarm@alarm ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:10:75:28:5e:30 brd ff:ff:ff:ff:ff:ff [alarm@alarm ~]$ ip neigh 192.168.1.253 dev eth0 lladdr 62:38:e0:c2:54:a8 STALE 192.168.1.254 dev eth0 lladdr 8c:5a:25:e4:56:b0 STALE fe80::8e5a:25ff:fee4:56b0 dev eth0 lladdr 8c:5a:25:e4:56:b0 router STALE fe80::1eb5:75df:b84:98d1 dev eth0 lladdr 00:1d:60:35:b8:13 STALE 2600:1702:4860:9dd0:21d:60ff:fe35:b813 dev eth0 lladdr 00:1d:60:35:b8:13 DELAY fe80::6038:e0ff:fec2:54a8 dev eth0 lladdr 62:38:e0:c2:54:a8 router STALE
On 14/05/2021 19:35, Robert McBroom via users wrote:
On 5/12/21 6:46 PM, Ed Greshko wrote:
On 13/05/2021 04:05, Roger Heflin wrote:
Do an "ip route" on both the source and destination nodes.
also do an "ip neigh" on both.
And an "ip link" on both.
Yes, that would be very helpful if Robert would supply that information. Thanks for making that suggestion
Have to apologize. Cockpit error. The address should have been
192.168.1.211 instead of 192.168.1.112
From the host system
Well, the information below would seem to be incomplete since you probably have not tried to access 192.168.1.211. We do see FAILED for 192.168.1.112 since you've probably tried it and a host with that IP address doesn't exist.
You can see that for the IPv6 address of 2600:1702:4860:9dd0:210:75ff:fe28:5e30 the hwaddress of 00:10:75:28:5e:30 matches that of eth0 in the "ip link" results of the target system. That would indicate physical connectivity.
So, would you do these in order?
ip -4 add show ping 192.168.1.211 traceroute -n 192.168.1.211 ip neigh
[rm3]RobertPC ~]$ ip route default via 192.168.1.254 dev enp2s0 proto dhcp metric 100 10.237.214.0/24 via 192.168.1.254 dev enp2s0 proto static metric 100 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.185 metric 100 [rm3@RobertPC ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 00:1d:60:35:b8:13 brd ff:ff:ff:ff:ff:ff [rm3@RobertPC ~]$ ip neigh 192.168.1.254 dev enp2s0 lladdr 8c:5a:25:e4:56:b0 REACHABLE 192.168.1.111 dev enp2s0 FAILED 192.168.1.239 dev enp2s0 lladdr 00:00:c0:33:7b:6f STALE 192.168.1.112 dev enp2s0 FAILED fe80::6038:e0ff:fec2:54a8 dev enp2s0 lladdr 62:38:e0:c2:54:a8 router STALE 2600:1702:4860:9dd0:210:75ff:fe28:5e30 dev enp2s0 lladdr 00:10:75:28:5e:30 STALE fe80::8e5a:25ff:fee4:56b0 dev enp2s0 lladdr 8c:5a:25:e4:56:b0 router REACHABLE fe80::210:75ff:fe28:5e30 dev enp2s0 lladdr 00:10:75:28:5e:30 STALE
from the target system
[rm3@RobertPC ~]# ssh alarm@2600:1702:4860:9dd0:210:75ff:fe28:5e30 alarm@2600:1702:4860:9dd0:210:75ff:fe28:5e30's password: Last login: Wed May 12 15:59:14 2021 from fe80::c466:3bc6:17fa:9268%eth0 [alarm@alarm ~]$ ip route default via 192.168.1.253 dev eth0 proto dhcp src 192.168.1.211 metric 1024 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.211 192.168.1.253 dev eth0 proto dhcp scope link src 192.168.1.211 metric 1024 [alarm@alarm ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:10:75:28:5e:30 brd ff:ff:ff:ff:ff:ff [alarm@alarm ~]$ ip neigh 192.168.1.253 dev eth0 lladdr 62:38:e0:c2:54:a8 STALE 192.168.1.254 dev eth0 lladdr 8c:5a:25:e4:56:b0 STALE fe80::8e5a:25ff:fee4:56b0 dev eth0 lladdr 8c:5a:25:e4:56:b0 router STALE fe80::1eb5:75df:b84:98d1 dev eth0 lladdr 00:1d:60:35:b8:13 STALE 2600:1702:4860:9dd0:21d:60ff:fe35:b813 dev eth0 lladdr 00:1d:60:35:b8:13 DELAY fe80::6038:e0ff:fec2:54a8 dev eth0 lladdr 62:38:e0:c2:54:a8 router STALE
Since it is allowing ipv6 and but blocking v4 it feels like an iptables/firewall setting blocking v4.
Are there any firewall/iptables rules on either node and if so what do they look like?
On Fri, May 14, 2021 at 7:39 AM Ed Greshko ed.greshko@greshko.com wrote:
On 14/05/2021 19:35, Robert McBroom via users wrote:
On 5/12/21 6:46 PM, Ed Greshko wrote:
On 13/05/2021 04:05, Roger Heflin wrote:
Do an "ip route" on both the source and destination nodes.
also do an "ip neigh" on both.
And an "ip link" on both.
Yes, that would be very helpful if Robert would supply that information. Thanks for making that suggestion
Have to apologize. Cockpit error. The address should have been
192.168.1.211 instead of 192.168.1.112
From the host system
Well, the information below would seem to be incomplete since you probably have not tried to access 192.168.1.211. We do see FAILED for 192.168.1.112 since you've probably tried it and a host with that IP address doesn't exist.
You can see that for the IPv6 address of 2600:1702:4860:9dd0:210:75ff:fe28:5e30 the hwaddress of 00:10:75:28:5e:30 matches that of eth0 in the "ip link" results of the target system. That would indicate physical connectivity.
So, would you do these in order?
ip -4 add show ping 192.168.1.211 traceroute -n 192.168.1.211 ip neigh
[rm3]RobertPC ~]$ ip route default via 192.168.1.254 dev enp2s0 proto dhcp metric 100 10.237.214.0/24 via 192.168.1.254 dev enp2s0 proto static metric 100 192.168.1.0/24 dev enp2s0 proto kernel scope link src 192.168.1.185
metric 100
[rm3@RobertPC ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP mode DEFAULT group default qlen 1000
link/ether 00:1d:60:35:b8:13 brd ff:ff:ff:ff:ff:ff[rm3@RobertPC ~]$ ip neigh 192.168.1.254 dev enp2s0 lladdr 8c:5a:25:e4:56:b0 REACHABLE 192.168.1.111 dev enp2s0 FAILED 192.168.1.239 dev enp2s0 lladdr 00:00:c0:33:7b:6f STALE 192.168.1.112 dev enp2s0 FAILED fe80::6038:e0ff:fec2:54a8 dev enp2s0 lladdr 62:38:e0:c2:54:a8 router
STALE
2600:1702:4860:9dd0:210:75ff:fe28:5e30 dev enp2s0 lladdr
00:10:75:28:5e:30 STALE
fe80::8e5a:25ff:fee4:56b0 dev enp2s0 lladdr 8c:5a:25:e4:56:b0 router
REACHABLE
fe80::210:75ff:fe28:5e30 dev enp2s0 lladdr 00:10:75:28:5e:30 STALE
from the target system
[rm3@RobertPC ~]# ssh alarm@2600:1702:4860:9dd0:210:75ff:fe28:5e30 alarm@2600:1702:4860:9dd0:210:75ff:fe28:5e30's password: Last login: Wed May 12 15:59:14 2021 from fe80::c466:3bc6:17fa:9268%eth0 [alarm@alarm ~]$ ip route default via 192.168.1.253 dev eth0 proto dhcp src 192.168.1.211 metric
1024
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.211 192.168.1.253 dev eth0 proto dhcp scope link src 192.168.1.211 metric
1024
[alarm@alarm ~]$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:002: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DEFAULT group default qlen 1000
link/ether 00:10:75:28:5e:30 brd ff:ff:ff:ff:ff:ff[alarm@alarm ~]$ ip neigh 192.168.1.253 dev eth0 lladdr 62:38:e0:c2:54:a8 STALE 192.168.1.254 dev eth0 lladdr 8c:5a:25:e4:56:b0 STALE fe80::8e5a:25ff:fee4:56b0 dev eth0 lladdr 8c:5a:25:e4:56:b0 router STALE fe80::1eb5:75df:b84:98d1 dev eth0 lladdr 00:1d:60:35:b8:13 STALE 2600:1702:4860:9dd0:21d:60ff:fe35:b813 dev eth0 lladdr 00:1d:60:35:b8:13
DELAY
fe80::6038:e0ff:fec2:54a8 dev eth0 lladdr 62:38:e0:c2:54:a8 router STALE
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 5/14/21 8:38 AM, Ed Greshko wrote:
On 14/05/2021 19:35, Robert McBroom via users wrote:
On 5/12/21 6:46 PM, Ed Greshko wrote:
On 13/05/2021 04:05, Roger Heflin wrote:
Do an "ip route" on both the source and destination nodes.
also do an "ip neigh" on both.
And an "ip link" on both.
Yes, that would be very helpful if Robert would supply that information. Thanks for making that suggestion
Have to apologize. Cockpit error. The address should have been
192.168.1.211 instead of 192.168.1.112
From the host system
Well, the information below would seem to be incomplete since you probably have not tried to access 192.168.1.211. We do see FAILED for 192.168.1.112 since you've probably tried it and a host with that IP address doesn't exist.
You can see that for the IPv6 address of 2600:1702:4860:9dd0:210:75ff:fe28:5e30 the hwaddress of 00:10:75:28:5e:30 matches that of eth0 in the "ip link" results of the target system. That would indicate physical connectivity.
So, would you do these in order?
ip -4 add show ping 192.168.1.211 traceroute -n 192.168.1.211 ip neigh
Tried the correct address as soon as my mind quit pl aying tricks on me then caught on that the second ipv6 address wanted the tag of the local device attached
ip -4 add show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 192.168.1.185/24 brd 192.168.1.255 scope global dynamic noprefixroute enp2s0 valid_lft 56762sec preferred_lft 56762sec
traceroute -n 192.168.1.211 traceroute to 192.168.1.211 (192.168.1.211), 30 hops max, 60 byte packets 1 192.168.1.211 0.292 ms 0.204 ms 0.167 ms
traceroute -n 2600:1702:4860:9dd0:210:75ff:fe28:5e30 traceroute to 2600:1702:4860:9dd0:210:75ff:fe28:5e30 (2600:1702:4860:9dd0:210:75ff:fe28:5e30), 30 hops max, 80 byte packets 1 2600:1702:4860:9dd0:210:75ff:fe28:5e30 0.938 ms 0.837 ms 0.795 ms
traceroute -n fe80::210:75ff:fe28:5e30%enp2s0 traceroute to fe80::210:75ff:fe28:5e30%enp2s0 (fe80::210:75ff:fe28:5e30%enp2s0), 30 hops max, 80 byte packets 1 fe80::210:75ff:fe28:5e30%enp2s0 0.300 ms 0.176 ms 0.276 ms
On 15/05/2021 11:46, Robert McBroom via users wrote:
Tried the correct address as soon as my mind quit pl aying tricks on me then caught on that the second ipv6 address wanted the tag of the local device attached
So, everything is working as expected.
Bottom line, it was just the wrong IPv4 address all along. :-) :-) I don't have enough fingers to count when I've done something similar.
ip -4 add show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 192.168.1.185/24 brd 192.168.1.255 scope global dynamic noprefixroute enp2s0 valid_lft 56762sec preferred_lft 56762sec
traceroute -n 192.168.1.211 traceroute to 192.168.1.211 (192.168.1.211), 30 hops max, 60 byte packets 1 192.168.1.211 0.292 ms 0.204 ms 0.167 ms
traceroute -n 2600:1702:4860:9dd0:210:75ff:fe28:5e30 traceroute to 2600:1702:4860:9dd0:210:75ff:fe28:5e30 (2600:1702:4860:9dd0:210:75ff:fe28:5e30), 30 hops max, 80 byte packets 1 2600:1702:4860:9dd0:210:75ff:fe28:5e30 0.938 ms 0.837 ms 0.795 ms
traceroute -n fe80::210:75ff:fe28:5e30%enp2s0 traceroute to fe80::210:75ff:fe28:5e30%enp2s0 (fe80::210:75ff:fe28:5e30%enp2s0), 30 hops max, 80 byte packets 1 fe80::210:75ff:fe28:5e30%enp2s0 0.300 ms 0.176 ms 0.276 ms
-
Ed Greshko -
Mike Wright -
Robert McBroom -
Roger Heflin