Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data transferring between peers on the localhost doesn't work on macOS #59

Open
kovewnikov opened this issue Jan 6, 2025 · 1 comment · May be fixed by #60
Open

Data transferring between peers on the localhost doesn't work on macOS #59

kovewnikov opened this issue Jan 6, 2025 · 1 comment · May be fixed by #60

Comments

@kovewnikov
Copy link

Hey team, first of all, I want to thank you for adding IPv6 support and other features to the original ENet—nicely done! However, I'm encountering an issue on my Mac

Minimum repro steps:

Server code
#include <iostream>
#define ENET_IMPLEMENTATION
#include <enet.h>

int main(int argc, const char * argv[])
{
    if (enet_initialize() != 0)
    {
        return 1;
    }
    
    ENetAddress localAddress;
    memset(&localAddress, 0, sizeof(ENetAddress));
    enet_address_set_host (&localAddress, "127.0.0.1");
    localAddress.port = 1234;
    ENetHost* server = enet_host_create (&localAddress, 32, 2, 0, 0);
    if (!server)
    {
        exit (1);
    }
    
    while (true)
    {
        ENetEvent event;
        if (enet_host_service (server, &event, 1000) > 0)
        {
            printf("Got event %d\n", event.type);
        }
    }
    
    enet_host_destroy(server);
    enet_deinitialize();
    return 0;
}
Client code
#include <iostream>
#define ENET_IMPLEMENTATION
#include <enet.h>

int main(int argc, const char * argv[])
{
    if (enet_initialize () != 0)
    {
        return 1;
    }
    
    ENetAddress localAddress;
    memset(&localAddress, 0, sizeof(ENetAddress));
    enet_address_set_host (&localAddress, "127.0.0.1");
    localAddress.port = 8973;
    ENetHost* client = enet_host_create (&localAddress, 1, 2, 0, 0);
    if (client == NULL)
    {
        exit (1);
    }
    
    ENetAddress remoteAddress = localAddress;
    remoteAddress.port = 1234;
    ENetPeer* remoteServer = enet_host_connect (client, &remoteAddress, 2, 0);
    if (remoteServer == NULL)
    {
        exit (1);
    }
    
    ENetEvent event;
    /* Wait up to 5 seconds for the connection attempt to succeed. */
    if (enet_host_service (client, & event, 5000) > 0 &&
        event.type == ENET_EVENT_TYPE_CONNECT)
    {
        std::printf("Connection to server is succeeded.\n");
    }
    else
    {
        enet_peer_reset (remoteServer);
        std::printf("Connection to server is failed. Either the 5 seconds are up or a disconnect event was received.\n");
    }

    enet_host_destroy(client);
    enet_deinitialize();
    return 0;
}
Client output
Connection to server is failed. Either the 5 seconds are up or a disconnect event was received.

So, as you can see, the client never connects to the server.

Notes:

  • It seems like the culprit is enet_socket_receive - because after receiving the message via recvmsg the sockaddr_in6 sin actually contains sockaddr_in (the field sin6_family is set to AF_INET instead of AF_INET6) ¯\_(ツ)_/¯
  • Explicitly setting the IPv6 localAddress during socket creation/binding, like this:
    enet_address_set_host (&localAddress, "::ffff:127.0.0.1"); doesn't help
  • Explicitly setting the localAddress as "any" like this:
    localAddress.host = ENET_HOST_ANY;
    instead of
    enet_address_set_host (&localAddress, "127.0.0.1"); doesn't help.

Environment:

  • macOS: Sequoia 15.2
  • Xcode 16.2
  • Apple M1 max
kovewnikov added a commit to kovewnikov/enet that referenced this issue Jan 6, 2025
@zpl-zak
Copy link
Member

zpl-zak commented Jan 6, 2025

Hey,

I don't have a way to validate this issue on IPv6 stack right now unfortunately, but if the proposed fix works well and does not affect IPv4-only set up anyhow, we'd gladly accept a PR to get it merged in.

Thank you for looking into the issue!

@zpl-zak zpl-zak linked a pull request Jan 6, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants