Recent posts

#1

25.7, 25.10 Series / Re: Hostwatch - high disk writ...

Last post by OPNenthu - Today at 12:23:05 AM

@franco I know you said the issue is clear, but I just hit it as well.  Adding a data point.

I don't know the trigger but I can tell you what I did before it happened.  My site-to-site wireguard tunnel wasn't working because an Unbound blocklist was blocking my DDNS provider, so I added that the subdomains I needed to the whitelist and got the tunnel working again.  Shortly after, the system memory spiked and top is showing the issue. 

Code Select Expand

last pid: 27749;  load averages:  2.25,  2.23,  1.85                                                              up 0+16:09:17  18:10:59
92 processes:  1 running, 91 sleeping
CPU: 39.2% user,  0.0% nice, 11.7% system,  0.0% interrupt, 49.1% idle
Mem: 4752M Active, 614M Inact, 26M Laundry, 1946M Wired, 401M Free
ARC: 1148M Total, 196M MFU, 754M MRU, 12M Anon, 20M Header, 163M Other
     835M Compressed, 2203M Uncompressed, 2.64:1 Ratio
Swap: 8192M Total, 8192M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
96386 hostd        20  20    0    94M    11M uwait    0  24:44  99.90% hostwatch
17017 root          5  21    0    65M    32M kqread   2  23:58  99.71% syslog-ng
92246 root          1  20    0    15M  3932K CPU1     1   0:00   0.14% top
58889 root          1  24    0    59M    33M nanslp   2   0:00   0.10% php
48741 nobody        1  20    0    17M  5504K select   0   0:02   0.06% dnsmasq
  520 root          4  68    0   121M    46M accept   3   0:47   0.05% python3.11
97534 root          1  20    0    23M    10M kqread   1   0:08   0.04% lighttpd

In addition, the symlink 'latest.log' disappeared, but the hostwatch service is not dead.

Code Select Expand

root@firewall:/var/log/hostwatch # ls -l
total 4032364
-rw-------  1 root wheel 4129140649 Jan 16 18:09 hostwatch_20260116.log


Note: I have two wireguard VPN gateways which were operational the whole time and didn't trigger this.

---

Resolution attempts:

1. Disable the WG instance & peer for the site-to-site tunnel
- No effect

2. Restart Unbound service
- No effect

3. Restart Host discovery service
- Restored the CPU to idle, but did not free used memory.  No change in iostat.

Code Select Expand

last pid: 93333;  load averages:  1.43,  2.06,  1.94                                                              up 0+16:17:01  18:18:43
98 processes:  1 running, 97 sleeping
CPU:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
Mem: 4851M Active, 552M Inact, 29M Laundry, 1911M Wired, 396M Free
ARC: 1108M Total, 198M MFU, 725M MRU, 760K Anon, 18M Header, 164M Other
     791M Compressed, 2139M Uncompressed, 2.70:1 Ratio
Swap: 8192M Total, 8192M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
57652 root          1  20    0    15M  3980K CPU0     0   0:00   0.16% top
85230 root          1  21    0    59M    33M nanslp   0   0:00   0.10% php
16847 root          1  20    0    24M  8112K select   3   0:07   0.07% ntpd
60180 root          1  20    0    14M  2976K bpf      1   0:00   0.06% filterlog
17017 root          3  20    0    67M    36M kqread   1  30:45   0.06% syslog-ng
  520 root          4  68    0   129M    45M accept   2   0:50   0.06% python3.11
97534 root          1  20    0    23M  9948K kqread   0   0:08   0.05% lighttpd
48741 nobody        1  20    0    17M  5624K select   2   0:03   0.03% dnsmasq


Code Select Expand

root@firewall:~ # iostat -x
                        extended device statistics 
device       r/s     w/s     kr/s     kw/s  ms/r  ms/w  ms/o  ms/t qlen  %b 
mmcsd0         0       0      0.0      0.0     0     0     0     0    0   0
mmcsd0bo       0       0      0.0      0.0     0     0     0     0    0   0
mmcsd0bo       0       0      0.0      0.0     0     0     0     0    0   0
nda0           2       9     20.5    238.7     0     0     2     1    0   1
pass0          0       0      0.0      0.0     0     0     0     0    0   0


#2

25.7, 25.10 Series / Re: 25.7.11_1 host discovery i...

Last post by wbennett - January 16, 2026, 11:50:55 PM

By default, discovery is configured on all interfaces. I tried restricting it to LAN only, but the service stops and won't restart. If I switch it back to all interfaces, it works without problems.

I am seeing the same. I tried restricting it to LAN and Wireguard and the service stops and won't restart.

#3

25.7, 25.10 Series / Re: Hostwatch - high disk writ...

Last post by pfry - January 16, 2026, 11:45:06 PM

Out of curiosity, what is considered a "movement", and what sort of errors would it log? Just trying to get a handle on the high writes. I don't see any notable change in write frequency on my own system, and it's the wacky four-bridge setup, where "Interfaces: Neighbors: Automatic Discovery" (by default) picks up every MAC on multiple interfaces. (I fired it up with default settings just to see if I could trigger the issue, as I don't use it normally; actual ARP mapping does not normally move, as I do not normally re-plug machines and I have static ARP entries to tame my ISP's unlimited proxy.)

#4

General Discussion / Re: Wireless Access Points

Last post by stanps - January 16, 2026, 11:39:23 PM

Fortunately many homes here are wired with coaxial for TV (antenna, satellite, and cable all use it) so I was able to use that with MoCA-Ethernet adapters.

+1 on MoCA-Ethernet!

#5

Zenarmor (Sensei) / Latest Zenarmor update breaks ...

Last post by Irishfluter - January 16, 2026, 11:13:51 PM

Hello.  Since Zenarmor updated to engine version 2.3.2 - Jan 12, 2026 9:56 AM, I am showing thousands of blocked Malware/Virus detections per day which I believe are false positives, and the Treatlife app is no longer working to control grouped Treatlife smart light bulbs, although individual bulb control does still work.

Verified by changing packet engine to Passive Mode (reporting only), which restores the group bulb control in the Treatlife app.

Thanks.

#6

25.7, 25.10 Series / Re: CALL FOR TESTING: IPv6 imp...

Last post by Maurice - January 16, 2026, 11:08:03 PM

Oh, I probably have to perform 2. (switch to development branch and apply patch) to see the IA_PD lifetime?

#7

25.7, 25.10 Series / Re: CALL FOR TESTING: IPv6 imp...

Last post by Maurice - January 16, 2026, 11:00:11 PM

you can see configured lifetimes in ifconfig and with -L switch you can see how much is left

On the WAN interface, ifconfig shows the lifetime of the interface address (IA_NA). But where do I see the lifetime of the prefix (IA_PD)? On the tracking LAN interface, ifconfig does not show a lifetime.

NA was setting vltime and pltime correctly

I can confirm this. IA_NA pltime is lower than vltime: inet6 2001:db8:6490:5d00::2 prefixlen 128 pltime 270 vltime 300

from my testing so far dhcp6c renews far more frequently than pltime

From my testing, dhcp6c renews after half of vltime. So as long as pltime > vltime/2, no problem.

The key thing here is that we want to see the ifconfig -L times so we can actually distinguish which prefix was the last one assigned and use that as the primary one for e.g. radvd. Some ISPs renew with a new prefix but having the first one stick around and no way to distinguish because they both do not expire was suboptimal and at some point the old one disappears but there is no renew triggering a radvd reload so then the prefix stops working for clients.

Excellent! This has plagued me a lot and the workarounds I had to implement are nightmare fuel.

I was a bit surprised to find all these related bugs for just trying to do what the standard intended.

Unfortunately, I'm not surprised at all.

Cheers
Maurice

#8

General Discussion / Re: Wireless Access Points

Last post by OPNenthu - January 16, 2026, 11:00:02 PM

The mesh works really well providing you make sure there's a good signal between the master and slave device. Preferably only slave one device to each wired master.

Hi @marjohn56, quick question about this: for the meshed APs, do WiFi clients still get to use the 5GHz band or are they forced back to 2.4GHz?

#9

25.7, 25.10 Series / Re: CALL FOR TESTING: IPv6 imp...

Last post by franco - January 16, 2026, 10:25:16 PM

Nice, you can see configured lifetimes in ifconfig and with -L switch you can see how much is left (actually found and fixed this switch for 25.7.11).

Note that dhcp6c sets vltime = pltime for prefixes.  It's all a bit odd that NA was setting vltime and pltime correctly but PD set infinite for both. To crawl towards a better solution we avoid deprecation of prefixes for now but from my testing so far dhcp6c renews far more frequently than pltime so in a next step we can probably set the real pltime too.

The key thing here is that we want to see the ifconfig -L times so we can actually distinguish which prefix was the last one assigned and use that as the primary one for e.g. radvd. Some ISPs renew with a new prefix but having the first one stick around and no way to distinguish because they both do not expire was suboptimal and at some point the old one disappears but there is no renew triggering a radvd reload so then the prefix stops working for clients.

I was a bit surprised to find all these related bugs for just trying to do what the standard intended.  ;)


Thanks a lot,
Franco

#10

25.7, 25.10 Series / Re: Hostwatch - high disk writ...

Last post by franco - January 16, 2026, 10:19:27 PM

It's supposed to log hardware address movements, but if it seems them constantly that is probably undesirable as logging. The issue is clear and we'll find a solution for it soon.


Cheers,
Franco