Messages

Thanks, this was very recently reported and already hotfixed: https://github.com/opnsense/core/issues/9618


Cheers,
Franco

A hotfix release was issued as 25.7.11_1:

o system: fix vsprintf() error on stray % invoke

The best course of action would be asking over at Dnsmasq for a canonical way to delete a single lease on FreeBSD?


Cheers,
Franco

PS: not seeing the upcoming release name here at all...

FWIW https://github.com/opnsense/changelog/blob/master/community/25.7/25.7.11#L25-L27

A happy new year to all of you!

25.7.11 comes at a strange point in time but we will try to offer a bit of
familiarity and common sense as we probably all need more of this.  <3

This release brings the new host discovery service which resolves and remembers
MAC addresses for IPv4 and IPv6 hosts in your connected networks and provides
this data for the firewall MAC aliases and captive portal clients.  It is now
enabled by default, but you can choose to opt out by disabling the automatic
discovery option.

A lot of work went into IPv6 improvements over the holidays as is tradition
with the help of users debugging their networks during that time.  A number
of kernel fixes have been supplied and dhcp6c will also receive a larger update
in 26.1 soon.

The changes are otherwise clustered around preparation for the major upgrade
which brings an number of fundamental changes with the ongoing removal of
ISC-DHCP from core.  A plugin is already available through the development
version and should auto-install.  If not make sure you install it before
attempting a reboot there.  For the stable version everything is as it was.

That being said, 26.1-RC1 will be out early next week and RC2 likely follows
quickly.  We are still set for a final release date of January 28.  See you on
the other side!

Here are the full patch notes:

o system: add tooltip explaining active status in snapshots
o system: add "lazy loading" model support on Trust\Cert
o system: properly fill DNS SAN from existing certificates (contributed by Klaas Demter)
o system: rename sudoers file to make it more sortable (David Jack Wange Olrik)
o system: numerous safe execution changes
o system: sort to retain order in syslog-ng source definitions
o interfaces: fix comparison in PPP check code during assignment
o interfaces: prefer longer lifetimes if multiple exist
o interfaces: defer manual rtsold script execution
o interfaces: use mwexecfb() in two instances
o interfaces: move configure_interface_hardware() to main file
o interfaces: migrate "sharednet" setting to its respective sysctls
o interfaces: add and enable new host discovery feature for neighbours via hostwatch
o firewall: automation: only show ICMP type when protocol is ICMP
o firewall: automation: add multi-select ICMP6 options
o firewall: use new host discovery in MAC type aliases
o firewall: simplify port alias check
o captive portal: assign empty array when "interface list arp json" returns invalid JSON
o captive portal: use new host discovery service by default
o dhcrelay: reload table to update relay status
o intrusion detection: datakey hint was missing for rules edit
o intrusion detection: replace "all" alert selection with explicit maximum choices
o ipsec: most safe execution transformations done
o isc-dhcp: interalize interfaces_staticarp_configure()
o isc-dhcp: safeguard access to DHCPv6 "enable" property
o kea: refactor daemon(8) call to mwexecfb()
o network time: fix GPS coordinate display in status page (contributed by brotherla)
o openvpn: add simple search functionality for accounts table in client export
o openvpn: skip dynamic content when loading the model in client export
o openvpn: convert two more exec() calls
o openvpn: fix archive client export
o unbound: remove delete selected button for single select overrides grid
o unbound: add per-policy quick actions in reporting overview
o unbound: add overrides reference counter for aliases
o unbound: info section was larger than table width
o backend: exec() removal in get_sysctl()/set_sysctl()
o backend: exec() removal in auth scripts
o mvc: reduce some call overheaad in BaseField/IntegerField
o mvc: introduce defaultConfig property for AppConfig
o mvc: uppercase all form labels
o mvc: use asInt() in GidField and UidField
o mvc: BaseField: add isSet()
o tests: revamped config and base model tests
o ui: bootgrid: allow conditional command rendering through a filter function
o plugins: os-frr 1.50[1]
o plugins: os-ndp-proxy-go 1.3[2]
o plugins: os-telegraf 1.12.14[3]
o src: in6: modify address prefix lifetimes when updating address lifetimes
o src: ipv6: fix off-by-one in pltime and vltime expiration checks
o src: ipv6: do not complain when deleting an address with prefix length of 128
o src: ifconfig: fix the -L flag when using netlink
o src: netlink: do not directly access ifnet members
o src: netlink: do not overwrite existing data in a linear buffer in snl_writer
o src: netmap: Let memory allocator parameters be settable via loader.conf
o src: pfsync: avoid zeroing the state export union
o src: divert: fix removal of divert sockets from a group
o src: divert: use a jenkins hash to select the target socket
o src: divert: define semantics for SO_REUSEPORT_LB on divert sockets
o src: divert: use CK_SLISTs for the divcb hash table
o src: pf: rationalize the ip_divert_ptr test
o src: pf: fix handling of IPv6 divert packets
o src: rtsold: check RA lifetime before triggering the one-shot always script
o ports: suricata 8.0.3[4]


Stay safe,
Your OPNsense team

--
[1] https://github.com/opnsense/plugins/blob/stable/25.7/net/frr/pkg-descr
[2] https://github.com/opnsense/plugins/blob/stable/25.7/net/ndp-proxy-go/pkg-descr
[3] https://github.com/opnsense/plugins/blob/stable/25.7/net-mgmt/telegraf/pkg-descr
[4] https://suricata.io/2026/01/13/suricata-8-0-3-and-7-0-14-released/

Things are likely changing in the default install of 26.1 as we're trying to unwind these implicit IPv6 behaviours steered from the interface settings  we've inherited.  They don't really work in a post ISC DHCPD world.


Cheers,
Franco

Building a complex solution for a problem that doesn't exist for 99.9% of the users to allow to chose a shell that is not even installed by default in a very tiny shell script that offers a bit of convenience shows how impractical the request is.

Why not set the admin shell to bash? Why not use a separate admin user with bash shell and sudo su for the console menu?  These types of setups have been supported for many years already.


Cheers,
Franco

I can offer you the latest code we shipped. If that's not what you want from upstream acme.sh you need to patch the file manually because it looks like they did not release it yet?

In general it helps to get the data straight before experimenting if the change one wants is actually there.


Cheers,
Franco

You can always install the community one:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/MINT/25.7.10/latest/All/acme.sh-3.1.2.pkg
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/MINT/25.7.10/latest/All/os-acme-client-4.11.pkg


Cheers,
Franco

All of the things that have been said here are normal.

WAN has DHCPv6 mode by default as witnessed by a ps dump with "dhcp6c" in it.

LAN has Track6 mode by default which launches DHCPv6 and Radvd.

If you dont want IPv6 set IPv6 mode of WAN and LAN(s) to "None".

This isn't rocket science. Never has been.


Cheers,
Franco

# opnsense-patch https://github.com/opnsense/core/commit/00687dbe

Mea culpa :)

Thanks, some progress in the ticket now: https://github.com/opnsense/core/issues/9601

The failure detection we added certainly works as expected. Unfortunately the current package manager isn't very good in these instances. We will be looking into it shortly. It's not our territory, but it seems we need to dig into this.


Cheers,
Franco

Thanks for your message and your mailing list thread! There seem to be a number of similar stories out there. Let me add one more that matters.

Here is my one and only 2023 code of conduct complaint that I filed after bit of a backstory of misconduct in the ports scope towards me.

From: Sergio Carlavilla <carlavilla@freebsd.org>
Date: Mon, 9 Oct 2023 11:06:12 +0200
Subject: Re: reporting an inappropriate mailing list reply
To: Franco Fichtner <franco@opnsense.org>
Cc: "conduct@freebsd.org" <conduct@freebsd.org>, FreeBSD Core Team <core@freebsd.org>

On Mon, 9 Oct 2023 at 11:03, Franco Fichtner <franco@opnsense.org> wrote:
>
> Hi,
>
> [REDACTED]
>
>
> Thanks,
> Franco

Hi Franco,

Okay, we've received the message.

We will contact you when we have studied the case and have a response.

Bye!

Sergio Carlavilla
Core Team Secretary.

I never got another reply on this complaint. I eventually chased down a core team member on the issue and the person assured me it would be taken care of internally. I trusted the person so there wasn't a reason to not agree to it. The email gives the offender a very lax outlook. Compared to how the core team handled the complaint against me  I just think both of these instances were inappropriate and unprofessional.

Date: Wed, 6 Mar 2024 10:19:40 +0100
From: XYZ <xyz@freebsd.org>
To: Franco Fichtner <franco@opnsense.org>
Subject: Re: reporting an inappropriate mailing list reply

On Wed, Mar 06, 2024 at 10:08:26AM +0100, Franco Fichtner wrote:
> Hi [REDACTED],
>
> > On 6. Mar 2024, at 10:05, XYZ <xyz@freebsd.org> wrote:
> >
> > Yes [REDACTED] can be border sometime, at even cross dangerous roads sometimes, I do
> > talk quite a lot with him about him, to make sure he improves.
>
> If I can take your word for it I'll let this go then.

You can take my word, on this, he [REDACTED], so I feel like it is kind of my
duty, his behaviour has degraded the time he started getting more involved in
the project, due accumulating lots of frustration, as a result he ends up being
more (too much?) opinionated, and even aggressive sometime, I am trying to cool
him down, as frustration is part of high involvements and at some point we all
need to be able to deal with it, or we simply burnout.

[REDACTED]

still if you see bad interactions, don't hesitate to send me a heads u
directly, I am not tracking all his communication, so I may miss them.

[REDACTED]

Best regards,
[REDACTED]

The trust in the core team was mostly gone in that instance. What came after and anyone can look up is the core team's inability to bring people together even over technical matters.

So I think it's clear the code of conduct is dead and the core team cannot claim it to justify its decisions. The illusion here is that "words" matter and people are supposed to be friendly but actions like systematic neglect and abuse of power are much worse for the code, its users and even its developers in the long run.


Cheers,
Franco