[BDS-526] BDS failed to bind sockets on machines with ipv6 disabled Created: 12/Feb/19  Updated: 10/Feb/20  Resolved: 10/Feb/20

Status: Resolved
Project: Bedrock Dedicated Server
Affects Version/s: 1.9.0.15
Fix Version/s: None

Type: Bug
Reporter: Inactivate Assignee: Unassigned
Resolution: Invalid Votes: 1
Labels: None

Attachments: Text File trace_failed.log     Text File trace_ok.log    

 Description   

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.

  1. Fresh install Ubuntu box with docker installed apt install docker.io
  2. run: sudo docker run -it --rm -p 19132:19132/udp roemer/bedrock-server , so far everything goes fine
  3. add GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1" in /etc/default/grub
  4. run sudo update-grub
  5. reboot
  6. 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.



 Comments   
Comment by IonicEcko [ 10/Feb/20 ]

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!

Comment by Inactivate [ 10/Feb/20 ]

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.

 

Comment by IonicEcko [ 10/Feb/20 ]

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.

Generated at Sat Jan 11 07:14:25 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.