[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: |
|
| 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. SymptomsThe 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 ReproduceI'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.
Some CluesThe 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 |