Messages

Quick follow-up with additional info.

I did a ufs install out of concern for drive wear. I went back to the router to do another fresh install with zfs, just in case, when I saw a system message/error pop up on the monitor: bad dir info, mangled entry. That's on a fresh install with 100% proper shutdowns, plus it's connected to a UPS.

I suspected a failing drive, but nvmecontrol is reporting 6% wear, and nothing else concerning is popping out at me.

The other thing I failed to mention was that I restored a backup config once it was all back up and running, but before I attempted an update past 25.7. I'll be skipping that this round and attempt to fully update before I restore any configs.

I found this thread after the update to 25.7 appeared to leave my system in a semi-broken state. It ran after the 25.7 update, but like the others, it wasn't able to update past that. I attempted the bootstrap, but something about that bricked my install.

I then downloaded the latest vga image and performed a fresh install from usb, which started me out on 25.7. The first time, the pkg db was corrupted after attempting to install the realtek plugins from the console (my lan interface requires it). Instead of trying to deal with that, I just started the installation process all over again. The second time, I did that realtek step manually in the live environment via console, and performed the installation with the opnsense-installer command.

It's now up again, however, it won't update past that, just like before... which is unfortunate, because a couple plugins are demanding an update.

And yes, N100 here too.

The most recent output from the "Updates" tab:

Code Select Expand

***GOT REQUEST TO UPDATE***
Currently running OPNsense 25.7 (amd64) at Sat Nov 29 03:12:08 CST 2025
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (162 candidates): .......... done
Processing candidates (162 candidates): ...... done
Checking integrity... done (1 conflicting)
  - py311-pyopenssl-25.3.0_1,1 conflicts with py311-openssl-25.0.0_1,1 on /usr/local/lib/python3.11/site-packages/OpenSSL/SSL.py
Checking integrity... done (0 conflicting)
The following 85 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
py311-pyopenssl: 25.3.0_1,1

Installed packages to be UPGRADED:
boost-libs: 1.88.0_1 -> 1.89.0_1
ca_root_nss: 3.108 -> 3.117_2
curl: 8.14.1 -> 8.17.0
kea: 2.6.3_1 -> 3.0.2
krb5: 1.21.3_1 -> 1.22.1
liblz4: 1.10.0,1 -> 1.10.0_2,1
libnghttp2: 1.66.0 -> 1.68.0
libpfctl: 0.15 -> 0.17
libucl: 0.9.2_1 -> 0.9.2_2
libunistring: 1.3 -> 1.4.1
libxml2: 2.14.5 -> 2.14.6
lighttpd: 1.4.79 -> 1.4.82
nspr: 4.36 -> 4.38.2
nss: 3.113.1_1 -> 3.118.1
ntp: 4.2.8p18_4 -> 4.2.8p18_5
openssh-portable: 10.0.p1_1,1 -> 10.2.p1_1,1
openssl: 3.0.17,1 -> 3.0.18,1
openvpn: 2.6.14 -> 2.6.16
opnsense: 25.7 -> 25.7.8
opnsense-lang: 25.1.11 -> 25.7.4
opnsense-update: 25.7 -> 25.7.8
pcre2: 10.45_1 -> 10.47
perl5: 5.40.2_2 -> 5.42.0_1
php83: 8.3.23 -> 8.3.28
php83-ctype: 8.3.23 -> 8.3.28
php83-curl: 8.3.23 -> 8.3.28
php83-dom: 8.3.23 -> 8.3.28
php83-filter: 8.3.23 -> 8.3.28
php83-gettext: 8.3.23 -> 8.3.28
php83-ldap: 8.3.23 -> 8.3.28
php83-mbstring: 8.3.23 -> 8.3.28
php83-pcntl: 8.3.23 -> 8.3.28
php83-pdo: 8.3.23 -> 8.3.28
php83-pear: 1.10.13 -> 1.10.16
php83-phpseclib: 3.0.46 -> 3.0.47
php83-session: 8.3.23 -> 8.3.28
php83-simplexml: 8.3.23 -> 8.3.28
php83-sockets: 8.3.23 -> 8.3.28
php83-sqlite3: 8.3.23_1 -> 8.3.28
php83-xml: 8.3.23 -> 8.3.28
php83-zlib: 8.3.23 -> 8.3.28
pkcs11-helper: 1.29.0_3 -> 1.31.0
py311-aioquic: 1.2.0 -> 1.3.0_1
py311-anyio: 4.9.0 -> 4.11.0
py311-attrs: 25.3.0 -> 25.4.0
py311-certifi: 2025.6.15 -> 2025.10.5
py311-charset-normalizer: 3.4.2 -> 3.4.4
py311-cryptography: 44.0.3_2,1 -> 45.0.7_1,1
py311-dnspython: 2.7.0,1 -> 2.8.0_1,1
py311-duckdb: 1.3.1_1 -> 1.3.2
py311-idna: 3.10 -> 3.11
py311-jq: 1.8.0_1 -> 1.10.0
py311-markupsafe: 3.0.2 -> 3.0.3
py311-numexpr: 2.11.0 -> 2.14.1
py311-numpy: 1.26.4_6,1 -> 1.26.4_10,1
py311-pandas: 2.2.3_2,1 -> 2.2.3_3,1
py311-pycparser: 2.22 -> 2.23
py311-pylsqpack: 0.3.22 -> 0.3.23
py311-pyyaml: 6.0.1_1 -> 6.0.3
py311-requests: 2.32.4 -> 2.32.5
py311-sqlite3: 3.11.13_11 -> 3.11.14_11
py311-trio: 0.30.0 -> 0.32.0
py311-truststore: 0.10.1 -> 0.10.4
py311-typing-extensions: 4.14.0 -> 4.15.0
py311-ujson: 5.10.0_1 -> 5.11.0
py311-urllib3: 1.26.20,1 -> 2.5.0,1
py311-vici: 5.9.11_1 -> 6.0.3
python311: 3.11.13 -> 3.11.14
readline: 8.2.13_2 -> 8.3.1
sqlite3: 3.50.2_1,1 -> 3.50.4_2,1
strongswan: 5.9.14 -> 6.0.3_1
sudo: 1.9.17p1 -> 1.9.17p2_2
suricata: 7.0.11_1 -> 8.0.2
syslog-ng: 4.8.2_3 -> 4.10.2
unbound: 1.23.1 -> 1.24.1
wpa_supplicant: 2.11_5 -> 2.11_7
zstd: 1.5.7 -> 1.5.7_1

Installed packages to be REINSTALLED:
cyrus-sasl-2.1.28_5 (provided shared library changed)
cyrus-sasl-gssapi-2.1.28 (provided shared library changed)
dnsmasq-2.91_1,1 (required shared library changed)
glib-2.84.1_3,2 (required shared library changed)
openldap26-client-2.6.10 (required shared library changed)
rrdtool-1.9.0_1 (direct dependency changed: perl5)

Installed packages to be REMOVED:
py311-openssl: 25.0.0_1,1

Number of packages to be removed: 1
Number of packages to be installed: 1
Number of packages to be upgraded: 77
Number of packages to be reinstalled: 6

The process will require 8 MiB more space.
[1/88] Upgrading libnghttp2 from 1.66.0 to 1.68.0...
[1/88] Extracting libnghttp2-1.68.0: .......... done
[2/88] Upgrading libpfctl from 0.15 to 0.17...
[2/88] Extracting libpfctl-0.17: ...... done
[3/88] Upgrading libucl from 0.9.2_1 to 0.9.2_2...
[3/88] Extracting libucl-0.9.2_2: .......... done
[4/88] Upgrading libunistring from 1.3 to 1.4.1...
[4/88] Extracting libunistring-1.4.1: .......... done
[5/88] Upgrading nspr from 4.36 to 4.38.2...
[5/88] Extracting nspr-4.38.2: .......... done
[6/88] Upgrading pcre2 from 10.45_1 to 10.47...
[6/88] Extracting pcre2-10.47: .......... done
[7/88] Upgrading perl5 from 5.40.2_2 to 5.42.0_1...
[7/88] Extracting perl5-5.42.0_1:
pkg-static: Fail to set time on /Archive/Tar/Constant.pm:No such file or directory
[7/88] Extracting perl5-5.42.0_1... done
Starting web GUI...done.
***DONE***

There's actually 2 different broadcasts in play here on port 987 (it's different for 2nd screen vs. remote play). I just did another capture to be sure of what I saw per application. And just to be clear, the only SSDP traffic I see on either interface is just UPnP.

2nd screen is the application that does a network broadcast I'd expect (so for example if the network is 192.168.1.0/24, the broadcast address is 192.168.1.255), and at the OpnSense box I see up to 5 of those when UDPR is off. Their remote play application is the one that does a wide open 255.255.255.255 (I see it once from the OpnSense box). I agree, it's a bit strange but that's what is being done (and to be honest I've mostly just been testing the 2nd screen app so far, figured that'd be the simpler of the two).

The packet data themselves contain the same thing, even reference the same "device-discovery-protocol-version", so it's a little funny they do broadcasts differently. In any case, I haven't found another way to send these broadcasts across different networks until your plugin existed, though I admit I'm not exactly fully familiar with OpnSense yet.

BTW, thanks a ton for your work on this.

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

Correct,  that's not multicast it's broadcast.

Thanks for clarifying, so if it's broadcast, users are meant to leave that field blank? I mean I know it's labeled "multicast addresses" but it wasn't super clear to me what should be done in that case.

UDPR itself does not need rules as it bypasses the fw. The only rule(s) needed are for the server to respond back to the client which does not go via UDPR.

This where I'm confused. I'm actually seeing 2 broadcasts on the vlan interface in the firewall log live view, one in the OUT direction (which is allowed through, "let out anything from firewall host itself") and one in the IN direction (which is being blocked via a default deny rule). The IN is what I needed an additional rule for. Both broadcasts are from the same IP on LAN. If I disable the rule, the PS4 Second Screen application doesn't find my PS4. It's only when I re-enable it that it works.

I also have a rule allowing broadcast traffic back from the VLAN to LAN, and that was enabled the entire time while testing all this.

forget the broadcast address, the source address, leave them blank, just put the port and lan interfaces and try that. you'll likely as not need firewall rules too, but First just see if it fires up.

Thanks marjohn56, this put me on the right track. It works beautifully now - can control my Logitech server from within my guest VLAN.

I was having this issue too. If I try to use the multicast address of 255.255.255.255 (port 987, PS4 device discovery but only sometimes), it'd silently fail and I had no idea if it was actually running or not. Restarting it from shell, or starting the binary manually with the same options (thanks to the config file for making it a copy/paste ordeal) gave me the

Code Select Expand

IP_ADD_MEMBERSHIP on rcv: Invalid argument message. It wasn't until I saw this part of the thread and got rid of the multicast option that it was able to start up successfully. I suppose it probably won't matter to me if I leave it like that but I like to be explicit in my rules.

I'm guessing this is thrown because 255.255.255.255 is technically outside the "official" multicast range? Either way, I think it'd be nice to have some kind of feedback in the web UI if the daemon can't be started for some reason. The most I can see from there is that it failed to start in the system log files but it doesn't tell me why.

Just wanted to share something that confused me as it might help others with their firewall rules. My home network is set up with my primary LAN network (most trusted devices) having access to all VLAN machines. My firewall rules for this are on the LAN interface. However, broadcasts weren't getting through to the VLAN and I couldn't figure out why (source and multicast addresses were left blank, so the broadcasts still appeared to be coming from the original machine). I discovered I needed an additional rule on my VLAN interface to specifically allow broadcasts from my LAN network, despite that rule already being in place on my LAN interface. It seems the source interface's rules aren't being looked at in the event the firewall box itself is generating the traffic or something? I understand why if that's the case, it's just something to be aware of for this plugin.

Hopefully this helps someone else.