[BDS-526] BDS failed to bind sockets on machines with ipv6 disabled

The issue is the one reported in https://bugs.mojang.com/browse/BDS-178, I'm adding more details here and a complement steps for reproducing it.

Symptoms

The server starts with logs:

[2019-02-12 07:02:23 INFO] IPv4 supported, port: 0
[2019-02-12 07:02:23 INFO] IPv6 supported, port: 0

And

netstat -lunp

shows the BDS is not listening on any port.

Steps to Reproduce

I'm running a Ubuntu Server 16.04 box with Parallels Desktop virtual machine on a mac. I believe the versions of all these runtime environments have no impact on this issue.

Fresh install Ubuntu box with docker installed apt install docker.io
run: sudo docker run -it --rm -p 19132:19132/udp roemer/bedrock-server , so far everything goes fine
add GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1" in /etc/default/grub
run sudo update-grub
reboot
re-run sudo docker run -it --rm -p 19132:19132/udp roemer/bedrock-server and the issue appears

Some Clues

The difference after disable ipv6 from GRUB is, the socket system call no longer recognizes AF_INET6 any more:

$ nc -6 -u -l :: 12345
nc: Address family not supported by protocol

I did a strace -o trace.log -s 100 ./bedrock_server and found it probably a bug in the code:

# partial trace back on machine with ipv6 ENABLED:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP) = 8
bind(8, {sa_family=AF_INET6, sin6_port=htons(19133), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
...
getsockname(8, {sa_family=AF_INET6, sin6_port=htons(19133), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [128->28]) = 0
sendto(8, "\0\0\0\0", 4, 0, {sa_family=AF_INET6, sin6_port=htons(19133), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(8)                                = 0
close(7)                                = 0
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 7
bind(7, {sa_family=AF_INET, sin_port=htons(19132), sin_addr=inet_addr("0.0.0.0")}, 16) = 0

# partial trace back on machine with ipv6 DISABLED:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
...
close(7)                                = 0
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 7
bind(7, {sa_family=AF_INET, sin_port=htons(19132), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
... # the following traceback shows weird behavior:
socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
close(7)                                = 0
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 7
bind(7, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [262144], 4) = 0
setsockopt(7, SOL_SOCKET, SO_LINGER, {l_onoff=0, l_linger=0}, 8) = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [16384], 4) = 0
setsockopt(7, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
getsockname(7, {sa_family=AF_INET, sin_port=htons(39782), sin_addr=inet_addr("0.0.0.0")}, [128->16]) = 0
setsockopt(7, SOL_IP, IP_HDRINCL, [0], 4) = -1 ENOPROTOOPT (Protocol not available)
getsockname(7, {sa_family=AF_INET, sin_port=htons(39782), sin_addr=inet_addr("0.0.0.0")}, [128->16]) = 0
sendto(7, "\0\0\0\0", 4, 0, {sa_family=AF_INET, sin_port=htons(39782), sin_addr=inet_addr("127.0.0.1")}, 16) = 4
socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
close(7)                                = 0

Looks like it's a reused variable holding the socket fd and assigned ipv4 socket fd by mistake in case of ipv6 socket is failed to be created.

Attachments2

trace_failed.log

Inactivate

2019-02-12, 09:32:04 AM

trace_ok.log

Inactivate

2019-02-12, 09:32:04 AM

Comments3

IonicEcko 2020-02-10, 07:11:44 AM

Hi Bananawanted,

If you're experiencing the same issue as a previous bug report please up-vote the existing report and add any contributing evidence in the comments. Having multiple reports makes it hard to consolidate the information and dilutes the effectiveness of the bug tracker.

Ionic

Could a mod please link to ~~BDS-178~~ and close this issue.

Inactivate 2020-02-10, 02:36:00 PM

Hey @IonicEcko

I can confirm the issue still exists on the latest build, and can be reproduced with the exactly same steps described above.

I also noticed the error message printed to the console has changed to 'Network port occupied' following the 'port: 0' messages in the latest build. You'll be able to find a lot of similar bug reports whiches probably share the same root cause with this one.

IonicEcko 2020-02-10, 03:02:08 PM

Awesome Banana, thanks for confirming.

It looks like this one got closed without linking to the master issue, I'll get that sorted tomorrow.

Thanks again!