--- 192.168.50.200 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
I have no idea where to look to see what is causing the problem.
Am 19.12.2022 schrieb Bit Twister <BitTwister@mouse-potato.com>:
--- 192.168.50.200 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
I have no idea where to look to see what is causing the problem.
Check your firewalls.
You can also use ARP/NDP to find out if they are
online because the have to reply to these messages instead of ICMP echo request.
Am 19.12.2022 schrieb Bit Twister <BitTwister@mouse-potato.com>:
--- 192.168.50.200 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
I have no idea where to look to see what is causing the problem.
Check your firewalls.
Did a shorewall clear on mtv and wb and still ping fails from/to
either nodes.
man shorewall snippet
Clear will remove all rules and chains installed by Shorewall.
The firewall is then wide open and unprotected. Existing connections
are untouched. Clear is often used to see if the firewall
is causing connection problems.
Am 19.12.2022 schrieb Bit Twister <BitTwister@mouse-potato.com>:
Did a shorewall clear on mtv and wb and still ping fails from/to
either nodes.
man shorewall snippet
Clear will remove all rules and chains installed by Shorewall.
The firewall is then wide open and unprotected. Existing connections
are untouched. Clear is often used to see if the firewall
is causing connection problems.
Then use Wireshark/other package capture an check if the ICMP echo
request packages reached the computer.
Maybe it is configured to not answer the ICMP echo request.
No idea where that can be done other than the firewall.
No idea where that can be done other than the firewall.
ping failure, what do I check?
I have three nodes on the lan. wb, mtv, and tb.
mtv.home.test has address 192.168.50.200
wb.home.test has address 192.168.50.132
Any suggestions?
Thanks in advance for any replies.
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.50.1 0.0.0.0 UG 1024 0 0 enp4s0
169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0 0 enp4s0
[root@wb ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.50.1 0.0.0.0 UG 10 0 0 enp15s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp15s0
On 19/12/2022 11.08, Bit Twister wrote:
ping failure, what do I check?
I have three nodes on the lan. wb, mtv, and tb.
...
mtv.home.test has address 192.168.50.200
wb.home.test has address 192.168.50.132
Any suggestions?
Thanks in advance for any replies.
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.50.1 0.0.0.0 UG 1024 0 0 enp4s0
169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0 0 enp4s0
Why does this machine has a separate route to the gateway?
[root@wb ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.50.1 0.0.0.0 UG 10 0 0 enp15s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp15s0
On Mon, 19 Dec 2022 09:11:27 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
No idea where that can be done other than the firewall.
Let's look at just tb and mtv for now.
On each system, what's the output of ...
# ip addr |grep -e default -e 'inet '
# grep -v ^'#' /etc/shorewall/interfaces
# cat /etc/shorewall/rules.drakx
On Mon, 19 Dec 2022 22:20:10 +0100, Carlos E. R. wrote:
On 19/12/2022 11.08, Bit Twister wrote:
ping failure, what do I check?
I have three nodes on the lan. wb, mtv, and tb.
...
mtv.home.test has address 192.168.50.200
wb.home.test has address 192.168.50.132
Any suggestions?
Thanks in advance for any replies.
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.50.1 0.0.0.0 UG 1024 0 0 enp4s0
169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0 0 enp4s0
Why does this machine has a separate route to the gateway?
You ask me like I know what I am doing. :)
mtv is my mythtv node where I record all my tv shows. Saves me 20+ minutes per
hour of viewing because I can fast forward through commercials.
The 169.254.1 range is the second nic to my other network switch where all the Over The Air Silicondust TV tuners are connected.
Routing is automagically built by the nic configuration files which are
used by systemd networking modules. I amazes me that I have a complex setup and know so little about what I am doing.
Which reminds me to say nics on all systems are connected to network switches with the Internet nic switch hooked to my lan router.
That is what stumps me logic wise. If ssh tb with ssh mtv works from wb
and tb can ping mtv that tells me I do not have physical connectivity problems,
and with shorewall firewall wide open/off ping should work.
root@wb ~]# host tb
tb.home.test has address 192.168.50.100
root@wb ~]# host mtv
mtv.home.test has address 192.168.50.200
root@wb ~]# host wb
wb.home.test has address 192.168.50.132
[root@wb ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.50.1 0.0.0.0 UG 10 0 0 enp15s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp15s0
On Mon, 19 Dec 2022 15:53:40 -0500, David W. Hodgins wrote:
On Mon, 19 Dec 2022 09:11:27 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
No idea where that can be done other than the firewall.
Let's look at just tb and mtv for now.
On each system, what's the output of ...
# ip addr |grep -e default -e 'inet '
# grep -v ^'#' /etc/shorewall/interfaces
# cat /etc/shorewall/rules.drakx
That is odd, I have guessed that with shorewall clear,
nothing in /etc/shorewall would apply, rule wise.
[root@wb ~]# ssh tb
Last login: Mon Dec 19 19:51:43 2022 from wb.home.test
ssh DISPLAY=localhost:11.0
Mageia release 8 (Official) for x86_64
FYI: Above custom message via ~/.bash_profile
===================== tb ==========================
[root@tb ~]# ip addr |grep -e default -e 'inet '
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
2: enp15s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.50.100/24 brd 192.168.50.255 scope global enp15s0
3: enp20s0u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
FYI: I make extensive use of /etc/shorewall/params so that
all shorewall settings are consistent but have any specific node changes since my install scripts have to support my neighbor and my setup.
]# grep -v ^'#' /etc/shorewall/interfaces
net enp15s0 $NET_OPTIONS
loc enp22s0f4u1 $NET_OPTIONS
# grep NET_OPTIONS /etc/shorewall/params | grep -v ^'#'
NET_OPTIONS="" # used in /interfaces
root@tb ~]# cat /etc/shorewall/rules.drakx
[root@tb ~]# dir /etc/shorewall/rules.drakx
-rw------- 1 root root 0 Nov 4 06:55 /etc/shorewall/rules.drakx
[root@tb ~]# ssh mtv
===================== mtv ==========================
Last login: Mon Dec 19 07:28:42 2022 from tb.home.test
ssh DISPLAY=localhost:10.0
Mageia release 8 (Official) for x86_64
# ip addr |grep -e default -e 'inet '
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
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 169.254.1.200/24 brd 169.254.1.255 scope global enp3s0
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.50.200/24 brd 192.168.50.255 scope global dynamic enp4s0
# grep -v ^'#' /etc/shorewall/interfaces
net enp4s0 $NET_OPTIONS
loc enp3s0 $NET_OPTIONS
# grep NET_OPTIONS /etc/shorewall/params | grep -v ^'#'
NET_OPTIONS="" # used in /interfaces
# cat /etc/shorewall/rules.drakx
[root@mtv ~]#
On Mon, 19 Dec 2022 21:29:27 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
[root@tb ~]# ip addr |grep -e default -e 'inet '
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
2: enp15s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.50.100/24 brd 192.168.50.255 scope global enp15s0
3: enp20s0u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
FYI: I make extensive use of /etc/shorewall/params so that
all shorewall settings are consistent but have any specific node changes
since my install scripts have to support my neighbor and my setup.
]# grep -v ^'#' /etc/shorewall/interfaces
net enp15s0 $NET_OPTIONS
loc enp22s0f4u1 $NET_OPTIONS
NOTE: enp22s0f4u1 should be enp20s0u3 based on the ip addr output.
# grep NET_OPTIONS /etc/shorewall/params | grep -v ^'#'
NET_OPTIONS="" # used in /interfaces
root@tb ~]# cat /etc/shorewall/rules.drakx
[root@tb ~]# dir /etc/shorewall/rules.drakx
-rw------- 1 root root 0 Nov 4 06:55 /etc/shorewall/rules.drakx
The dir command is not cat. :-)
[root@tb ~]# ssh mtv
===================== mtv ==========================
Last login: Mon Dec 19 07:28:42 2022 from tb.home.test
ssh DISPLAY=localhost:10.0
Mageia release 8 (Official) for x86_64
# ip addr |grep -e default -e 'inet '
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
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 169.254.1.200/24 brd 169.254.1.255 scope global enp3s0
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.50.200/24 brd 192.168.50.255 scope global dynamic enp4s0
# grep -v ^'#' /etc/shorewall/interfaces
net enp4s0 $NET_OPTIONS
loc enp3s0 $NET_OPTIONS
# grep NET_OPTIONS /etc/shorewall/params | grep -v ^'#'
NET_OPTIONS="" # used in /interfaces
# cat /etc/shorewall/rules.drakx
[root@mtv ~]#
So mtv does not have shorewall configured?
Please post the results of
cat /etc/sysconfig/network-scripts/ifcfg-e*
for each system.
On Mon, 19 Dec 2022 21:35:23 -0500, David W. Hodgins wrote:
Please post the results of
cat /etc/sysconfig/network-scripts/ifcfg-e*
for each system.
[root@wb ~]# ssh tb
Last login: Mon Dec 19 23:07:26 2022 from wb.home.test
ssh DISPLAY=localhost:11.0
Mageia release 8 (Official) for x86_64
[root@tb ~]#
# cat /etc/sysconfig/network-scripts/ifcfg-e*
DEVICE=enp15s0
BOOTPROTO=static
IPADDR=192.168.50.100
NETMASK=255.255.255.0
GATEWAY=192.168.50.1
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
LINK_DETECTION_DELAY=6
IPV6INIT=yes
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DNS1=127.0.0.1
DNS2=8.8.8.8
DOMAIN=home.test
DEVICE=enp20s0u3
BOOTPROTO=static
IPADDR=169.254.1.100
NETMASK=255.255.0.0
ONBOOT=yes
MII_NOT_SUPPORTED=no
USERCTL=no
DOMAIN="home.test tuner.test"
RESOLV_MODS=no
IPV6INIT=yes
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
]# ssh mtv
Last login: Mon Dec 19 22:09:28 2022 from tb.home.test
ssh DISPLAY=localhost:10.0
Mageia release 8 (Official) for x86_64
[root@mtv ~]#
# cat /etc/sysconfig/network-scripts/ifcfg-e*
DEVICE=enp3s0
BOOTPROTO=static
IPADDR=169.254.1.200
NETMASK=255.255.0.0
ONBOOT=yes
METRIC=5
MII_NOT_SUPPORTED=no
USERCTL=no
NEEDHOSTNAME=no
PEERDNS=no
PEERYP=no
PEERNTPD=no
RESOLV_MODS=no
LINK_DETECTION_DELAY=10
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DOMAIN="home.test tuner.test"
DEVICE=enp4s0
BOOTPROTO=static
IPADDR=192.168.11.200
NETMASK=255.255.255.0
GATEWAY=192.168.50.1
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
DNS1=127.0.0.1
DOMAIN=google
RESOLV_MODS=no
LINK_DETECTION_DELAY=6
IPV6INIT=yes
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DNS2=8.8.8.8
Can only guess you will need systemd network files since that is what
I use.
[root@mtv ~]# cat /usr/lib/systemd/network/*__e* | grep -v "#"
[Match]
Name=enp4s0
[Network]
Description=LAN_NIC
DHCP=ipv4
DNS=127.0.0.1
Domains=home.test
IPv6AcceptRouterAdvertisements=false
[Address]
Address=192.168.50.200/24
[Route]
Gateway=192.168.11.1
[Match]
Name=enp3s0
[Network]
Description=TUNER_NIC
IPv6AcceptRouterAdvertisements=false
[Address]
Address=169.254.1.200/24
[root@tb ~]# ssh mtv
Last login: Mon Dec 19 21:03:48 2022 from tb.home.test
ssh DISPLAY=localhost:10.0
Mageia release 8 (Official) for x86_64
[root@mtv ~]
# cat /usr/lib/systemd/network/*__e* | grep -v "#"
[Match]
Name=enp4s0
[Network]
Description=LAN_NIC
DHCP=ipv4
DNS=127.0.0.1
Domains=home.test
IPv6AcceptRouterAdvertisements=false
[Address]
Address=192.168.50.200/24
[Route]
Gateway=192.168.11.1
[Match]
Name=enp3s0
[Network]
Description=TUNER_NIC
IPv6AcceptRouterAdvertisements=false
[Address]
Address=169.254.1.200/24
I have found ip route to provide more significant information.
my wb1 node is getting two ip addresses one of which is wb. :(
Still trying to work that out.
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 proto dhcp src 192.168.50.200 metric 1024 169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200 192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200 192.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
Damn, confused myself as to which nic was LAN.
added a GATEWAY=192.168.50.1 to /etc/sysconfig/network-scripts/ifcfg-enp4s0 and removed it from /etc/sysconfig/network-scripts/ifcfg-enp3s0
After systemctl restart network mtv can ping wb and vice versa.
Off to reboot mtv and verify it still works.
Nope, back to no ping and according to route -n there is no gateway route
on mtv. Above file dumps are after reboot.
[root@tb ~]# ip route
default via 192.168.50.1 dev enp15s0 metric 10
169.254.0.0/16 dev enp20s0u3 proto kernel scope link src 169.254.1.100 192.168.50.0/24 dev enp15s0 proto kernel scope link src 192.168.50.100
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.50.1 0.0.0.0 UG 10 0 0 enp15s0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 enp20s0u3 192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp15s0
On Tue, 20 Dec 2022 00:53:32 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Mon, 19 Dec 2022 21:35:23 -0500, David W. Hodgins wrote:
Please post the results of
cat /etc/sysconfig/network-scripts/ifcfg-e*
for each system.
[root@wb ~]# ssh tb
Last login: Mon Dec 19 23:07:26 2022 from wb.home.test
ssh DISPLAY=localhost:11.0
Mageia release 8 (Official) for x86_64
[root@tb ~]#
# cat /etc/sysconfig/network-scripts/ifcfg-e*
DEVICE=enp15s0
BOOTPROTO=static
IPADDR=192.168.50.100
NETMASK=255.255.255.0
GATEWAY=192.168.50.1
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
LINK_DETECTION_DELAY=6
IPV6INIT=yes
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DNS1=127.0.0.1
DNS2=8.8.8.8
DOMAIN=home.test
DEVICE=enp20s0u3
BOOTPROTO=static
IPADDR=169.254.1.100
NETMASK=255.255.0.0
ONBOOT=yes
MII_NOT_SUPPORTED=no
USERCTL=no
DOMAIN="home.test tuner.test"
RESOLV_MODS=no
IPV6INIT=yes
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
]# ssh mtv
Last login: Mon Dec 19 22:09:28 2022 from tb.home.test
ssh DISPLAY=localhost:10.0
Mageia release 8 (Official) for x86_64
[root@mtv ~]#
# cat /etc/sysconfig/network-scripts/ifcfg-e*
DEVICE=enp3s0
BOOTPROTO=static
IPADDR=169.254.1.200
NETMASK=255.255.0.0
ONBOOT=yes
METRIC=5
MII_NOT_SUPPORTED=no
USERCTL=no
NEEDHOSTNAME=no
PEERDNS=no
PEERYP=no
PEERNTPD=no
RESOLV_MODS=no
LINK_DETECTION_DELAY=10
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DOMAIN="home.test tuner.test"
DEVICE=enp4s0
BOOTPROTO=static
IPADDR=192.168.11.200
NETMASK=255.255.255.0
GATEWAY=192.168.50.1
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
DNS1=127.0.0.1
DOMAIN=google
RESOLV_MODS=no
LINK_DETECTION_DELAY=6
IPV6INIT=yes
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no
DNS2=8.8.8.8
Can only guess you will need systemd network files since that is what
I use.
[root@mtv ~]# cat /usr/lib/systemd/network/*__e* | grep -v "#"
[Match]
Name=enp4s0
[Network]
Description=LAN_NIC
DHCP=ipv4
DNS=127.0.0.1
Domains=home.test
IPv6AcceptRouterAdvertisements=false
[Address]
Address=192.168.50.200/24
[Route]
Gateway=192.168.11.1
[Match]
Name=enp3s0
[Network]
Description=TUNER_NIC
IPv6AcceptRouterAdvertisements=false
[Address]
Address=169.254.1.200/24
[root@tb ~]# ssh mtv
Last login: Mon Dec 19 21:03:48 2022 from tb.home.test
ssh DISPLAY=localhost:10.0
Mageia release 8 (Official) for x86_64
[root@mtv ~]
# cat /usr/lib/systemd/network/*__e* | grep -v "#"
[Match]
Name=enp4s0
[Network]
Description=LAN_NIC
DHCP=ipv4
DNS=127.0.0.1
Domains=home.test
IPv6AcceptRouterAdvertisements=false
[Address]
Address=192.168.50.200/24
[Route]
Gateway=192.168.11.1
[Match]
Name=enp3s0
[Network]
Description=TUNER_NIC
IPv6AcceptRouterAdvertisements=false
[Address]
Address=169.254.1.200/24
I have found ip route to provide more significant information.
my wb1 node is getting two ip addresses one of which is wb. :(
Still trying to work that out.
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 proto dhcp src 192.168.50.200 metric 1024
169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200
192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200
192.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024 >>
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
Damn, confused myself as to which nic was LAN.
added a GATEWAY=192.168.50.1 to /etc/sysconfig/network-scripts/ifcfg-enp4s0 >> and removed it from /etc/sysconfig/network-scripts/ifcfg-enp3s0
After systemctl restart network mtv can ping wb and vice versa.
Off to reboot mtv and verify it still works.
Nope, back to no ping and according to route -n there is no gateway route
on mtv. Above file dumps are after reboot.
[root@tb ~]# ip route
default via 192.168.50.1 dev enp15s0 metric 10
169.254.0.0/16 dev enp20s0u3 proto kernel scope link src 169.254.1.100
192.168.50.0/24 dev enp15s0 proto kernel scope link src 192.168.50.100
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface >> 0.0.0.0 192.168.50.1 0.0.0.0 UG 10 0 0 enp15s0 >> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 enp20s0u3
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp15s0
For 169.254 there's a mixing of /16 and /24 being specified. Is that intentional?
Not on my part and that is on tb. Just a result of some setting in some
file by some app.
Since I have very little idea about who is doing what from where, it is pretty hard fix it except play around with network and systemd config files.
On Tue, 20 Dec 2022 02:34:02 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Not on my part and that is on tb. Just a result of some setting in some
file by some app.
Since I have very little idea about who is doing what from where, it is
pretty hard fix it except play around with network and systemd config files.
There are four ways normal networking can be configured in Mageia.
For avahi, I've never bothered looking into it's configuration files. I just disable it.
# grep MII /etc/sysconfig/network-scripts/ifcfg-e*
MII_NOT_SUPPORTED=yes
The MII stands for Media Independent Interface, which is another name for zeroconf.
Most likely one of the avahi configuration files on tb has been altered to restrict it to a /24 instead of it's default of using /16. Don't do that.
The SOLUTION to the ping problem was no gateway (UG) line seen in
route -n
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface 0.0.0.0 192.168.50.1 0.0.0.0 UG 10
0 0 enp4s0 169.254.1.0 0.0.0.0 255.255.255.0 U
0 0 0 enp3s0 192.168.50.0 0.0.0.0
255.255.255.0 U 0 0 0 enp4s0
Once I got a gateway defined, doing a systemd restart network, ping
started working.
Am 20.12.2022 schrieb Bit Twister <BitTwister@mouse-potato.com>:
The SOLUTION to the ping problem was no gateway (UG) line seen in
route -n
Once I got a gateway defined, doing a systemd restart network, ping
started working.
How does your routing table now look like?
If no route exists, there should be an ICMP message.
On Tue, 20 Dec 2022 02:34:02 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Not on my part and that is on tb. Just a result of some setting in some
file by some app.
Since I have very little idea about who is doing what from where, it is
pretty hard fix it except play around with network and systemd config files.
There are four ways normal networking can be configured in Mageia.
I'll review the rest of the article tomorrow.
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface 0.0.0.0 192.168.50.1 0.0.0.0 UG 10
0 0 enp4s0 0.0.0.0 192.168.50.1 0.0.0.0 UG
1024 0 0 enp4s0 169.254.1.0 0.0.0.0
255.255.255.0 U 0 0 0 enp3s0 192.168.50.0
0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0
0 enp4s0
and no idea how the UH line is created.
Am 20.12.2022 schrieb Bit Twister <BitTwister@mouse-potato.com>:
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0
0 enp4s0
and no idea how the UH line is created.
That is a flag, see the manpage of route.
UH means it is up and it affects one host (IPv4 /32 and IPv6 /128 as destination address prefix length/netmask).
On Tue, 20 Dec 2022 03:36:21 -0500, David W. Hodgins wrote:
I'll review the rest of the article tomorrow.Looking at
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 metric 10
default via 192.168.50.1 dev enp4s0 proto dhcp src 192.168.50.200 metric 1024 169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200 192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200 192.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024
Going to have to look into dhcp oh how to ignore managing 192.168.50.200 network nic.
On Tue, 20 Dec 2022 07:28:13 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 03:36:21 -0500, David W. Hodgins wrote:
I'll review the rest of the article tomorrow.Looking at
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 metric 10
default via 192.168.50.1 dev enp4s0 proto dhcp src 192.168.50.200 metric 1024
169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200
192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200
192.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024 >>
Going to have to look into dhcp oh how to ignore managing 192.168.50.200
network nic.
As the systems all have fixed ipv4 addresses, with no ipvt6, the DUID entries in
/etc/systemd/networkd.conf should be commented out, DHCP= in /etc/systemd/network/*
should be no, and BOOTPROTO= in /etc/sysconfig/network-scripts/ifcfg-* should be
static.
On Tue, 20 Dec 2022 07:28:13 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 03:36:21 -0500, David W. Hodgins wrote:
I'll review the rest of the article tomorrow.Looking at
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 metric 10
default via 192.168.50.1 dev enp4s0 proto dhcp src 192.168.50.200 metric 1024
169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200
192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200
192.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024 >>
Going to have to look into dhcp oh how to ignore managing 192.168.50.200
network nic.
As the systems all have fixed ipv4 addresses, with no IPV6, the DUID entries in
/etc/systemd/networkd.conf should be commented out,
DHCP= in /etc/systemd/network/* should be no,
and BOOTPROTO= in /etc/sysconfig/network-scripts/ifcfg-* should be
static.
On Tue, 20 Dec 2022 13:33:55 +0100, Marco Moock wrote:
Am 20.12.2022 schrieb Bit Twister <BitTwister@mouse-potato.com>:
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0
0 enp4s0
and no idea how the UH line is created.
That is a flag, see the manpage of route.
That still does not tell me how it got there.
On Tue, 20 Dec 2022 13:40:38 -0500, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
Meant to add -
If you're only using ipv4, then either, drakx-net, or networkmanager can be used
on a given install. Using systemd-networkd instead is not recommended due to many
other startup scripts expecting either drakx-net or networkmanager.
If you're using ipv6 too, then either use networkmanager, or a careful combination
of drakx-net and systemd-networkd.
I have disabled ipv6 at the system level with ipv6.disable=1 which
gets me kernel: IPv6: Loaded, but administratively disabled, reboot
required to enable
Am 20.12.2022 um 14:51:00 Uhr schrieb Bit Twister:
I have disabled ipv6 at the system level with ipv6.disable=1 which
gets me kernel: IPv6: Loaded, but administratively disabled, reboot
required to enable
For what reason?
On Tue, 20 Dec 2022 21:51:52 +0100, Marco Moock wrote:
Am 20.12.2022 um 14:51:00 Uhr schrieb Bit Twister:
I have disabled ipv6 at the system level with ipv6.disable=1 which
gets me kernel: IPv6: Loaded, but administratively disabled, reboot
required to enable
For what reason?
Reason 1: Seeing articles and CVE ipv6 bug exploits when surfing the net.
go ahead google for ipv6 exploits
Reason 2. My ISP only provides ipv4 to residential customers.
Reason 3. Other than lan computers and router I have no ipv6 devices.
Reason 4. Extra maintenance on things like shorewall, named...
Reason 5. Have not run across the need for it, so far.
Security cameras and Over-the-Air TV network tuners are ipv4.
On Tue, 20 Dec 2022 16:08:35 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 21:51:52 +0100, Marco Moock wrote:
Am 20.12.2022 um 14:51:00 Uhr schrieb Bit Twister:
I have disabled ipv6 at the system level with ipv6.disable=1 which
gets me kernel: IPv6: Loaded, but administratively disabled, reboot
required to enable
For what reason?
Reason 1: Seeing articles and CVE ipv6 bug exploits when surfing the net.
go ahead google for ipv6 exploits
Reason 2. My ISP only provides ipv4 to residential customers.
Are you positive about this?
In my case, my router, which supposedly supported
ipv6 died (lightning strike). With a new router, my ipv6 connections started working as per the router's status page. At that point I re-enabled ipv6 on my
systems.
Reason 3. Other than lan computers and router I have no ipv6 devices.
Reason 4. Extra maintenance on things like shorewall, named...
Reason 5. Have not run across the need for it, so far.
There are sites that only have ipv6 addresses and their numbers are increasing.
The ipv6 exploits are different, but similar to ipv4 exploits. The biggest security
difference is that with ipv6, every device is directly accessible without the the
need for the router to have rules to forward traffic to the device.
That means you cannot just rely on a firewall in the router to block unwanted traffic. It must be done in a firewall on every device using ipv6, which is strongly recommended in an ipv4 only lan anyway.
Security cameras and Over-the-Air TV network tuners are ipv4.
That will change at some point.
On Mon, 19 Dec 2022 22:20:10 +0100, Carlos E. R. wrote:
On 19/12/2022 11.08, Bit Twister wrote:
ping failure, what do I check?
I have three nodes on the lan. wb, mtv, and tb.
...
mtv.home.test has address 192.168.50.200
wb.home.test has address 192.168.50.132
Any suggestions?
Thanks in advance for any replies.
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.50.1 0.0.0.0 UG 1024 0 0 enp4s0
169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
192.168.50.1 0.0.0.0 255.255.255.255 UH 1024 0 0 enp4s0
Why does this machine has a separate route to the gateway?
You ask me like I know what I am doing. :)
On Tue, 20 Dec 2022 13:40:38 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 07:28:13 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 03:36:21 -0500, David W. Hodgins wrote:
I'll review the rest of the article tomorrow.Looking at
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 metric 10
default via 192.168.50.1 dev enp4s0 proto dhcp src 192.168.50.200 metric 1024
169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200
192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200
192.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024
Going to have to look into dhcp oh how to ignore managing 192.168.50.200 >>> network nic.
As the systems all have fixed ipv4 addresses, with no IPV6, the DUID entries in
/etc/systemd/networkd.conf should be commented out,
# grep DUID /etc/systemd/networkd.conf
#DUIDType=vendor
#DUIDRawData=
DHCP= in /etc/systemd/network/* should be no,
# grep DHCP /etc/systemd/network/*
FYI for future troubleshooting that would be
$ grep DHCP /usr/lib/systemd/network/*
10_xx__enp4s0.network: DHCP=no
20_xx__dhcp.network:# /usr/lib/systemd/network/20_xx__dhcp.network 20_xx__dhcp.network:# Created by /local/bin/install_dhcp_nic Thu 08 Apr 10:37 2021
20_xx__dhcp.network:# /local/bin/install_dhcp_nic and run 20_xx__dhcp.network: Description=DHCP_NIC
20_xx__dhcp.network: DHCP=ipv4
20_xx__dhcp.network:#****** end /usr/lib/systemd/network/20_xx__dhcp.network ****
The 20_xx__dhcp is disabled via
$ dir /etc/systemd/network/*
lrwxrwxrwx 1 root root 9 Apr 8 2021 /etc/systemd/network/20_xx__dhcp_nic.network -> /dev/nul
80-container-host0.network:DHCP=yes
80-container-host0.network:[DHCP]
80-container-ve.network:DHCPServer=yes
80-container-vz.network:DHCPServer=yes
80-vm-vt.network:# configuration as ve-* to provide NAT/DHCP to VMs. 80-vm-vt.network:DHCPServer=yes
80-wifi-ap.network.example:DHCPServer=yes 80-wifi-station.network.example:DHCP=yes
and BOOTPROTO= in /etc/sysconfig/network-scripts/ifcfg-* should be
static.
$ grep BOOTPROTO= /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network-scripts/ifcfg-enp3s0:BOOTPROTO=static /etc/sysconfig/network-scripts/ifcfg-enp4s0:BOOTPROTO=static
Just now rebooted and ping is working. But look here
[root@mtv ~]# ip route
169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200 192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200
[root@mtv ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
No default gateway flag in above or default in ip route.
And now I named appears to be broke.
Snippet from systemctl status named
Dec 20 14:19:29 mtv.home.test named[4075]: network unreachable resolving 'yahoo.com/A/IN': 193.0.14.129#53
Dec 20 14:19:29 mtv.home.test named[4075]: network unreachable resolving 'yahoo.com/AAAA/IN': 193.0.14.129#53
Dec 20 14:19:29 mtv.home.test named[4075]: network unreachable resolving 'yahoo.com/A/IN': 199.9.14.201#53
Dec 20 14:19:29 mtv.home.test named[4075]: network unreachable resolving 'yahoo.com/AAAA/IN': 199.9.14.201#53
# host wb
wb.home.test has address 192.168.50.132
# host tb
tb.home.test has address 192.168.50.100
# host yahoo.com
;; connection timed out; no servers could be reached
On Tue, 20 Dec 2022 16:31:26 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 16:08:35 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 21:51:52 +0100, Marco Moock wrote:
Am 20.12.2022 um 14:51:00 Uhr schrieb Bit Twister:
I have disabled ipv6 at the system level with ipv6.disable=1 which
gets me kernel: IPv6: Loaded, but administratively disabled, reboot
required to enable
For what reason?
Reason 1: Seeing articles and CVE ipv6 bug exploits when surfing the net. >>> go ahead google for ipv6 exploits
Reason 2. My ISP only provides ipv4 to residential customers.
Are you positive about this?
Yup.
$ wget -qO - http://icanhazip.com
72.181.165.117
I even have a ck_network script to tell me if my ip address changes.
In my case, my router, which supposedly supported
ipv6 died (lightning strike). With a new router, my ipv6 connections started >> working as per the router's status page. At that point I re-enabled ipv6 on my
systems.
Reason 3. Other than lan computers and router I have no ipv6 devices.
Reason 4. Extra maintenance on things like shorewall, named...
Reason 5. Have not run across the need for it, so far.
There are sites that only have ipv6 addresses and their numbers are increasing.
Yep, but I believe the ISPs have a ipv4/ipv6 stack converter.
The ipv6 exploits are different, but similar to ipv4 exploits. The biggest security
difference is that with ipv6, every device is directly accessible without the the
need for the router to have rules to forward traffic to the device.
That means you cannot just rely on a firewall in the router to block unwanted
traffic. It must be done in a firewall on every device using ipv6, which is >> strongly recommended in an ipv4 only lan anyway.
Security cameras and Over-the-Air TV network tuners are ipv4.
That will change at some point.
Yea, but I hope if I loose a tuner, or camera they will have ipv4 access.
Modified lan nic systemd network file to have
[Route]
Gateway=192.168.50.1
Did a restart network and default is back,
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.50.1 0.0.0.0 UG 10 0 0 enp4s0
169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
[root@mtv ~]# ip route
default via 192.168.50.1 dev enp4s0 metric 10
169.254.1.0/24 dev enp3s0 proto kernel scope link src 169.254.1.200 192.168.50.0/24 dev enp4s0 proto kernel scope link src 192.168.50.200
[root@mtv ~]# host yahoo.com
yahoo.com has address 98.137.11.164
<big snip of results>
Hopefully, everything will still work on reboot.
Solution so far is set
[Network]
DHCP=no
and add
[Route]
Gateway=192.168.50.1
to system-networkd LAN nic network configuration file.
On Tue, 20 Dec 2022 16:31:26 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 16:08:35 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 21:51:52 +0100, Marco Moock wrote:
Am 20.12.2022 um 14:51:00 Uhr schrieb Bit Twister:
I have disabled ipv6 at the system level with ipv6.disable=1 which
gets me kernel: IPv6: Loaded, but administratively disabled, reboot
required to enable
For what reason?
Reason 1: Seeing articles and CVE ipv6 bug exploits when surfing the net. >>> go ahead google for ipv6 exploits
Reason 2. My ISP only provides ipv4 to residential customers.
Are you positive about this?
Yup.
$ wget -qO - http://icanhazip.com
72.181.165.117
On Tue, 20 Dec 2022 16:54:27 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Solution so far is set
[Network]
DHCP=no
and add
[Route]
Gateway=192.168.50.1
to system-networkd LAN nic network configuration file.
Ignore the article I posted just before I recived this on. :-)
Try the reboot, just to be sure.
On Tue, 20 Dec 2022 16:54:27 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 16:31:26 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 16:08:35 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Reason 2. My ISP only provides ipv4 to residential customers.
Are you positive about this?
Yup.
$ wget -qO - http://icanhazip.com
72.181.165.117
That does not show whether or not the router has ipv6.
On my tp-link router, after logging in, I have to select advanced, and then click on the ipv6 link on the internet part of the status page to see the router's ipv6 settings to see the router's dynamically assigned ipv6 address.
On Tue, 20 Dec 2022 15:26:23 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 13:40:38 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 07:28:13 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
FYI for future troubleshooting that would be
$ grep DHCP /usr/lib/systemd/network/*
The directory /usr/lib/systemd/network/ is only for package supplied files, not for system administration.
System administrator created systemd config files belong in /etc/systemd or a subdirectory of /etc/systemd.
For networking, it should be in /etc/systemd/network/
The 20_xx__dhcp is disabled via
$ dir /etc/systemd/network/*
lrwxrwxrwx 1 root root 9 Apr 8 2021 /etc/systemd/network/20_xx__dhcp_nic.network -> /dev/nul
Why create the file only to then mask it?
80-container-host0.network:DHCP=yes
80-container-host0.network:[DHCP]
80-container-ve.network:DHCPServer=yes
80-container-vz.network:DHCPServer=yes
80-vm-vt.network:# configuration as ve-* to provide NAT/DHCP to VMs.
80-vm-vt.network:DHCPServer=yes
80-wifi-ap.network.example:DHCPServer=yes
80-wifi-station.network.example:DHCP=yes
Those files are only used if you're using things like tunneling, systemd containers, etc.
They will not be used for a normal lan.
On Tue, 20 Dec 2022 17:56:14 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 16:54:27 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Solution so far is set
[Network]
DHCP=no
and add
[Route]
Gateway=192.168.50.1
to system-networkd LAN nic network configuration file.
Ignore the article I posted just before I recived this on. :-)
Hehehe, you are supposed to read all posted articles before replying. :-D
Try the reboot, just to be sure.
Need to wait for time mythtv is not recording shows.
Well, I hear what you are saying but that is a bit of a hassle. I have
$ ls -1 /usr/lib/systemd/network/*xx* /usr/lib/systemd/network/10_xx__enp4s0.network /usr/lib/systemd/network/11_xx__enp3s0.network /usr/lib/systemd/network/20_xx__dhcp.network /usr/lib/systemd/network/30_xx__wlan.network
You would have me put them in /etc/systemd/network/
but, to disable an interface you remove the configuration file
or in my case, soft link it to /dev/null.
In either case you would have to recreate the file to enable it.
Since /etc/systemd/network/ overrides /usr/lib/systemd/network/
files all I have to do is create a link to /dev/null in /etc/systemd/network/ to disable an interface and delete the soft link to enable it.
Now that I think about it I could create xx*.custom and
soft link xx*.custom to xx*.network.
Did you try the wget at your command line?
I thought it returned an ipv6 if ISP was giving you one.
If no ipv6 from icanhazip try these
wget -qO - http://ident.me/
wget -qO - http://smxi.org/opt/ip.php
wget -qO - https://ipecho.net/plain
On Tue, 20 Dec 2022 19:56:55 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Did you try the wget at your command line?
I thought it returned an ipv6 if ISP was giving you one.
If no ipv6 from icanhazip try these
wget -qO - http://ident.me/
wget -qO - http://smxi.org/opt/ip.php
wget -qO - https://ipecho.net/plain
icanhazip.com does not return anything anymore.
http://myip.dnsomatic.com/ returns the ipv4 address.
http://ident.me/ returns the ipv6 address.
http://smxi.org/opt/ip.php returns the ipv4 address.
On Tue, 20 Dec 2022 22:52:28 -0500, David W. Hodgins wrote:
On Tue, 20 Dec 2022 19:56:55 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
Did you try the wget at your command line?
I thought it returned an ipv6 if ISP was giving you one.
If no ipv6 from icanhazip try these
wget -qO - http://ident.me/
wget -qO - http://smxi.org/opt/ip.php
wget -qO - https://ipecho.net/plain
icanhazip.com does not return anything anymore.
http://myip.dnsomatic.com/ returns the ipv4 address.
http://ident.me/ returns the ipv6 address.
http://smxi.org/opt/ip.php returns the ipv4 address.
how about
wget -qO - http://whatismyip.akamai.com
icanhazip.com does not return anything anymore.
On Tue, 20 Dec 2022 23:44:20 -0500, David W. Hodgins wrote:
icanhazip.com does not return anything anymore.
If it did and now doesn't that is odd, could you try again with
curl http://icanhazip.com
wget -qO - http://icanhazip.com
There are sites that only have ipv6 addresses and their numbers are increasing. The ipv6 exploits are different, but similar to ipv4
exploits. The biggest security difference is that with ipv6, every
device is directly accessible without the the need for the router to
have rules to forward traffic to the device.
That means you cannot just rely on a firewall in the router to block
unwanted traffic. It must be done in a firewall on every device using
ipv6, which is strongly recommended in an ipv4 only lan anyway.
Am 20.12.2022 um 16:31:26 Uhr schrieb David W. Hodgins:
There are sites that only have ipv6 addresses and their numbers are
increasing. The ipv6 exploits are different, but similar to ipv4
exploits. The biggest security difference is that with ipv6, every
device is directly accessible without the the need for the router to
have rules to forward traffic to the device.
That means you cannot just rely on a firewall in the router to block
unwanted traffic. It must be done in a firewall on every device using
ipv6, which is strongly recommended in an ipv4 only lan anyway.
That is wrong. Most SOHO routers have an SPI firewall for IPv6 that
only allow incoming packets that were requested and the result is the
same as IPv4 stateful NAT without the disadvantages of it.
Exceptions are easy and no static NAT rules (port forwarding) is
necessary).
On Wed, 21 Dec 2022 00:42:23 -0500, Bit Twister <BitTwister@mouse-potato.com> wrote:
On Tue, 20 Dec 2022 23:44:20 -0500, David W. Hodgins wrote:
icanhazip.com does not return anything anymore.
If it did and now doesn't that is odd, could you try again with
curl http://icanhazip.com
wget -qO - http://icanhazip.com
Sysop: | Tetrazocine |
---|---|
Location: | Melbourne, VIC, Australia |
Users: | 4 |
Nodes: | 8 (0 / 8) |
Uptime: | 59:09:24 |
Calls: | 65 |
Files: | 21,500 |
Messages: | 73,556 |