[BDS-3989] Default server port is used even if another port is defined Created: 05/Aug/19 Updated: 20/Dec/23 Resolved: 07/Jul/23 |
|
| Status: | Resolved |
| Project: | Bedrock Dedicated Server |
| Affects Version/s: | 1.14.32.1, 1.14.60, 1.16.0, 1.16.40 |
| Fix Version/s: | 1.20.1 Hotfix |
| Type: | Bug | ||
| Reporter: | Jahus | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 51 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||
| ADO: | 359891 | ||||||||||||||||||||||||
| Description |
|
Summary Steps to Reproduce:
What I expected to happen: How this impacts server owners: Original description moved to comments for clarity |
| Comments |
| Comment by Smell of Curry [ 20/Dec/23 ] |
|
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`. |
| Comment by Jahus [ 18/Jun/23 ] |
|
@Kai, do you confirm that the port is not used if the new option is toggled? |
| Comment by Kai [ 17/Jun/23 ] |
|
@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
|
| Comment by Kai [ 12/May/22 ] |
|
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! K |
| Comment by GameParrot [ 07/Apr/22 ] |
|
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. |
| Comment by Thomas Walker [ 25/Apr/21 ] |
|
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. |
| Comment by Kai [ 20/Mar/21 ] |
|
I bet you know what I was gonna comment, still affects 1.16.210.06. |
| Comment by Kristian Domke [ 30/Jan/21 ] |
|
As it really is a problem to navigate around, it should be fixed at last. |
| Comment by Pieter Jan Prijs [ 28/Jan/21 ] |
|
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... |
| Comment by Omkhar [ 19/Dec/20 ] |
|
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? |
| Comment by Kai [ 15/Dec/20 ] |
|
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) @OcelotOnesie, 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 |
| Comment by Cr@shedC0w [ 13/Jul/20 ] |
|
This is confirmed in 1.16.1. |
| Comment by /dev/urandom [ 24/Jun/20 ] |
|
I can confirm the issue in 1.16 as well |
| Comment by IonicEcko [ 27/May/20 ] |
|
Original Description by Jahus: server-port=19131 When server is ran: … }}{{INFO] IPv4 supported, port: 19131 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 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 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. |
| Comment by AsherMaximum [ 19/Jan/20 ] |
|
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. |