I have 3 computers connected using cat-5 and a small switch.
The computer kraken is running leap 15.1 patched as much as was possible.
Computers shrimp and crab are running leap 15.3 patched daily.

Here is a snippet of the /etc/hosts file:
# DHCP IP's, actually reserved, for the local beasties

192.168.1.4 clam
192.168.1.2 crab
192.168.1.6 kiwa0
192.168.1.7 kiwa1
192.168.1.9 kiwa2
192.168.1.8 kiwa3
192.168.1.10 kiwa4
192.168.1.3 kraken
192.168.1.5 shrimp

192.168.1.1 mudskipper

# Static IP's for the cat-5 critters
# c is crab, k is kraken, and s is shrimp

10.10.13.4 c
10.10.13.2 k
10.10.13.3 s

Here is the output from the route command, it's the same for all of the computers:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default mudskipper 0.0.0.0 UG 600 0 0 wlan0
10.10.13.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0

Using, the wlan0 interface, the commands ssh and rsync will connect/pass files
from crab, kraken, and shrimp without problems and in any combination of them.

Using, the eth0 interface, the computers k and s will ssh or rsync in either
direction. Neither will work with c. k and c were working until I rebooted c.

The computer c can ssh or rsync with either k or s without problem.

On 2021-08-06, Sidney_Kotic <kant@have.it> wrote:
> I have 3 computers connected using cat-5 and a small switch.
> The computer kraken is running leap 15.1 patched as much as was possible.
> Computers shrimp and crab are running leap 15.3 patched daily.
>
> Here is a snippet of the /etc/hosts file:
> # DHCP IP's, actually reserved, for the local beasties
>
> 192.168.1.4 clam
> 192.168.1.2 crab
> 192.168.1.6 kiwa0
> 192.168.1.7 kiwa1
> 192.168.1.9 kiwa2
> 192.168.1.8 kiwa3
> 192.168.1.10 kiwa4
> 192.168.1.3 kraken
> 192.168.1.5 shrimp
>
> 192.168.1.1 mudskipper
>
> # Static IP's for the cat-5 critters
> # c is crab, k is kraken, and s is shrimp
>
> 10.10.13.4 c
> 10.10.13.2 k
> 10.10.13.3 s

Sorry, I am having trouble. You mean you have two entries for crab,
kraken and shrimp? Your system will (try to ) use the first one.
I really have no idea what it is you are trying to do.

I would suggest that you give them different names on the two networks

>
> Here is the output from the route command, it's the same for all of the computers:
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> default mudskipper 0.0.0.0 UG 600 0 0 wlan0
> 10.10.13.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
> 192.168.1.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
>
> Using, the wlan0 interface, the commands ssh and rsync will connect/pass files
> from crab, kraken, and shrimp without problems and in any combination of them.
>
> Using, the eth0 interface, the computers k and s will ssh or rsync in either
> direction. Neither will work with c. k and c were working until I rebooted c.
>
> The computer c can ssh or rsync with either k or s without problem.

On 8/6/21 4:11 PM, William Unruh wrote:

Thanks for the reply. Let me see if I can clear up some confusion.

These are the relevant /etc/hosts entries.
>> 192.168.1.2 crab
>> 192.168.1.3 kraken
>> 192.168.1.5 shrimp

>> 10.10.13.4 c
>> 10.10.13.2 k
>> 10.10.13.3 s

All the 192.168.1.* hosts are on wlan0. All the 10.10.13.* hosts are on eth0.
So crab IS c depending on whether it's wlan0 or eth0. On wlan0 its IP is
192.168.1.2 (and that's how it gets to the internet) and on eth0 it uses
10.10.13.4 for an IP address.

> I really have no idea what it is you are trying to do.

I live in a building where there are WiFi routers everywhere. Right now I
could, if I had the correct password, use any one of the probably 20+ routers
the computers see, if I had to guess I'd say there are about 150 WiFi routers in
this building. All of those routers are fighting to use the same 2.4/5Ghz
frequencies. Heck when I had to get a replacement cable modem the company gave
me a new one that has a builtin WiFi router, meaning I have 2 WiFi routers
running (ironically they're wired together with a cable, probably on 192.168.0.*
network).
By using the eth0, an old switch, and cables, I can pass traffic between c, k,
and s without adding to the WiFi traffic. I often move large 1Gb to 2Gb files
between these 3 computers. WiFi network throughput is often abysmal.

> I would suggest that you give them different names on the two networks

They do have different names, and IP addresses on different interfaces.

To try and put it succinctly.
1. All the computers work on the wlan0/192.168.1.* network.
2. The hosts k and s work fine on the eth0/10.10.13.* network. So it works.
3. Neither hosts k or s can initiate a connect to host c on the eth0/10.10.13.*
network. This is the problem.
4. Host c can initiate connects to hosts k and s fine on the eth0/10.10.13.*
network. This is important as it shows the eth0 interface on host c does work.

On 2021-08-07, Sidney_Kotic <kant@have.it> wrote:
> On 8/6/21 4:11 PM, William Unruh wrote:
>
> Thanks for the reply. Let me see if I can clear up some confusion.
>
> These are the relevant /etc/hosts entries.
>>> 192.168.1.2 crab
>>> 192.168.1.3 kraken
>>> 192.168.1.5 shrimp
>
>>> 10.10.13.4 c
>>> 10.10.13.2 k
>>> 10.10.13.3 s
>
> All the 192.168.1.* hosts are on wlan0. All the 10.10.13.* hosts are on eth0.
> So crab IS c depending on whether it's wlan0 or eth0. On wlan0 its IP is
> 192.168.1.2 (and that's how it gets to the internet) and on eth0 it uses
> 10.10.13.4 for an IP address.

I understand that the computers are identical. But the names should not
be. It confuses the hell out of the system if one name as two separate
IP addresses (unless you really call them c,k, and s, but I was under
the impression that that was just your shorthand for crab, kraken and
shrimp.
Ie, are those actually your hosts entries, literally, or is c k and to
be read as crab kraken and shrimp? If it is literally c k and s then
that is fine, but then you also have to call them as c k and s, not as
crab, kraken and shrimp

>
>> I really have no idea what it is you are trying to do.
>
> I live in a building where there are WiFi routers everywhere. Right now I
> could, if I had the correct password, use any one of the probably 20+ routers
> the computers see, if I had to guess I'd say there are about 150 WiFi routers in
> this building. All of those routers are fighting to use the same 2.4/5Ghz
> frequencies. Heck when I had to get a replacement cable modem the company gave
> me a new one that has a builtin WiFi router, meaning I have 2 WiFi routers
> running (ironically they're wired together with a cable, probably on 192.168.0.*
> network).
> By using the eth0, an old switch, and cables, I can pass traffic between c, k,
> and s without adding to the WiFi traffic. I often move large 1Gb to 2Gb files
> between these 3 computers. WiFi network throughput is often abysmal.
>
>> I would suggest that you give them different names on the two networks
>
> They do have different names, and IP addresses on different interfaces.
>
> To try and put it succinctly.
> 1. All the computers work on the wlan0/192.168.1.* network.

Under what names?

> 2. The hosts k and s work fine on the eth0/10.10.13.* network. So it works.

Under what name

> 3. Neither hosts k or s can initiate a connect to host c on the eth0/10.10.13.*
> network. This is the problem.

Are you sure that there is not some other machine with IP
10.10.13.4?

Are you sure that the answers are not sent on the wlan0 line?

> 4. Host c can initiate connects to hosts k and s fine on the eth0/10.10.13.*
> network. This is important as it shows the eth0 interface on host c does work.

> Ie, are those actually your hosts entries, literally, or is c k and to
> be read as crab kraken and shrimp? If it is literally c k and s then
> that is fine, but then you also have to call them as c k and s, not as
> crab, kraken and shrimp

Those are the host names. c, crab, k, kraken, s, and shrimp. Each host name has
a unique IP assigned to it. Not to be snippy about it...but I retired in 2002
as a sysadmin taking care of 40 or 50 machines, a dozen were SUN Sparc servers
running Solaris. They all had two network cards, one to talk to client
machines, and one so the servers could talk to each other. So I've set this up
before. Once upon a time I had a BSD machine at home running two cards (it was
a firewall and did NAT [IP masquerading back in the old days, who knows what the
latest term is], one to the ISP and the other to several linux machines behind it.

>> 1. All the computers work on the wlan0/192.168.1.* network.
>
> Under what names?

For that network they are crab, kraken, and shrimp.

>> 2. The hosts k and s work fine on the eth0/10.10.13.* network. So it works.
>
> Under what name

For that network c, k, and s.

> Are you sure that there is not some other machine with IP
> 10.10.13.4?

My networks, I assigned the IP addresses and names.

> Are you sure that the answers are not sent on the wlan0 line?

Can't see how. wlan0 talks to a WiFi router which passes it's traffic on up to
the network the cable company runs. I ran wireshark on c and saw the broadcast
traffic from the switch asking who had 10.10.13.4 when I tried to "ssh bill@c"
from k, and k ended up with an ARP cache entry for c on eth0.

On 07/08/2021 05.49, Sidney_Kotic wrote:
> On 8/6/21 4:11 PM, William Unruh wrote:
>
> Thanks for the reply.  Let me see if I can clear up some confusion.
>
> These are the relevant /etc/hosts entries.
>>> 192.168.1.2     crab
>>> 192.168.1.3     kraken
>>> 192.168.1.5     shrimp
>
>>> 10.10.13.4      c
>>> 10.10.13.2      k
>>> 10.10.13.3      s
>
> All the 192.168.1.* hosts are on wlan0.  All the 10.10.13.* hosts are on
> eth0.
> So crab IS c depending on whether it's wlan0 or eth0.  On wlan0 its IP
> is 192.168.1.2 (and that's how it gets to the internet) and on eth0 it
> uses 10.10.13.4 for an IP address.
>
>> I really have no idea what it is you are trying to do.
>
> I live in a building where there are WiFi routers everywhere.  Right now
> I could, if I had the correct password, use any one of the probably 20+
> routers the computers see, if I had to guess I'd say there are about 150
> WiFi routers in this building.  All of those routers are fighting to use
> the same 2.4/5Ghz frequencies.  Heck when I had to get a replacement
> cable modem the company gave me a new one that has a builtin WiFi
> router, meaning I have 2 WiFi routers running (ironically they're wired
> together with a cable, probably on 192.168.0.* network).
> By using the eth0, an old switch, and cables, I can pass traffic between
> c, k, and s without adding to the WiFi traffic.  I often move large 1Gb
> to 2Gb files between these 3 computers.  WiFi network throughput is
> often abysmal.
>
>> I would suggest that you give them different names on the two networks
>
> They do have different names, and IP addresses on different interfaces.
>
> To try and put it succinctly.
> 1.  All the computers work on the wlan0/192.168.1.* network.
> 2.  The hosts k and s work fine on the eth0/10.10.13.* network.  So it
> works.
> 3.  Neither hosts k or s can initiate a connect to host c on the
> eth0/10.10.13.* network.  This is the problem.
> 4.  Host c can initiate connects to hosts k and s fine on the
> eth0/10.10.13.* network.  This is important as it shows the eth0
> interface on host c does work.

I would suggest that there is some difference in the routing table of c.
We tend to see what should be there instead of what is actually there.

So print ifconfig and route output in all three computers.

Perhaps the problem could be in name solving, so try using IP numbers
instead.

Another clue would be switching off the wifi temporarily to see what
changes.

--
Cheers,
Carlos E.R.

> I would suggest that there is some difference in the routing table of c.
> We tend to see what should be there instead of what is actually there.

To paraphrase Simon & Garfunkel from The Boxer...
"Still, a man sees what he wants to see and disregards the rest."
The real lyrics say "hear" instead of "see".

I looked at the output from all 3 computers for the ip a and route commands.
The only differences, aside from the expected, are kraken using wlan1 and the
altname being missing from kraken. Recall that kraken is running on 15.1 and
several years ago you helped me get this interface working on what was then
fairly new hardware. Seems like someone had to patch the module in order to get
it to load under openSUSE, I spent quite a bit of time loading openSUSE and then
Ubuntu (maybe it was Debian or RedHat) and comparing the results of the various
commands.

Now, having said the above, I've fixed it temporarily. It's working. But as
soon as I reboot crab it stops working.

The, not so very good, fix is:
Yast --> Services Manager --> firewalld
After boot it's "Inacive(dead)" for some reason. It's defined to start "On
Boot". The computer crab is the only one not having a firewalld running, it's
also the only one which will not accept an inbound connect.
After manually starting it the eth0 connects work, until a reboot.

On 07/08/2021 20.12, Sidney_Kotic wrote:
>> I would suggest that there is some difference in the routing table of c.
>> We tend to see what should be there instead of what is actually there.
>
> To paraphrase Simon & Garfunkel from The Boxer...
> "Still, a man sees what he wants to see and disregards the rest."
> The real lyrics say "hear" instead of "see".
>
> I looked at the output from all 3 computers for the ip a and route
> commands. The only differences, aside from the expected, are kraken
> using wlan1 and the altname being missing from kraken.  Recall that
> kraken is running on 15.1 and several years ago you helped me get this
> interface working on what was then fairly new hardware.  Seems like
> someone had to patch the module in order to get it to load under
> openSUSE, I spent quite a bit of time loading openSUSE and then Ubuntu
> (maybe it was Debian or RedHat) and comparing the results of the various
> commands.
>
> Now, having said the above, I've fixed it temporarily.  It's working. 
> But as soon as I reboot crab it stops working.
>
> The, not so very good, fix is:
> Yast --> Services Manager --> firewalld
> After boot it's "Inacive(dead)" for some reason.  It's defined to start
> "On Boot".  The computer crab is the only one not having a firewalld
> running, it's also the only one which will not accept an inbound connect.
> After manually starting it the eth0 connects work, until a reboot.

Oh.

--
Cheers,
Carlos E.R.

On 2021-08-07, Sidney_Kotic <kant@have.it> wrote:
>> I would suggest that there is some difference in the routing table of c.
>> We tend to see what should be there instead of what is actually there.
>
> To paraphrase Simon & Garfunkel from The Boxer...
> "Still, a man sees what he wants to see and disregards the rest."
> The real lyrics say "hear" instead of "see".
>
> I looked at the output from all 3 computers for the ip a and route commands.
> The only differences, aside from the expected, are kraken using wlan1 and the
> altname being missing from kraken. Recall that kraken is running on 15.1 and
> several years ago you helped me get this interface working on what was then
> fairly new hardware. Seems like someone had to patch the module in order to get
> it to load under openSUSE, I spent quite a bit of time loading openSUSE and then
> Ubuntu (maybe it was Debian or RedHat) and comparing the results of the various
> commands.
>
> Now, having said the above, I've fixed it temporarily. It's working. But as
> soon as I reboot crab it stops working.
>
> The, not so very good, fix is:
> Yast --> Services Manager --> firewalld
> After boot it's "Inacive(dead)" for some reason. It's defined to start "On
> Boot". The computer crab is the only one not having a firewalld running, it's
> also the only one which will not accept an inbound connect.
> After manually starting it the eth0 connects work, until a reboot.

If you are running systemd, then your firewall startup script is not set
to run on boot. If you are using sysV then your /etc/init.d firewall
script is not set to start up.
And at least some firewall software is set up to reject everything by
default.

On 8/7/21 2:49 PM, William Unruh wrote:

> If you are running systemd, then your firewall startup script is not set
> to run on boot.

This is probably what's happening. Since the /etc/init.d directories are all empty.

In which case I can plead complete ignorance of systemd, I was raised in the
world of init.d (I still use vi as a text editor), and how to configure things
in it. Could you give me pointers about what I need to change?

> And at least some firewall software is set up to reject everything by
> default.

Which makes sense.

----------------
To make the day more enjoyable apparently some of the hardware in crab went
south. wlan0 will not work. dmesg shows me multiple messages saying:
rtl8821ae: Init MAC failed
So as a workaround I've plugged in a USB WiFi adapter that I had laying around
in the back of the desk drawer and brought it up as wlan1. The IP address for
crab has changed to 192.168.1.12, but I can fix all those problems if this ends
up a permanent configuration.

On 2021-08-08, Sidney_Kotic <kant@have.it> wrote:
> On 8/7/21 2:49 PM, William Unruh wrote:
>
>> If you are running systemd, then your firewall startup script is not set
>> to run on boot.
>
> This is probably what's happening. Since the /etc/init.d directories are all empty.
>
> In which case I can plead complete ignorance of systemd, I was raised in the
> world of init.d (I still use vi as a text editor), and how to configure things
> in it. Could you give me pointers about what I need to change?

The systemd stuff is in /lib/systemd
Many of those are service files.
I do not know what the firewall software is on Suse, so cannot suggest
which to enable.

>
>> And at least some firewall software is set up to reject everything by
>> default.
>
> Which makes sense.
>
> ----------------
> To make the day more enjoyable apparently some of the hardware in crab went
> south. wlan0 will not work. dmesg shows me multiple messages saying:
> rtl8821ae: Init MAC failed
> So as a workaround I've plugged in a USB WiFi adapter that I had laying around
> in the back of the desk drawer and brought it up as wlan1. The IP address for
> crab has changed to 192.168.1.12, but I can fix all those problems if this ends
> up a permanent configuration.

On 08/08/2021 07.25, Sidney_Kotic wrote:
> On 8/7/21 2:49 PM, William Unruh wrote:
>
>> If you are running systemd, then your firewall startup script is not set
>> to run on boot.
>
> This is probably what's happening.  Since the /etc/init.d directories
> are all empty.

Yes, of course openSUSE uses systemd only.

> In which case I can plead complete ignorance of systemd, I was raised in
> the world of init.d (I still use vi as a text editor), and how to
> configure things in it.

You must learn the basics of systemd. It is quite easy.

>  Could you give me pointers about what I need to
> change?

The first thing to find out is why the firewall failed to start. Very
probably it tries to start and fails for some reason. The command is:

systemctl status firewalld

It should say

loaded: ... enabled
active: active

Yours will probably say different, so copy it here. If not, issue:

systemctl --now enable firewalld

and then ask for status. If it fails, then you need to find out why:

journalctl

--
Cheers,
Carlos E.R.

On 8/8/21 12:40 AM, Carlos E. R. wrote:

> Yours will probably say different, so copy it here. If not, issue:

crab:~ # systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor
preset: disabled)
Active: inactive (dead)
Docs: man:firewalld(1)

> systemctl --now enable firewalld

This did bring it up.

> and then ask for status. If it fails, then you need to find out why:
>
> journalctl

I went through that, as best as I could. Here are all of the entries dealing
with the firewalld from a reboot up to the time I logged back in and issued the
enable command above:

Aug 08 08:28:34 crab systemd[1]: Starting SuSEfirewall2 phase 1...
Aug 08 08:28:34 crab systemd[1]: Condition check resulted in YaST2 Second Stage
being skipped.
Aug 08 08:28:34 crab systemd[1]: Condition check resulted in YaST2 Firstboot
being skipped.

Aug 08 08:28:36 crab SuSEfirewall2[1024]: Firewall rules set to CLOSE.
Aug 08 08:28:36 crab systemd[1]: Finished SuSEfirewall2 phase 1.

Aug 08 08:28:38 crab systemd[1]: Starting SuSEfirewall2 phase 2...

Aug 08 08:28:44 crab SuSEfirewall2[1365]: Firewall rules successfully set
Aug 08 08:28:44 crab systemd[1]: Finished SuSEfirewall2 phase 2.

Not much to see there. Nothing that tells me why it wasn't started. Where, in
the filesystem, would I look to see how systemd should do that?

On 08/08/2021 19.39, Sidney_Kotic wrote:
> On 8/8/21 12:40 AM, Carlos E. R. wrote:
>
>> Yours will probably say different, so copy it here. If not, issue:
>
> crab:~ # systemctl status firewalld
> ● firewalld.service - firewalld - dynamic firewall daemon
>      Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled;
> vendor preset: disabled)
>      Active: inactive (dead)
>        Docs: man:firewalld(1)
>
>> systemctl --now enable firewalld
>
> This did bring it up.
>
>> and then ask for status. If it fails, then you need to find out why:
>>
>> journalctl
>
> I went through that, as best as I could.  Here are all of the entries
> dealing with the firewalld from a reboot up to the time I logged back in
> and issued the enable command above:
>
> Aug 08 08:28:34 crab systemd[1]: Starting SuSEfirewall2 phase 1...
> Aug 08 08:28:34 crab systemd[1]: Condition check resulted in YaST2
> Second Stage being skipped.
> Aug 08 08:28:34 crab systemd[1]: Condition check resulted in YaST2
> Firstboot being skipped.
>
> Aug 08 08:28:36 crab SuSEfirewall2[1024]: Firewall rules set to CLOSE.
> Aug 08 08:28:36 crab systemd[1]: Finished SuSEfirewall2 phase 1.
>
> Aug 08 08:28:38 crab systemd[1]: Starting SuSEfirewall2 phase 2...
>
> Aug 08 08:28:44 crab SuSEfirewall2[1365]: Firewall rules successfully set
> Aug 08 08:28:44 crab systemd[1]: Finished SuSEfirewall2 phase 2.
>
> Not much to see there.  Nothing that tells me why it wasn't started. 
> Where, in the filesystem, would I look to see how systemd should do that?

I see a possible problem: SuSEfirewall2 also tries to start, and
conflicts with firewalld.

So check both:

systemctl status firewalld
systemctl status SuSEfirewall2

The second should be disabled and stopped. If not, then "--now disable"

--
Cheers,
Carlos E.R.

On Sun, 8 Aug 2021 09:39:39 -0800, Sidney_Kotic wrote:
>
> Aug 08 08:28:44 crab SuSEfirewall2[1365]: Firewall rules successfully set
> Aug 08 08:28:44 crab systemd[1]: Finished SuSEfirewall2 phase 2.
>
> Not much to see there. Nothing that tells me why it wasn't started. Where, in
> the filesystem, would I look to see how systemd should do that?

Systemd Unit files control unit operation. Unless configured otherwise
information is written into the journal file and can be viewed via journalctl.
As root run, systemctl list-units --type=service | grep fail

Adding the systemd-journal group to your login id, log out/in will allow you to view
the system journal information without having to be root.

man journalctl for journalctl usage.

if looking for firewall messages I would try
journalctl | grep -i firewall

Want to see how systemd usees unit files:
systemd-analyze plot > /var/tmp/blame.svg
firefox /var/tmp/blame.svg &

On 2021-08-08, Sidney_Kotic <kant@have.it> wrote:
> On 8/8/21 12:40 AM, Carlos E. R. wrote:
>
>> Yours will probably say different, so copy it here. If not, issue:
>
> crab:~ # systemctl status firewalld
> ● firewalld.service - firewalld - dynamic firewall daemon
> Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor
> preset: disabled)
Note that the vendor (SUSE) set up the system so that the firewall was
disabled.

> Active: inactive (dead)
> Docs: man:firewalld(1)
>
>> systemctl --now enable firewalld
>
> This did bring it up.
>
>> and then ask for status. If it fails, then you need to find out why:
>>
>> journalctl
>
> I went through that, as best as I could. Here are all of the entries dealing
> with the firewalld from a reboot up to the time I logged back in and issued the
> enable command above:
>
> Aug 08 08:28:34 crab systemd[1]: Starting SuSEfirewall2 phase 1...
> Aug 08 08:28:34 crab systemd[1]: Condition check resulted in YaST2 Second Stage
> being skipped.
> Aug 08 08:28:34 crab systemd[1]: Condition check resulted in YaST2 Firstboot
> being skipped.
>
> Aug 08 08:28:36 crab SuSEfirewall2[1024]: Firewall rules set to CLOSE.
> Aug 08 08:28:36 crab systemd[1]: Finished SuSEfirewall2 phase 1.
>
> Aug 08 08:28:38 crab systemd[1]: Starting SuSEfirewall2 phase 2...
>
> Aug 08 08:28:44 crab SuSEfirewall2[1365]: Firewall rules successfully set
> Aug 08 08:28:44 crab systemd[1]: Finished SuSEfirewall2 phase 2.
>
> Not much to see there. Nothing that tells me why it wasn't started. Where, in
> the filesystem, would I look to see how systemd should do that?

The above just says it started, presumably because you told it to start
(systemctl --now enable firewall)
Presumably it was not enabled for startup. and thus nothing was enetered
into the logs because it never tried to start it up then.

On 8/8/21 10:05 AM, Carlos E. R. wrote:

> I see a possible problem: SuSEfirewall2 also tries to start, and
> conflicts with firewalld.
>
> So check both:
>
> systemctl status firewalld
> systemctl status SuSEfirewall2

Went back into yast and set the SuSEfirewall2 stuff to start manually. Left
firewalld to start at boot.

Rebooted and things look fine.

On 8/8/21 10:15 AM, Bit Twister wrote:

> Want to see how systemd usees unit files:
> systemd-analyze plot > /var/tmp/blame.svg
> firefox /var/tmp/blame.svg &

That is interesting. I'll have to study that output for a while.

On 08/08/2021 22.13, Sidney_Kotic wrote:
> On 8/8/21 10:05 AM, Carlos E. R. wrote:
>
>> I see a possible problem: SuSEfirewall2 also tries to start, and
>> conflicts with firewalld.
>>
>> So check both:
>>
>> systemctl status firewalld
>> systemctl status SuSEfirewall2
>
> Went back into yast and set the SuSEfirewall2 stuff to start manually. 
> Left firewalld to start at boot.
>
> Rebooted and things look fine.

My recommendation, unless you have a previous configuration in
SuSEfirewall2, just uninstall it.

The two programs conflict. The conflict is not automatic, because there
are people like me with configuration of SuSEfirewall2 going back to
decades, who need both tools in order to do a migration. Thus YaST, for
the moment, allows you to set both to start, or to set one to start
manually. But this generates a conflict if they actually both try to run.

So, set SuSEfirewall2 to run "never", or just do:

systemctl --now disable SuSEfirewall2

And even better, uninstall it. And do the same on all your machines
running Leap 15.* or Tumbleweed.

--
Cheers,
Carlos E.R.

Am 08.08.21 um 20:29 schrieb William Unruh:
> On 2021-08-08, Sidney_Kotic <kant@have.it> wrote:
>> On 8/8/21 12:40 AM, Carlos E. R. wrote:
>>
>>> Yours will probably say different, so copy it here. If not, issue:
>>
>> crab:~ # systemctl status firewalld
>> ● firewalld.service - firewalld - dynamic firewall daemon
>> Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor
>> preset: disabled)
> Note that the vendor (SUSE) set up the system so that the firewall was
> disabled.
>

Nope. Standard setup is ALWAYS firewall enabled. That "vendor preset" is
the preset from installation (and changed by you)