|
|
This needs to be added, as the Linux and Mac OS X server builds already support it, and are forcefully overriding IPv4 addresses where able. |
|
|
|
This appears to be partially supported in the Windows server now after cURL was updated, however there are still some caveats that require us to go over the network code and configuration files to fully support it. I believe the client is also lacking the ability to correctly enter in IPv6 addresses, although I'm not sure how it will actually handle attempting to connect with them once it does. We may need to update it in order to do so. |
|
|
|
This needs to be a requirement for 0.6 now. The server listing not only supports it, but Windows versions of the server are forcefully outputting IPv6 addresses prioritized over IPv4 on host systems that support IPv6. Support doesn't appear to be a problem on the server's end at all anymore as of 0.6 Nightly 2, but the client definitely needs this added to utilize IPv6 and connect to these servers properly.
Someone with C++ knowledge should be able to address this in the client by updating the related functions and applicable file includes so that both IPv4 and IPv6 can be used. The 0.6 Nightly 2 client also already allows IPv6 addresses to be input in the Quick Connect menu, as it doesn't limit the input length, however it doesn't know how to handle these addresses, and immediately errors before even showing the main client UI. (IPv4 addresses that would time out or fail correctly navigate to the main UI before failing, showing the connection attempt). |
|
|
|
Upon further inspection, it appears that the CLuaSockets may also need to be updated in the server to fully support IPv6 properly with scripting.
During some tests with an IPv4/IPv6 dual upgrade on the client on Windows, I was able to bypass the original error message and have the main UI attempt to connect, however it was not successful in connecting at all. If the logic can be properly worked out, this may not be too difficult to correct for full support in the client with minimal code changes, however it will require one of the Developers to fix, as I do not have the C++ knowledge to do this myself. |
|
|
|
There appears to be another bug with IPv6 in MTAServer's console on Windows. It does not display the address. This also appears to be an issue with Mac OS (aka Mac OS X) and *nix builds. |
|
|
|
Regarding my previous comment, there seems to be something weird going on here. It doesn't show the address if not specified, however IPv4 specification will, but won't bind to the IPv4 address if IPv6 is present, leaving no way to override the connection despite the feature's intent. I have not tried with IPv6 to see if it will display or not yet, however if IPv6 is present, it will force that bind regardless, so the underlying issues definitely need fixing. I'm also unable to query MTAServer on IPv4 if IPv6 is active, even if the IPv4 bind attempt is done. (Manual querying via IPv6 is not currently implemented in the web interface, however MTAServer for 0.6-Nightly 2 does support sending it's IPv6 address to the server listing on its own. MTAServer 0.6-Nightly 1 behaves the same way as 0.5r2 and earlier versions of MTAServer where IPv6 is not usable or visible at all). |
|
