Wrong source address being used for IPv6 connections in some instances.

[DarkRTA]

On Linux, if you listen on ::0 (an unspecified ipv6 address), LNL does not seem to specify a source address for outgoing UDP packets, and will end up sending replies on a different address than what they were received on. This causes connection attempts to fail as clients get replies from an IPv6 address that is different from the one they are attempting to connect to.

Reproduction steps:

• Start a server listening on ::0 with any free port on a machine with multiple ipv6 addresses.
• Try connecting a client to every IPv6 address on the server machine. Most of them should fail to work as LNL will send the reply to the initial connection packet from a different address than what it was received on.

I won't be able to provide any minimal code examples due to my lack of C# knowledge. I ran across this in an application that uses LNL (Resonite) and determined that the bug is in LNL itself after speaking with Resonite's developers.

[RevenantX]

This is how sockets works? I don't do anything special, just using simple socket. Check with simple sockets maybe this is just specific of IPv6

[DarkRTA]

Yeah this is IPv6 specific and I think may actually be a shortcoming of dotnet's Socket class after I sat down and dug through its documentation.

A feature of IPv6 is the ability to have multiple addresses on a single interface, and software is expected to take a generally well defined set of steps to pick a good source address to communicate with a host when one isn't specified. This works fine for TCP where there is connection tracking, but UDP makes no such provisions. Effectively what is happening here is you could receive a packet on 3fff::4, but your OS may prefer sending from 2001:db8::3 when you go to reply unless you find some way to manually specify what address the packet should be sent from.

I don't think this is an issue if you specify an address to listen on beforehand, but if you listen on ::0 which means listen on all addresses, you can end up with replies being sent from a different address than what you received a packet on, causing clients to get confused and connections failing outright. Unfortunately, after I dug through the documentation of dotnet's Socket class, I didn't see an easy way to specify the source address per packet so its likely this is unfixable without doing something completely different here.

[RevenantX]

@DarkRTA try enable https://revenantx.github.io/LiteNetLib/api/LiteNetLib.LiteNetManager.html#LiteNetLib_LiteNetManager_AllowPeerAddressChange
maybe this will help

[DarkRTA]

Does that handle the case where the server responds on a different IP address than what the client was attempting to connect to?

[RevenantX]

@DarkRTA i cannot check that currently with my setup. But try enable this option on client too.