ping failure, what do I check?

[Bit Twister]

ping failure, what do I check?

I have three nodes on the lan. wb, mtv, and tb.

I have install_scripts to do system configurations so
all node setups should be pretty much the same +/- network
ip addresses and network cards. Firewall is shorewall
and are pretty much the same.

tb can ping mtv and wb. wb and mtv can not ping each other.
Setting at wb terminal I have root xterms open on all three
nodes via ssh. I had to ssh tb, then from tb, ssh mtv.

I opened terminals on wb and mtv to constantly watch/display
the system log (jpournalctl).

No drop lines show up on either wb or mtv during ping failures.

[root@mtv ~]# host mtv
mtv.home.test has address 192.168.50.200

[root@mtv ~]# host wb
wb.home.test has address 192.168.50.132

keep an eye on root prompts on the following:

[root@tb ~]# ping -4c1 -w1 192.168.50.200
PING 192.168.50.200 (192.168.50.200) 56(84) bytes of data.
64 bytes from 192.168.50.200: icmp_seq=1 ttl=64 time=0.249 ms

--- 192.168.50.200 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.249/0.249/0.249/0.000 ms

[root@tb ~]# ping -4c1 -w1 192.168.50.132
PING 192.168.50.132 (192.168.50.132) 56(84) bytes of data.
64 bytes from 192.168.50.132: icmp_seq=1 ttl=64 time=0.208 ms

--- 192.168.50.132 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.208/0.208/0.208/0.000 ms



[root@mtv ~]# ping -4c1 -w1 192.168.50.132
PING 192.168.50.132 (192.168.50.132) 56(84) bytes of data.

--- 192.168.50.132 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

[root@wb ~]# ping -4c1 -w1 192.168.50.200
PING 192.168.50.200 (192.168.50.200) 56(84) bytes of data.

--- 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.

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

[Marco Moock]

Am 19.12.2022 schrieb Bit Twister <BitTw...@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.

[Bit Twister]

On Mon, 19 Dec 2022 13:04:25 +0100, Marco Moock wrote:
> Am 19.12.2022 schrieb Bit Twister <BitTw...@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.

Check the original post, I have opened a system log tool journalctl
to display the log continusily looking for shorewall drops.
I do see drops for rules to reject some packets.

> 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.

Looking like arp is working. No idea how to do something for NDP

[root@wb ~]# arp | sort
Address HWtype HWaddress Flags Mask Iface
mtv.home.test ether 08:60:6e:44:25:56 C enp15s0
myrtr.home.test ether a4:2b:8c:09:90:f9 C enp15s0
tb.home.test ether d8:5e:d3:e4:b7:d0 C enp15s0

[root@wb ~]# arp --numeric | sort --version-sort --key=1
192.168.50.1 ether a4:2b:8c:09:90:f9 C enp15s0
192.168.50.100 ether d8:5e:d3:e4:b7:d0 C enp15s0
192.168.50.200 ether 08:60:6e:44:25:56 C enp15s0
Address HWtype HWaddress Flags Mask Iface

[Bit Twister]

On Mon, 19 Dec 2022 13:04:25 +0100, Marco Moock wrote:

> Am 19.12.2022 schrieb Bit Twister <BitTw...@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.

[Marco Moock]

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.

[Bit Twister]

On Mon, 19 Dec 2022 14:45:05 +0100, Marco Moock wrote:
> Am 19.12.2022 schrieb Bit Twister <BitTw...@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.

Why tb can ping mtv which works.
$ type uping
uping is aliased to `ping -4c1 -w1'

[root@tb ~]# uping mtv
PING mtv.home.test (192.168.50.200) 56(84) bytes of data.
64 bytes from mtv.home.test (192.168.50.200): icmp_seq=1 ttl=64 time=0.207 ms

--- mtv.home.test ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.207/0.207/0.207/0.000 ms

[root@wb ~]# uping mtv
PING mtv.home.test (192.168.50.200) 56(84) bytes of data.

--- mtv.home.test ping statistics ---

1 packets transmitted, 0 received, 100% packet loss, time 0ms

> Maybe it is configured to not answer the ICMP echo request.

No idea where that can be done other than the firewall.

[Marco Moock]

Am 19.12.2022 schrieb Bit Twister <BitTw...@mouse-potato.com>:

> No idea where that can be done other than the firewall.

Is there another one active?
Maybe ufw or iptables?

[David W. Hodgins]

On Mon, 19 Dec 2022 09:11:27 -0500, Bit Twister <BitTw...@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

Regards, Dave Hodgins

[Carlos E. R.]

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
>

--
Cheers,
Carlos E.R.

[Bit Twister]

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
>>
>


--

The warranty and liability expired as you read this message.
If the above breaks your system, it's yours and you keep both pieces.
Practice safe computing. Backup the file before you change it.
Do a, man command_here or cat command_here, before using it.

[Bit Twister]

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 ~]#

[David W. Hodgins]

Please post the results of
cat /etc/sysconfig/network-scripts/ifcfg-e*
for each system.

Regards, Dave Hodgins

[David W. Hodgins]

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?

Regards, Dave Hodgins

[Bit Twister]

On Mon, 19 Dec 2022 21:46:19 -0500, David W. Hodgins wrote:
> On Mon, 19 Dec 2022 21:29:27 -0500, Bit Twister <BitTw...@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.

Nice catch, got a new computer last week to replace mtv.

tb is the new system. Still working out changes needed for install scripts.
That is going to save me a bunch of time trying to figure out why mythtv
is not recording shows on tb. :)

# ip addr |grep -e default -e 'inet ' snippet

3: enp20s0u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000

inet 169.254.1.100/16 brd 169.254.255.255 scope global enp20s0u3

>> # 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. :-)

Yep, but I was anticipating a reply to the null output from the cat command. :-D

>> [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?

Bad assumption. /etc/shorewall/rules.drakx is empty because I made no
selections during install setup.

No, same shorewall install scripts configured all nodes.
I your ""enp22s0f4u1 should be enp20s0u3" catch made me fix the
base hardware information file for tb used by install/change scripts.

[root@mtv ~]# dir /etc/shorewall/rules.drakx
-rw------- 1 root root 0 Apr 8 2021 /etc/shorewall/rules.drakx

[Bit Twister]

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

[David W. Hodgins]

For 169.254 there's a mixing of /16 and /24 being specified. Is that intentional?

If you want the lan to be totally open, you might want to consider adding
ACCEPT net:10.0.0.0/8 fw
ACCEPT net:169.254.0.0/16 fw
ACCEPT net:172.16.0.0/12 fw
ACCEPT net:192.168.0.0/16 fw
for shorewall on all systems. That ensures that all posssible rfc1918 addresses
are allowed full access. Not great from a security point of view, but much
more convenient.

Regards, Dave Hodgins

[Bit Twister]

>> 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.

I can not even get a gateway (UG) set correctly on mtv.

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

mtv txt]$ grep gate /etc/sysconfig/network-scripts/ifcfg-e*
/etc/sysconfig/network-scripts/ifcfg-enp4s0:GATEWAY=192.168.50.1

mtv txt]$ grep gate /usr/lib/systemd/network/*__e*
/usr/lib/systemd/network/10_xx__enp4s0.network: Gateway=192.168.11.1

[David W. Hodgins]

On Tue, 20 Dec 2022 02:34:02 -0500, Bit Twister <BitTw...@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.

First was drakx-net.

Second, avahi which handles zeroconf network configuration, typically used
by smartphones and apple computers. That's the 169.254.0.0/16 addresses.
https://en.wikipedia.org/wiki/Zero-configuration_networking

Third, networkmanager was added.

Fourth, systemd-networkd.service.

The installer only handles drakx-net or networkmanager. They cannot both be
used on a given install. The drakx-net method is being deprecated and will
likely be removed in Mageia 10 as it doesn't seem to work well with ipv6,
and networkmanager will likely become the only choice in the installer.

While the installer doesn't handle configuring it (no config needed), avahi
is installed and activated too.

systemd-networkd can be used by itself, but that causes problems with
applications that expect either drakx-net or networkmanager. It can be
used in at the same time as drakx-net, if done correctly. I do that
on some of my installs to get ipv6 working without using networkmanager.

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.
If the alteration wasn't intention you may want to remove avahi using
"rpm -e --nodeps avahi" and then reinstall avahi. The old config files
will be kept with the .rpmsave suffix.

I'll review the rest of the article tomorrow.

Regards, Dave Hodgins

[Bit Twister]

On Tue, 20 Dec 2022 03:36:21 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 02:34:02 -0500, Bit Twister <BitTw...@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.

Yeah, but I configured/enabled systemd-netwoked and thought it was in control.
Starting to look like I missed something.

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.

>
> 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.

Thanks changed scripts to set MII_NOT_SUPPORTED=yes

I thought I had disabled it by getting rid of mdms stuff in /etc/nsswitch.conf

$ grep hosts: /etc/nsswitch.conf
# hosts: mdns4_minimal files nis dns mdns4 myhostname
hosts: files dns myhostname

>
> 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.

I THINK it was a NETMASK setting in one of the /etc/sysconfig/network-scripts/ifcfg-e*
set
NETMASK=255.255.0.0 which I changed to NETMASK=255.255.255.0
See above route dump.

[Marco Moock]

Am 20.12.2022 schrieb Bit Twister <BitTw...@mouse-potato.com>:

> 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

The line "destination 0.0.0.0/0" is the equivalent to the IPv4 default
gateway.

> 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.

[Bit Twister]

On Tue, 20 Dec 2022 11:40:52 +0100, Marco Moock wrote:
> Am 20.12.2022 schrieb Bit Twister <BitTw...@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?

$ 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

> If no route exists, there should be an ICMP message.

Yep, that is why ping failed.

[Bit Twister]

On Tue, 20 Dec 2022 03:36:21 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 02:34:02 -0500, Bit Twister <BitTw...@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.

It is getting weirder and weirder. Upon reboot ping is failing.
systemctl restart network, get ping to work. Downside is, each restart
adds another gateway.

# 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.

but looking on tb I get

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.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp20s0u3

[Bit Twister]

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.

[Marco Moock]

Am 20.12.2022 schrieb Bit Twister <BitTw...@mouse-potato.com>:

> # 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.

That is a flag, see the manpage of route.

Flags Possible flags include
U (route is up)
H (target is a host)
G (use gateway)
R (reinstate route for dynamic routing)
D (dynamically installed by daemon or redirect)
M (modified from routing daemon or redirect)
A (installed by addrconf)
C (cache entry)
! (reject route)

UH means it is up and it affects one host (IPv4 /32 and IPv6 /128 as
destination address prefix length/netmask).

[Bit Twister]

On Tue, 20 Dec 2022 13:33:55 +0100, Marco Moock wrote:
> Am 20.12.2022 schrieb Bit Twister <BitTw...@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.

> UH means it is up and it affects one host (IPv4 /32 and IPv6 /128 as
> destination address prefix length/netmask).

Frap, now systemctl restart network no longer allows ping to work.

# cat after_boot.txt

after_boot

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

After systemctl restart network

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

$ 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

snippet from my dhcp.conf script to try getting dhcpd to not add its

92.168.50.1 dev enp4s0 proto dhcp scope link src 192.168.50.200 metric 1024

line. Tried

set -- $( grep _lan_mac_nic_${_node}_c: /local/doc/unix.help | grep $_net_nic)
_mac=$4
echo "
host block_net_nic {
hardware ethernet $_mac;
ignore booting;
}
" >> $_fn

which pulls the mac address from my unix.help file. Looking at
https://forums.freebsd.org/threads/how-to-block-a-mac-using-dhcpd-conf.71987/
tried "deny" and surprise, surprise the static network did not come up.
That is worthy of a bug report.

Just now tried ignore. network came up, ping still broke and as you can
see from the above ip route. dhcpd is still helping me into the ditch.

[David W. Hodgins]

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.

Regards, Dave Hodgins

[David W. Hodgins]

On Tue, 20 Dec 2022 13:40:38 -0500, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Tue, 20 Dec 2022 07:28:13 -0500, Bit Twister <BitTw...@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.

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.

Regards, Dave Hodgins

[Bit Twister]

On Tue, 20 Dec 2022 13:40:38 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 07:28:13 -0500, Bit Twister <BitTw...@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


Guessing no default route causing this problem. :(

[Marco Moock]

Am 20.12.2022 um 11:22:30 Uhr schrieb Bit Twister:

> On Tue, 20 Dec 2022 13:33:55 +0100, Marco Moock wrote:
> > Am 20.12.2022 schrieb Bit Twister <BitTw...@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.

route gives it as an output to inform the user about the state of the
route. That's all.

[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


$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz root=LABEL=cauldron noiswmd vga=791 ipv6.disable=1 audit=0 splash=off plymouth.enable=0 noresume mitigations=off

and any apps that complain about it get their configuration file changed.

I try to keep messages in the journal showing only problems where possible.

[Marco Moock]

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?

[Bit Twister]

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.

[David W. Hodgins]

On Tue, 20 Dec 2022 16:08:35 -0500, Bit Twister <BitTw...@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.

Regards, Dave Hodgins

[Bit Twister]

On Tue, 20 Dec 2022 16:31:26 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 16:08:35 -0500, Bit Twister <BitTw...@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.

[Ted Heise]

On Mon, 19 Dec 2022 19:54:39 -0600,
Bit Twister <BitTw...@mouse-potato.com> wrote:
> 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. :)

Okay, this made me laugh and think, "I appreciate this person's
attitude."

--
Ted Heise <the...@panix.com> West Lafayette, IN, USA

[David W. Hodgins]

On Tue, 20 Dec 2022 15:26:23 -0500, Bit Twister <BitTw...@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 <BitTw...@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=

Good.

> > 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/*

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/

> 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

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.

I'm getting lost as to what you have where. :-)
Let's start again, one system at a time starting with mtv.
Please post all of the network interface configuration files being used on mtv.

Regards, Dave Hodgins

[David W. Hodgins]

Ignore the article I posted just before I recived this on. :-)

Try the reboot, just to be sure.

Regards, Dave Hodgins

[David W. Hodgins]

On Tue, 20 Dec 2022 16:54:27 -0500, Bit Twister <BitTw...@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 <BitTw...@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

That does not show whether or not the router has ipv6.

Check the router's configuration page at http://192.168.50.1

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.

Regards, Dave Hodgins

[Bit Twister]

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.

[Bit Twister]

On Tue, 20 Dec 2022 18:03:25 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 16:54:27 -0500, Bit Twister <BitTw...@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 <BitTw...@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.

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

I do remember someone's reply which showed an ipv6 but did not
note which one. I would be nice if you tell me which one(s) return ipv6
so I can update my hard copy brain book.

> 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.

Running Netgear router and click in the WAN box for details like address
and dhcp lease info.

[Bit Twister]

On Tue, 20 Dec 2022 17:23:46 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 15:26:23 -0500, Bit Twister <BitTw...@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 <BitTw...@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/

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.

>> 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?

Just to have it in case I need it.
Going to be doing it for the wireless connection on nodes I will
be disabling it.

I ran into the requirement when my neighbor switched ISP to Spectrum.
Tech came out, wired up the cable modem, jacked in his computer
and could not connect because I had set his node nic as static
and I did not know how to set dhcp client in system-networkd xx.network
The upside was that the tech had spent too much time getting
the coax from poll to modem, so he gave my neighbor a router for free,
and up came the connection.

>> 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.

Good to know, been thinking about vpn tunneling.

> They will not be used for a normal lan.

With dir /local/bin/*_changes | wc -l
201
customization files I have more of a Frankenstein setup.

[David W. Hodgins]

On Tue, 20 Dec 2022 19:41:06 -0500, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Tue, 20 Dec 2022 17:56:14 -0500, David W. Hodgins wrote:
>> On Tue, 20 Dec 2022 16:54:27 -0500, Bit Twister <BitTw...@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

Hard to do when I received it in the same run of leafnode that the next article
was downloaded. It posts my replies, then downloads the new articles. :-)

>> Try the reboot, just to be sure.
>
> Need to wait for time mythtv is not recording shows.

Understood.

Regards, Dave Hodgins

[David W. Hodgins]

On Tue, 20 Dec 2022 21:42:57 -0500, Bit Twister <BitTw...@mouse-potato.com> wrote:
> 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.

If I want to disable it, I just rename it from whatever.network to
whatever.network.disabled, and systemd then ignores the file.

Regards, Dave Hodgins

[David W. Hodgins]

On Tue, 20 Dec 2022 19:56:55 -0500, Bit Twister <BitTw...@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.

Running "inxi -i" returns both the ipv4 and ipv6 public addresses.

Regards, Dave Hodgins

[Bit Twister]

On Tue, 20 Dec 2022 22:52:28 -0500, David W. Hodgins wrote:
> On Tue, 20 Dec 2022 19:56:55 -0500, Bit Twister <BitTw...@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

[David W. Hodgins]

The ipv4 address only.

Regards, Dave Hodgins

[Bit Twister]

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

[David W. Hodgins]

It's working now, returning my ipv6 address.
The sites that return ipv6 if you have it, return ipv4 if you don't.

If you don't have ipv6, the router will do nat translation for the ipv4
address and send it from your public ipv4 address. Because icanhazip
receives an ipv4 packet, it responds with the ipv4 address your router
sent it using.

If you do have ipv6, the router doesn't do any translation. It's sent
with your computer as the sender. The address returned is the address
of your computer, not the address of the router.

Regards, Dave Hodgins

[Marco Moock]

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).

[Bit Twister]

On Wed, 21 Dec 2022 09:16:38 +0100, Marco Moock wrote:
> 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.

Yep, my hourly cron ck_connection script showing plenty of DROP attempts
at my 4000+ port. :(
Thought if funny that they are from my mtv node, instead of my wb node,
since both are on the same WAN ip.

> 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).

Well that bites. Sounds like I can not have ssh port anywhere I want it
on the WAN side, and normal ssh port on the LAN side like my current set up.

[Bit Twister]

On Wed, 21 Dec 2022 03:07:52 -0500, David W. Hodgins wrote:
> On Wed, 21 Dec 2022 00:42:23 -0500, Bit Twister <BitTw...@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

What about that other site I gave? My updated results, from you, gets me

$ urls address ipv
curl http://icanhazip.com ! fetch get your internet/wan ip address ipv4/6
curl http://ident.me ! fetch get your internet/wan ip address ipv4/6
curl https://ipecho.net/plain ! fetch get your internet/wan ip address ipv4
curl http://whatismyip.akamai.com ! fetch get your internet/wan ip address ipv4
curl whatismyip.akamai.com ! fetch get your internet/wan ip address ipv4
wget -qO - http://icanhazip.com ! fetch get your internet/wan ip address ipv4/6
wget -qO - http://ident.me/ ! fetch get your internet/wan ip address ipv4/6
wget -qO - https://ipecho.net/plain ! fetch get your internet/wan ip address ipv4
wget -qO - http://smxi.org/opt/ip.php ! fetch get your internet/wan ip address ipv4
wget -qO - http://whatismyip.akamai.com ! fetch get your internet/wan ip address ipv4
http://www.iana.org/assignments/ipv4-address-space ! whois ip4 assignment lookup

And for any curious Lurkers
$ type urls
urls is hashed (/usr/local/bin/urls)

which is linked to /usr/local/bin/ux, a custom script, and a snippet from its header.
#* ux - search different files with user supplied keywords. Version 2.4
#*
#* basename is called to determine command and file to use.

Rather than keep internet sites in my browser bookmarks, I keep them in my urls file
which has
$ wc -l < /local/doc/urls
3918
urls.

Currently I have
dir /usr/local/bin | grep ux | wc -l
52
ux commands


FYI: MTV reboot failed to bring up the network. Had to run
systemctl restart network
to get LAN access.

I assume failure is because of my named zone problems. :-(

OH yeah, you get nothing returned from ip route or route n
if no LAN connection.