Last millennium we talked like this:
https://en.wikipedia.org/wiki/Control-Alt-Delete

please use code tag.

Right. One reason for that kind of effect is when different devices happen to share macaddress. But, does your latop invent new macaddress when it reboots? (I know that some people regard macaddresses to be part of the user's "online fingerprint" and therefore invent obfuscations that involve changing macaddress especially of their uplink interfaces)

Did you check whether arp messages are received on the laptop (from any problem device)? As you probably know the IP level messaging (such as icmp) involves prior "arp" messaging where devices "learn" the relationships between IP addresses and MAC addresses. The ping requestor and responder both need to fill their arp tables with such associations, though separately and individually, before being able to send their icmp messages.

If there is holdup at that level (or any kind of interference by the router in that messaging) then the effect is the one typically voiced as "machine A cannot ping machine B".

In the phone+frame cases you can only check the arp messaging on the laptop, and then focus on arp requests (about the laptop IP) from those devices. The laptop should receive them and should reply to them. Receiving and not replying puts the problem firmly at the laptop, whereas "not receiving" as well as "receiving and replying" puts the problem back onto the network.

ok. I believe netbsd uses pf (maybe short for packet filter?) for firewalling... it's the same as iptables but totally different In particular, its commands are different, and as I remember pf are set up in a certain order, and the later rules override the earlier ones.

I'll have to browse a bit to be able to say things about it. However, it looks to me like the server (192.168.1.4) has firewall rules that blocks its traffic to the laptop (192.168.1.17). Unless it has some kernel flag(s) to stop it responding to icmp requests. I would guess netbsd has different commands for sysctl too(?)

no that's not ping reqeust or response; that's ssh packets. Try using

tcpdump -n -i wlan0 icmp

to focus on icmp packets only. And please copy the exact responses rather than "like this" copying.

By this it indicates that the ping requests don't arrive at the server.

How about ping -n 9.9.9.9 from the laptop; does that get proper response? This test is only for verifying that packets from the laptop can go to and from the router. If that is the case, you will need to reconsider the router configuration.

Presumably it does have some isolation between LAN devices or device groups.

As you may know all (almost) network messaging comes in pairs with outbound packets getting inbound responses. I use tcpdump to look at that to show what happens on an interface, like:

tcpdump -n -i wlan0

to see packets in to and out from wlan0 without attempting "reverse dns" on them (i.e. see IP addresses rather than domain names).

You do that in one terminal while using an other terminal for trying things like ping. The best is if you can do the same on the target host, to see where the messages hold-up may be. Note that for ipv4 it is essential that "arp" messaging move freely; the hosts use that so as to learn the ethernet addresses of LAN devices. All networking is carried by the link-level LAN connectivity, which uses the ethernet addresses or broadcasts (i.e. address ff:ff:ff:ff:ff:ff plus the broadcast flag bit set). 

In your case, I do suspect your router. I think that most routers have "broadcast groups" where they only forward broadcast messages to interfaces within the group of the interface where the messages come in. Which router do you have -- brand and version "number"? (with that we can probably find its instruction book on the Internet)

Routers may also have limitations on number of connected devices.

I have no idea what the synaptics program does.

At a guess you have setup multiarch (perhaps an amd64 machine with arm64 as foreign architecture) and librewolf have published different most recent versions of their package in those architectures. To solve that "normally" you'd add an attribute like "[arch=amd64]" for the repository line, making it be like

deb [arch=amd64] http://repo.librewolf.net librewolf main

Doing so would focus that repository line to apply for the nominated architecture only. (Use a comma separated value list to nominate more architectures)

But that's all guess work.

Yes it sounds like the installation (not liveCD) has something wrong.

Does it have a firewall? e.g. does iptables-save report something; (or if you use nftables there would be a similar command among its programs). And use ip6tables-save for ipv6 rules. (I'm not sure about the nftables commands)

Is the interface up? ifconfig wlan0 would be the easiest, if you have net-tools installed. An you'd also check with ip link show dev wlan0 and ip address show dev wlan0. The ip command comes from the iproute2 package.

Is there a default route? ip route show ... and checking ipv6: ip -6 route show

Hmm but if understand right, the laptop does have other internet access... anyhow, please include the outputs of those commands and we'll see if there's something to see there.

No, service management should not be a brick because it needs openness and flexibility. In my mind, my words were rather an attempt to explain why one might raise the questions you raised; my view is that a service management system needs to be open and flexible in order to be useful in a multitude of circumstances.

Are you seeking answers really, or are you seeking questions? Don't you wish to come to conclusions about those questions you ask, or do you prefer to side step and ask similar or new questions about other sub systems? Why don't you focus on individual functions. such as partitioning or file manager or keyboard mapping?

It could.

yes it adds overhead; every block access needs to go through the mapping tables.

Well "Devuan" is actually like a warehouse of software rather than a particular distribution so it all depends on which particular setup you want to have. The most recent "excalibur netinstall", which provides a range of distribution choices with the most recent software, will want at least 800 Mb RAM to run and would comfortably install most of its graphical desktop environments on an 8 Gb disk. Though, today one will want at least 20 Gb disk to be somewhat "future proof".

Almost all software is compiled for several architectures, including both 32-bit and 64 architectures. In debian parlance they have names like i386, amd64, armel, armhf, arm64, risc64, ppc64el etc.

The keyword is "Choice".