But, does your latop invent new macaddress when it reboots?

Unless this is the Devuan default, then no. It is a fully encrypted disk but I doubt that's related.

Nope, if I watch for arp messages while attempting to ping from my phone nothing ever shows up. However, if I boot into a liveCD with the same IP (192.168.1.17) I do get the arp messages and the ping works.

At any rate, since this seems to only happen on this current Devuan install I'll likely try a reinstall and see if that fixes it. Even the distro I had on this laptop before this one didn't have the issue so I'm assuming it's something that got messed up during installation or a bug.

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.

Then see if you can see any pattern to which can be pinged. And look for other oddities such as duplicate IP addresses. If still stuck post the table here.

Let's try this experiment: with the laptop running Devuan doing ping -n 192.168.1.4, check both the icmp and arp messages on the server. There should at least be arp messages from the server where it attempts to determine the macaddress for the host having 192.168.1.17. You should then also at the same time check for arp messages to the laptop.

Make sure you get both IP addresses and mac addresses of all messages. And report them here.

Also, please include output of

sysctl net.ipv4.conf.all | grep arp

I believe netbsd uses pf (maybe short for packet filter?) for firewalling...

pf(4) was deprecated. We now use the shiny new (since NetBSD 8 that is...) npf(7) xD Anyways, when I run npfctl show, which will show the current filter state and config I get:

# filtering:    inactive
# config:      empty

Regardless, I don't think that it has anything to do with the server as no systems on the entire network can ping the laptop. Even if I open a hotspot on my phone, join it along with another computer/phone I can't ping it.

To be frank, I don't actually know the freelist.org(?)/linux sysctl program pretty much at all. Giving the man page for the linux sysctl and it looks completely different than the NetBSD one. If you tell me what I need to look for I can probably find it, however.

I just did another test where I booted into a liveCD of a different distro on the laptop and I was able to ping the server and I was able to ping the laptop (booted into the liveCD) from another computer. What was particularly important about this test was that the IP address of the liveCD was 192.168.1.17. I think this pretty much rules out that it's a router or a server issue. Seems to me that there might be a bug in the devuan network stack?

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

There is also a ipv6 table as well, if you need it.

EDIT: I ran netstat -r (to view the routing tables) when I was attempting to ping the server from the laptop. Hence why we see the 192.168.1.17 in the table. If I'm not pinging it, I don't see the IP in the table.

Perhaps it's routing is off? Use ip r to check the default routing table... though if you have source based routing or something, the server might have many routing tables, and then you may need to use ip r show table all to see them all.

Note: that;s on the server and not the laptop.

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

Yes, works fine.

Haha, my mistake. I mistook 27 for 17 as the laptop's address is currently 192.168.1.17. I'll try it again.

listening on genet0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:05:47.900289 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 1, length 64
02:05:48.913712 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 2, length 64
02:05:49.995650 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 3, length 64
02:05:50.924072 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 4, length 64
02:05:51.925312 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 5, length 64
02:05:52.957950 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 6, length 64
02:05:53.964533 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 7, length 64
02:05:54.988505 IP 192.168.1.17 > 192.168.1.4: ICMP echo request, id 29541, seq 8, length 64

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.

since you don't have the same issues when using a _livecd/dvd/usb_ (no tailscale)

you'll need to know what tailscale has done and that might depend on how you installed tailscale.

No, it still happens when I turn off tailscale completely. It is possible that maybe tailscale broke something during installation as is suggested with the script you posted.

Sorry, I'm not sure why I assumed that orbi32 was the actual router name, it isn't. It's this one: https://www.netgear.com/support/product/rbr750/

The entire network is on 192.168.1.*, so I'm not sure about your second question. The only pattern that I see (that isn't really a pattern) is that 2 out of the 4-5 devices that I can't ping run NetBSD. However, I am able to ping my NetBSD laptop. Both of the other NetBSD systems are plugged into Ethernet. That being said, we'd almost have a pattern except for the fact that the rest of the devices that I can't ping both are linux systems (or so I assume) as one is my android phone and the other is out LG webOS TV, which back in the Palm/HP days ran linux. I can't remember what the last one is but there's a 99% chance it's a linux system.

Nope. None of the systems that the laptop can ping can ping it back. This was also seen when my friends came over for a LAN party and I attempted to use the laptop as the host... No one could connect. 2 of them were using macOS, 1 windows, and 1 linux (nixOS).

Yes, I was able to. I can't easily get you the log of the output but I can clearly see the ping making it to the server from and then the server responding to the ping. Here's what it kinda looks like:

${date} IP 192.168.1.27.65531 > 192.168.1.4.ssh: Flags [P.], seq 8065.8191, ack 110932, win 4197, optinos [nop,nopTS val 343 ecr342], langth 36
${date} IP 192.168.1.4.ssh > 192.168.1.27.65531: Flags [P.], seq 110932:110968, ack 81801, win 4197, options [nopnop,TS val 342 ecr 343]

From what I can tell, the ping is making it to the server but the server is failing to reply. Which tells me that there is something wrong with how this laptop is receiving data! We might be on to something...

Is there any pattern to which systems respond to ping from the laptop. Eg does it work for systems connected wirelessly but not ones with a wired connection? Do their IP addresses have any pattern (eg 192.168.1,* work but 192.168.0.* don't)?

Does the laptop respond to pings from other systems? If so does it respond to all the systems you can ping from?

you'll need to know what tailscale has done and that might depend on how you installed tailscale.

perhaps see this for possible clues:

https://github.com/tailscale/tailscale/blob/main/scripts/installer.sh

also wasn't able to find "orbi32" at:

https://www.netgear.com/support/product/orbi/

but maybe it is eos:

https://www.netgear.com/about/eos/

other links of possible interest to future forum/thread visitors:

https://www.netgear.com/home/services/orbilogin/
https://www.netgear.com/home/services/orbi-app/