Upon starting my server, additional and unspecified IPv4 and IPv6 ports were opened. I have specified and forwarded the default IPv6 port and a chosen IPv4 port. Two additional ports opened; one being default IPv4, but the IPv6 was chosen at random.
Linked issues
is duplicated by 6
Attachments
Comments 76
migrated
I have the same problem
I have the same problem
I have the same problem
I noticed this when trying to connect with a custom client.
The server's main ports (19132 and 19133) are facades which don't allow anyone to join but contained within the MOTD ping response is the real ports which the client uses to redirect and connect with. The problem comes with the fact that the second set of ports are random and cannot be specified in the configuration file so you have to keep updating your firewall settings.
This behaviour is found within the client for LAN servers as well so it's likely the changes were not noticed by the BDS team.
I've only opened the default 19132 on IPv4 and 19133 on IPv6 and I can connect on either and play. I need to use a different hostname, or enter the IP addresses directly, which is a Bad Thing, but the extra ports don't seem to be needed. Not sure what they are for.
I've only opened the default 19132 on IPv4 and 19133 on IPv6 and I can connect on either and play. I need to use a different hostname, or enter the IP addresses directly, which is a Bad Thing, but the extra ports don't seem to be needed. Not sure what they are for.
I've only opened the default 19132 on IPv4 and 19133 on IPv6 and I can connect on either and play. I need to use a different hostname, or enter the IP addresses directly, which is a Bad Thing, but the extra ports don't seem to be needed. Not sure what they are for.
I had the same question about the "extra" ports that show up in the console. Looking at a "netstat -ano" on my machine after starting the server, the two ports (19132 and 19133) defined in my server.properties file are open as TCP ports, while the two other, random ports (usually "5XXXX" or "6XXXX") are open for UDP.
It might be useful to at least indicate this in the console to clear up any confusion. For example:
[2020-03-17 16:07:58 INFO] IPv4 supported, port: 19132 (TCP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 19133 (TCP)[2020-03-17 16:07:58 INFO] IPv4 supported, port: 60896 (UDP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 60897 (UDP)
or some other arrangement of the information, but at least showing what protocol each port is using would be helpful.
As for firewall configuration, if these UDP ports are at least selected from a specific, defined range (i.e., 50000-65535), you may be able to set up your port forwarding for that range for just UDP traffic while setting up a TCP-only forwarding rule for just the ports specified in your server.properties file.
I had the same question about the "extra" ports that show up in the console. Looking at a "netstat -ano" on my machine after starting the server, the two ports (19132 and 19133) defined in my server.properties file are open as TCP ports, while the two other, random ports (usually "5XXXX" or "6XXXX") are open for UDP.
It might be useful to at least indicate this in the console to clear up any confusion. For example:
[2020-03-17 16:07:58 INFO] IPv4 supported, port: 19132 (TCP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 19133 (TCP)[2020-03-17 16:07:58 INFO] IPv4 supported, port: 60896 (UDP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 60897 (UDP)
or some other arrangement of the information, but at least showing what protocol each port is using would be helpful.
As for firewall configuration, if these UDP ports are at least selected from a specific, defined range (i.e., 50000-65535), you may be able to set up your port forwarding for that range for just UDP traffic while setting up a TCP-only forwarding rule for just the ports specified in your server.properties file.
I had the same question about the "extra" ports that show up in the console. Looking at a "netstat -ano" on my machine after starting the server, the two ports (19132 and 19133) defined in my server.properties file are open as TCP ports, while the two other, random ports (usually "5XXXX" or "6XXXX") are open for UDP.
It might be useful to at least indicate this in the console to clear up any confusion. For example:
[2020-03-17 16:07:58 INFO] IPv4 supported, port: 19132 (TCP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 19133 (TCP)[2020-03-17 16:07:58 INFO] IPv4 supported, port: 60896 (UDP)[2020-03-17 16:07:58 INFO] IPv6 supported, port: 60897 (UDP)
or some other arrangement of the information, but at least showing what protocol each port is using would be helpful.
As for firewall configuration, if these UDP ports are at least selected from a specific, defined range (i.e., 50000-65535), you may be able to set up your port forwarding for that range for just UDP traffic while setting up a TCP-only forwarding rule for just the ports specified in your server.properties file.
So is this necessarily a bug, or just poor documentation?
To be fair, a "bug" is, by definition, any programming "flaw" - whether intentional or not - resulting in behavior that is unintended or unexpected and the term can be applied to include anything from a simple typo on a dialog box to a severe memory leak, etc. Because the UDP ports are not explicitly configurable, nor is there any indication of what they are in the current console display, I would suggest that this would be considered both a bug and a documentation issue. I believe it's a good thing that this information is displayed to the user so that the ports that are actively in use by BDS can be seen, but not clarifying the intention and/or implementation for the use of these ports is, perhaps, an oversight that can cause confusion, as well as potential connectivity issues since the "random" UDP ports have to be open/forwarded in addition to the TCP ports in order for the client to properly and fully communicate with the server.
More complete documentation - both "internally" (displaying the protocol in the console) and externally (in the "HOWTO" or other implementation guide(s)) - would help to clarify the issue and take it from a "bug" to a "feature", but as there is currently no such documentation (that I've seen), this behavior is "unexpected" and potentially "breaking" for new BDS administrators.
To be fair, a "bug" is, by definition, any programming "flaw" - whether intentional or not - resulting in behavior that is unintended or unexpected and the term can be applied to include anything from a simple typo on a dialog box to a severe memory leak, etc. Because the UDP ports are not explicitly configurable, nor is there any indication of what they are in the current console display, I would suggest that this would be considered both a bug and a documentation issue. I believe it's a good thing that this information is displayed to the user so that the ports that are actively in use by BDS can be seen, but not clarifying the intention and/or implementation for the use of these ports is, perhaps, an oversight that can cause confusion, as well as potential connectivity issues since the "random" UDP ports have to be open/forwarded in addition to the TCP ports in order for the client to properly and fully communicate with the server.
More complete documentation - both "internally" (displaying the protocol in the console) and externally (in the "HOWTO" or other implementation guide(s)) - would help to clarify the issue and take it from a "bug" to a "feature", but as there is currently no such documentation (that I've seen), this behavior is "unexpected" and potentially "breaking" for new BDS administrators.
To be fair, a "bug" is, by definition, any programming "flaw" - whether intentional or not - resulting in behavior that is unintended or unexpected and the term can be applied to include anything from a simple typo on a dialog box to a severe memory leak, etc. Because the UDP ports are not explicitly configurable, nor is there any indication of what they are in the current console display, I would suggest that this would be considered both a bug and a documentation issue. I believe it's a good thing that this information is displayed to the user so that the ports that are actively in use by BDS can be seen, but not clarifying the intention and/or implementation for the use of these ports is, perhaps, an oversight that can cause confusion, as well as potential connectivity issues since the "random" UDP ports have to be open/forwarded in addition to the TCP ports in order for the client to properly and fully communicate with the server.
More complete documentation - both "internally" (displaying the protocol in the console) and externally (in the "HOWTO" or other implementation guide(s)) - would help to clarify the issue and take it from a "bug" to a "feature", but as there is currently no such documentation (that I've seen), this behavior is "unexpected" and potentially "breaking" for new BDS administrators.
I would agree with you, except that on the original issue (listed above), the concern was it creating/choosing a random port to open. I have both the configurations that were specified as well as the result when running BDS. The bug would be a security flaw, when it opens a port (regardless of TCP or UDP) for the express intent to allow traffic. Additionally, the port is chosen at random when you start BDS, thus making it difficult to prevent. This is a security bug and should be patched, to ensure no user inadvertently exposes their networks to unwanted incoming traffic.
TL;DR: The bug is a security risk, by requesting the computer to communicate through a port not specified or directed by the server owner.
I would agree with you, except that on the original issue (listed above), the concern was it creating/choosing a random port to open. I have both the configurations that were specified as well as the result when running BDS. The bug would be a security flaw, when it opens a port (regardless of TCP or UDP) for the express intent to allow traffic. Additionally, the port is chosen at random when you start BDS, thus making it difficult to prevent. This is a security bug and should be patched, to ensure no user inadvertently exposes their networks to unwanted incoming traffic.
TL;DR: The bug is a security risk, by requesting the computer to communicate through a port not specified or directed by the server owner.
I would agree with you, except that on the original issue (listed above), the concern was it creating/choosing a random port to open. I have both the configurations that were specified as well as the result when running BDS. The bug would be a security flaw, when it opens a port (regardless of TCP or UDP) for the express intent to allow traffic. Additionally, the port is chosen at random when you start BDS, thus making it difficult to prevent. This is a security bug and should be patched, to ensure no user inadvertently exposes their networks to unwanted incoming traffic.
TL;DR: The bug is a security risk, by requesting the computer to communicate through a port not specified or directed by the server owner.
Agreed. I over-simplified and unintentionally down-played the issue in my previous comments, but randomly opening arbitrary ports of communication absolutely presents an unnecessary security risk. It may be mitigated through other security measures, but not having clear documentation of what ports are being used, how they are "selected", and their purpose makes doing even that difficult. Not to mention the fact that there are likely a significant number of users who would be unaware of the potential risks involved in simply opening up a range of ports - possibly to both TCP and UDP traffic, "just to be sure" - which could result in even more damage done.
Agreed. I over-simplified and unintentionally down-played the issue in my previous comments, but randomly opening arbitrary ports of communication absolutely presents an unnecessary security risk. It may be mitigated through other security measures, but not having clear documentation of what ports are being used, how they are "selected", and their purpose makes doing even that difficult. Not to mention the fact that there are likely a significant number of users who would be unaware of the potential risks involved in simply opening up a range of ports - possibly to both TCP and UDP traffic, "just to be sure" - which could result in even more damage done.
Agreed. I over-simplified and unintentionally down-played the issue in my previous comments, but randomly opening arbitrary ports of communication absolutely presents an unnecessary security risk. It may be mitigated through other security measures, but not having clear documentation of what ports are being used, how they are "selected", and their purpose makes doing even that difficult. Not to mention the fact that there are likely a significant number of users who would be unaware of the potential risks involved in simply opening up a range of ports - possibly to both TCP and UDP traffic, "just to be sure" - which could result in even more damage done.
The random ports are the ones which the connection takes place over. I believe it's a "hack" of sorts to allow players from the IPv4 port to join with IPv6 and vice versa if preferred by the client. The reason not all people are having problems connecting to their servers may be due to Minecraft's network implementation using UPnP to open the firewall however not all routers, ISPs or firewalls will allow this.
UPnP may indeed be the "culprit" here. However, without documentation of any UPnP "requirements" for BDS, this remains a potentially significant security issue and a problem for some BDS admins. If the admin's router/firewall does not support UPnP, they will have to manually open the randomly chosen/assigned UDP ports for IPv4 and IPv6. Without knowing how BDS is choosing these port numbers or the ability to manually assign them, such users would possibly have to open a wide range of ports for UDP traffic, or be forced to close/open these ports for each BDS restart. Inexperienced admins may open a much wider range of ports than necessary, and may even open both TCP and UDP traffic on those ports.
UPnP may indeed be the "culprit" here. However, without documentation of any UPnP "requirements" for BDS, this remains a potentially significant security issue and a problem for some BDS admins. If the admin's router/firewall does not support UPnP, they will have to manually open the randomly chosen/assigned UDP ports for IPv4 and IPv6. Without knowing how BDS is choosing these port numbers or the ability to manually assign them, such users would possibly have to open a wide range of ports for UDP traffic, or be forced to close/open these ports for each BDS restart. Inexperienced admins may open a much wider range of ports than necessary, and may even open both TCP and UDP traffic on those ports.
UPnP may indeed be the "culprit" here. However, without documentation of any UPnP "requirements" for BDS, this remains a potentially significant security issue and a problem for some BDS admins. If the admin's router/firewall does not support UPnP, they will have to manually open the randomly chosen/assigned UDP ports for IPv4 and IPv6. Without knowing how BDS is choosing these port numbers or the ability to manually assign them, such users would possibly have to open a wide range of ports for UDP traffic, or be forced to close/open these ports for each BDS restart. Inexperienced admins may open a much wider range of ports than necessary, and may even open both TCP and UDP traffic on those ports.
I came across the same bug too. Hope it would be settled.
It is noteworthy that the additional ports tend to be default ones if the ports set in the "server.prosperities" are not default ports.
I came across the same bug too. Hope it would be settled.
It is noteworthy that the additional ports tend to be default ones if the ports set in the "server.prosperities" are not default ports.
I came across the same bug too. Hope it would be settled.
It is noteworthy that the additional ports tend to be default ones if the ports set in the "server.prosperities" are not default ports.
This bug also makes it impossible to run a second instance of Bedrock on the same host server. No matter what port is defined in server.properties, it always says the requested port is in use when it is not.
This bug also makes it impossible to run a second instance of Bedrock on the same host server. No matter what port is defined in server.properties, it always says the requested port is in use when it is not.
This bug also makes it impossible to run a second instance of Bedrock on the same host server. No matter what port is defined in server.properties, it always says the requested port is in use when it is not.
I've not encountered that in my testing. Admittedly, that testing has been extremely limited, but as long as I've got two separate copies of the entire BDS directory structure - including a separate copy of bedrock_server.exe - in individual folders and set the specific ports to different values in each of their respective server.properties files, I was successfully able to get two instances running concurrently on my machine.
I've not encountered that in my testing. Admittedly, that testing has been extremely limited, but as long as I've got two separate copies of the entire BDS directory structure - including a separate copy of bedrock_server.exe - in individual folders and set the specific ports to different values in each of their respective server.properties files, I was successfully able to get two instances running concurrently on my machine.
I've not encountered that in my testing. Admittedly, that testing has been extremely limited, but as long as I've got two separate copies of the entire BDS directory structure - including a separate copy of bedrock_server.exe - in individual folders and set the specific ports to different values in each of their respective server.properties files, I was successfully able to get two instances running concurrently on my machine.
OS: Ubuntu 18.04.4 LTS
This is what I'm seeing...
minecraft@server1:~/bedrock_server$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
minecraft@server1:~/bedrock_server$ grep port server.properties | sed -e 's/^#.*//g' | grep -v ^$
server-port=19232
server-portv6=19233
minecraft@server1:~/bedrock_server$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-02 12:51:37 INFO] Starting Server
[2020-04-02 12:51:37 INFO] Version 1.14.32.1
[2020-04-02 12:51:37 INFO] Session ID ed6a96e2-f484-42bd-b52b-274418abb2aa
[2020-04-02 12:51:37 INFO] Level Name: World Name
[2020-04-02 12:51:37 INFO] Game mode: 1 Creative
[2020-04-02 12:51:37 INFO] Difficulty: 2 NORMAL
[2020-04-02 12:51:37 INFO] opening worlds/World Name/db
[2020-04-02 12:51:39 INFO] IPv4 supported, port: 19232
[2020-04-02 12:51:39 INFO] IPv6 supported, port: 19233
[2020-04-02 12:51:39 INFO] IPv4 supported, port: 19132
[2020-04-02 12:51:39 INFO] IPv6 supported, port: 19133
[2020-04-02 12:51:40 INFO] Server started.
^Z
[1]+ Stopped LD_LIBRARY_PATH=. ./bedrock_server
minecraft@server1:~/bedrock_server$ bg
[1]+ LD_LIBRARY_PATH=. ./bedrock_server &
minecraft@cyclone:~/bedrock_server$ netstat -plan | grep :19[12]3[23]
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
udp 0 0 0.0.0.0:19132 0.0.0.0:* 6674/./bedrock_serv
udp 0 0 0.0.0.0:19232 0.0.0.0:* 6674/./bedrock_serv
udp6 0 0 :::19133 :::* 6674/./bedrock_serv
udp6 0 0 :::19233 :::* 6674/./bedrock_servSo some part of the code is hard-coding those port values - at least in the linux branch of the code.
OS: Ubuntu 18.04.4 LTS
This is what I'm seeing...
minecraft@server1:~/bedrock_server$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
minecraft@server1:~/bedrock_server$ grep port server.properties | sed -e 's/^#.*//g' | grep -v ^$
server-port=19232
server-portv6=19233
minecraft@server1:~/bedrock_server$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-02 12:51:37 INFO] Starting Server
[2020-04-02 12:51:37 INFO] Version 1.14.32.1
[2020-04-02 12:51:37 INFO] Session ID ed6a96e2-f484-42bd-b52b-274418abb2aa
[2020-04-02 12:51:37 INFO] Level Name: World Name
[2020-04-02 12:51:37 INFO] Game mode: 1 Creative
[2020-04-02 12:51:37 INFO] Difficulty: 2 NORMAL
[2020-04-02 12:51:37 INFO] opening worlds/World Name/db
[2020-04-02 12:51:39 INFO] IPv4 supported, port: 19232
[2020-04-02 12:51:39 INFO] IPv6 supported, port: 19233
[2020-04-02 12:51:39 INFO] IPv4 supported, port: 19132
[2020-04-02 12:51:39 INFO] IPv6 supported, port: 19133
[2020-04-02 12:51:40 INFO] Server started.
^Z
[1]+ Stopped LD_LIBRARY_PATH=. ./bedrock_server
minecraft@server1:~/bedrock_server$ bg
[1]+ LD_LIBRARY_PATH=. ./bedrock_server &
minecraft@cyclone:~/bedrock_server$ netstat -plan | grep :19[12]3[23]
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
udp 0 0 0.0.0.0:19132 0.0.0.0:* 6674/./bedrock_serv
udp 0 0 0.0.0.0:19232 0.0.0.0:* 6674/./bedrock_serv
udp6 0 0 :::19133 :::* 6674/./bedrock_serv
udp6 0 0 :::19233 :::* 6674/./bedrock_servSo some part of the code is hard-coding those port values - at least in the linux branch of the code.
OS: Ubuntu 18.04.4 LTS
This is what I'm seeing...
minecraft@server1:~/bedrock_server$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"
minecraft@server1:~/bedrock_server$ grep port server.properties | sed -e 's/^#.*//g' | grep -v ^$
server-port=19232
server-portv6=19233
minecraft@server1:~/bedrock_server$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-02 12:51:37 INFO] Starting Server
[2020-04-02 12:51:37 INFO] Version 1.14.32.1
[2020-04-02 12:51:37 INFO] Session ID ed6a96e2-f484-42bd-b52b-274418abb2aa
[2020-04-02 12:51:37 INFO] Level Name: World Name
[2020-04-02 12:51:37 INFO] Game mode: 1 Creative
[2020-04-02 12:51:37 INFO] Difficulty: 2 NORMAL
[2020-04-02 12:51:37 INFO] opening worlds/World Name/db
[2020-04-02 12:51:39 INFO] IPv4 supported, port: 19232
[2020-04-02 12:51:39 INFO] IPv6 supported, port: 19233
[2020-04-02 12:51:39 INFO] IPv4 supported, port: 19132
[2020-04-02 12:51:39 INFO] IPv6 supported, port: 19133
[2020-04-02 12:51:40 INFO] Server started.
^Z
[1]+ Stopped LD_LIBRARY_PATH=. ./bedrock_server
minecraft@server1:~/bedrock_server$ bg
[1]+ LD_LIBRARY_PATH=. ./bedrock_server &
minecraft@cyclone:~/bedrock_server$ netstat -plan | grep :19[12]3[23]
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
udp 0 0 0.0.0.0:19132 0.0.0.0:* 6674/./bedrock_serv
udp 0 0 0.0.0.0:19232 0.0.0.0:* 6674/./bedrock_serv
udp6 0 0 :::19133 :::* 6674/./bedrock_serv
udp6 0 0 :::19233 :::* 6674/./bedrock_servSo some part of the code is hard-coding those port values - at least in the linux branch of the code.
As was identified in the original posting, ports 19132 and 19133 are expected. The problem is, after specifying a new port for IPv4, a new, unspecified and random port was opened for IPv6 on (for me) 64114. This port is not the same port that opens every time, but is chosen at random and can be used as a means to backdoor an unwitting server owner and infiltrate the hosting system. This issue either needs to be addressed by Mojang as intentional or fixed, in order to prevent server hosts from malicious attacks due to poor coding.
As was identified in the original posting, ports 19132 and 19133 are expected. The problem is, after specifying a new port for IPv4, a new, unspecified and random port was opened for IPv6 on (for me) 64114. This port is not the same port that opens every time, but is chosen at random and can be used as a means to backdoor an unwitting server owner and infiltrate the hosting system. This issue either needs to be addressed by Mojang as intentional or fixed, in order to prevent server hosts from malicious attacks due to poor coding.
As was identified in the original posting, ports 19132 and 19133 are expected. The problem is, after specifying a new port for IPv4, a new, unspecified and random port was opened for IPv6 on (for me) 64114. This port is not the same port that opens every time, but is chosen at random and can be used as a means to backdoor an unwitting server owner and infiltrate the hosting system. This issue either needs to be addressed by Mojang as intentional or fixed, in order to prevent server hosts from malicious attacks due to poor coding.
@Rebecca Reed - there are two bugs here that have been merged into one (IMHO, wrongly). I came here because BDS-2824 and BDS-3397 have been marked as duplicates of this one. But I am working with what I've got so....
According to the documentation (https://minecraft.gamepedia.com/Server.properties):
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]Ergo, per the documentation, if I change those values to something other than the default, then the server should listen on those ports.
But... according to the output, above, the server is, first, binding to my custom-defined in server.properties ports (ipv4: 19232, ipv6: 19233),. Hurray!
... And THEN it is binding to the default ports (ipv4: 19132, ipv6:19133). Booo!!!
This means I can only run a single bedrock_server instance on my hardware And because I can only serve a single world from a bedrock server instance, that means that I can only have a single world running on my home server (which is a real ballache when you have multiple kids that each want their own world).
@Rebecca Reed - there are two bugs here that have been merged into one (IMHO, wrongly). I came here because BDS-2824 and BDS-3397 have been marked as duplicates of this one. But I am working with what I've got so....
According to the documentation (https://minecraft.gamepedia.com/Server.properties):
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]Ergo, per the documentation, if I change those values to something other than the default, then the server should listen on those ports.
But... according to the output, above, the server is, first, binding to my custom-defined in server.properties ports (ipv4: 19232, ipv6: 19233),. Hurray!
... And THEN it is binding to the default ports (ipv4: 19132, ipv6:19133). Booo!!!
This means I can only run a single bedrock_server instance on my hardware And because I can only serve a single world from a bedrock server instance, that means that I can only have a single world running on my home server (which is a real ballache when you have multiple kids that each want their own world).
@Rebecca Reed - there are two bugs here that have been merged into one (IMHO, wrongly). I came here because BDS-2824 and BDS-3397 have been marked as duplicates of this one. But I am working with what I've got so....
According to the documentation (https://minecraft.gamepedia.com/Server.properties):
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]Ergo, per the documentation, if I change those values to something other than the default, then the server should listen on those ports.
But... according to the output, above, the server is, first, binding to my custom-defined in server.properties ports (ipv4: 19232, ipv6: 19233),. Hurray!
... And THEN it is binding to the default ports (ipv4: 19132, ipv6:19133). Booo!!!
This means I can only run a single bedrock_server instance on my hardware And because I can only serve a single world from a bedrock server instance, that means that I can only have a single world running on my home server (which is a real ballache when you have multiple kids that each want their own world).
Okay, I have to take back my original statement about the ports being open for TCP vs. UDP. I just ran another test running two instances of the bedrock_server.exe on my local machine, then took a new netstat -ano snapshot. All eight ports - the two specified in each of the two server.properties files, as well as the two "random" ports automatically assigned by BDS - are listed as UDP ports. I must've looked at it wrong the first time, so I apologize for the confusion.
Here's what I'm seeing:
SERVER 1
D:\Minecraft>D:\Minecraft\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:06 INFO] Starting Server
[2020-04-02 12:29:06 INFO] Version 1.14.20.1
[2020-04-02 12:29:06 INFO] Session ID a97a1c4b-8f9b-4f08-bfd7-e5266fbf1d52
[2020-04-02 12:29:06 INFO] Level Name: Testing World 1
[2020-04-02 12:29:06 INFO] Game mode: 0 Survival
[2020-04-02 12:29:06 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:07 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_07
[2020-04-02 12:29:07 INFO] opening worlds/Testing World 1/db
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 19132
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 19133
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 57850
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 57851
[2020-04-02 12:29:16 INFO] Server started.
SERVER 2
D:\Minecraft>D:\Minecraft\Testing\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:29 INFO] Starting Server
[2020-04-02 12:29:29 INFO] Version 1.14.32.1
[2020-04-02 12:29:29 INFO] Session ID e33ef792-2521-4868-8670-a5f6d2d9d975
[2020-04-02 12:29:29 INFO] Level Name: Testing World 2
[2020-04-02 12:29:29 INFO] Game mode: 0 Survival
[2020-04-02 12:29:29 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:30 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_30
[2020-04-02 12:29:30 INFO] opening worlds/Testing World 2/db
[2020-04-02 12:29:35 INFO] IPv4 supported, port: 19134
[2020-04-02 12:29:35 INFO] IPv6 supported, port: 19135
[2020-04-02 12:29:36 INFO] IPv4 supported, port: 54240
[2020-04-02 12:29:36 INFO] IPv6 supported, port: 54241
[2020-04-02 12:29:37 INFO] Server started.netstat -ano (heavily redacted)
C:\Windows\system32>netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
UDP 0.0.0.0:19132 *:* 23584
UDP 0.0.0.0:19134 *:* 37028
UDP 0.0.0.0:54240 *:* 37028
UDP 0.0.0.0:57850 *:* 23584
UDP [::]:19133 *:* 23584
UDP [::]:19135 *:* 37028
UDP [::]:54241 *:* 37028
UDP [::]:57851 *:* 23584
So, again, I deeply apologize for spreading inaccurate information without fully testing and reviewing it first.
As for running multiple instances of bedrock_server.exe from the same hardware, as I stated above, these results are on the same machine (my local computer) at the same time. As the copy/paste should indicate, there are two complete copies of the BDS directory structure - including individual copies of the bedrock_server.exe and server.properties files - both running different versions of the BDS software and with different ports specified for communication.
SERVER 1 - server.properties
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
SERVER 2 - server.properties
server-port=19134
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19135
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
I believe that, as long as you have the complete directory structure duplicated for each instance of BDS you want to run, the only time you'd run into a problem running multiple instances would be if the randomly selected ports were the same as the specific ports set in the server.properties file of another instance.
For example, if I started SERVER 2 first - where the ports in the server.properties file are set to 19134/19135 - as mentioned by @MiHu and @David Fidler have noted in their comments above, the "random" ports selected and opened by BDS actually end up being the "default" ports of 19132/19133.
If I then tried to start SERVER 1 - where the ports in the server.properties file are still the "default" - the BDS startup would fail because those ports are already in use by the first instance.
Here's what I got when I tested this scenario:
SERVER 2
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:29 INFO] Starting Server
[2020-04-02 13:23:29 INFO] Version 1.14.32.1
[2020-04-02 13:23:29 INFO] Session ID dd414afe-fe12-4318-8eba-6ad4eabd9d02
[2020-04-02 13:23:29 INFO] Level Name: Testing World 2
[2020-04-02 13:23:29 INFO] Game mode: 0 Survival
[2020-04-02 13:23:29 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:29 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_29
[2020-04-02 13:23:29 INFO] opening worlds/Testing World 2/db
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19134
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19135
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19132
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19133
[2020-04-02 13:23:31 INFO] Server started.SERVER 1
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:53 INFO] Starting Server
[2020-04-02 13:23:53 INFO] Version 1.14.20.1
[2020-04-02 13:23:53 INFO] Session ID 06e47362-329e-4f3f-ae98-33eca8e8db0d
[2020-04-02 13:23:53 INFO] Level Name: Testing World 1
[2020-04-02 13:23:53 INFO] Game mode: 0 Survival
[2020-04-02 13:23:53 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:53 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_53
[2020-04-02 13:23:53 INFO] opening worlds/Testing World 1/db
[2020-04-02 13:23:55 INFO] IPv4 supported, port: 0
[2020-04-02 13:23:55 INFO] IPv6 supported, port: 0
[2020-04-02 13:23:55 ERROR] Network port occupied, can't start server.Exactly as expected. So, the moral of the story there is to start up any BDS instance that's using the default ports before any instances that are using "custom" ports.
Of course, all of that still doesn't address why BDS is opening these extra ports in the first place. Especially now that I've gone back and looked more closely at the information and found that all of the ports are opening over UDP. As @SupremeMortal mentioned, I'm guessing that it has something to do with UPnP, but that's still not really an acceptable answer. The application is opening up ports that haven't been explicitly set by the admin, and, as @Rebecca Reed has pointed out a couple of times, that opens up the potential for all sorts of dangerous activity "piggy-backing" on connections over which the admin has no direct control.
Of course, the "goal" of this post is to ensure that BDS doesn't open random ports without explicit permission from the server admin. Perhaps there should be an additional option in the server.properties file to enable/disable UPnP?
Okay, I have to take back my original statement about the ports being open for TCP vs. UDP. I just ran another test running two instances of the bedrock_server.exe on my local machine, then took a new netstat -ano snapshot. All eight ports - the two specified in each of the two server.properties files, as well as the two "random" ports automatically assigned by BDS - are listed as UDP ports. I must've looked at it wrong the first time, so I apologize for the confusion.
Here's what I'm seeing:
SERVER 1
D:\Minecraft>D:\Minecraft\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:06 INFO] Starting Server
[2020-04-02 12:29:06 INFO] Version 1.14.20.1
[2020-04-02 12:29:06 INFO] Session ID a97a1c4b-8f9b-4f08-bfd7-e5266fbf1d52
[2020-04-02 12:29:06 INFO] Level Name: Testing World 1
[2020-04-02 12:29:06 INFO] Game mode: 0 Survival
[2020-04-02 12:29:06 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:07 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_07
[2020-04-02 12:29:07 INFO] opening worlds/Testing World 1/db
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 19132
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 19133
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 57850
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 57851
[2020-04-02 12:29:16 INFO] Server started.
SERVER 2
D:\Minecraft>D:\Minecraft\Testing\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:29 INFO] Starting Server
[2020-04-02 12:29:29 INFO] Version 1.14.32.1
[2020-04-02 12:29:29 INFO] Session ID e33ef792-2521-4868-8670-a5f6d2d9d975
[2020-04-02 12:29:29 INFO] Level Name: Testing World 2
[2020-04-02 12:29:29 INFO] Game mode: 0 Survival
[2020-04-02 12:29:29 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:30 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_30
[2020-04-02 12:29:30 INFO] opening worlds/Testing World 2/db
[2020-04-02 12:29:35 INFO] IPv4 supported, port: 19134
[2020-04-02 12:29:35 INFO] IPv6 supported, port: 19135
[2020-04-02 12:29:36 INFO] IPv4 supported, port: 54240
[2020-04-02 12:29:36 INFO] IPv6 supported, port: 54241
[2020-04-02 12:29:37 INFO] Server started.netstat -ano (heavily redacted)
C:\Windows\system32>netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
UDP 0.0.0.0:19132 *:* 23584
UDP 0.0.0.0:19134 *:* 37028
UDP 0.0.0.0:54240 *:* 37028
UDP 0.0.0.0:57850 *:* 23584
UDP [::]:19133 *:* 23584
UDP [::]:19135 *:* 37028
UDP [::]:54241 *:* 37028
UDP [::]:57851 *:* 23584
So, again, I deeply apologize for spreading inaccurate information without fully testing and reviewing it first.
As for running multiple instances of bedrock_server.exe from the same hardware, as I stated above, these results are on the same machine (my local computer) at the same time. As the copy/paste should indicate, there are two complete copies of the BDS directory structure - including individual copies of the bedrock_server.exe and server.properties files - both running different versions of the BDS software and with different ports specified for communication.
SERVER 1 - server.properties
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
SERVER 2 - server.properties
server-port=19134
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19135
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
I believe that, as long as you have the complete directory structure duplicated for each instance of BDS you want to run, the only time you'd run into a problem running multiple instances would be if the randomly selected ports were the same as the specific ports set in the server.properties file of another instance.
For example, if I started SERVER 2 first - where the ports in the server.properties file are set to 19134/19135 - as mentioned by @MiHu and @David Fidler have noted in their comments above, the "random" ports selected and opened by BDS actually end up being the "default" ports of 19132/19133.
If I then tried to start SERVER 1 - where the ports in the server.properties file are still the "default" - the BDS startup would fail because those ports are already in use by the first instance.
Here's what I got when I tested this scenario:
SERVER 2
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:29 INFO] Starting Server
[2020-04-02 13:23:29 INFO] Version 1.14.32.1
[2020-04-02 13:23:29 INFO] Session ID dd414afe-fe12-4318-8eba-6ad4eabd9d02
[2020-04-02 13:23:29 INFO] Level Name: Testing World 2
[2020-04-02 13:23:29 INFO] Game mode: 0 Survival
[2020-04-02 13:23:29 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:29 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_29
[2020-04-02 13:23:29 INFO] opening worlds/Testing World 2/db
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19134
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19135
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19132
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19133
[2020-04-02 13:23:31 INFO] Server started.SERVER 1
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:53 INFO] Starting Server
[2020-04-02 13:23:53 INFO] Version 1.14.20.1
[2020-04-02 13:23:53 INFO] Session ID 06e47362-329e-4f3f-ae98-33eca8e8db0d
[2020-04-02 13:23:53 INFO] Level Name: Testing World 1
[2020-04-02 13:23:53 INFO] Game mode: 0 Survival
[2020-04-02 13:23:53 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:53 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_53
[2020-04-02 13:23:53 INFO] opening worlds/Testing World 1/db
[2020-04-02 13:23:55 INFO] IPv4 supported, port: 0
[2020-04-02 13:23:55 INFO] IPv6 supported, port: 0
[2020-04-02 13:23:55 ERROR] Network port occupied, can't start server.Exactly as expected. So, the moral of the story there is to start up any BDS instance that's using the default ports before any instances that are using "custom" ports.
Of course, all of that still doesn't address why BDS is opening these extra ports in the first place. Especially now that I've gone back and looked more closely at the information and found that all of the ports are opening over UDP. As @SupremeMortal mentioned, I'm guessing that it has something to do with UPnP, but that's still not really an acceptable answer. The application is opening up ports that haven't been explicitly set by the admin, and, as @Rebecca Reed has pointed out a couple of times, that opens up the potential for all sorts of dangerous activity "piggy-backing" on connections over which the admin has no direct control.
Of course, the "goal" of this post is to ensure that BDS doesn't open random ports without explicit permission from the server admin. Perhaps there should be an additional option in the server.properties file to enable/disable UPnP?
Okay, I have to take back my original statement about the ports being open for TCP vs. UDP. I just ran another test running two instances of the bedrock_server.exe on my local machine, then took a new netstat -ano snapshot. All eight ports - the two specified in each of the two server.properties files, as well as the two "random" ports automatically assigned by BDS - are listed as UDP ports. I must've looked at it wrong the first time, so I apologize for the confusion.
Here's what I'm seeing:
SERVER 1
D:\Minecraft>D:\Minecraft\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:06 INFO] Starting Server
[2020-04-02 12:29:06 INFO] Version 1.14.20.1
[2020-04-02 12:29:06 INFO] Session ID a97a1c4b-8f9b-4f08-bfd7-e5266fbf1d52
[2020-04-02 12:29:06 INFO] Level Name: Testing World 1
[2020-04-02 12:29:06 INFO] Game mode: 0 Survival
[2020-04-02 12:29:06 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:07 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_07
[2020-04-02 12:29:07 INFO] opening worlds/Testing World 1/db
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 19132
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 19133
[2020-04-02 12:29:14 INFO] IPv4 supported, port: 57850
[2020-04-02 12:29:14 INFO] IPv6 supported, port: 57851
[2020-04-02 12:29:16 INFO] Server started.
SERVER 2
D:\Minecraft>D:\Minecraft\Testing\bedrock_server.exe
NO LOG FILE! - setting up server logging...
[2020-04-02 12:29:29 INFO] Starting Server
[2020-04-02 12:29:29 INFO] Version 1.14.32.1
[2020-04-02 12:29:29 INFO] Session ID e33ef792-2521-4868-8670-a5f6d2d9d975
[2020-04-02 12:29:29 INFO] Level Name: Testing World 2
[2020-04-02 12:29:29 INFO] Game mode: 0 Survival
[2020-04-02 12:29:29 INFO] Difficulty: 1 EASY
[2020-04-02 12:29:30 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__12_29_30
[2020-04-02 12:29:30 INFO] opening worlds/Testing World 2/db
[2020-04-02 12:29:35 INFO] IPv4 supported, port: 19134
[2020-04-02 12:29:35 INFO] IPv6 supported, port: 19135
[2020-04-02 12:29:36 INFO] IPv4 supported, port: 54240
[2020-04-02 12:29:36 INFO] IPv6 supported, port: 54241
[2020-04-02 12:29:37 INFO] Server started.netstat -ano (heavily redacted)
C:\Windows\system32>netstat -ano
Active Connections
Proto Local Address Foreign Address State PID
UDP 0.0.0.0:19132 *:* 23584
UDP 0.0.0.0:19134 *:* 37028
UDP 0.0.0.0:54240 *:* 37028
UDP 0.0.0.0:57850 *:* 23584
UDP [::]:19133 *:* 23584
UDP [::]:19135 *:* 37028
UDP [::]:54241 *:* 37028
UDP [::]:57851 *:* 23584
So, again, I deeply apologize for spreading inaccurate information without fully testing and reviewing it first.
As for running multiple instances of bedrock_server.exe from the same hardware, as I stated above, these results are on the same machine (my local computer) at the same time. As the copy/paste should indicate, there are two complete copies of the BDS directory structure - including individual copies of the bedrock_server.exe and server.properties files - both running different versions of the BDS software and with different ports specified for communication.
SERVER 1 - server.properties
server-port=19132
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19133
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
SERVER 2 - server.properties
server-port=19134
# Which IPv4 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
server-portv6=19135
# Which IPv6 port the server should listen to.
# Allowed values: Integers in the range [1, 65535]
I believe that, as long as you have the complete directory structure duplicated for each instance of BDS you want to run, the only time you'd run into a problem running multiple instances would be if the randomly selected ports were the same as the specific ports set in the server.properties file of another instance.
For example, if I started SERVER 2 first - where the ports in the server.properties file are set to 19134/19135 - as mentioned by @MiHu and @David Fidler have noted in their comments above, the "random" ports selected and opened by BDS actually end up being the "default" ports of 19132/19133.
If I then tried to start SERVER 1 - where the ports in the server.properties file are still the "default" - the BDS startup would fail because those ports are already in use by the first instance.
Here's what I got when I tested this scenario:
SERVER 2
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:29 INFO] Starting Server
[2020-04-02 13:23:29 INFO] Version 1.14.32.1
[2020-04-02 13:23:29 INFO] Session ID dd414afe-fe12-4318-8eba-6ad4eabd9d02
[2020-04-02 13:23:29 INFO] Level Name: Testing World 2
[2020-04-02 13:23:29 INFO] Game mode: 0 Survival
[2020-04-02 13:23:29 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:29 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_29
[2020-04-02 13:23:29 INFO] opening worlds/Testing World 2/db
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19134
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19135
[2020-04-02 13:23:31 INFO] IPv4 supported, port: 19132
[2020-04-02 13:23:31 INFO] IPv6 supported, port: 19133
[2020-04-02 13:23:31 INFO] Server started.SERVER 1
NO LOG FILE! - setting up server logging...
[2020-04-02 13:23:53 INFO] Starting Server
[2020-04-02 13:23:53 INFO] Version 1.14.20.1
[2020-04-02 13:23:53 INFO] Session ID 06e47362-329e-4f3f-ae98-33eca8e8db0d
[2020-04-02 13:23:53 INFO] Level Name: Testing World 1
[2020-04-02 13:23:53 INFO] Game mode: 0 Survival
[2020-04-02 13:23:53 INFO] Difficulty: 1 EASY
[2020-04-02 13:23:53 INFO] Content logging enabled. Writing log to: ContentLog__Thursday__2020_April_02__13_23_53
[2020-04-02 13:23:53 INFO] opening worlds/Testing World 1/db
[2020-04-02 13:23:55 INFO] IPv4 supported, port: 0
[2020-04-02 13:23:55 INFO] IPv6 supported, port: 0
[2020-04-02 13:23:55 ERROR] Network port occupied, can't start server.Exactly as expected. So, the moral of the story there is to start up any BDS instance that's using the default ports before any instances that are using "custom" ports.
Of course, all of that still doesn't address why BDS is opening these extra ports in the first place. Especially now that I've gone back and looked more closely at the information and found that all of the ports are opening over UDP. As @SupremeMortal mentioned, I'm guessing that it has something to do with UPnP, but that's still not really an acceptable answer. The application is opening up ports that haven't been explicitly set by the admin, and, as @Rebecca Reed has pointed out a couple of times, that opens up the potential for all sorts of dangerous activity "piggy-backing" on connections over which the admin has no direct control.
Of course, the "goal" of this post is to ensure that BDS doesn't open random ports without explicit permission from the server admin. Perhaps there should be an additional option in the server.properties file to enable/disable UPnP?
@Jeremy Gamble - thanks for your previous post, it caused me to go back and take another look and things make a lot more sense now. I think that the reason that an instance opens the default ports is so the client (game) can auto-discover the server.
I tried starting two servers (as you suggest) and they do both start. However, only one server is discovered by the client.
To test this I did the following....
1. As root: disable firewall on server
root@server1:~# iptables -F; iptables -X; iptables -Z
root@server1:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destinationChain FORWARD (policy DROP)
target prot opt source destinationChain OUTPUT (policy ACCEPT)
target prot opt source destination2. As root: create user "minecraft" in /home/minecraft
adduser minecraft3. As root: become user minecraft:
su - minecraft4. As minecraft: create server directories
mkdir ~/s1 ~/s25. As minecraft: unzip server to ~/s1
unzip bedrock-server-1.14.32.1.zip -d ~/s1/6. As minecraft: Unzip server to ~/s2
unzip bedrock-server-1.14.32.1.zip -d ~/s2/7. Change server-name, levels-name and ports per the following:
minecraft@server1:~$ egrep "server-name|level-name|.*-port" s[12]/server.properties
s1/server.properties:server-name=Server1
s1/server.properties:server-port=19100
s1/server.properties:server-portv6=19101
s1/server.properties:level-name=level1
s2/server.properties:server-name=Server2
s2/server.properties:server-port=19200
s2/server.properties:server-portv6=19201
s2/server.properties:level-name=level28. Start server in ~/s1
minecraft@Server1:~$ cd s1
minecraft@Server1:~/s1$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:01:24 INFO] Starting Server
[2020-04-03 10:01:24 INFO] Version 1.14.32.1
[2020-04-03 10:01:24 INFO] Session ID 0ec216b4-56b7-4d96-aea5-8b3f249b608c
[2020-04-03 10:01:24 INFO] Level Name: level1
[2020-04-03 10:01:24 INFO] Game mode: 0 Survival
[2020-04-03 10:01:24 INFO] Difficulty: 1 EASY
[2020-04-03 10:01:24 INFO] opening worlds/level1/db
[2020-04-03 10:01:25 INFO] IPv4 supported, port: 19100
[2020-04-03 10:01:25 INFO] IPv6 supported, port: 19101
[2020-04-03 10:01:25 INFO] IPv4 supported, port: 19132
[2020-04-03 10:01:25 INFO] IPv6 supported, port: 19133
[2020-04-03 10:01:26 INFO] Server started.9. Start server in ~/s2
minecraft@server1:~$ cd s2/
minecraft@server1:~/s2$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:02:02 INFO] Starting Server
[2020-04-03 10:02:02 INFO] Version 1.14.32.1
[2020-04-03 10:02:02 INFO] Session ID 15140ceb-984e-4cdc-befa-91b64643b06f
[2020-04-03 10:02:02 INFO] Level Name: level2
[2020-04-03 10:02:02 INFO] Game mode: 0 Survival
[2020-04-03 10:02:02 INFO] Difficulty: 1 EASY
[2020-04-03 10:02:02 INFO] opening worlds/level2/db
[2020-04-03 10:02:04 INFO] IPv4 supported, port: 19200
[2020-04-03 10:02:04 INFO] IPv6 supported, port: 19201
[2020-04-03 10:02:04 INFO] IPv4 supported, port: 60796
[2020-04-03 10:02:04 INFO] IPv6 supported, port: 57886
[2020-04-03 10:02:05 INFO] Server started.10. Look at the open ports:
root@server1:~# netstat -plan | egrep bedrock_ser
udp 0 0 0.0.0.0:19100 0.0.0.0:* 18760/./bedrock_ser
udp 0 0 0.0.0.0:19132 0.0.0.0:* 18760/./bedrock_ser
udp 0 0 0.0.0.0:19200 0.0.0.0:* 18794/./bedrock_ser
udp 0 0 0.0.0.0:60796 0.0.0.0:* 18794/./bedrock_ser
udp6 0 0 :::57886 :::* 18794/./bedrock_ser
udp6 0 0 :::19101 :::* 18760/./bedrock_ser
udp6 0 0 :::19133 :::* 18760/./bedrock_ser
udp6 0 0 :::19201 :::* 18794/./bedrock_ser11. Try to join the servers....
[media]12. Kill Server1 process - Server 1 disappears from the list and server2 does not appear.
13. Kill Server2 process and then start ONLY Server 2
minecraft@cyclone:~/s2$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:17:42 INFO] Starting Server
[2020-04-03 10:17:42 INFO] Version 1.14.32.1
[2020-04-03 10:17:42 INFO] Session ID 9362f75d-a13a-4825-a79b-641502d8fe4a
[2020-04-03 10:17:42 INFO] Level Name: level2
[2020-04-03 10:17:42 INFO] Game mode: 0 Survival
[2020-04-03 10:17:42 INFO] Difficulty: 1 EASY
[2020-04-03 10:17:42 INFO] opening worlds/level2/db
[2020-04-03 10:17:44 INFO] IPv4 supported, port: 19200
[2020-04-03 10:17:44 INFO] IPv6 supported, port: 19201
[2020-04-03 10:17:44 INFO] IPv4 supported, port: 19132
[2020-04-03 10:17:44 INFO] IPv6 supported, port: 19133
[2020-04-03 10:17:45 INFO] Server started.14. Start Server 1 Process:
minecraft@cyclone:~/s1$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:19:18 INFO] Starting Server
[2020-04-03 10:19:18 INFO] Version 1.14.32.1
[2020-04-03 10:19:18 INFO] Session ID 5c66f904-53d4-4109-bb18-b0ec64399fdf
[2020-04-03 10:19:18 INFO] Level Name: level1
[2020-04-03 10:19:18 INFO] Game mode: 0 Survival
[2020-04-03 10:19:18 INFO] Difficulty: 1 EASY
[2020-04-03 10:19:18 INFO] opening worlds/level1/db
[2020-04-03 10:19:20 INFO] IPv4 supported, port: 19100
[2020-04-03 10:19:20 INFO] IPv6 supported, port: 19101
[2020-04-03 10:19:20 INFO] IPv4 supported, port: 41620
[2020-04-03 10:19:20 INFO] IPv6 supported, port: 36583
[2020-04-03 10:19:21 INFO] Server started.16. Check minecraft again....
[media]
So only one server is automatically discoverable at a time and this is probably because the first server that starts binds to the default ports 19132/19133.
You can go to the third tab in the client (Servers) and click "Add Server" and manually add the IP/port in there.
Note: The screenshots, above, are taken from the windows client. However, I also tried this on the Android client as well.
So, actually, in terms of being able to do what I wanted to be able to do (run multiple servers / worlds) from the same server, it turns out that I can do that. I was simply assuming (you know what they say about assumptions) that because the first process was binding to the default ports, that the second one would not start - which turns out not to be the case as the server just "picks different ports" to randomly open.
I do agree that randomly opening LISTEN ports is both undocumented and undesirable. It would be beneficial for us to understand why those ports are being opened, and what they are used for. (others have mentioned UPnP as a possibility).
Similarly, it would be beneficial for the auto-discover mechanism to be a bit more intelligent. I don't know how it works but based on what I'm observing here (and please note, I've not done any kind of deep packet inspection see what's happening), I'm guessing that the server does a network broadcast saying "I am a minecraft server - this is my IP" and the client checks that IP against the default ports, rather than the server saying "I am a minecraft server, this is my IP and port". Or maybe it does and the client's have a bug in them that they only check the default ports - I'm not sure. Either way, this process could be improved.
@Jeremy Gamble - thanks for your previous post, it caused me to go back and take another look and things make a lot more sense now. I think that the reason that an instance opens the default ports is so the client (game) can auto-discover the server.
I tried starting two servers (as you suggest) and they do both start. However, only one server is discovered by the client.
To test this I did the following....
1. As root: disable firewall on server
root@server1:~# iptables -F; iptables -X; iptables -Z
root@server1:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destinationChain FORWARD (policy DROP)
target prot opt source destinationChain OUTPUT (policy ACCEPT)
target prot opt source destination2. As root: create user "minecraft" in /home/minecraft
adduser minecraft3. As root: become user minecraft:
su - minecraft4. As minecraft: create server directories
mkdir ~/s1 ~/s25. As minecraft: unzip server to ~/s1
unzip bedrock-server-1.14.32.1.zip -d ~/s1/6. As minecraft: Unzip server to ~/s2
unzip bedrock-server-1.14.32.1.zip -d ~/s2/7. Change server-name, levels-name and ports per the following:
minecraft@server1:~$ egrep "server-name|level-name|.*-port" s[12]/server.properties
s1/server.properties:server-name=Server1
s1/server.properties:server-port=19100
s1/server.properties:server-portv6=19101
s1/server.properties:level-name=level1
s2/server.properties:server-name=Server2
s2/server.properties:server-port=19200
s2/server.properties:server-portv6=19201
s2/server.properties:level-name=level28. Start server in ~/s1
minecraft@Server1:~$ cd s1
minecraft@Server1:~/s1$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:01:24 INFO] Starting Server
[2020-04-03 10:01:24 INFO] Version 1.14.32.1
[2020-04-03 10:01:24 INFO] Session ID 0ec216b4-56b7-4d96-aea5-8b3f249b608c
[2020-04-03 10:01:24 INFO] Level Name: level1
[2020-04-03 10:01:24 INFO] Game mode: 0 Survival
[2020-04-03 10:01:24 INFO] Difficulty: 1 EASY
[2020-04-03 10:01:24 INFO] opening worlds/level1/db
[2020-04-03 10:01:25 INFO] IPv4 supported, port: 19100
[2020-04-03 10:01:25 INFO] IPv6 supported, port: 19101
[2020-04-03 10:01:25 INFO] IPv4 supported, port: 19132
[2020-04-03 10:01:25 INFO] IPv6 supported, port: 19133
[2020-04-03 10:01:26 INFO] Server started.9. Start server in ~/s2
minecraft@server1:~$ cd s2/
minecraft@server1:~/s2$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:02:02 INFO] Starting Server
[2020-04-03 10:02:02 INFO] Version 1.14.32.1
[2020-04-03 10:02:02 INFO] Session ID 15140ceb-984e-4cdc-befa-91b64643b06f
[2020-04-03 10:02:02 INFO] Level Name: level2
[2020-04-03 10:02:02 INFO] Game mode: 0 Survival
[2020-04-03 10:02:02 INFO] Difficulty: 1 EASY
[2020-04-03 10:02:02 INFO] opening worlds/level2/db
[2020-04-03 10:02:04 INFO] IPv4 supported, port: 19200
[2020-04-03 10:02:04 INFO] IPv6 supported, port: 19201
[2020-04-03 10:02:04 INFO] IPv4 supported, port: 60796
[2020-04-03 10:02:04 INFO] IPv6 supported, port: 57886
[2020-04-03 10:02:05 INFO] Server started.10. Look at the open ports:
root@server1:~# netstat -plan | egrep bedrock_ser
udp 0 0 0.0.0.0:19100 0.0.0.0:* 18760/./bedrock_ser
udp 0 0 0.0.0.0:19132 0.0.0.0:* 18760/./bedrock_ser
udp 0 0 0.0.0.0:19200 0.0.0.0:* 18794/./bedrock_ser
udp 0 0 0.0.0.0:60796 0.0.0.0:* 18794/./bedrock_ser
udp6 0 0 :::57886 :::* 18794/./bedrock_ser
udp6 0 0 :::19101 :::* 18760/./bedrock_ser
udp6 0 0 :::19133 :::* 18760/./bedrock_ser
udp6 0 0 :::19201 :::* 18794/./bedrock_ser11. Try to join the servers....
[media]12. Kill Server1 process - Server 1 disappears from the list and server2 does not appear.
13. Kill Server2 process and then start ONLY Server 2
minecraft@cyclone:~/s2$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:17:42 INFO] Starting Server
[2020-04-03 10:17:42 INFO] Version 1.14.32.1
[2020-04-03 10:17:42 INFO] Session ID 9362f75d-a13a-4825-a79b-641502d8fe4a
[2020-04-03 10:17:42 INFO] Level Name: level2
[2020-04-03 10:17:42 INFO] Game mode: 0 Survival
[2020-04-03 10:17:42 INFO] Difficulty: 1 EASY
[2020-04-03 10:17:42 INFO] opening worlds/level2/db
[2020-04-03 10:17:44 INFO] IPv4 supported, port: 19200
[2020-04-03 10:17:44 INFO] IPv6 supported, port: 19201
[2020-04-03 10:17:44 INFO] IPv4 supported, port: 19132
[2020-04-03 10:17:44 INFO] IPv6 supported, port: 19133
[2020-04-03 10:17:45 INFO] Server started.14. Start Server 1 Process:
minecraft@cyclone:~/s1$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:19:18 INFO] Starting Server
[2020-04-03 10:19:18 INFO] Version 1.14.32.1
[2020-04-03 10:19:18 INFO] Session ID 5c66f904-53d4-4109-bb18-b0ec64399fdf
[2020-04-03 10:19:18 INFO] Level Name: level1
[2020-04-03 10:19:18 INFO] Game mode: 0 Survival
[2020-04-03 10:19:18 INFO] Difficulty: 1 EASY
[2020-04-03 10:19:18 INFO] opening worlds/level1/db
[2020-04-03 10:19:20 INFO] IPv4 supported, port: 19100
[2020-04-03 10:19:20 INFO] IPv6 supported, port: 19101
[2020-04-03 10:19:20 INFO] IPv4 supported, port: 41620
[2020-04-03 10:19:20 INFO] IPv6 supported, port: 36583
[2020-04-03 10:19:21 INFO] Server started.16. Check minecraft again....
[media]
So only one server is automatically discoverable at a time and this is probably because the first server that starts binds to the default ports 19132/19133.
You can go to the third tab in the client (Servers) and click "Add Server" and manually add the IP/port in there.
Note: The screenshots, above, are taken from the windows client. However, I also tried this on the Android client as well.
So, actually, in terms of being able to do what I wanted to be able to do (run multiple servers / worlds) from the same server, it turns out that I can do that. I was simply assuming (you know what they say about assumptions) that because the first process was binding to the default ports, that the second one would not start - which turns out not to be the case as the server just "picks different ports" to randomly open.
I do agree that randomly opening LISTEN ports is both undocumented and undesirable. It would be beneficial for us to understand why those ports are being opened, and what they are used for. (others have mentioned UPnP as a possibility).
Similarly, it would be beneficial for the auto-discover mechanism to be a bit more intelligent. I don't know how it works but based on what I'm observing here (and please note, I've not done any kind of deep packet inspection see what's happening), I'm guessing that the server does a network broadcast saying "I am a minecraft server - this is my IP" and the client checks that IP against the default ports, rather than the server saying "I am a minecraft server, this is my IP and port". Or maybe it does and the client's have a bug in them that they only check the default ports - I'm not sure. Either way, this process could be improved.
@Jeremy Gamble - thanks for your previous post, it caused me to go back and take another look and things make a lot more sense now. I think that the reason that an instance opens the default ports is so the client (game) can auto-discover the server.
I tried starting two servers (as you suggest) and they do both start. However, only one server is discovered by the client.
To test this I did the following....
1. As root: disable firewall on server
root@server1:~# iptables -F; iptables -X; iptables -Z
root@server1:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destinationChain FORWARD (policy DROP)
target prot opt source destinationChain OUTPUT (policy ACCEPT)
target prot opt source destination2. As root: create user "minecraft" in /home/minecraft
adduser minecraft3. As root: become user minecraft:
su - minecraft4. As minecraft: create server directories
mkdir ~/s1 ~/s25. As minecraft: unzip server to ~/s1
unzip bedrock-server-1.14.32.1.zip -d ~/s1/6. As minecraft: Unzip server to ~/s2
unzip bedrock-server-1.14.32.1.zip -d ~/s2/7. Change server-name, levels-name and ports per the following:
minecraft@server1:~$ egrep "server-name|level-name|.*-port" s[12]/server.properties
s1/server.properties:server-name=Server1
s1/server.properties:server-port=19100
s1/server.properties:server-portv6=19101
s1/server.properties:level-name=level1
s2/server.properties:server-name=Server2
s2/server.properties:server-port=19200
s2/server.properties:server-portv6=19201
s2/server.properties:level-name=level28. Start server in ~/s1
minecraft@Server1:~$ cd s1
minecraft@Server1:~/s1$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:01:24 INFO] Starting Server
[2020-04-03 10:01:24 INFO] Version 1.14.32.1
[2020-04-03 10:01:24 INFO] Session ID 0ec216b4-56b7-4d96-aea5-8b3f249b608c
[2020-04-03 10:01:24 INFO] Level Name: level1
[2020-04-03 10:01:24 INFO] Game mode: 0 Survival
[2020-04-03 10:01:24 INFO] Difficulty: 1 EASY
[2020-04-03 10:01:24 INFO] opening worlds/level1/db
[2020-04-03 10:01:25 INFO] IPv4 supported, port: 19100
[2020-04-03 10:01:25 INFO] IPv6 supported, port: 19101
[2020-04-03 10:01:25 INFO] IPv4 supported, port: 19132
[2020-04-03 10:01:25 INFO] IPv6 supported, port: 19133
[2020-04-03 10:01:26 INFO] Server started.9. Start server in ~/s2
minecraft@server1:~$ cd s2/
minecraft@server1:~/s2$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:02:02 INFO] Starting Server
[2020-04-03 10:02:02 INFO] Version 1.14.32.1
[2020-04-03 10:02:02 INFO] Session ID 15140ceb-984e-4cdc-befa-91b64643b06f
[2020-04-03 10:02:02 INFO] Level Name: level2
[2020-04-03 10:02:02 INFO] Game mode: 0 Survival
[2020-04-03 10:02:02 INFO] Difficulty: 1 EASY
[2020-04-03 10:02:02 INFO] opening worlds/level2/db
[2020-04-03 10:02:04 INFO] IPv4 supported, port: 19200
[2020-04-03 10:02:04 INFO] IPv6 supported, port: 19201
[2020-04-03 10:02:04 INFO] IPv4 supported, port: 60796
[2020-04-03 10:02:04 INFO] IPv6 supported, port: 57886
[2020-04-03 10:02:05 INFO] Server started.10. Look at the open ports:
root@server1:~# netstat -plan | egrep bedrock_ser
udp 0 0 0.0.0.0:19100 0.0.0.0:* 18760/./bedrock_ser
udp 0 0 0.0.0.0:19132 0.0.0.0:* 18760/./bedrock_ser
udp 0 0 0.0.0.0:19200 0.0.0.0:* 18794/./bedrock_ser
udp 0 0 0.0.0.0:60796 0.0.0.0:* 18794/./bedrock_ser
udp6 0 0 :::57886 :::* 18794/./bedrock_ser
udp6 0 0 :::19101 :::* 18760/./bedrock_ser
udp6 0 0 :::19133 :::* 18760/./bedrock_ser
udp6 0 0 :::19201 :::* 18794/./bedrock_ser11. Try to join the servers....
[media]12. Kill Server1 process - Server 1 disappears from the list and server2 does not appear.
13. Kill Server2 process and then start ONLY Server 2
minecraft@cyclone:~/s2$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:17:42 INFO] Starting Server
[2020-04-03 10:17:42 INFO] Version 1.14.32.1
[2020-04-03 10:17:42 INFO] Session ID 9362f75d-a13a-4825-a79b-641502d8fe4a
[2020-04-03 10:17:42 INFO] Level Name: level2
[2020-04-03 10:17:42 INFO] Game mode: 0 Survival
[2020-04-03 10:17:42 INFO] Difficulty: 1 EASY
[2020-04-03 10:17:42 INFO] opening worlds/level2/db
[2020-04-03 10:17:44 INFO] IPv4 supported, port: 19200
[2020-04-03 10:17:44 INFO] IPv6 supported, port: 19201
[2020-04-03 10:17:44 INFO] IPv4 supported, port: 19132
[2020-04-03 10:17:44 INFO] IPv6 supported, port: 19133
[2020-04-03 10:17:45 INFO] Server started.14. Start Server 1 Process:
minecraft@cyclone:~/s1$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2020-04-03 10:19:18 INFO] Starting Server
[2020-04-03 10:19:18 INFO] Version 1.14.32.1
[2020-04-03 10:19:18 INFO] Session ID 5c66f904-53d4-4109-bb18-b0ec64399fdf
[2020-04-03 10:19:18 INFO] Level Name: level1
[2020-04-03 10:19:18 INFO] Game mode: 0 Survival
[2020-04-03 10:19:18 INFO] Difficulty: 1 EASY
[2020-04-03 10:19:18 INFO] opening worlds/level1/db
[2020-04-03 10:19:20 INFO] IPv4 supported, port: 19100
[2020-04-03 10:19:20 INFO] IPv6 supported, port: 19101
[2020-04-03 10:19:20 INFO] IPv4 supported, port: 41620
[2020-04-03 10:19:20 INFO] IPv6 supported, port: 36583
[2020-04-03 10:19:21 INFO] Server started.16. Check minecraft again....
[media]
So only one server is automatically discoverable at a time and this is probably because the first server that starts binds to the default ports 19132/19133.
You can go to the third tab in the client (Servers) and click "Add Server" and manually add the IP/port in there.
Note: The screenshots, above, are taken from the windows client. However, I also tried this on the Android client as well.
So, actually, in terms of being able to do what I wanted to be able to do (run multiple servers / worlds) from the same server, it turns out that I can do that. I was simply assuming (you know what they say about assumptions) that because the first process was binding to the default ports, that the second one would not start - which turns out not to be the case as the server just "picks different ports" to randomly open.
I do agree that randomly opening LISTEN ports is both undocumented and undesirable. It would be beneficial for us to understand why those ports are being opened, and what they are used for. (others have mentioned UPnP as a possibility).
Similarly, it would be beneficial for the auto-discover mechanism to be a bit more intelligent. I don't know how it works but based on what I'm observing here (and please note, I've not done any kind of deep packet inspection see what's happening), I'm guessing that the server does a network broadcast saying "I am a minecraft server - this is my IP" and the client checks that IP against the default ports, rather than the server saying "I am a minecraft server, this is my IP and port". Or maybe it does and the client's have a bug in them that they only check the default ports - I'm not sure. Either way, this process could be improved.
@David Fidler - I'm glad the information was useful/helpful. I'm a firm believer that the more detail we can provide, the better the bug report will be received. Even if the information is superfluous, for a programmer (like me), the more detailed the explanation and definition of the problem, the easier it is to find a solution.
So only one server is automatically discoverable at a time and this is probably because the first server that starts binds to the default ports 19132/19133.Well, that makes sense, actually. For an extremely simplified example, I liken it to trying to host a Web server on a residential Internet connection. Many ISP's have port 80 blocked to prevent their customers from doing that for a variety of reasons (excess traffic, security concerns, etc.). Still, with a bit of creative port forwarding and communication, one can host a simple Web site on a non-standard port. Since pretty much every Web client defaults it's communication to port 80 for HTTP, the client has to be explicitly told to use a different port (for example, 8080) when trying to access that particular resource. Obviously, with DDNS and even more creativity, it's possible to even get around that, but that goes well beyond the scope of this example.
This is basically what I am assuming (yep 😉) is going on with the Minecraft client. It will only look for servers on the default ports when trying to auto-discover servers. If the server is running on a "non-standard" port, the game client must be explicitly told which port(s) to use for the connection. An admin that wants to run the server on a different port will require the player to go through the "Add Server" dialog to actually connect. Personally, I'm okay with that. I'm not sure how the client would be able to automatically detect servers running on non-standard without scanning all 65K ports in existence (which would open up a whole different set of potential security issues).
Now, it's just a matter of identifying the purpose and function of the two extra "random" ports.
@David Fidler - I'm glad the information was useful/helpful. I'm a firm believer that the more detail we can provide, the better the bug report will be received. Even if the information is superfluous, for a programmer (like me), the more detailed the explanation and definition of the problem, the easier it is to find a solution.
So only one server is automatically discoverable at a time and this is probably because the first server that starts binds to the default ports 19132/19133.Well, that makes sense, actually. For an extremely simplified example, I liken it to trying to host a Web server on a residential Internet connection. Many ISP's have port 80 blocked to prevent their customers from doing that for a variety of reasons (excess traffic, security concerns, etc.). Still, with a bit of creative port forwarding and communication, one can host a simple Web site on a non-standard port. Since pretty much every Web client defaults it's communication to port 80 for HTTP, the client has to be explicitly told to use a different port (for example, 8080) when trying to access that particular resource. Obviously, with DDNS and even more creativity, it's possible to even get around that, but that goes well beyond the scope of this example.
This is basically what I am assuming (yep 😉) is going on with the Minecraft client. It will only look for servers on the default ports when trying to auto-discover servers. If the server is running on a "non-standard" port, the game client must be explicitly told which port(s) to use for the connection. An admin that wants to run the server on a different port will require the player to go through the "Add Server" dialog to actually connect. Personally, I'm okay with that. I'm not sure how the client would be able to automatically detect servers running on non-standard without scanning all 65K ports in existence (which would open up a whole different set of potential security issues).
Now, it's just a matter of identifying the purpose and function of the two extra "random" ports.
@David Fidler - I'm glad the information was useful/helpful. I'm a firm believer that the more detail we can provide, the better the bug report will be received. Even if the information is superfluous, for a programmer (like me), the more detailed the explanation and definition of the problem, the easier it is to find a solution.
So only one server is automatically discoverable at a time and this is probably because the first server that starts binds to the default ports 19132/19133.Well, that makes sense, actually. For an extremely simplified example, I liken it to trying to host a Web server on a residential Internet connection. Many ISP's have port 80 blocked to prevent their customers from doing that for a variety of reasons (excess traffic, security concerns, etc.). Still, with a bit of creative port forwarding and communication, one can host a simple Web site on a non-standard port. Since pretty much every Web client defaults it's communication to port 80 for HTTP, the client has to be explicitly told to use a different port (for example, 8080) when trying to access that particular resource. Obviously, with DDNS and even more creativity, it's possible to even get around that, but that goes well beyond the scope of this example.
This is basically what I am assuming (yep 😉) is going on with the Minecraft client. It will only look for servers on the default ports when trying to auto-discover servers. If the server is running on a "non-standard" port, the game client must be explicitly told which port(s) to use for the connection. An admin that wants to run the server on a different port will require the player to go through the "Add Server" dialog to actually connect. Personally, I'm okay with that. I'm not sure how the client would be able to automatically detect servers running on non-standard without scanning all 65K ports in existence (which would open up a whole different set of potential security issues).
Now, it's just a matter of identifying the purpose and function of the two extra "random" ports.
It's not actually that hard of a problem to solve (I too, am a programmer). Auto-discovery systems function in one of two ways - either they do an L2 broadcast stating that the exist (as is the case with DHCP) or they do an L3 broadcast (IP-level on the broadcast IP of the current network). Clients listen for certain packet patterns.
That broadcast traffic can contain any kind of information - the client just has to be looking for it and it has to know how to interpret the contents.
So either the server is only broadcasting the IP and the client is responsible for trying to connect to the default ports on the target IP, or the server is already broadcasting IP:port and the client is not gathering the "port" part and is only trying to hit the default ports.
But you're right, it's a minor inconvenience. Having the output of this discussion, though, in the documentation would be useful.
It's not actually that hard of a problem to solve (I too, am a programmer). Auto-discovery systems function in one of two ways - either they do an L2 broadcast stating that the exist (as is the case with DHCP) or they do an L3 broadcast (IP-level on the broadcast IP of the current network). Clients listen for certain packet patterns.
That broadcast traffic can contain any kind of information - the client just has to be looking for it and it has to know how to interpret the contents.
So either the server is only broadcasting the IP and the client is responsible for trying to connect to the default ports on the target IP, or the server is already broadcasting IP:port and the client is not gathering the "port" part and is only trying to hit the default ports.
But you're right, it's a minor inconvenience. Having the output of this discussion, though, in the documentation would be useful.
It's not actually that hard of a problem to solve (I too, am a programmer). Auto-discovery systems function in one of two ways - either they do an L2 broadcast stating that the exist (as is the case with DHCP) or they do an L3 broadcast (IP-level on the broadcast IP of the current network). Clients listen for certain packet patterns.
That broadcast traffic can contain any kind of information - the client just has to be looking for it and it has to know how to interpret the contents.
So either the server is only broadcasting the IP and the client is responsible for trying to connect to the default ports on the target IP, or the server is already broadcasting IP:port and the client is not gathering the "port" part and is only trying to hit the default ports.
But you're right, it's a minor inconvenience. Having the output of this discussion, though, in the documentation would be useful.
Still having two of each IPv4 and IPv6 opening up on version: 1.17.10.04
[INFO] IPv4 supported, port: 21212. <- My chosen port
[INFO] IPv6 supported, port: 21213 <- My chosen port
[INFO] IPv4 supported, port: 19132 <- Not one I setup
[INFO] IPv6 supported, port: 19133 <- Not one I setup
netstat -an | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:21212 0.0.0.0:* <-- My chosen port
udp 0 0 0.0.0.0:19132 0.0.0.0:* <-- Not my chosen port
udp6 0 0 :::21213 :::* <-- My chosen port
udp6 0 0 :::19133 :::* <-- Not my chosen port.
Still having two of each IPv4 and IPv6 opening up on version: 1.17.10.04
[INFO] IPv4 supported, port: 21212. <- My chosen port
[INFO] IPv6 supported, port: 21213 <- My chosen port
[INFO] IPv4 supported, port: 19132 <- Not one I setup
[INFO] IPv6 supported, port: 19133 <- Not one I setup
netstat -an | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:21212 0.0.0.0:* <-- My chosen port
udp 0 0 0.0.0.0:19132 0.0.0.0:* <-- Not my chosen port
udp6 0 0 :::21213 :::* <-- My chosen port
udp6 0 0 :::19133 :::* <-- Not my chosen port.
Still having two of each IPv4 and IPv6 opening up on version: 1.17.10.04
[INFO] IPv4 supported, port: 21212. <- My chosen port
[INFO] IPv6 supported, port: 21213 <- My chosen port
[INFO] IPv4 supported, port: 19132 <- Not one I setup
[INFO] IPv6 supported, port: 19133 <- Not one I setup
netstat -an | less
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:21212 0.0.0.0:* <-- My chosen port
udp 0 0 0.0.0.0:19132 0.0.0.0:* <-- Not my chosen port
udp6 0 0 :::21213 :::* <-- My chosen port
udp6 0 0 :::19133 :::* <-- Not my chosen port.
Correct, that's the conclusion that we've come to...
The first server that you start, no matter which ports you choose, will always open up on UDP:19132/19133 because these are the ports that are used for game discovery on the local network. You have no choice.
You can block them with a firewall [if you like] and it just means that you won't be able to discover the game automatically through the client - you'll need to specificy the IP:port in the "custom server" screen.
If you are hosting multiple servers on your system (like I do) and you do want ONE of them to be auto-discoverable, you must start that instance before any others (so it grabs the ports).
Unfortunately, there really is no way to work around this... bedrock server has no "server-ip" config (like Java edition did) to force binding to a single IP (ie - if your server had a bunch of VIPs, one for each server instance).
In java edition, you could specify "server-ip=10.1.1.10" ; but bedrock forces a bind of the port to 0.0.0.0.
From a product perspective, a better solution for this would be to have a registry process (which is independent from the server) listen on those ports and then have the mc servers register their existence with the that port at startup. However, having not seen the code, I suspect that would be an architectural change and my guess is that the client only expects to have a single server per host. It would also open up some security issues/concerns if that registry process didn't do some kind of IP authentication before accepting the record.
However, at the end of the day, not that many people have participated in this thread and highlighted it as an issue. My guess is that the PM/Dev team have marked this as "low priority - do not fix" because it will not end in global thermonuclear meltdown, and it's really only inconveniencing a few of us.
Correct, that's the conclusion that we've come to...
The first server that you start, no matter which ports you choose, will always open up on UDP:19132/19133 because these are the ports that are used for game discovery on the local network. You have no choice.
You can block them with a firewall [if you like] and it just means that you won't be able to discover the game automatically through the client - you'll need to specificy the IP:port in the "custom server" screen.
If you are hosting multiple servers on your system (like I do) and you do want ONE of them to be auto-discoverable, you must start that instance before any others (so it grabs the ports).
Unfortunately, there really is no way to work around this... bedrock server has no "server-ip" config (like Java edition did) to force binding to a single IP (ie - if your server had a bunch of VIPs, one for each server instance).
In java edition, you could specify "server-ip=10.1.1.10" ; but bedrock forces a bind of the port to 0.0.0.0.
From a product perspective, a better solution for this would be to have a registry process (which is independent from the server) listen on those ports and then have the mc servers register their existence with the that port at startup. However, having not seen the code, I suspect that would be an architectural change and my guess is that the client only expects to have a single server per host. It would also open up some security issues/concerns if that registry process didn't do some kind of IP authentication before accepting the record.
However, at the end of the day, not that many people have participated in this thread and highlighted it as an issue. My guess is that the PM/Dev team have marked this as "low priority - do not fix" because it will not end in global thermonuclear meltdown, and it's really only inconveniencing a few of us.
Correct, that's the conclusion that we've come to...
The first server that you start, no matter which ports you choose, will always open up on UDP:19132/19133 because these are the ports that are used for game discovery on the local network. You have no choice.
You can block them with a firewall [if you like] and it just means that you won't be able to discover the game automatically through the client - you'll need to specificy the IP:port in the "custom server" screen.
If you are hosting multiple servers on your system (like I do) and you do want ONE of them to be auto-discoverable, you must start that instance before any others (so it grabs the ports).
Unfortunately, there really is no way to work around this... bedrock server has no "server-ip" config (like Java edition did) to force binding to a single IP (ie - if your server had a bunch of VIPs, one for each server instance).
In java edition, you could specify "server-ip=10.1.1.10" ; but bedrock forces a bind of the port to 0.0.0.0.
From a product perspective, a better solution for this would be to have a registry process (which is independent from the server) listen on those ports and then have the mc servers register their existence with the that port at startup. However, having not seen the code, I suspect that would be an architectural change and my guess is that the client only expects to have a single server per host. It would also open up some security issues/concerns if that registry process didn't do some kind of IP authentication before accepting the record.
However, at the end of the day, not that many people have participated in this thread and highlighted it as an issue. My guess is that the PM/Dev team have marked this as "low priority - do not fix" because it will not end in global thermonuclear meltdown, and it's really only inconveniencing a few of us.
Still the problem in v1.17.11.01
[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Starting Server[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Version 1.17.11.01[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Session ID 9876543-cccc-bbbb-aaaa-123456789[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Level Name: reiWelt[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Game mode: 1 Creative[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Difficulty: 0 PEACEFUL[2021-08-16 04:01:15] [INFO] opening worlds/worldName/db[2021-08-16 04:01:16] [INFO] IPv4 supported, port: 19332[2021-08-16 04:01:16] [INFO] IPv6 supported, port: 19333[2021-08-16 04:01:16] [INFO] IPv4 supported, port: 35776[2021-08-16 04:01:16] [INFO] IPv6 supported, port: 33455[2021-08-16 04:01:16] [INFO] Server started.
Still the problem in v1.17.11.01
[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Starting Server[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Version 1.17.11.01[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Session ID 9876543-cccc-bbbb-aaaa-123456789[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Level Name: reiWelt[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Game mode: 1 Creative[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Difficulty: 0 PEACEFUL[2021-08-16 04:01:15] [INFO] opening worlds/worldName/db[2021-08-16 04:01:16] [INFO] IPv4 supported, port: 19332[2021-08-16 04:01:16] [INFO] IPv6 supported, port: 19333[2021-08-16 04:01:16] [INFO] IPv4 supported, port: 35776[2021-08-16 04:01:16] [INFO] IPv6 supported, port: 33455[2021-08-16 04:01:16] [INFO] Server started.
Still the problem in v1.17.11.01
[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Starting Server[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Version 1.17.11.01[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Session ID 9876543-cccc-bbbb-aaaa-123456789[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Level Name: reiWelt[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Game mode: 1 Creative[2021-08-16 04:01:15] [2021-08-16 04:01:15 INFO] Difficulty: 0 PEACEFUL[2021-08-16 04:01:15] [INFO] opening worlds/worldName/db[2021-08-16 04:01:16] [INFO] IPv4 supported, port: 19332[2021-08-16 04:01:16] [INFO] IPv6 supported, port: 19333[2021-08-16 04:01:16] [INFO] IPv4 supported, port: 35776[2021-08-16 04:01:16] [INFO] IPv6 supported, port: 33455[2021-08-16 04:01:16] [INFO] Server started.
This still affects 1.18.0.02
[2021-12-06 21:03:24:701 INFO] IPv4 supported, port: 12794[2021-12-06 21:03:24:701 INFO] IPv6 supported, port: 12795[2021-12-06 21:03:25:123 INFO] Server started.[2021-12-06 21:03:25:346 INFO] IPv4 supported, port: 19132[2021-12-06 21:03:25:346 INFO] IPv6 supported, port: 19133
Try update your BDS Vision
Try update your BDS Vision
Try update your BDS Vision
This still affects 1.18.11.01
[2022-02-10 11:21:46:646 INFO] Starting Server[2022-02-10 11:21:46:646 INFO] Version 1.18.11.01...[2022-02-10 11:21:50:547 INFO] IPv4 supported, port: 12794[2022-02-10 11:21:50:547 INFO] IPv6 supported, port: 12795[2022-02-10 11:21:50:981 INFO] Server started.[2022-02-10 11:21:51:165 INFO] IPv4 supported, port: 19132[2022-02-10 11:21:51:165 INFO] IPv6 supported, port: 19133
This still affect 1.18.12.01
Can we have an ETA on this old but blocking port issue ?
[2022-03-12 09:49:26:096 INFO] Starting Server
[2022-03-12 09:49:26:096 INFO] Version 1.18.12.01
...
[2022-03-12 09:49:27:642 INFO] IPv4 supported, port: 19134
[2022-03-12 09:49:27:642 INFO] IPv6 not supported
[2022-03-12 09:49:27:927 INFO] Server started.
[2022-03-12 09:49:27:944 INFO] IPv4 supported, port: 19132
[2022-03-12 09:49:27:944 INFO] IPv6 not supported
This still affect 1.18.12.01
Can we have an ETA on this old but blocking port issue ?
[2022-03-12 09:49:26:096 INFO] Starting Server
[2022-03-12 09:49:26:096 INFO] Version 1.18.12.01
...
[2022-03-12 09:49:27:642 INFO] IPv4 supported, port: 19134
[2022-03-12 09:49:27:642 INFO] IPv6 not supported
[2022-03-12 09:49:27:927 INFO] Server started.
[2022-03-12 09:49:27:944 INFO] IPv4 supported, port: 19132
[2022-03-12 09:49:27:944 INFO] IPv6 not supported
This still affect 1.18.12.01
Can we have an ETA on this old but blocking port issue ?
[2022-03-12 09:49:26:096 INFO] Starting Server
[2022-03-12 09:49:26:096 INFO] Version 1.18.12.01
...
[2022-03-12 09:49:27:642 INFO] IPv4 supported, port: 19134
[2022-03-12 09:49:27:642 INFO] IPv6 not supported
[2022-03-12 09:49:27:927 INFO] Server started.
[2022-03-12 09:49:27:944 INFO] IPv4 supported, port: 19132
[2022-03-12 09:49:27:944 INFO] IPv6 not supported
it appears preview 1.19.50 has code intended to resolve this issue by allowing the disabling of LAN Discovery for server instances:
Added server property 'enable-lan-visibility' to disable the explicit LAN discovery by clients. This will prevent unexpected port conflicts when running multiple dedicated servers on a single host. Clarified port use in server logs and made error messaging more clear (BDS-1094)
What's curious is that there is a new BDS server log message in 1.19.40.02 related to this feature, but the flag doesn't work in that release:
[2022-10-29 00:01:04:304 INFO] Server started.
[2022-10-29 00:01:04:537 INFO] Please note that LAN discovery will not function for this server.
[2022-10-29 00:01:04:537 INFO] Server IP must be specified in Servers tab in game.
it appears preview 1.19.50 has code intended to resolve this issue by allowing the disabling of LAN Discovery for server instances:
Added server property 'enable-lan-visibility' to disable the explicit LAN discovery by clients. This will prevent unexpected port conflicts when running multiple dedicated servers on a single host. Clarified port use in server logs and made error messaging more clear (BDS-1094)
What's curious is that there is a new BDS server log message in 1.19.40.02 related to this feature, but the flag doesn't work in that release:
[2022-10-29 00:01:04:304 INFO] Server started.
[2022-10-29 00:01:04:537 INFO] Please note that LAN discovery will not function for this server.
[2022-10-29 00:01:04:537 INFO] Server IP must be specified in Servers tab in game.
it appears preview 1.19.50 has code intended to resolve this issue by allowing the disabling of LAN Discovery for server instances:
Added server property 'enable-lan-visibility' to disable the explicit LAN discovery by clients. This will prevent unexpected port conflicts when running multiple dedicated servers on a single host. Clarified port use in server logs and made error messaging more clear (BDS-1094)
What's curious is that there is a new BDS server log message in 1.19.40.02 related to this feature, but the flag doesn't work in that release:
[2022-10-29 00:01:04:304 INFO] Server started.
[2022-10-29 00:01:04:537 INFO] Please note that LAN discovery will not function for this server.
[2022-10-29 00:01:04:537 INFO] Server IP must be specified in Servers tab in game.