Same issue here, tried Chrome and Safari.

I forgot to mention that my app has a direct connect method for when broadcast discovery doesn’t work on a user’s network. In this case the user enters the IP address of the PC running the server and the port to connect on. For the small number of users that can no longer connect post iOS 16 update this mode isn’t working either. So perhaps I was wrongly focusing on the broadcast aspect of it? I’m not sure I know enough to answer all your questions. Part of the idea of using Unity with Lidgren was that I wouldn’t have to know about the nitty gritty details of each platform. It has worked since I ported the app to iOS in 2018 ¯_(ツ)_/¯ While digging into Lidgren I can see in direct connect mode it still binds to the LocalAddress configuration parameter that I leave at the default value of IPAddress.Any. Port is also left at 0. When bound it takes any free port usually somewhere above 40000. var ep = (EndPoint)new NetEndPoint(localAddress, reBind ? m_listenPort : m_configuration.Port); m_socket.Bind(ep); When sending the following code is hit: int bytesSent = m_socket.SendTo(data, 0, numBytes, SocketFlags.None, targetCopy); In direct mode the targetCopy has the IP and port as entered by the user. Default port of my server is 9999 but can be configured to anything valid and free. When using discover mode a discovery message is first sent to "255.255.255.255:9999" after connection is established the targetCopy variable sends to the specific end point found eg: "192.168.188.46:9999". So as Lidgren gives me the LocalAddress parameter to bind to a specific interface would the possible solution be to find the address of the correct adapter and set it to that? But as I think I’ve seen mentioned there is no way to ensure we can get the address of the primary interface? I’ll have to look at how much work it is to integrate Bonjour into the current app if that is the best way forward.

Hello, Thanks for answering. The code that is failing isn’t making the en0 assumption, it is using an open source C# network library called Lidgren: https://github.com/lidgren/lidgren-network-gen3 Lidgren binds to the local address 0.0.0.0:0 which I understand means the socket will listen on all interfaces. This library that was previously working pre update for the users is attempting to discover a server running on their local network. I saw the other thread about assuming the interface is called en0. I use the same code snippet elsewhere in my app when the user is playing with a game console, they need to enter their devices IP address into the games settings and it will send the UDP packets directly to that address. As a convenience for the user I use the same code snippet with the en0 assumption to let them know the address of their device to type into the game settings. After seeing your suggestion that this assumption might be related to these network issues I asked one of my users who is having connectivity issues using the Lidgren code to discover his PC server to switch to console mode in my app as a test and see if the IP address of his device was reported. He did successfully have the iPhone IP Address printed in the log. So I’m thinking the code that assumes the interface name may be unreliable in theory but isn’t the cause of the current issues. PS: I’d assume most of us picked this code up at this stackoverflow thread: https://stackoverflow.com/questions/30748480/swift-get-devices-wifi-ip-address Interestingly enough I haven’t heard from any console users having issues. In that mode I use System.Net.Sockets.UdpClient to listen for data. This is making me think the issue is when Lidgren tries to discover local peers by sending a discovery message using the System.Net.IPAddress.Broadcast address that resolves to 255.255.255.255. I believe as the app has Multicast Networking capabilities this should be allowed work.