Can not connect to manymine

[I-Am-Skoot]

I setup my three servers and can not see it on the LAN, or when I try to directly connect, I can not connect, and see an error in the manymine logs.

My docker-compose file

version: "4.6"

services:
  manymine:
    image: illiteratealliterator/manymine
    container_name: manymine
    ports:
      - '19132:19132/udp'
      - '19132:19132/tcp'
    environment:
      MM_DISCOVERY_INTERVAL: 5000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  skoot:
    container_name: skoot_server
    environment:
      EULA: TRUE
      SERVER_PORT: 60001
      SERVER_NAME: Skoot
    image: "itzg/minecraft-bedrock-server:latest"
    ipc: "private"
    logging:
      driver: "json-file"
      options: {}
    ports:
      - "60001:60001/udp"
    stdin_open: true
    tty: true
    volumes:
      - "/opt/MCServer/minecraftbe/Skoot:/data"
    working_dir: "/data"
    labels:
      manymine.enable: true
  skootskoot:
    container_name: skootskoot_server
    environment:
      EULA: TRUE
      SERVER_PORT: 60002
      SERVER_NAME: Skoot Skoot
    image: "itzg/minecraft-bedrock-server:latest"
    ipc: "private"
    logging:
      driver: "json-file"
      options: {}
    ports:
      - "60002:60002/udp"
    stdin_open: true
    tty: true
    volumes:
      - "/opt/MCServer/minecraftbe/SkootSkoot:/data"
    working_dir: "/data"
    labels:
      manymine.enable: true
  therealworld:
    container_name: therealworld_server
    environment:
      EULA: TRUE
      SERVER_PORT: 60003
      SERVER_NAME: The Real World
    image: "itzg/minecraft-bedrock-server:latest"
    ipc: "private"
    logging:
      driver: "json-file"
      options: {}
    ports:
      - "60003:60003/udp"
    stdin_open: true
    tty: true
    volumes:
      - "/opt/MCServer/minecraftbe/TheRealWorld:/data"
    working_dir: "/data"
    labels:
      manymine.enable: true

  backup:
    image: kaiede/minecraft-bedrock-backup
    container_name: backups
    restart: always
    depends_on:
      - "skoot"
      - "skootskoot"
      - "therealworld"
    tty: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/MCServer/backups:/backups
      - /opt/MCServer/minecraftbe/Skoot:/skoot_server
      - /opt/MCServer/minecraftbe/SkootSkoot:/skootskoot_server
      - /opt/MCServer/minecraftbe/TheRealWorld:/therealworld_server

networks:
    default:
        external:
            name: mc-network

Output from manymine

Server discovery interval: 5000ms
Server ping interval: 1000ms
Listening for pings at 0.0.0.0:19132
Server added: /skoot_server (4124c60b4ef87226aff48fa88183ed66b73be3f37172beb2bcdfe649ecfad7d7)
Server /skoot_server is running on internal port 60001 and external port 60001
Server added: /therealworld_server (540eae96467ea4cd0d690d4e94c949e48740dab2b88b29c02e659d1727f89dd0)
Server /therealworld_server is running on internal port 60003 and external port 60003
Server added: /skootskoot_server (6cb136dd26621f2a82480c8c51baaf2e353f92dcf0bcf183f8ffefa430d368c0)
Server /skootskoot_server is running on internal port 60002 and external port 60002
/skoot_server (10.250.254.131:60001) changed state from [Initial] to [No Response]
/therealworld_server (10.250.254.128:60003) changed state from [Initial] to [Connected]
Connector: Ignoring unexpected/invalid packet on listen port.
/skootskoot_server (10.250.254.129:60002) changed state from [Initial] to [No Response]
/skootskoot_server (10.250.254.129:60002) changed state from [No Response] to [Connected]
/skoot_server (10.250.254.131:60001) changed state from [No Response] to [Connected]
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1
Ignoring unexpected packet on listen port: open_connection_request_1

Any ideas?

[illiteratealliterator]

Hi @skenigma - your config looks good to me, and manymine seems to have connected to your servers without problem.

Regarding this error in the logs:

Ignoring unexpected packet on listen port: open_connection_request_1

I'm assuming this is from when you tried to "directly connect" (by adding an entry on servers tab?) as this looks like a client was trying to start a session on port 19132 rather than the ports your servers are hosted on.

Your servers should appear under the 'Friends' tab. However, my kids stopped playing Minecraft about a year ago so I haven't been updating my containers. I just pulled latest and downloaded Minecraft on my iPad, and alas, my servers also no longer appear. So it looks like something has changed (likely on the Minecraft client side) which means this method of proxying LAN discovery no longer works.

Sorry, I will try and take a look at it when I get a chance, but I'm not sure when that will be.

[I-Am-Skoot]

Thank you for your diligence @illiteratealliterator. Is there something I can assist with on this?

[pandasuit]

@illiteratealliterator I'm running multiple up to date Bedrock servers (1.19.51.01 as of right now) on my machine and Manymine is still proxying discovery correctly. I just confirmed in Windows and iPhone Minecraft client (latest update) that things still work. My family plays regularly so I'd have heard a lot of complaining if things stopped working :)

Any luck getting this to work @skenigma ?

One thing I'd check is that the Bedrock server is still respecting the SERVER_PORT you are telling it to use. I'm letting it use 19132 inside the container but mapping it to a different port in my compose file (explicitly as udp). Check your Bedrock server logs to see what port it claims to be using. You'll see a line like IPv4 supported, port: 19132: Used for gameplay and LAN discovery.

[illiteratealliterator]

That's good to hear @pandasuit. I just tried what you said, but unfortunately it made no difference for me. I confirmed I'm on the same bedrock version as you (using the itzg container on ubuntu), and I was testing using an iPad client. What client are you using? I won't have a chance to debug what's going on here for about a month unfortunately, due to travel plans.

[pandasuit]

@illiteratealliterator I've tested with iOS, Windows, and Xbox clients now. all working.

I'm using itzg/minecraft-bedrock-server and illiteratealliterator/manymine containers but I'm building local images and running those images instead of the official ones. The only local change I've made to the itzg Dockerfile is I'm forcing OS security updates on build. Likely irrelevant to this issue.

If I find some time I'll try to repro with something closer to skenigma's compose file.

[jtp10181]

So I am not sure what I did exactly but I got this thing to work. Originally I could not get it to work at all. I setup wireshark and added some extra logging to the handleClientPing function as well. I captured some "real" server ping responses and some from ManyMine on wireshark. My intention was to figure out what changed and fix it! Everything looked legit though, a mystery. I started suspecting maybe they had blocked any ports besides 19132 from showing on LAN to prevent people from spoofing remote servers as LAN servers.

Then I changed some ports around and suddenly the server on 19136 showed up and I could connect to it!. So then I took it and moved it to port 19142 and it worked there as well. I moved my other server from 19134 to 19141 and that also worked.

I am setting the SERVER_PORT and the forwarding port to the same thing.

I found that if you leave the SERVER_PORT as 19132 and just forward a different port to it, sometimes the discovery packets go through from the server itself but they have the 19132 port on it which obviously wont work due to the bridge connection and port forwarding.

I am running everything through Portainer using Stacks (compose). I have each server on a separate stack so that I can modify one stack/server and re-apply without restarting everything. I need to clean a few things up now that I got this all working but I may come back and post some examples later.

[jtp10181]

For this to work you would need to create a new bridge network named "minecraft-bridge", or to use a different bridge just change the compose files to match.

Here is my "tools" stack. For the backup service you would need to fix the volume mapping paths for your setup, and there is also a separate config file for the backup settings. The backup service can removed if you don't want to use it.

version: "3.4"

services:
  manymine:
    image: illiteratealliterator/manymine
    container_name: minecraft-manymine
    restart: unless-stopped
    environment:
      MM_DISCOVERY_INTERVAL: 30000
    ports:
      - '19132:19132/udp'
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - minecraft-bridge

  backup:
    image: kaiede/minecraft-bedrock-backup
    container_name: minecraft-backup
    restart: always
    environment:
      TZ: "America/Chicago"
    tty: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /mnt/dietpi_userdata/minecraft/backups:/backups
      - /mnt/dietpi_userdata/docker-data/volumes/minecraft-bedrock_bds/_data:/bds
      - /mnt/dietpi_userdata/docker-data/volumes/minecraft-bedrock2_bds/_data:/bds2
    networks:
      - minecraft-bridge

networks:
  minecraft-bridge:
    external: true

Here is the stack I use for the servers. I use variables so I can duplicate it to make new servers, just have to change the container name.

version: '3.4'

services:
  bds:
    container_name: minecraft-bedrock
    image: itzg/minecraft-bedrock-server
    restart: unless-stopped
    environment:
      EULA: TRUE
      VERSION: LATEST
      GAMEMODE: survival
      DIFFICULTY: normal
      MAX_PLAYERS: 8
      SERVER_NAME: "${SERVER_NAME}"
      SERVER_PORT: ${SERVER_PORT}
      LEVEL_NAME: "${WORLD_NAME}"
      DEFAULT_PLAYER_PERMISSION_LEVEL: visitor
      ALLOW_CHEATS: ${ALLOW_CHEATS}
      TZ: "America/Chicago"
    ports:
      - "${SERVER_PORT}:${SERVER_PORT}/udp"
    volumes: 
      - bds:/data
    labels: 
      - manymine.enable=true
    networks:
      - minecraft-bridge
    stdin_open: true
    tty: true

volumes:
  bds: {}

networks:
  minecraft-bridge:
    external: true

Variables:

SERVER_NAME=Bedrock Server
SERVER_PORT=19141
WORLD_NAME=My World
ALLOW_CHEATS=true

[mruschmann]

I just fought the good fight here. After a few hours I figured out that entries in the "Servers" tab do not show up in the "Friends" tab anymore. This is probably why things like changing the port worked for some. Changing the ports did not work for me. However, I did not try changing the Server Name or World Name after I figured this out.

[jtp10181]

Not sure if you are saying that you got it working or not? Just tried mine out and my server shows up on the "Friends" tab listed under LAN games using Windows, not sure about consoles at the moment but should still be working fine I would assume.

[merval]

Is there anyway to set this up to allow for external players (not connected to my LAN) to connect? When I specify the server in the servers section of minecraft, I get the error mentioned in the creation of this issue. I was hoping to get this setup similar the itzg mc-router.

[jtp10181]

External players should not connect through manymine, just forward the port directly to the Minecraft server. I have two port forwards setup like this and it has worked fine last time we used it. I used different external ports, do not remember why exactly, but they could be the same. The servers are on 19141 and 19142 running in docker.