netflector available as plugin (mDNS, SSDP, DIAL, WSD, WoL reflector)

[RamSense]

@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.

[UnicronHD]

@RamSense Thanks, that confirms the peers change does what it should: the copy carries the server's own source, and the multicast and broadcast errors are gone.

On the endpoint problem. The ICMP you captured goes from the phone to the server, so it tells us the Roon app had no socket open on 9003 at that moment: the phone cannot answer the server's query while its port is closed, which is exactly "not an endpoint". The open question is why the port was closed. Two candidates: the app was in the background (iOS suspends it, and Roon holds its listener only in the foreground), or something made the app drop the socket while it was up. udp-proxy-2020's finding was the second kind, but that needs an ICMP port unreachable arriving at the phone, and there is none in what you sent. netflector's host does not hold port 9003 open, so if the phone ever sends unicast 9003 traffic to one of the OPNsense addresses, OPNsense would answer with exactly that ICMP. Whether that happens depends on where the 350-byte packets go.

Could you check:

• The exact destination address of the 350-byte packets on wg0, and whether their payload is a SOOD query or a reply.
• Any ICMP toward the phone on wg0: tcpdump -ni wg0 icmp and dst host 10.10.10.2.
• The wg0 address and prefix on OPNsense, and the phone's tunnel address and prefix (/24 or /32).
• Whether the Roon app was in the foreground when you captured the port-unreachable from the phone.
• Which OS the Roon Core runs on.