[Errno 57] Socket is not connected

[crypto-sami]

Hello, when I run this piece of code to get the players online, it tells me the number of players online however throws out an error when I query to see which players are online. I have the port forwarding set up correctly and the server is ran on Debian 11 in a docker container.

[PerchunPak]

Can you provide all commands to reproduce?

[PerchunPak]

Also, it would be greate if you could try this sample from #538 (comment).

Nevermind, just saw that you use query. Is the status okay? Is the async status and async query okay? Try to run this.

import asyncio
import mcstatus

server = mcstatus.JavaServer.lookup("mc.sturk.au:25565")

async def test():
    try:
        server.status()
    except Exception as exc:
        print(f"Status is not okay: {exc}")
    else:
        print("Status is okay")

    try:
        await server.async_status()
    except Exception as exc:
        print(f"Async status is not okay: {exc}")
    else:
        print("Async status is okay")

    try:
        await server.async_query()
    except Exception as exc:
        print(f"Async query is not okay: {exc}")
    else:
        print("Async query is okay")


if __name__ == "__main__":
    asyncio.run(test())

[crypto-sami]

hello i ran that and it returned an error, what do you mean all commands to reproduce? as in the whole error message?

File "c:\Users\Sami\Documents\VSCode Projects\python-ssh\main.py", line 4, in
server = mcstatus.lookup("mc.sturk.au:25565")
AttributeError: module 'mcstatus' has no attribute 'lookup'

[PerchunPak]

Oh, my error. Updated the comment, try again.

what do you mean all commands to reproduce?

How do you run the container?

[crypto-sami]

i ran it now and it says both status and async status is ok however it said async query is not ok. Its just a paper mc server within a docker container, to run i just run a basic .sh file i set up

[PerchunPak]

Nevermind, I reproduced it with docker.io/library/python:3.11-slim.

Run mcstatus mc.sturk.au query > log.txt command and send here unedited content of the log.txt file please.

[crypto-sami]

this is what was put in the log.txt
The server did not respond to the query protocol.
Please ensure that the server has enable-query turned on, and that the necessary port (same as server-port unless query-port is set) is open in any firewall(s).
See https://wiki.vg/Query for further information.

[crypto-sami]

i run the staff++ plugin, i dont think this should cause any issues. I also only have the port 22565 open on my router settings. I haven't set a certain query port in the server config properties

[kevinkjt2000]

Query must be enabled in server.properties. Additionally, the UDP port for query defaults to 25565, and any firewalls must also allow the UDP traffic.

[ItsDrike]

Yeah, this is probably just another query isn't enabled or accessible issue, but what surprises me is the error message. I'd expect the error on connection getting established, not on closing.

[kevinkjt2000]

Well the error is that the socket was never connected. The exit methods attempt a losing a socket that was never connected.

[kevinkjt2000]

Closing this as a duplicate of #489

[ItsDrike]

Yes, but I wouldn't even expect it to make it past __init__ on the UDPSocketConnection connection, since connection establishing would fail with an exception. It's weird that it's getting into __exit__, and attempting a close in the first place, as that would imply that the connection was somehow established, doesn't it?

mcstatus/mcstatus/server.py

Line 193 in 0f66b5c

async with UDPAsyncSocketConnection(address, self.timeout) as connection:

mcstatus/mcstatus/protocol/connection.py

Line 548 in 0f66b5c

self.socket = socket.socket(

Although now that I'm thinking of it, UDP connections don't really do any sort of handshake, so I suppose it makes sense.

[PerchunPak]

Sorry for such delay, just want to mention that I got TimeoutError when tested it. I think, just the screenshot in the head of the issue is not full.

[ItsDrike]

Yeah, the screenshot not being complete makes a lot more sense actually, even though UDP would probably indeed let you get past __init__ as there's no initial handshake, during query, you'd still need to actually send/receive traffic, and it's at that moment where the error would absolutely happen. But at that point, you're already within a context manager, and so __exit__ will get ran even if there was an exception, triggering another exception encountered during close.