I can verify that this bug continues to exist in latest version.
This bug does not cause any gameplay impact to my knowledge on a vanilla minecraft server, so it would be difficult to demonstrate any issues in the vanilla game. If you investigate the packets sent to the server on join vs for a status ping is where you find the discrepancy.
Steps to reproduce:
Add a server to the multiplayer server list with a domain which has an SRV record pointing to a server on a different hostname/port (For example, adding test.example.com to your server list, with SRV record _minecraft._tcp.test.example.com pointing to example.com port 12345 and with example.com having its own A record pointing to the numeric IP)
Log the hostname and port sent in the initial handshake/intention packet
Observed result:
Connections to join the server with the above example would yield an intention packet in which the hostname field is set to “example.com” and the port set to 12345.
Status pings to the server with the above specified example would yield an intention packet in which the hostname field is set to “test.example.com” and port 25565 (Despite the fact that it correctly connects to example.com at port 12345)
Expected result: The intention packets for both types would have the same hostname/port fields (set to example.com at port 12345, as is currently done on join but not on status ping)
The following is the reason I came up in my investigation that this occurs.
Login connections do the following (In net/minecraft/network/Connection.connect):
The above code uses the resolver to resolve the address, and uses the InetSocketAddress returned by the resolver to supply the information passed into initiateServerboundPlayConnections which passes it through into the packet data.
Status connections do the following (In net/minecraft/client/multiplayer/ServerStatusPinger.pingserver):
final ServerAddressrawAddress = ServerAddress.parseString(data.ip);Optional<InetSocketAddress> resolvedAddress = ServerNameResolver.DEFAULT.resolveAddress(rawAddress).map(ResolvedServerAddress::asInetSocketAddress);
if (resolvedAddress.isEmpty()) {
this.onPingFailed(ConnectScreen.UNKNOWN_HOST_MESSAGE,data);
} else {
final InetSocketAddress address = (InetSocketAddress)resolvedAddress.get();finalConnectionconnection=Connection.connectToServer(address,eventLoopGroupHolder,null);...try {
connection.initiateServerboundStatusConnection(rawAddress.getHost(),rawAddress.getPort(),listener);connection.send(ServerboundStatusRequestPacket.INSTANCE);
} catch(Throwablevar11) {
LOGGER.error("Failedtopingserver {}",rawAddress,var11);
}
}
Which instead has the call to initiateServerboundStatusConnection source the hostname and port from the raw, unresolved address as opposed to resolved version, and thus despite connecting to the correct resolved address it will provide incorrect hostname/port data.
Making it instead use the values sourced from the resolved address exactly as is done in the logic in ConnectScreen would resolve this issue.
I can verify that this bug continues to exist in latest version.
This bug does not cause any gameplay impact to my knowledge on a vanilla minecraft server, so it would be difficult to demonstrate any issues in the vanilla game. If you investigate the packets sent to the server on join vs for a status ping is where you find the discrepancy.
Steps to reproduce:
Add a server to the multiplayer server list with a domain which has an SRV record pointing to a server on a different hostname/port (For example, adding test.example.com to your server list, with SRV record _minecraft._tcp.test.example.com pointing to example.com port 12345 and with example.com having its own A record pointing to the numeric IP)
Log the hostname and port sent in the initial handshake/intention packet
Observed result:
Connections to join the server with the above example would yield an intention packet in which the hostname field is set to “example.com” and the port set to 12345.
Status pings to the server with the above specified example would yield an intention packet in which the hostname field is set to “test.example.com” and port 25565 (Despite the fact that it correctly connects to example.com at port 12345)
Expected result:
The intention packets for both types would have the same hostname/port fields (set to example.com at port 12345, as is currently done on join but not on status ping)
The following is the reason I came up in my investigation that this occurs.
Login connections do the following (In net/minecraft/network/Connection.connect):
The above code uses the resolver to resolve the address, and uses the InetSocketAddress returned by the resolver to supply the information passed into initiateServerboundPlayConnections which passes it through into the packet data.
Status connections do the following (In net/minecraft/client/multiplayer/ServerStatusPinger.pingserver):
Which instead has the call to initiateServerboundStatusConnection source the hostname and port from the raw, unresolved address as opposed to resolved version, and thus despite connecting to the correct resolved address it will provide incorrect hostname/port data.
Making it instead use the values sourced from the resolved address exactly as is done in the logic in ConnectScreen would resolve this issue.