This is not correct fix, as server advertisement would also be incorrect (so we should fix inside server/advertisement). I believe the mechanics of this may have changed from a prior version

This function is upstream of server/advertisement, correct? Further server/advertisement receives a utf-8 string so we could not do a two-byte adjustment (easily) on that input.

The output of server/advertisement is where I discovered this issue, but we typically don't use the field this affects (header):

ServerAdvertisement {
  motd: 'BlahBlah',
  levelName: 'My World',
  playersOnline: '1',
  playersMax: '5',
  gamemode: 'Creative',
  serverId: '13124841751394787494',
  protocol: '554',
  version: '1.19.40.20',
  header: '\x00VMCPE'  # should be 'MCPE'
}

I guess the "correctest" fix would be to treat pong return value as a binary non-null-terminated string with two-byte length prepended and parse it accordingly, but the end result would be the same.

Yeah, I don't think this is a problem (minecraft identifies the server with or without a length header) but it's possible this is something that should be handled at RakNet level. Since RakNet unconnected pong data is not necessarily a length-prefixed string (could be an integer or some other binary structure) we may want to return a Buffer that can be skipped 2 bytes inside bedrock-protocol for the actual string.

In RakNet, the pong data is just written as a non-length prefixed string
https://github.dev/extremeheat/fb-raknet/blob/9af9fb2d74c56c87d54071d7aac93cf0c28b110a/Source/RakPeer.cpp#L2285-L2286

do you plan to finish this ?

old