Messages

I received an email this morning regarding the release of ZenArmor 2.1. Could you please confirm whether any action is required on my part to install the update? It doesn't appear to have upgraded automatically.

Additionally, does this release include the long-awaited multi-core / multi-thread support?

The nvm update tool offers the -rd option to reset user settings. However, the documentation doesn't clearly explain what this does. Would using this option be beneficial? My assumption is that it might remove manufacturer-specific tweaks and return the device to a more stock configuration, but I'm not certain.

You can also enable the autotrim property in zfs itself:

Code Select Expand

zpool set autotrim=on zroot
Of course scheduling with cron has the benefit of being able to plan when it happens, away from other i/o-intensive jobs, although I have never seen it take more than a few minutes at the very most.

Have you tried rebooting after toggling udp/raw? I found out it sometimes didn't reload the associated firewall rules automatically after a change.

The new 2.0 release of ZenArmor contains bugs that make it unreliable for my setup. Is there a way to install an older version and prevent it from being upgraded automatically during system updates?

Same here. I have increased ring_num to 1024, not running Suricata, and ZA crashes within hours. Even sooner when I do any performance testing. I have temporarily uninstalled ZA as to have a fresh start when a fix is released (have been running 2.1 alpha releases as well).

I'm getting this sequence of warnings, and it's always the same duid:

Code Select Expand

WARN [kea-dhcp6.alloc-engine.0x1340fa505700] ALLOC_ENGINE_V6_ALLOC_FAIL_CLASSES duid=[00:03:00:01:da:c5:77:4c:86:f0], [no hwaddr info],
tid=0x41270a: Failed to allocate an IPv6 address for client with classes: ALL, UNKNOWN
WARN [kea-dhcp6.alloc-engine.0x1340fa505700] ALLOC_ENGINE_V6_ALLOC_FAIL_NO_POOLS duid=[00:03:00:01:da:c5:77:4c:86:f0], [no hwaddr info],
tid=0x41270a: no pools were available for the lease allocation
WARN [kea-dhcp6.alloc-engine.0x1340fa505700] ALLOC_ENGINE_V6_ALLOC_FAIL_SUBNET duid=[00:03:00:01:da:c5:77:4c:86:f0], [no hwaddr info],
tid=0x41270a: failed to allocate an IPv6 lease in the subnet 2a02:xxxx:xxxx::/64, subnet-id 1, shared network (none)

A ChatGPT consultation suggests the generated config has some kind of class restriction, because the client has both the classes ALL and UNKNOWN, hence it not being assigned a pool to distribute an address from. I looked in the generated config files, and it doesn't seem to use anything with classes or reservations.

This is my kea-dhcpd6.conf:

Code Select Expand

{
    "Dhcp6": {
        "valid-lifetime": 4000,
        "interfaces-config": {
            "interfaces": [
                "igc0"
            ]
        },
        "lease-database": {
            "type": "memfile",
            "persist": true
        },
        "control-socket": {
            "socket-type": "unix",
            "socket-name": "\/var\/run\/kea6-ctrl-socket"
        },
        "loggers": [
            {
                "name": "kea-dhcp6",
                "output_options": [
                    {
                        "output": "syslog"
                    }
                ],
                "severity": "INFO"
            }
        ],
        "subnet6": [
            {
                "id": 1,
                "subnet": "2a02:xxxx:xxxx::\/64",
                "option-data": [],
                "pools": [
                    {
                        "pool": "2a02:xxxx:xxxx::1000-2a02:xxxx:xxxx::2000"
                    }
                ],
                "pd-pools": [],
                "reservations": [],
                "interface": "igc0",
                "pd-allocator": "random",
                "allocator": "random"
            }
        ],
        "hooks-libraries": [
            {
                "library": "\/usr\/local\/lib\/kea\/hooks\/libdhcp_lease_cmds.so"
            }
        ]
    }

Any ideas what the issue could be, or what to try further?

A reboot may be required because DNSmasq modifies firewall settings, but these changes don't appear to be fully applied when using the 'Apply' button in the DNSmasq menu. As a result, client requests may not reach DNSmasq.

I have KPN FttH and would like to share some screenshots of my configuration, but it appears that direct uploads are not supported on this forum. It seems they need to be hosted externally, which I find cumbersome. Would it be possible for me to email them to you, or is there an alternative method you would prefer?

But there were some devices on the network that work perfectly fine with ISC/KEA that just refuse to talk to the dnsmasq DHCP service and get an IP?

I believe I observed this behavior as well. In my case, it occurred when a client attempted to renew a lease for an IP address outside the configured range in DNSmasq. For example, requesting a .10 address while the DHCP range was set to .100–.199. 'New' leases were no problem.

I was testing the recently added DHCP support in DNSmasq and wanted to report that while IPv6 DHCP appears to be working fine, DHCPv4 was not. The service started up without issues, but no DHCPv4 requests seemed to reach it initially. After a reboot, requests started coming through, suggesting a possible firewall-related issue.

However, on the client side (Windows 11), things got even stranger: after said reboot the client received an IP address that was outside the assigned range, while an address within the assigned range was allocated as the DHCP server/DNS/Gateway. Very odd behavior.

Unfortunately, I wasn't able to investigate further because of angry users (a.k.a. my kids) demanding working internet.

Apologies for not wording my question more clearly. I'm fully on board with the bufferbloat issue in general; I was just wondering more specifically about the effects of ICMPv6 apparently being squashed by other traffic.

Nice work! I'm wondering though — is this fixing an actual problem in day-to-day use, or is it more about looking good in tests? Would love to hear a bit more about that.

Is FQ_CoDel definitely the issue? Have you monitored CPU usage during the speed drop? It might also be DNS slowness or the upstream router needing a reboot or something.

Have you tried the 'ignore client uid' setting? I'm not sure this is the real problem or only hides it, but this sometimes successfully prevents systems from acquiring multiple leases.