Messages

Yep, the typical FreeBSD package manager bug that we're seeing.

Apparently a rare but still prevalent race condition between renameat() and chdir().


Cheers,
Franco

> IA_PD prefix: xxxx:xxxx:xxxx::/48 pltime=600 vltime=600

Your ISP proposes a lifetime of 10 minutes. The client will honour it and try to renew the lease after 5 minutes.

Ask your ISP to set more conservative lifetime (pltime/vltime) defaults.

In theory we could add lifetime request values in the GUI but

1) nobody needed it so far
2) I'm not even sure it works reliably since the server has to decide


Cheers,
Franco

The hang would be from the installer disk, not the disk to be written (in general).  I'm note sure why it hangs and these things have been reported sparsely in the past, but it's been years while since this was happening more frequently.


Cheers,
Franco

No that's right that's why the max setting was added too.  Unfortunately the default was bumped to TLSv1.3 which didn't work for that particular use case.


Cheers,
Franco

So you created VLANs via ifconfig on the command line?


Cheers,
Franco

Do I read this correct? There are ISPs who do this in direct violation of RFC 3633? Or has this RFC been superseeded?

No, we're doing this now since it's no longer in the RFC (and it works nicely to put a prefix on WAN).

We'll update the port as it became available in FreeBSD ports, but we avoided it for now because it usually has build issues and we didn't want to ruin 26.1 with it.


Cheers,
Franco

It's a brave new world since https://github.com/opnsense/dhcp6c/commit/369b4dcf ;)

You can reset your states. You can set your rules to not track state. It's up to your really.  :)


Cheers,
Franco

> OPNsense needs a GUA as a source address for many local services (DNS resolver, firmware updater etc).

Yes but not necessarily on the WAN side.


Cheers,
Franco

The backend uses quite some Python for fetching and managing data.

We did fix the two _1 CVEs in 26.1.1 but apparently there is _2 with two new ones.  The circle of life.  ;)


Cheers,
Franco

I didn't catch the fact that the successful ping was from a client behind ;)

In some cases there's a bad SLAAC address on the WAN. It's not easy to get rid of it programmatically.


Cheers,
Franco

Should be worth raising a ticket over.  Not sure if we can find a good solution that fits all, but I remember the live log had similar issues before so that's why it has search filters there.


Cheers,
Franco

We'll likely pivot to curl use as well in the not so distant future.


Cheers,
Franco

It's a hard-off for the automatic ISC-DHCPv6 and Radvd, yes.


Cheers,
Franco