I don’t think change engine code is a good solution, create a class public from the IpConnection and then configure the engine.ini to use it should be a better solution.
And the user should not need to check if the address is ipv6, the design of the InetAddress class is to avoid low level operation on a specific protocol.
Hi. I’ve seen Your solution and it is really nice. Also - your solution should be inside the engine’s IpConnection.cpp, because the original one is bugged.
The main issue in the original code is that in LowLevelSend it copies resolved address into 4 bytes uint32, which will completely break everything if the address is ipv6. So, the original code breaks the convention of protocol transparency.
Also, I suggest to check if Your solution works in real live IPv6 environment. When I was working on the solution to this I’ve been testing it in this nat64 enviro provided by MacOSX and everything worked fine, but in real IPv6 network on mobile device there were still issues.
Also check if this code will still work with connections IPv6->IPv6, IPv4->IPv4 and IPv6->IPv4. Not sure if host resolving is currently right for all situations.
Anyway, realy neat solution 
I’ve been doing it on 4.18.something, hmm… Check the @feiwu solution it should work really nice without engine modification.
Hi Zompi, our programmer decied to try your solution first (he have his own reassons i think). We performed the engine changes in UE 4.18.1, everything still working as expected in a IPV4 client network, but when we trying to connect to the server from a IPV6 client network it returns Host name resolution failed with 51 error. We’re testing the connection using windows client and server.
What we do:
- We compiled the moded engine (4.18.1)
- We Compiled our project using the moded engine
- We packaged a windows version of our client and dedicated server (debug)
- We opened our dedicated server in the desired remote pc (default port: 7777)
- We executed our client (in a pc with ipv6 network only, not the apple simulation, is a real one)
- We openend the console
- We executed OPEN hostname.com
- It returned the mentioned error
Our hostname is a DNS with our ipv4 and ipv6 addresses.
Have you a idea about what is happening?, thanks in advance.
LOGS: https:///74B1L3hM
Hi!
First of all, I have to admit… I’ve never tried to make it work on Windows… Because we’re working on mobiles here, we’ve been testing it on IOS, Android and building dedicated server application for Linux.
But as far as I understand - you’ve enabled IPv6 for Windows (SocketSubsystemWindows should inherit from FSocketSubsystemBSDIPv6).
Quick look to the google and the error code 51 is:
“An MX record is returned but no A record—indicating the host itself exists, but is not directly reachable.”
Soo… it seems the DNS does not return the valid IP address (or it didn’t return it at all). Have you tried to ping it? Are you sure it works? Does it point directly to the host machine address?
We’ve been testing this on Amazon EC2 machines, so it was easy for us to configure the environment there.
The other hint I have is to set such hints:
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
Sadly this is the only feedback I’m able to provide… Please inform if anything helped!
Hi again Zompi, you was right, the client resolves the IPv6 like a charm in android devices. But it does not reach our dedicated server after executing the open hostname.com command. We think that the issue may be related with the platform where our dedicated server is running right now, that is Windows. As we can see the server is listening IPV4 only, but we dont sure.
- [2018.02.28-17.48.57:193][ 0]LogInit: WinSock: I am database1 (IPV4_WAN_ADDRESS:0)
- [2018.02.28-17.48.57:193][ 0]PacketHandlerLog: Loaded PacketHandler component: Engine.EngineHandlerComponentFactory (StatelessConnectHandlerComponent)
- [2018.02.28-17.48.57:194][ 0]LogNet: GameNetDriver IpNetDriver_0 IpNetDriver listening on port 7777
Windows uses Socket Subsystem that inherits from regular FSocketSubsystemBSD, so if you haven’t change that - dedicated server will try to use IPv4 connection.
Fun fact - you can run a dedicated server in IPv4 network and connect to it from the IPv6 network. But then - the server must be inside IPv4 network. Otherwise it will receive IPv6 packets and will have no proper implementation to handle it.
The easiest solution would be to inherit the Windows Socket Subsystem from FSocketSubsystemBSDIPv6.
You can check this article to clarify a lttle: http://zompi.pl/migrating-to-ipv6/