"
Great, The plugin 0.1.6 with netflector 0.16.0 is installed and working perfectly here.
Thanks again for all the work and support!
Thanks again for all the work and support!
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
#1
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 21, 2026, 07:30:43 AM #2
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 20, 2026, 07:08:02 AM
@UnicronHD, thanks again for all the work and for digging into this with me.
Looking forward to the official release!
Looking forward to the official release!
#3
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 19, 2026, 01:48:16 PM
@UnicronHD, the LAN-only baseline reproduces it too.
WireGuard was completely OFF and the iPhone was on normal LAN Wi-Fi only.
The endpoint behaviour was still intermittent. When it failed, I waited 20-30 seconds and the endpoint still did not appear. It only came back after one or more force-close/reopen cycles of Roon.
So this is not just a 2-3 second discovery delay. The same remaining behaviour exists without WireGuard and without netflector. I did not know that.
That seems to confirm your conclusion that the netflector/discovery side is now closed and the remaining issue is in Roon/iOS endpoint/session behaviour after discovery.
WireGuard was completely OFF and the iPhone was on normal LAN Wi-Fi only.
The endpoint behaviour was still intermittent. When it failed, I waited 20-30 seconds and the endpoint still did not appear. It only came back after one or more force-close/reopen cycles of Roon.
So this is not just a 2-3 second discovery delay. The same remaining behaviour exists without WireGuard and without netflector. I did not know that.
That seems to confirm your conclusion that the netflector/discovery side is now closed and the remaining issue is in Roon/iOS endpoint/session behaviour after discovery.
#4
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 19, 2026, 01:30:19 PM
@UnicronHD, confirmed.
The inbound rule did not match on my OPNsense setup, but an outbound quick block on wg0 does:
block drop out quick on wg0 inet from 10.10.10.2 to 10.10.10.255
After the test it had:
Packets: 66
Bytes: 20316
With that rule active:
- ICMP capture from 10.10.10.1 to 10.10.10.2 stays completely empty.
- The previous "host 10.10.10.255 unreachable" messages are gone.
- The duplicate relay is also gone.
- On ax1 I now see only TTL 64 copies of the phone traffic.
- The 348-byte SOOD endpoint announcements still reach 192.168.1.255:9003.
- The 98-byte discovery packets also still reach the LAN.
So the forwarding/ICMP issue is confirmed and fixed by blocking the routed egress copy.
However, the iPhone endpoint is still intermittent in Roon. During the latest tests there were attempts where the endpoint did not appear even though the 348-byte announcements were present on ax1 and there were no ICMP errors toward the phone.
So at this point the remaining intermittent endpoint issue no longer appears to correlate with:
- missing netflector relay
- duplicate relay
- or ICMP unreachable responses.
I have not changed anything else in the setup.
The inbound rule did not match on my OPNsense setup, but an outbound quick block on wg0 does:
block drop out quick on wg0 inet from 10.10.10.2 to 10.10.10.255
After the test it had:
Packets: 66
Bytes: 20316
With that rule active:
- ICMP capture from 10.10.10.1 to 10.10.10.2 stays completely empty.
- The previous "host 10.10.10.255 unreachable" messages are gone.
- The duplicate relay is also gone.
- On ax1 I now see only TTL 64 copies of the phone traffic.
- The 348-byte SOOD endpoint announcements still reach 192.168.1.255:9003.
- The 98-byte discovery packets also still reach the LAN.
So the forwarding/ICMP issue is confirmed and fixed by blocking the routed egress copy.
However, the iPhone endpoint is still intermittent in Roon. During the latest tests there were attempts where the endpoint did not appear even though the 348-byte announcements were present on ax1 and there were no ICMP errors toward the phone.
So at this point the remaining intermittent endpoint issue no longer appears to correlate with:
- missing netflector relay
- duplicate relay
- or ICMP unreachable responses.
I have not changed anything else in the setup.
#5
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 19, 2026, 12:33:50 PM
@UnicronHD thanks. I repeated the tests and have some more useful data.
Setup used:
- Binary: netflector-0.16.0rc2-freebsd15-amd64
- --version: netflector 0.16.0
- SHA256: e0b0c32a9f062c36c29ddc7cf193ae984e59fc5215ee05167391f3e14cc2f3b4
- Command: /tmp/netflector-0.16.0rc2-freebsd15-amd64 /tmp/roon-peers-trace.toml
- No NETFLECTOR_* environment variables are set.
- Only the manually started rc2 process was running; the plugin service was not running.
- LAN is directly on ax1, 192.168.1.1/24. There is no bridge, lagg or VLAN on top of ax1.
- iPhone WireGuard IPv4 interface address is now 10.10.10.2/24.
- The OPNsense peer AllowedIP remains 10.10.10.2/32.
Config:
In the trace run I did repeated force-close/open tests with the same netflector process:
1: endpoint YES
2: endpoint YES
3: endpoint NO
4: endpoint NO
Netflector continued to log the phone traffic being reflected to:
10.10.10.2:<port> -> 192.168.1.255:9003
during the later failed attempts as well.
I then did a second controlled test with a simultaneous tcpdump on ax1.
Results of that test:
1: endpoint YES
2: endpoint NO
3: endpoint NO
4: endpoint YES
The important result is that the 348-byte iPhone endpoint announcements were actually visible on ax1 during all four attempts, including both failed ones:
10.10.10.2:<ephemeral> -> 192.168.1.255:9003
UDP length 348
The normal 98-byte discovery traffic and 491-byte Core replies were also present during the failed attempts.
So the intermittent endpoint failure no longer seems to correlate with netflector failing to relay the broadcast. The announcements are not only reported as reflected by netflector; they are actually present on the LAN interface even when Roon does not show the iPhone endpoint.
Full trace from the trace run:
Note: I only redacted the public IPv6 addresses and the LAN MAC address in the trace. Internal IPv4 addresses, interface names, ports, timestamps and netflector log contents are otherwise unchanged.
Setup used:
- Binary: netflector-0.16.0rc2-freebsd15-amd64
- --version: netflector 0.16.0
- SHA256: e0b0c32a9f062c36c29ddc7cf193ae984e59fc5215ee05167391f3e14cc2f3b4
- Command: /tmp/netflector-0.16.0rc2-freebsd15-amd64 /tmp/roon-peers-trace.toml
- No NETFLECTOR_* environment variables are set.
- Only the manually started rc2 process was running; the plugin service was not running.
- LAN is directly on ax1, 192.168.1.1/24. There is no bridge, lagg or VLAN on top of ax1.
- iPhone WireGuard IPv4 interface address is now 10.10.10.2/24.
- The OPNsense peer AllowedIP remains 10.10.10.2/32.
Config:
Code Select
log_level = "trace"
[reflectors.roon-remote]
source_if = "ax1"
target_if = "wg0"
target_peers = ["10.10.10.2"]
udp_ports = [9003]
udp_groups = ["239.255.90.90"]
udp_broadcast = true
bidirectional = true
In the trace run I did repeated force-close/open tests with the same netflector process:
1: endpoint YES
2: endpoint YES
3: endpoint NO
4: endpoint NO
Netflector continued to log the phone traffic being reflected to:
10.10.10.2:<port> -> 192.168.1.255:9003
during the later failed attempts as well.
I then did a second controlled test with a simultaneous tcpdump on ax1.
Results of that test:
1: endpoint YES
2: endpoint NO
3: endpoint NO
4: endpoint YES
The important result is that the 348-byte iPhone endpoint announcements were actually visible on ax1 during all four attempts, including both failed ones:
10.10.10.2:<ephemeral> -> 192.168.1.255:9003
UDP length 348
The normal 98-byte discovery traffic and 491-byte Core replies were also present during the failed attempts.
So the intermittent endpoint failure no longer seems to correlate with netflector failing to relay the broadcast. The announcements are not only reported as reflected by netflector; they are actually present on the LAN interface even when Roon does not show the iPhone endpoint.
Full trace from the trace run:
Code Select
2026-09-19T10:20:54Z DEBUG netflector: log level Trace
2026-09-19T10:20:54Z INFO netflector: netflector 0.16.0 starting
2026-09-19T10:20:54Z DEBUG netflector: loading configuration from /tmp/roon-peers-trace.toml with NETFLECTOR_* overrides
2026-09-19T10:20:54Z DEBUG netflector::sys: open-file limit already 466659
2026-09-19T10:20:54Z DEBUG netflector::config: reflector roon-remote: ax1 <-> wg0 [udp(9003 on 239.255.90.90,broadcast)] family=Default
2026-09-19T10:20:54Z DEBUG netflector::config::conflict: no reflector conflicts
2026-09-19T10:20:54Z INFO netflector: loaded 1 reflector
2026-09-19T10:20:54Z DEBUG netflector::dispatch::lifecycle: interface monitor installed
2026-09-19T10:20:54Z DEBUG netflector::capture::bpf: opened BPF capture on ax1 (fd 4, Ethernet, 4096-byte buffer)
2026-09-19T10:20:54Z DEBUG netflector::interface: ax1: ifindex 6
2026-09-19T10:20:54Z DEBUG netflector::interface: ax1: resolved mac 02:00:00:00:00:01, v4 192.168.1.1/24, v6 fe80::1, v6-routable 2001:db8:1::1, mtu 1500
2026-09-19T10:20:54Z INFO netflector::interface: interface ax1: gained IPv6 fe80::1
2026-09-19T10:20:54Z INFO netflector::interface: interface ax1: gained IPv6 routable 2001:db8:1::1
2026-09-19T10:20:54Z INFO netflector::interface: interface ax1: gained MAC 02:00:00:00:00:01
2026-09-19T10:20:54Z INFO netflector::interface: interface ax1: gained IPv4 192.168.1.1
2026-09-19T10:20:54Z DEBUG netflector::dispatch: watching ax1 as capture CaptureKey(0)
2026-09-19T10:20:54Z DEBUG netflector::capture::bpf: opened BPF capture on wg0 (fd 5, DltNull, 4096-byte buffer)
2026-09-19T10:20:54Z DEBUG netflector::interface: wg0: ifindex 11
2026-09-19T10:20:54Z DEBUG netflector::interface: wg0: resolved mac none, v4 10.10.10.1/24, v6 2001:db8:2::1, v6-routable 2001:db8:2::1, mtu 1420
2026-09-19T10:20:54Z INFO netflector::interface: interface wg0: gained IPv6 2001:db8:2::1
2026-09-19T10:20:54Z INFO netflector::interface: interface wg0: gained IPv6 routable 2001:db8:2::1
2026-09-19T10:20:54Z INFO netflector::interface: interface wg0: gained IPv4 10.10.10.1
2026-09-19T10:20:54Z DEBUG netflector::dispatch: watching wg0 as capture CaptureKey(1)
2026-09-19T10:20:54Z INFO netflector: roon-remote: MTU mismatch: ax1 has 1500, wg0 has 1420; packets larger than 1420 bytes cannot cross toward the smaller side and are dropped
2026-09-19T10:20:54Z DEBUG netflector::reflector: UDP relay: joined 239.255.90.90 on ax1
2026-09-19T10:20:54Z INFO netflector::reflector::udp: UDP relay "roon-remote": ax1 -> wg0 on 1 port(s) to 1 group(s) and broadcasts
2026-09-19T10:20:54Z DEBUG netflector::reflector: UDP relay: joined 239.255.90.90 on wg0
2026-09-19T10:20:54Z INFO netflector::reflector::udp: UDP relay "roon-remote": wg0 -> ax1 on 1 port(s) to 1 group(s) and broadcasts
2026-09-19T10:20:54Z DEBUG netflector::reactor: watch fd 4 for HandlerKey(Key { index: 0, generation: 0 }) as RegKey(Key { index: 0, generation: 0 })
2026-09-19T10:20:54Z DEBUG netflector::reactor: watch fd 5 for HandlerKey(Key { index: 0, generation: 0 }) as RegKey(Key { index: 1, generation: 0 })
2026-09-19T10:20:54Z DEBUG netflector::reactor: watch fd 3 for HandlerKey(Key { index: 0, generation: 0 }) as RegKey(Key { index: 2, generation: 0 })
2026-09-19T10:20:54Z INFO netflector: running; press Ctrl-C or send SIGTERM to stop
2026-09-19T10:20:54Z DEBUG netflector::reactor: watch fd 9 for HandlerKey(Key { index: 2, generation: 0 }) as RegKey(Key { index: 3, generation: 0 })
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:64505 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:64505 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51405 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:49551 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51405 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:57834 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:49551 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:57834 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55097 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55097 to 192.168.1.255:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:00Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:01Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:01Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:02Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55097 to 192.168.1.255:9003
2026-09-19T10:21:02Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55097 to 192.168.1.255:9003
2026-09-19T10:21:02Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55097 to 192.168.1.255:9003
2026-09-19T10:21:02Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55097 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55241 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:60392 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55241 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:60392 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:64552 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:63541 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:64552 to 192.168.1.255:9003
2026-09-19T10:21:03Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:63541 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:57712 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:63704 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51022 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:57712 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:63704 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51022 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65002 to 192.168.1.255:9003
2026-09-19T10:21:07Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65002 to 192.168.1.255:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62406 to 192.168.1.255:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62406 to 192.168.1.255:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:08Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:09Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62406 to 192.168.1.255:9003
2026-09-19T10:21:09Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62406 to 192.168.1.255:9003
2026-09-19T10:21:09Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62406 to 192.168.1.255:9003
2026-09-19T10:21:09Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62406 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53458 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53458 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:58420 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:63726 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56444 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:58420 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:63726 to 192.168.1.255:9003
2026-09-19T10:21:10Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56444 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50271 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53396 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:58427 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51933 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50271 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53396 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:58427 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51933 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56067 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56067 to 192.168.1.255:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:12Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:13Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:13Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56067 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56067 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56067 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56067 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55869 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62698 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:60621 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55869 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62698 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:60621 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53664 to 192.168.1.255:9003
2026-09-19T10:21:14Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53664 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:52623 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:61699 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:52623 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:61699 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55696 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:58224 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:55696 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:58224 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50268 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50268 to 192.168.1.255:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:24Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:25Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:25Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50268 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50268 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50268 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:50268 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51265 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51265 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:57440 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:57440 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51906 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51906 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56434 to 192.168.1.255:9003
2026-09-19T10:21:26Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56434 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62645 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:62645 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:52706 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:52466 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:60102 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:52706 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:52466 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:60102 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65044 to 192.168.1.255:9003
2026-09-19T10:21:33Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65044 to 192.168.1.255:9003
2026-09-19T10:21:34Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:34Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:34Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:53241 to 239.255.90.90:9003
2026-09-19T10:21:34Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 239.255.90.90:9003
2026-09-19T10:21:34Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:34Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 192.168.1.60:58287 to 10.10.10.255:9003
2026-09-19T10:21:35Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65044 to 192.168.1.255:9003
2026-09-19T10:21:35Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65044 to 192.168.1.255:9003
2026-09-19T10:21:35Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65044 to 192.168.1.255:9003
2026-09-19T10:21:35Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65044 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51255 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65460 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53125 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:51255 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:65460 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:53125 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56721 to 192.168.1.255:9003
2026-09-19T10:21:37Z DEBUG netflector::reflector::simple: reflected UDP relay datagram from 10.10.10.2:56721 to 192.168.1.255:9003
Note: I only redacted the public IPv6 addresses and the LAN MAC address in the trace. Internal IPv4 addresses, interface names, ports, timestamps and netflector log contents are otherwise unchanged.
#6
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 19, 2026, 11:31:27 AM
@UnicronHD the /24 change confirms the first half of your diagnosis, but it looks like there is still something missing in the relay.
After changing the iPhone from 10.10.10.2/32 to 10.10.10.2/24, the 348-byte endpoint announcements now correctly go to:
10.10.10.2:<ephemeral> -> 10.10.10.255:9003
I see several of these on wg0.
However, in the simultaneous ax1 capture I do not see corresponding 348-byte packets arriving at:
10.10.10.2:<ephemeral> -> 192.168.1.255:9003
The LAN capture still only contains the usual 98-byte discovery packets and 491-byte replies.
Behaviour also matches that: on the first Roon start the iPhone endpoint did not appear; on the second start it did, presumably because it happened to answer one of the Core's own queries.
So changing to /24 fixes Roon's broadcast destination exactly as expected, but Netflector does not appear to relay those 348-byte 10.10.10.255:9003 broadcasts from wg0 onto the LAN yet.
Happy to capture anything else you need.
After changing the iPhone from 10.10.10.2/32 to 10.10.10.2/24, the 348-byte endpoint announcements now correctly go to:
10.10.10.2:<ephemeral> -> 10.10.10.255:9003
I see several of these on wg0.
However, in the simultaneous ax1 capture I do not see corresponding 348-byte packets arriving at:
10.10.10.2:<ephemeral> -> 192.168.1.255:9003
The LAN capture still only contains the usual 98-byte discovery packets and 491-byte replies.
Behaviour also matches that: on the first Roon start the iPhone endpoint did not appear; on the second start it did, presumably because it happened to answer one of the Core's own queries.
So changing to /24 fixes Roon's broadcast destination exactly as expected, but Netflector does not appear to relay those 348-byte 10.10.10.255:9003 broadcasts from wg0 onto the LAN yet.
Happy to capture anything else you need.
#7
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 18, 2026, 07:32:53 PM
@UnicronHD thanks for the follow-up. I checked your remaining details.
The iPhone WireGuard interface is configured as 10.10.10.2/32. OPNsense has wg0 = 10.10.10.1/24, with 10.10.10.2/32 as the peer AllowedIP.
The ~350-byte packets are actually 348-byte SOOD packets. Their exact destination is the iPhone's own tunnel address:
10.10.10.2:<ephemeral> -> 10.10.10.2:9003
The payload starts with SOOD, message type Q, and includes the iPhone endpoint data (iOS 26.7, raat_version 1.1.48, tcp_port 9200).
During the dedicated capture I saw no ICMP packets toward 10.10.10.2.
Roon Server runs on Linux, Debian 12 (bookworm), x86_64.
Roon was in the foreground during the endpoint test.
One thing that may be relevant is the /32 on the iPhone together with the destination above: the phone's SOOD packet is sourced from 10.10.10.2 and is also addressed to 10.10.10.2:9003, and it does not appear on the LAN capture.
This may also be an interesting difference compared with udp-proxy-2020. Its VPN handling learns the client from UDP/9003 traffic seen on the tunnel interface and forwards that traffic onto the other configured interfaces; its debug examples show WG client traffic being reinjected toward the LAN.
So perhaps the relevant question here is whether UDP/9003 sourced from a configured WG peer should also be treated as discovery input for the opposite interface even when its destination is the peer's own tunnel address (?)
Happy to run any further captures or test another build.
The iPhone WireGuard interface is configured as 10.10.10.2/32. OPNsense has wg0 = 10.10.10.1/24, with 10.10.10.2/32 as the peer AllowedIP.
The ~350-byte packets are actually 348-byte SOOD packets. Their exact destination is the iPhone's own tunnel address:
10.10.10.2:<ephemeral> -> 10.10.10.2:9003
The payload starts with SOOD, message type Q, and includes the iPhone endpoint data (iOS 26.7, raat_version 1.1.48, tcp_port 9200).
During the dedicated capture I saw no ICMP packets toward 10.10.10.2.
Roon Server runs on Linux, Debian 12 (bookworm), x86_64.
Roon was in the foreground during the endpoint test.
One thing that may be relevant is the /32 on the iPhone together with the destination above: the phone's SOOD packet is sourced from 10.10.10.2 and is also addressed to 10.10.10.2:9003, and it does not appear on the LAN capture.
This may also be an interesting difference compared with udp-proxy-2020. Its VPN handling learns the client from UDP/9003 traffic seen on the tunnel interface and forwards that traffic onto the other configured interfaces; its debug examples show WG client traffic being reinjected toward the LAN.
So perhaps the relevant question here is whether UDP/9003 sourced from a configured WG peer should also be treated as discovery input for the opposite interface even when its destination is the peer's own tunnel address (?)
Happy to run any further captures or test another build.
#8
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 13, 2026, 09:29:25 PM
@UnicronHD Good progress with this build!
With target_peers = ["10.10.10.2"] the Roon server is consistently discovered, bidirectional UDP/9003 communication works, and the previous Network is unreachable / ICMP issues for multicast and broadcast are gone.
There is still one issue: the iPhone does not reliably appear as a Roon audio endpoint.
I also captured:
10.10.10.2 > 192.168.1.60: ICMP udp port 9003 unreachable
for a peer-unicast packet from the Roon server to 10.10.10.2:9003.
In addition, I repeatedly see 350-byte UDP/9003 packets on wg0 from the iPhone to its own WG address, but these do not appear on the LAN capture. The LAN side only shows the normal 98-byte discovery packets and 491-byte replies.
This may be worth comparing with udp-proxy-2020: since v0.0.11 it opens a UDP listening socket specifically to prevent ICMP Port Unreachable messages, as these were found to make Roon on iOS close its listening port and prevent the phone from appearing as an audio output. The ICMP direction here is different, so it may not be the exact same issue, but the symptom is very similar.
So the new peer handling clearly fixes the original WireGuard multicast/broadcast problem, but there still seems to be something missing for reliable iPhone endpoint discovery. Happy to test further.
With target_peers = ["10.10.10.2"] the Roon server is consistently discovered, bidirectional UDP/9003 communication works, and the previous Network is unreachable / ICMP issues for multicast and broadcast are gone.
There is still one issue: the iPhone does not reliably appear as a Roon audio endpoint.
I also captured:
10.10.10.2 > 192.168.1.60: ICMP udp port 9003 unreachable
for a peer-unicast packet from the Roon server to 10.10.10.2:9003.
In addition, I repeatedly see 350-byte UDP/9003 packets on wg0 from the iPhone to its own WG address, but these do not appear on the LAN capture. The LAN side only shows the normal 98-byte discovery packets and 491-byte replies.
This may be worth comparing with udp-proxy-2020: since v0.0.11 it opens a UDP listening socket specifically to prevent ICMP Port Unreachable messages, as these were found to make Roon on iOS close its listening port and prevent the phone from appearing as an audio output. The ICMP direction here is different, so it may not be the exact same issue, but the symptom is very similar.
So the new peer handling clearly fixes the original WireGuard multicast/broadcast problem, but there still seems to be something missing for reliable iPhone endpoint discovery. Happy to test further.
#9
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 10, 2026, 09:28:22 PM
@UnicronHD Thanks for looking into it.
I'm happy to help test the next build/fix when it's ready.
I'm happy to help test the next build/fix when it's ready.
#10
Zenarmor (Sensei) / Re: Very high SSD writes with Zenarmor + SQLite
September 08, 2026, 07:33:09 PM
I can add another real-world data point to this.
I have been investigating unexpectedly high SSD wear on a Deciso DEC850v2 running OPNsense with Zenarmor and the local SQLite reporting backend. The original SSD became heavily worn after roughly two years of operation and I have now had to replace it.
My network is not particularly large: around 40 active devices in a normal home/family environment.
I opened a support case with Zenarmor on August 21 and supplied them with the measurements and logs I had collected. During that investigation, Zenarmor support confirmed that around 45 session records per second for approximately 40 devices is considered normal, and also explained that a single website visit can generate another 10–15 records because connections/sessions and DNS requests are recorded for reporting.
The preserved IPDR logs from my old installation show continuous activity in conn_all.sqlite, together with periodic cleanup/incremental-vacuum operations. The database was operating in SQLite WAL mode. Unfortunately, I did not record the instantaneous size of conn_all.sqlite-wal before the old SSD was removed, which Zenarmor support has subsequently asked about.
I am not claiming that Zenarmor alone has been conclusively proven to have caused the SSD failure. However, it is a very serious suspected contributor. The important point for me is that the high record rate is apparently considered normal Zenarmor workload, rather than the result of some abnormal client on my network.
Since replacing the SSD, I rebuilt OPNsense without reinstalling Zenarmor. So far, the excessive SSD write behaviour that triggered this investigation has not returned. In other words, removing Zenarmor from the new installation has, at least for now, clearly removed the abnormal write-load problem we were seeing.
Because of that, I currently have no intention of reinstalling Zenarmor until there is a convincing technical explanation or solution for the local write behaviour.
At this point I have also not received any reimbursement for the SSD that had to be replaced, nor have I received a concrete technical fix or mitigation from Zenarmor. The case is still open and I am still waiting for a substantive response from their technical/development team.
Their suggested workaround has been remote Elasticsearch, but to me that does not fully answer the underlying question: why does the normal local Zenarmor reporting workload generate enough sustained write activity that SSD endurance becomes a concern on an official Deciso appliance?
I have retained the old IPDR logs, SSD wear data and other evidence. I would therefore be very interested in further measurements from others in this thread, especially controlled Zenarmor ON/OFF comparisons and findings around SQLite WAL/checkpointing, cleanup and write amplification.
Your A/B measurements are particularly interesting because they seem consistent with the direction of what I observed, although my measurements were collected differently.
I have been investigating unexpectedly high SSD wear on a Deciso DEC850v2 running OPNsense with Zenarmor and the local SQLite reporting backend. The original SSD became heavily worn after roughly two years of operation and I have now had to replace it.
My network is not particularly large: around 40 active devices in a normal home/family environment.
I opened a support case with Zenarmor on August 21 and supplied them with the measurements and logs I had collected. During that investigation, Zenarmor support confirmed that around 45 session records per second for approximately 40 devices is considered normal, and also explained that a single website visit can generate another 10–15 records because connections/sessions and DNS requests are recorded for reporting.
The preserved IPDR logs from my old installation show continuous activity in conn_all.sqlite, together with periodic cleanup/incremental-vacuum operations. The database was operating in SQLite WAL mode. Unfortunately, I did not record the instantaneous size of conn_all.sqlite-wal before the old SSD was removed, which Zenarmor support has subsequently asked about.
I am not claiming that Zenarmor alone has been conclusively proven to have caused the SSD failure. However, it is a very serious suspected contributor. The important point for me is that the high record rate is apparently considered normal Zenarmor workload, rather than the result of some abnormal client on my network.
Since replacing the SSD, I rebuilt OPNsense without reinstalling Zenarmor. So far, the excessive SSD write behaviour that triggered this investigation has not returned. In other words, removing Zenarmor from the new installation has, at least for now, clearly removed the abnormal write-load problem we were seeing.
Because of that, I currently have no intention of reinstalling Zenarmor until there is a convincing technical explanation or solution for the local write behaviour.
At this point I have also not received any reimbursement for the SSD that had to be replaced, nor have I received a concrete technical fix or mitigation from Zenarmor. The case is still open and I am still waiting for a substantive response from their technical/development team.
Their suggested workaround has been remote Elasticsearch, but to me that does not fully answer the underlying question: why does the normal local Zenarmor reporting workload generate enough sustained write activity that SSD endurance becomes a concern on an official Deciso appliance?
I have retained the old IPDR logs, SSD wear data and other evidence. I would therefore be very interested in further measurements from others in this thread, especially controlled Zenarmor ON/OFF comparisons and findings around SQLite WAL/checkpointing, cleanup and write amplification.
Your A/B measurements are particularly interesting because they seem consistent with the direction of what I observed, although my measurements were collected differently.
#11
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 08, 2026, 12:39:50 PM
Thanks — good news, the first test was functionally successful.
Roon on my iPhone (10.10.10.2) over WireGuard discovers the Roon Server (192.168.1.60), the server also discovers the iPhone as an endpoint, and actual audio playback to the iPhone works.
Packet capture confirms bidirectional UDP/9003 unicast communication with the original addresses preserved, for example:
10.10.10.2:53799 -> 192.168.1.60:9003
192.168.1.60:9003 -> 10.10.10.2:53799
So the important roadwarrior/source-IP use case works.
There is one thing worth looking at though. Netflector logged once:
UDP relay: cannot reflect datagram from 192.168.1.60:50259 to 239.255.90.90:9003: Network is unreachable (os error 51)
The packet capture also shows OPNsense generating ICMP unreachable messages back to the Roon server for some of the reflected multicast/broadcast traffic, e.g.:
ICMP host 239.255.90.90 unreachable
and
ICMP host 10.10.10.255 unreachable
This does not prevent Roon from working in my test, but it looks related to the ICMP behaviour we discussed earlier and may be worth checking for the L3/WireGuard case.
Apart from that, the first Roon/WireGuard test is a success!
Roon on my iPhone (10.10.10.2) over WireGuard discovers the Roon Server (192.168.1.60), the server also discovers the iPhone as an endpoint, and actual audio playback to the iPhone works.
Packet capture confirms bidirectional UDP/9003 unicast communication with the original addresses preserved, for example:
10.10.10.2:53799 -> 192.168.1.60:9003
192.168.1.60:9003 -> 10.10.10.2:53799
So the important roadwarrior/source-IP use case works.
There is one thing worth looking at though. Netflector logged once:
UDP relay: cannot reflect datagram from 192.168.1.60:50259 to 239.255.90.90:9003: Network is unreachable (os error 51)
The packet capture also shows OPNsense generating ICMP unreachable messages back to the Roon server for some of the reflected multicast/broadcast traffic, e.g.:
ICMP host 239.255.90.90 unreachable
and
ICMP host 10.10.10.255 unreachable
This does not prevent Roon from working in my test, but it looks related to the ICMP behaviour we discussed earlier and may be worth checking for the L3/WireGuard case.
Apart from that, the first Roon/WireGuard test is a success!
#12
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 07, 2026, 05:21:43 PMQuote from: UnicronHD on September 06, 2026, 11:10:53 PMWhich version of OPNsense are you running? Is it amd64 or arm64? Basically I need to know FreeBSD version and architecture to prepare a binary for you.
Thanks, great to hear that the first implementation is ready. I'm happy to test it.
I'm running:
OPNsense 26.7.3_11-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8
Architecture: amd64
#13
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 03, 2026, 08:52:57 PM
That sounds like a sensible approach. Generic payload-unaware reflection seems cleaner than adding Roon-specific protocol parsing, provided the original IP/UDP identity and the routed VPN/roadwarrior case can be preserved.
Regarding the UDP listener in udp-proxy-2020: I believe that was added for a slightly different reason. Aaron Turner found that the original UDP/9003 directed-broadcast packet arriving from the VPN client could cause the router to return ICMP Port Unreachable when nothing was listening locally on port 9003. His first workaround was a firewall DROP rule; the listener was later added to avoid needing that rule.
So this may be unrelated to the spoofed source-IP of the reflected packet. It might simply be worth checking during testing whether Netflector/FreeBSD generates such ICMP responses for the original VPN packet.
Regarding the UDP listener in udp-proxy-2020: I believe that was added for a slightly different reason. Aaron Turner found that the original UDP/9003 directed-broadcast packet arriving from the VPN client could cause the router to return ICMP Port Unreachable when nothing was listening locally on port 9003. His first workaround was a firewall DROP rule; the listener was later added to avoid needing that rule.
So this may be unrelated to the spoofed source-IP of the reflected packet. It might simply be worth checking during testing whether Netflector/FreeBSD generates such ICMP responses for the original VPN packet.
#14
Development and Code Review / Re: netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)
September 02, 2026, 05:44:20 PM
Thanks for looking into this in more detail. This sounds very promising.
I had a closer look at how udp-proxy-2020 actually handles this, since it is already proven to work with Roon across routed networks and VPN connections.
As far as I can see, udp-proxy-2020 does not implement any SOOD-aware query/response proxying and does not interpret the SOOD payload. It captures the configured UDP traffic and reinjects it onto the other interfaces while preserving the original source IP and UDP source/target ports.
So I think your "naive" solution may actually be the right model for SOOD: preserve the original endpoint and let subsequent unicast communication use normal routing, rather than making Netflector part of that unicast conversation.
That also seems to fit the output-device case you mentioned. Netflector would not need to decide whether a "Q" semantically represents a discovery query from a Remote or an announcement/discovery packet from an output device. It can simply relay the SOOD packet while preserving its original source identity.
There is another detail which seems relevant to your question about unicast responses. Aaron Turner's Roon Wireshark dissector indicates that, besides the normal Roon Server discovery on UDP/9003, there is also a Roon Discovery service where replies may originate from an ephemeral UDP port and the dissector therefore uses conversation tracking. To me that is another argument in favour of preserving the original source IP and port rather than introducing SOOD-specific response translation.
One implementation detail from udp-proxy-2020 may also be worth keeping in mind. In addition to BPF capture/injection it opens a normal UDP listener on the configured port and discards anything received there. That was added because ICMP Port Unreachable responses could otherwise cause problems for Roon clients, particularly iOS clients over VPN. I don't know whether that will be relevant to Netflector on OPNsense, but it seems worth being aware of when testing a first implementation.
So I would definitely start with the simple source-IP/source-port preserving model. If you build an initial SOOD implementation that way, I would be very happy to test it with Roon Remote over WireGuard and also with the Roon server/output side.
I had a closer look at how udp-proxy-2020 actually handles this, since it is already proven to work with Roon across routed networks and VPN connections.
As far as I can see, udp-proxy-2020 does not implement any SOOD-aware query/response proxying and does not interpret the SOOD payload. It captures the configured UDP traffic and reinjects it onto the other interfaces while preserving the original source IP and UDP source/target ports.
So I think your "naive" solution may actually be the right model for SOOD: preserve the original endpoint and let subsequent unicast communication use normal routing, rather than making Netflector part of that unicast conversation.
That also seems to fit the output-device case you mentioned. Netflector would not need to decide whether a "Q" semantically represents a discovery query from a Remote or an announcement/discovery packet from an output device. It can simply relay the SOOD packet while preserving its original source identity.
There is another detail which seems relevant to your question about unicast responses. Aaron Turner's Roon Wireshark dissector indicates that, besides the normal Roon Server discovery on UDP/9003, there is also a Roon Discovery service where replies may originate from an ephemeral UDP port and the dissector therefore uses conversation tracking. To me that is another argument in favour of preserving the original source IP and port rather than introducing SOOD-specific response translation.
One implementation detail from udp-proxy-2020 may also be worth keeping in mind. In addition to BPF capture/injection it opens a normal UDP listener on the configured port and discards anything received there. That was added because ICMP Port Unreachable responses could otherwise cause problems for Roon clients, particularly iOS clients over VPN. I don't know whether that will be relevant to Netflector on OPNsense, but it seems worth being aware of when testing a first implementation.
So I would definitely start with the simple source-IP/source-port preserving model. If you build an initial SOOD implementation that way, I would be very happy to test it with Roon Remote over WireGuard and also with the Roon server/output side.
#15
26.7 Series / Re: Wan connection fails after upgrading to 26.7.3
September 02, 2026, 03:25:35 PM
Thanks for the update. Your gateway-group finding prompted me to check my configuration as well.
I also found an old unused gateway group. It contained only `WAN_DHCP6` as Tier 2 and was not referenced by any firewall rule, so I removed the group through the GUI and applied the configuration.
However, this does not appear to be the root cause on my system.
After removing the unused gateway group, I kept my existing `radix4` workaround active and then tried to switch the IPv4 FIB algorithm live back to `radix4_lockless`:
sysctl net.route.algo.inet.algo=radix4_lockless
This failed immediately:
net.route.algo.inet.algo: radix4
sysctl: net.route.algo.inet.algo=radix4_lockless: Invalid argument
At the same time the kernel logged a new failure:
[fib_algo] inet.0 setup_fd_instance: radix4_lockless algo instance setup failed, failures=0
The active algorithm therefore remained `radix4`.
My WireGuard IPv4 route and connectivity remained correct during the test, but this was because the switch to `radix4_lockless` never succeeded:
route to: 10.10.10.2
fib: 0
interface: wg0
So in my case, removing the old unused gateway group did not make `radix4_lockless` usable again.
For now I therefore still need:
net.route.algo.inet.algo=radix4
as the workaround.
This suggests that an incomplete or stale gateway group may be a trigger in some configurations, but it does not appear to be the sole cause of the `radix4_lockless` setup/rebuild failure.
I have not rebooted after removing the group; this was a live test while keeping the persistent `radix4` tunable in place.
DEC850v2 / OPNsense 26.7.3_8 / PPPoE / WireGuard
I also found an old unused gateway group. It contained only `WAN_DHCP6` as Tier 2 and was not referenced by any firewall rule, so I removed the group through the GUI and applied the configuration.
However, this does not appear to be the root cause on my system.
After removing the unused gateway group, I kept my existing `radix4` workaround active and then tried to switch the IPv4 FIB algorithm live back to `radix4_lockless`:
sysctl net.route.algo.inet.algo=radix4_lockless
This failed immediately:
net.route.algo.inet.algo: radix4
sysctl: net.route.algo.inet.algo=radix4_lockless: Invalid argument
At the same time the kernel logged a new failure:
[fib_algo] inet.0 setup_fd_instance: radix4_lockless algo instance setup failed, failures=0
The active algorithm therefore remained `radix4`.
My WireGuard IPv4 route and connectivity remained correct during the test, but this was because the switch to `radix4_lockless` never succeeded:
route to: 10.10.10.2
fib: 0
interface: wg0
So in my case, removing the old unused gateway group did not make `radix4_lockless` usable again.
For now I therefore still need:
net.route.algo.inet.algo=radix4
as the workaround.
This suggests that an incomplete or stale gateway group may be a trigger in some configurations, but it does not appear to be the sole cause of the `radix4_lockless` setup/rebuild failure.
I have not rebooted after removing the group; this was a live test while keeping the persistent `radix4` tunable in place.
DEC850v2 / OPNsense 26.7.3_8 / PPPoE / WireGuard
