<!-- 
RSS generated by JIRA (9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13) at Sat Jan 11 07:41:37 UTC 2025

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Mojang Studios Jira</title>
    <link>https://bugs.mojang.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en</language>    <build-info>
        <version>9.12.2</version>
        <build-number>9120002</build-number>
        <build-date>10-01-2024</build-date>
    </build-info>


<item>
            <title>[BDS-7707] bedrock binds to first IP address on multi-homed server</title>
                <link>https://bugs.mojang.com/browse/BDS-7707</link>
                <project id="11700" key="BDS">Bedrock Dedicated Server</project>
                    <description>&lt;p&gt;&lt;b&gt;Steps to reproduce...&lt;/b&gt;&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Build Linux box - Attempted on both Gentoo and Ubuntu 20.04&lt;/li&gt;
	&lt;li&gt;Install Minecraft&lt;/li&gt;
	&lt;li&gt;Assign multiple IPs to an adaptor (192.168.1.2, 192.168.1.3, 192.168.1.4)&lt;/li&gt;
	&lt;li&gt;Attempt to connect to 192.168.1.3 or 192.168.1.4 - doesn&apos;t work&lt;/li&gt;
	&lt;li&gt;Attempt to connect to 192.168.1.2 - it works&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;&lt;b&gt;What I expected to happen...&lt;/b&gt;&lt;br/&gt;
Bedrock should either bind to all IPs and answer on all IPs, or allow specification of which IP to bind to within server.properties&lt;/p&gt;

&lt;p&gt;&lt;b&gt;What actually happened...&lt;/b&gt;&lt;br/&gt;
Bedrock only binds to the first IP&lt;/p&gt;

&lt;p&gt;&lt;b&gt;How this affects the usage of BDS...&lt;/b&gt;&lt;br/&gt;
On a system with multiple IPs it is ambiguous as to which one Bedrock will answer on.&lt;/p&gt;</description>
                <environment></environment>
        <key id="358753">BDS-7707</key>
            <summary>bedrock binds to first IP address on multi-homed server</summary>
                <type id="1" iconUrl="https://bugs.mojang.com/secure/viewavatar?size=xsmall&amp;avatarId=18903&amp;avatarType=issuetype">Bug</type>
                                    <status id="5" iconUrl="https://bugs.mojang.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="7">Invalid</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="omkhar">Omkhar</reporter>
                        <labels>
                    </labels>
                <created>Sat, 25 Jul 2020 16:13:43 +0200</created>
                <updated>Wed, 18 Jan 2023 04:24:24 +0100</updated>
                            <resolved>Tue, 11 Aug 2020 04:29:48 +0200</resolved>
                                    <version>1.16.10</version>
                                                            <votes>0</votes>
                                    <watches>2</watches>
                                                                            <comments>
                            <comment id="1221576" author="ranmakei" created="Wed, 18 Jan 2023 04:24:24 +0100"  >&lt;p&gt;I am having an issue that is indicative of this behavior. The bedrock server appears to bind to all IP addresses using 0.0.0.0:19132. If I already have another server bound to an IP with the same port as bedrock 19132 it causes the bedrock server to fail to boot because it can&apos;t bind to an IP. I can put in the config to bind to a specific IP like the java version, but it does not appear to do anything.&lt;/p&gt;

&lt;p&gt;This is causing an issue that prevents multiple bedrock servers from being able to run on the same box.&#160;&lt;/p&gt;

&lt;p&gt;Trying to run two servers:&lt;/p&gt;

&lt;p&gt;A Survival server on IP1:19132&lt;br/&gt;
A Creative server on IP2:19132&lt;/p&gt;</comment>
                            <comment id="1121769" author="omkhar" created="Sun, 5 Dec 2021 22:03:54 +0100"  >&lt;p&gt;I&apos;m not sure how else to describe this, but if you can forward to someone who understands socket programming it might help. In order to serve inbound connections, BDS needs to bind() to a port. There have been numerous reports on the internet with ridiculous problems with the way BDS binds on Linux.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Further you&apos;re completely mixing up how routing works.&#160;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="783464" author="ionicecko" created="Sun, 9 Aug 2020 17:12:52 +0200"  >&lt;p&gt;To cut a long story short, I don&apos;t misunderstand and BDS doesn&apos;t &quot;bind&quot; to any specific interface, it will respond to connections on any interface, obeying the OS&apos;s routing table. However in a default configuration this can result in linux responding on a different IP to the original destination, causing it not to connect. This means your below assertion is not accurate.&lt;/p&gt;

&lt;blockquote&gt;
&lt;h4&gt;&lt;a name=&quot;Whatactuallyhappened...&quot;&gt;&lt;/a&gt;What actually happened...&lt;/h4&gt;
&lt;p&gt;Bedrock only binds to the first IP&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;BDS will respond to traffic coming in on any interface, it is not attached to one specific interface, your OS configuration however determines how it responds.&lt;/p&gt;

&lt;p&gt;You can test this by forcing traffic to a specific destination out specific interfaces via routing and then monitoring the traffic and noting that BDS is responding on different interfaces simultaneously. You will also find that the IP your server responds on is the same one that shows when checking the default IP for all network traffic using a service like whatsmyip. I&apos;ve just done this on Ubuntu 20.04 to cover your concern about using Windows (they are the same codebase, in 90% of cases issues translate).&lt;/p&gt;

&lt;p&gt;BDS not responding to multiple interfaces would have in fact been a bug, but wanting a way to easily specify that it bind to a specific interface would be considered a feature request and as such is not suitable for the bug tracker. Feature Requests can be made over at &lt;a href=&quot;https://feedback.minecraft.net&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://feedback.minecraft.net&lt;/a&gt;, or more specifically the &lt;a href=&quot;https://feedback.minecraft.net/hc/en-us/community/topics/360000721951-Realms-and-Dedicated-Servers&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;Realms and Dedicated Servers&lt;/a&gt; section. &lt;/p&gt;</comment>
                            <comment id="783394" author="omkhar" created="Sun, 9 Aug 2020 15:25:43 +0200"  >&lt;p&gt;I think you might have misunderstood the concern, the operating system and resolution.&lt;/p&gt;

&lt;p&gt;Firstly, this was discovered on two different Linux distributions, I&apos;m not sure how relevant testing or not testing on Windows might be, but I don&apos;t know your code base.&lt;/p&gt;

&lt;p&gt;Secondly, you&apos;ve misinterpreted the defect, as well as how networking works under Linux.&lt;/p&gt;

&lt;p&gt;This is not true, nor is it the root of the concern:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;Lets say your server has 2 IP addresses (192.168.0.1 and .2), it will always have one of the two that it uses for outgoing traffic. So when using 192.168.0.1 to connect it responds using 192.168.0.1 to respond and everything works.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;In Linux the struct for &lt;tt&gt;sockaddr_in&lt;/tt&gt; is defined as follows in &lt;tt&gt;socket.h&lt;/tt&gt;:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;struct sockaddr_in { __uint8_t sin_len; sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; char sin_zero&lt;span class=&quot;error&quot;&gt;&amp;#91;8&amp;#93;&lt;/span&gt;; };&#160;&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;When passing this to &lt;tt&gt;bind()&lt;/tt&gt; if you specify &lt;tt&gt;sin_addr&lt;/tt&gt; as an actual address (rather than&#160;&lt;tt&gt;INADDR_ANY&lt;/tt&gt;) it will &lt;tt&gt;bind()&lt;/tt&gt; to a specific IP on the host.&lt;/p&gt;

&lt;p&gt;Your statement regarding one always being used for outbound traffic is incorrect. If you bind to one IP, all datagrams will bear that IP as the source when responding. Doing otherwise would result in asynchronous traffic where traffic is sent from one IP and returns on another.&lt;/p&gt;

&lt;p&gt;The issue, is that bedrock doesn&apos;t currently have a method of specifying what &lt;tt&gt;sin_addr&lt;/tt&gt; is being used for &lt;tt&gt;bind()&lt;/tt&gt;. Presumably you&apos;re using &lt;tt&gt;INADDR_ANY&lt;/tt&gt; which subsequently binds to the first IP it sees.&#160;&lt;/p&gt;

&lt;p&gt;What I&apos;m asking for is a config item in &lt;tt&gt;server.properties&lt;/tt&gt; that will allow me to explicitly specific which IP bedrock binds to. For example:&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;server.properties&#160;&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;bind-address=192.168.200.4&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;??Source : &lt;a href=&quot;https://www.cs.rutgers.edu/~pxk/417/notes/sockets/udp.html??&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://www.cs.rutgers.edu/~pxk/417/notes/sockets/udp.html??&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="783251" author="ionicecko" created="Sun, 9 Aug 2020 08:19:57 +0200"  >&lt;p&gt;I&apos;m not able to reproduce this on Windows, not the scenario you describe where BDS won&apos;t respond on both interfaces, however that&apos;s not the full story.&lt;/p&gt;

&lt;p&gt;The server wont respond against both IP&apos;s without additional configuration. This is a networking thing to do with routing.&lt;/p&gt;

&lt;p&gt;Lets say your server has 2 IP addresses (192.168.0.1 and .2), it will always have one of the two that it uses for outgoing traffic. So when using 192.168.0.1 to connect it responds using 192.168.0.1 to respond and everything works.&lt;/p&gt;

&lt;p&gt;However when you try to connect using 192.168.0.2, it responds using 192.168.0.1 and because of the discrepancy it fails.&lt;/p&gt;

&lt;p&gt;If you update the routing table to respond using the second interface everything will start working.&lt;/p&gt;

&lt;p&gt;As such its not ambiguous which interface BDS will respond on, it will respond on any, however your routing will decide if it succeeds or fails.&lt;/p&gt;

&lt;p&gt;I&apos;ll chuck this one into awaiting response. Let me know if you believe this to be incorrect.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                <customfield id="customfield_10500" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Confirmation Status</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Unconfirmed]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_11700" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_11600" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i1jmnb:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    </customfields>
    </item>
</channel>
</rss>