benaclejames
OSC Query broadcasts in the local area network instead only localhost
I noticed that OSC Query seems to announce itself on the local network. This causes other VRC clients in the same network to try connect to it:
2025.03.07 00:22:24 Debug - no SRV Records found in not parse answer from 172.16.1.170:5353 2025.03.07 00:22:24 Debug - Found new OSC Service: VRCFT-NHM5HG at 127.0.0.1:57440 2025.03.07 00:22:26 Error - Could not make new OscClient: An error occurred while sending the request
In the log example above you see that the request seems to come from a different machine than mine. My local IP is 172.16.1.28 and 170 my main PC running VRCFT. OSC query should only announce itself on the loopback interface otherwise it will confuse other clients in the LAN.
Update:
I tried to mitigate this issue by announcing the service on the loopback interface only but VRC doesn't seem register it in that case. I created an upstream issue for this as I think this should be fixed in two locations.
https://github.com/vrchat-community/osc/issues/169
There are a myriad of problems with the current oscquery implementation that are being worked on. Unfortunately, only broadcasting on the loopback device is not really a long term fix, as VRCFT should be able to function over the network (in the future). This is required for standalone support (Quest, Pico, etc). I don't think VRC has a solution to really support oscquery with multiple VRChat clients on the same network ?
I don't think the current setup should cause any issues, though. At the moment VRCFT only responds to multicast announcements from the local machine:
https://github.com/benaclejames/VRCFaceTracking/blob/master/VRCFaceTracking.Core/mDNS/MulticastDnsService.cs#L233-L238
So although VRCFT's response is broadcast to the whole network, the remote VRC will just try to connect to localhost and fail. Are you experiencing problems with this outside of VRC logging the failure to connect ?
The current implentation does cause issues. The issue has some sort of impact in the game loop as it tries to reconnect for eternity. I only noticed this issue because it has impact on the client and on world logic. E.g. worlds that use Midi can crash when the client tries to connect for a longer period of time. I have tested this on 3 different systems and the result is always the same.
True, this might be a VRC issue but the implementation is flawed and should not be used for any future features without addressing these issues. Also keep in mind that some VR-Arcades do have multiple clients in a network.
As workaround I added a firewall rule to drop any incoming traffic from the other client in windows but this has to be addressed as it makes no sense to announce a localhost service on a network interface that doesn't even have the same network address assigned. You only announce multicast on an interface where you are in scope.
The problem is that in the long run, VRCFT shouldn't only be announcing a localhost address. For it to support standalone clients, or running on remote PCs, it will need updating to advertise a LAN address. This is required to support Quest/Pico versions of VRChat, or to offload Babble/ETVR to a second PC, etc.
SlimeVR recently added support for OSCQuery, it might be worth checking how they're handling the scenario of multiple VRC clients. If they are at all..