You are not logged in.
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(?)
Offline
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.
I would guess netbsxd has different commands for sysctl too(?)
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?
Offline
Well, you did report the ping request going out from the laptop, and also arriving to the server, but there was no response message out from the server and in to the laptop. Other than for that I agree with you that it appears the Devuan installation on the laptop makes this happen. Especially since the laptop seems invisible to all other systems.
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
Offline
Well, now we're really stuck. Seems that overnight things have "resolved" between the server and the laptop. I'm able to ping it and it can ping me. Also, my other system is able to ping and connect to an example HTTP server on the laptop. While this might seem like the entire thing is fixed, it isn't. I still can't ping my phone, my wife's phone and my digital picture frame (which is just a raspberry pi). My phone and the picture frame both can't ping the laptop. Basically the same situation but with different devices. While I generally don't ever need to ping these or ssh out into them it still shows there is a problem. I can't get any information from my phone as I don't have the device rooted. I can, however, maybe get something from the picture frame. It's an old first generation RPI but we'll see what I get.
Offline
Try drawing up a table with a line for every device on your LAN (including the router) with the following entries:
IP_address pingable_from_laptop(y/n) Connection_to_lan(wired or wireless) what_it_is OS
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.
Offline
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.
Offline