Omkhar

I'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.

Further you're completely mixing up how routing works. 

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

I think you might have misunderstood the concern, the operating system and resolution.

Firstly, this was discovered on two different Linux distributions, I'm not sure how relevant testing or not testing on Windows might be, but I don't know your code base.

Secondly, you've misinterpreted the defect, as well as how networking works under Linux.

This is not true, nor is it the root of the concern:

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.

In Linux the struct for sockaddr_in is defined as follows in socket.h:

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[8]; }; 

When passing this to bind() if you specify sin_addr as an actual address (rather than INADDR_ANY) it will bind() to a specific IP on the host.

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.

The issue, is that bedrock doesn't currently have a method of specifying what sin_addr is being used for bind(). Presumably you're using INADDR_ANY which subsequently binds to the first IP it sees. 

What I'm asking for is a config item in server.properties that will allow me to explicitly specific which IP bedrock binds to. For example:

server.properties 

bind-address=192.168.200.4

??Source : https://www.cs.rutgers.edu/~pxk/417/notes/sockets/udp.html??

As entertaining as some of these suggestions are, I just strace'd the start up again, this seems to be the relevant lines:

socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 7<UDP:[33556]>bind(7<UDP:[33556]>, {sa_family=AF_INET, sin_port=htons(19134), sin_addr=inet_addr("0.0.0.0")}, 16) = 0setsockopt(7<UDP:[33556]>, SOL_SOCKET, SO_RCVBUF, [262144], 4) = 0setsockopt(7<UDP:[33556]>, SOL_SOCKET, SO_LINGER, {l_onoff=0, l_linger=0}, 8) = 0setsockopt(7<UDP:[33556]>, SOL_SOCKET, SO_SNDBUF, [16384], 4) = 0setsockopt(7<UDP:[33556]>, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0getsockname(7<UDP:[33556]>, {sa_family=AF_INET, sin_port=htons(19134), sin_addr=inet_addr("0.0.0.0")}, [128->16]) = 0{color:#FF0000}setsockopt(7<UDP:[33556]>, SOL_IP, IP_HDRINCL, [0], 4) = -1 ENOPROTOOPT (Protocol not available){color}getsockname(7<UDP:[33556]>, {sa_family=AF_INET, sin_port=htons(19134), sin_addr=inet_addr("0.0.0.0")}, [128->16]) = 0sendto(7<UDP:[33556]>, "\0\0\0\0", 4, 0, {sa_family=AF_INET, sin_port=htons(19134), sin_addr=inet_addr("127.0.0.1")}, 16) = 4{color:#FF0000}socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP) = -1 EAFNOSUPPORT (Address family not supported by protocol){color}close(7<UDP:[33556]>)                   = 0

This issue occurs for me with a brand new installation. I presume this would be a vanilla world.

The link you cite doesn’t provide a resolution. 

Issue seems to be resolved, please close