BDS-526BDS 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
Created Issue:
BDS binds to incorrect socket 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: 0And
netstat -lunpshows 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 protocolI 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) = 0Looks 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.
BDSbindsto incorrectsocket on machines with ipv6 disabledBDS failed to bind sockets on machines with ipv6 disabled
![[Mojang] Mega_Spud (Jay Wells)](../../../data/avatars/users/92696.png){kind=small}
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-178and close this issue.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.
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!