Nether causes "minecraft for windows" to close immediately for MITM proxy

[appoulos]

I'm using github.com/sandertv/gophertunnel v1.51.0 to mitm proxy a connection between the latest version 1.21.121 of bedrock dedicated server on linux and "minecraft for windows." Overworld dimension works fine, but upon entering the nether, the "minecraft for windows" process closes unexpectedly. Dimensions overworld and the_end do not cause the same problem. Also, the nether works fine when bypassing the proxy.

I can replicate the problem with a command:

/execute as @a in nether run tp ~ ~1 ~

"overworld" and "the_end" work as expected:

/execute as @a in overworld run tp ~ ~1 ~
/execute as @a in the_end run tp ~ ~1 ~

[Happy2018new]

This is a reproducible problem. (Windows BDS Server + Windows MCBE)

[Happy2018new]

I confirmed this problem in the few last versions (of mc), and with your issue opened, I look deeper and maybe I can understand what happened here.

Generally speaking, there are multiple ways to solve your problem.

Solution A

Clean SavedChunks for all packet.NetworkChunkPublisherUpdate.
The following image show how I do. Note that all modify is based on main.go.

Solution B

Disable ClientSideGeneration when gophertunnel try start game for the client connection.

Solution C

Disbale client-side-chunk-generation-enabled in server.properties of BDS.

Solution D

In minecraft/conn.go, just disable this line.

Solution E

Or you can ignore any packet.BiomeDefinitionList that send from BDS.
Note that this solution introduce new problem which is the biome color is not correct.

[Happy2018new]

But one thing I need to say is that all the solutions above are ugly, because the essence of these fixes is all about drilling holes, which is not good for the robustness of the program.

And you might interested at what is the essence of these solutions. Well, let me explain it.

In this packet, the usge of SavedChunks is currently unknown.

// NetworkChunkPublisherUpdate is sent by the server to change the point around which chunks are and remain
// loaded. This is useful for mini-game servers, where only one area is ever loaded, in which case the
// NetworkChunkPublisherUpdate packet can be sent in the middle of it, so that no chunks ever need to be
// additionally sent during the course of the game.
// In reality, the packet is not extraordinarily useful, and most servers just send it constantly at the
// position of the player.
// If the packet is not sent at all, no chunks will be shown to the player, regardless of where they are sent.
type NetworkChunkPublisherUpdate struct {
	// Position is the block position around which chunks loaded will remain shown to the client. Most servers
	// set this position to the position of the player itself.
	Position protocol.BlockPos
	// Radius is the radius in blocks around Position that chunks sent show up in and will remain loaded in.
	// Unlike the RequestChunkRadius and ChunkRadiusUpdated packets, this radius is in blocks rather than
	// chunks, so the chunk radius needs to be multiplied by 16. (Or shifted to the left by 4.)
	Radius uint32
	// SavedChunks ...
	// TODO: Figure out what this field is used for.
	SavedChunks []protocol.ChunkPos
}

And by access NetworkChunkPublisherUpdatePacket, you can find that Mojang call this field as Server Built Chunks List.

Therefore I guess this field is related to ClientSideGeneration... Maybe this field is used to notify these chunks is generated by the server, and the left chunks can generated by the client self, which this description can corresponding to how ClientSideGeneration works.

So I try Solution C and it works. Then I try Solution B and it also works.

But up to this point, the cause of the client's crash still cannot be explained. Therefore, we need more conjectures and assumptions.

So we need to think about anything related to ClientSideGeneration. The first thing that came to my mind was packet.BiomeDefinitionList.
Because the comment of this packet mentioned server-side generation.

// BiomeDefinitionList is sent by the server to let the client know all biomes that are available and
// implemented on the server side. When enabled, it also includes information for the client to
// accurately recreate the server-side generation in vanilla worlds/servers for increased performance.
type BiomeDefinitionList struct {
	// BiomeDefinitions is a list of biomes that are available on the server.
	BiomeDefinitions []protocol.BiomeDefinition
	// StringList is a makeshift dictionary implementation Mojang created to try and reduce the size of the
	// overall packet. It is a list of common strings that are used in the biome definitions, such as
	// biome names, float values or query expressions.
	StringList []string
}

Note that BDS itself will send packet.BiomeDefinitionList to the client side, and because gophertunnel send an empty packet.BiomeDefinitionList, so the problem maybe is we need to send a completely one instead of empty one.

// handleRequestChunkRadius handles an incoming RequestChunkRadius packet. It sets the initial chunk radius
// of the connection, and spawns the player.
func (conn *Conn) handleRequestChunkRadius(pk *packet.RequestChunkRadius) error {
	if pk.ChunkRadius < 1 {
		return fmt.Errorf("expected chunk radius of at least 1, got %v", pk.ChunkRadius)
	}
	conn.expect(packet.IDSetLocalPlayerAsInitialised)
	radius := pk.ChunkRadius
	if r := conn.gameData.ChunkRadius; r != 0 {
		radius = r
	}
	_ = conn.WritePacket(&packet.ChunkRadiusUpdated{ChunkRadius: radius})
	conn.gameData.ChunkRadius = pk.ChunkRadius
	// Clients pre-1.21.80 crash when not sending all biomes, due to achievements assuming all biomes are present.
	// To maintain backwards compatibility, we send empty biomes so the protocol can handle legacy biome data
	// for older clients (see: https://github.com/Sandertv/gophertunnel/blob/a61732e9cb7bc04e5e7dd961ad4fea597f1229dc/minecraft/conn.go#L1274-L1278).
	_ = conn.WritePacket(&packet.BiomeDefinitionList{})
	_ = conn.WritePacket(&packet.PlayStatus{Status: packet.PlayStatusPlayerSpawn})
	_ = conn.WritePacket(&packet.CreativeContent{})
	return nil
}

_ = conn.WritePacket(&packet.BiomeDefinitionList{})

You can see it send an empty one.

And because BDS will send this packet, so we can just disable this line so that gophertunnel would not send packet.packet.BiomeDefinitionList itself.
And you can find that this is actually Solution D, and it works.

Then I adjust Solution D, to let gophertunnel continue send an empty one again, but ignore any packet.BiomeDefinitionList from BDS, which is Solution E.

And it still works... So my assumption is wrong. The actual problem is not that gophertunnel sent an empty packet.BiomeDefinitionList.

The real problem seems the Minecraft client can only receive packet.BiomeDefinitionList once.
And that's why I said all the solutions are horrible, because these solutions do not touch upon the essence.

To truly solve this problem, it is necessary to ensure that the packet.BiomeDefinitionList is sent only once.

However, the current organizational structure of gophertunnel requires it to send this packet by itself. However, some servers may send a packet.BiomeDefinitionList by themselves, such as BDS.

It is not good to block the real packet.BiomeDefinitionList from the server because they may have some custom data.

This means that even if gophertunnel itself sends the original packet.BiomeDefinitionList packet filled with content, if a server uses a custom packet.BiomeDefinitionList, the color rendering of the biome by the client will be incorrect.

This means that gophertunnel may need to decouple some of its logic. In my opinion, no packets from the server should be blocked, so the packet.BiomeDefinitionList should not be sent by the internal implementation of gophertunnel but elsewhere.

Elegantly fixing this issue should be very complicated if the correct order of sending packets is to be taken into account.