[BDS-3989] Default server port is used even if another port is defined

Summary
When non-standard ports are available, BDS will use the standard ports as the "additional" automatic ports (BDS-1094) rather than ones from the normal random range.

Steps to Reproduce:

Modify server-port and server-portv6 to 19131 and 19134 respectively
Start server
Note that the additional open ports are 19132 and 19133 rather than from the usual random range

What I expected to happen:
The additional ports should be from a higher, unused range

How this impacts server owners:
If you have 2 servers, one that is configured to run on 19132 and 19133 (BDS A) and another to run on 19134 and 19135 (BDS B). If when starting the server, BDS B starts before BDS A it will consume 19132 and 33 as its random ports preventing BDS A from starting (due to ports being in use)

Original description moved to comments for clarity

Linked issues

is duplicated by 3

BDS-4552 Server always listens on port 19132 even if another port is set Resolved

BDS-4620 Server listens on more than 2 ports when server.properties is configured to use non-default ports. Resolved

BDS-9819 When using other port numbers than default, default ports are still locked/in use Resolved

relates to 1

BDS-1094 Additional IPv4 and IPv6 port opening upon starting server Resolved

Comments 25

migrated 2020-01-19T07:02:35Z

I am having this issue in 1.14 as well. If I start the server on 19132 first, starting the one on 19134 doesn't try to use 19132, however, the server is not able to be connected to.

migrated 2020-01-19T07:02:35Z

I am having this issue in 1.14 as well. If I start the server on 19132 first, starting the one on 19134 doesn't try to use 19132, however, the server is not able to be connected to.

migrated 2020-05-27T08:49:43Z

Original Description by @unknown:
From server.properties:

server-port=19131
server-portv6=19134

When server is ran:

{{… }}INFO] IPv4 supported, port: 19131
{{… }}INFO] IPv6 supported, port: 19134
{{… }}INFO] IPv4 supported, port: 19132
{{… }}INFO] IPv6 supported, port: 19133
{{… }}INFO] Server started.

As you can see, the server ran on defined ports, but also on default ones.

It looks like the server always runs 2 other ports after running on the ones defined in server.properties.

In instance, if you set default ports in server.properties, the server adds two random ports.

Example:

{{… }}INFO] IPv4 supported, port: 19131
{{… }}INFO] IPv6 supported, port: 19134
{{… }}INFO] IPv4 supported, port: 42484
{{… }}INFO] IPv6 supported, port: 54985
{{… }}INFO] Server started.

I don't see why it should do such a thing. Especially that if the ports are random, we can't create a proper firewall rule for them.

Finally, I want to point out that this behavior is new and wasn't present in 1.11.2.1. Here is a typical output from the latter:

{{… }}INFO] IPv4 supported, port: 19131
{{… }}INFO] IPv6 supported, port: 19134
{{… }}INFO] Server started.

This issue is preventing me from launching 2 servers as services; one on default ports (needed) and another on other ports because the one that doesn't use default port may occupy default ports if ran first. This would make the other server unable to run because the ports are already in use.

migrated 2020-05-27T08:49:43Z

Original Description by @unknown:
From server.properties:

server-port=19131
server-portv6=19134

When server is ran:

As you can see, the server ran on defined ports, but also on default ones.

It looks like the server always runs 2 other ports after running on the ones defined in server.properties.

In instance, if you set default ports in server.properties, the server adds two random ports.

Example:

I don't see why it should do such a thing. Especially that if the ports are random, we can't create a proper firewall rule for them.

Finally, I want to point out that this behavior is new and wasn't present in 1.11.2.1. Here is a typical output from the latter:

{{… }}INFO] IPv4 supported, port: 19131
{{… }}INFO] IPv6 supported, port: 19134
{{… }}INFO] Server started.

migrated 2020-06-24T08:55:11Z

I can confirm the issue in 1.16 as well

15 more comments

migrated 2020-06-24T08:55:11Z

I can confirm the issue in 1.16 as well

migrated 2020-07-13T19:56:37Z

This is confirmed in 1.16.1.

migrated 2020-07-13T19:56:37Z

This is confirmed in 1.16.1.

kmpoppe 2020-12-15T21:59:00Z

This issue still persists in 1.16.201 as of December 15th, 2020 and has also been in 1.16.100 and 1.16.200 (if affected versions shall be updated)

@@unknown, is there any chance for this Bug to be fixed any time soon? As a Linux bedrock server user with multiple different worlds for different groups it's a real pain in the backside to have only one server running at any given time.

Thank you for updating us!

Kai

migrated 2020-12-19T15:29:43Z

I can confirm this issue on multiple versions of the Bedrock Linux server I’ve tried through 2020. I have resorted to rather hacky work arounds. The network code for the Linux port appears quite defective. Why isn’t this being prioritized or addressed?

migrated 2020-12-19T15:29:43Z

migrated 2021-01-28T10:38:47Z

Can confirm this also happening with windows version 1.16.201.2 on Windows 10.

It is a real PITA since if my default server crashes, and my secondary server restarts, it takes up the default port.

Took me a while the first time to figure out why the default port was already in use...

migrated 2021-01-28T10:38:47Z

Can confirm this also happening with windows version 1.16.201.2 on Windows 10.

It is a real PITA since if my default server crashes, and my secondary server restarts, it takes up the default port.

Took me a while the first time to figure out why the default port was already in use...

migrated 2021-01-30T12:15:19Z

As it really is a problem to navigate around, it should be fixed at last.

migrated 2021-01-30T12:15:19Z

As it really is a problem to navigate around, it should be fixed at last.

kmpoppe 2021-03-20T17:07:11Z

I bet you know what I was gonna comment, still affects 1.16.210.06.

migrated 2021-04-25T03:37:59Z

I recently came across this bug and am similarly frustrated with how long this has been open. It looks like Mojang is opening those for "auto-discovery" to work but if you don't care about that, this is seriously annoying.

For those using Linux, I do have a quick, exceedingly ugly hack to work around this though. This is, admittedly, hideous. But it works!

tldr, this hooks calls to glibc bind() and, if the requested port is 19132 or 19133, redirects it into the ephemeral range (typically 32768-61000) where they won't get in the way of anything. Yes, it would be much cleaner to simply not open them at all, but this is simply transparent to bedrock_server (it just thinks it opened the ports and nobody is connecting to them).

Working happily with multiple bedrock_server instances on one system (obviously no auto-discovery) and using BedrockConnect (which uses the default ports).

/*
 * An incredibly ugly hack to hook bedrock_server's
 * superfluous bind to the default ports (19132 and 19133)
 * and redirect them out of the way into the ephemeral range
 *
 * Instructions:
 * Save this file as bindhook.c in the same dir as bedrock_server
 * compile with `gcc -o libhook.so -shared -fPIC -ldl bindhook.c`
 * run with `LD_PRELOAD=./libhook.so ./bedrock_server`
 */

#define _GNU_SOURCE
#include <dlfcn.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stddef.h>

int bind (int fd, const struct sockaddr *sk, socklen_t sl) {
    static int (*real_bind)(int, const struct sockaddr *, socklen_t) = NULL;
    static struct sockaddr_in *sk_in;
    uint16_t port;

    if (!real_bind)
        real_bind = dlsym(RTLD_NEXT, "bind");
    // AF_INET or AF_INET6, sin_port is in the same place
    sk_in = (struct sockaddr_in *) sk;
    port = ntohs(sk_in->sin_port);
    if ((port == 19132) || (port == 19133))
        sk_in->sin_port = htons(0);
    return real_bind(fd, sk, sl);
}

This should theoretically be possible on Windows as well using DLL injection and API hooks, but it is much more involved than a simple call to dlsym() and I haven't really worked on Windows for 20+ years at this point.

migrated 2021-04-25T03:37:59Z

For those using Linux, I do have a quick, exceedingly ugly hack to work around this though. This is, admittedly, hideous. But it works!

Working happily with multiple bedrock_server instances on one system (obviously no auto-discovery) and using BedrockConnect (which uses the default ports).

/*
 * An incredibly ugly hack to hook bedrock_server's
 * superfluous bind to the default ports (19132 and 19133)
 * and redirect them out of the way into the ephemeral range
 *
 * Instructions:
 * Save this file as bindhook.c in the same dir as bedrock_server
 * compile with `gcc -o libhook.so -shared -fPIC -ldl bindhook.c`
 * run with `LD_PRELOAD=./libhook.so ./bedrock_server`
 */

#define _GNU_SOURCE
#include <dlfcn.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <stddef.h>

int bind (int fd, const struct sockaddr *sk, socklen_t sl) {
    static int (*real_bind)(int, const struct sockaddr *, socklen_t) = NULL;
    static struct sockaddr_in *sk_in;
    uint16_t port;

    if (!real_bind)
        real_bind = dlsym(RTLD_NEXT, "bind");
    // AF_INET or AF_INET6, sin_port is in the same place
    sk_in = (struct sockaddr_in *) sk;
    port = ntohs(sk_in->sin_port);
    if ((port == 19132) || (port == 19133))
        sk_in->sin_port = htons(0);
    return real_bind(fd, sk, sl);
}

owlfalls35 2022-04-07T19:48:57Z

This is also annoying because it means that friends can't join a single-player world even if the server is on a different port.

kmpoppe 2022-05-12T21:17:28Z

As @Thomas Walker said, my guess is that these ports are used for auto-discovery.

For security reasons I sincerely think, that server admins of small / family- / church- / school-servers should be able to deactivate the auto-discovery for publicly accessible IPs through server.properties.

I dunno, @Mojang, if you really think auto-discovery should stay non-deactivatable and thus us being unable to run multiple worlds on one machine, could we please get a "won't fix" on this issue so that people stop reporting and checkin on this issue every so often?

Thx!

kmpoppe 2023-06-17T19:30:51Z

@Mods, I guess this issue can be closed as there is now the option to turn the default port discovery on and off since 1.19.50 (See BDS-1094)

migrated 2023-06-18T15:17:53Z

@Kai, do you confirm that the port is not used if the new option is toggled?

migrated 2023-06-18T15:17:53Z

@Kai, do you confirm that the port is not used if the new option is toggled?

migrated 2023-12-20T13:05:25Z

This issue is still a problem and causes severe issues when running multiple servers on the same machine. If BDS finds the default port open it will automatically bind to that port, however, when people try to connect to that port, it will show that the server is popular which makes no sense.

This is a serious issue and needs to be fixed, its a shame this has been open for as long as it has.

EDIT:

Set `enable-lan-visibility=false` in `server.properties`.

migrated 2023-12-20T13:05:25Z

This is a serious issue and needs to be fixed, its a shame this has been open for as long as it has.

EDIT:

Set `enable-lan-visibility=false` in `server.properties`.