[SPIGOT-2549] Respawn packet has incorrect encoding Created: 23/Jul/16 Updated: 24/Jul/16 Resolved: 23/Jul/16 |
|
Status: | Resolved |
Project: | Spigot |
Component/s: | None |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Bug | Priority: | Minor |
Reporter: | Dorquemada | Assignee: | Unassigned |
Resolution: | Invalid | Votes: | 0 |
Labels: | Respawn, spigot, | ||
Environment: |
OS: Linux, MS Client: Wurst 4.0, Vanilla 1.10.2, Server: 64.34.190.101:28965 |
Description |
When receiving Respawn (0x33, client-bound) packets from a Spigot 1.10 server, these are encoded incorrectly. The packet format should be as follows: Examples for a Respawn packet received from various servers:
00 00 00 00 01 01 04 66 6c 61 74 .......flat
ff ff ff ff 00 00 07 64 65 66 61 75 6c 74 .......default ff ff ff ff 03 00 07 64 65 66 61 75 6c 74 .......default My guess is that Spigot 1.10 sends the values of dimension,difficulty,gamemode as shorts, which would interpret the output from the first example as dimension=0 (overworld), difficulty=11 (hard+hardcore), gamemode=0 (survival), while it should encode them as int,byte,byte (in both cases followed by a string) |
Comments |
Comment by Dorquemada [ 24/Jul/16 ] |
I agree this issue is likely caused by some plugins running on that server, as it's the only place where this behavior occurs. I was not able to detect it on any other Spigot 1.10 server. |
Comment by md_5 [ 24/Jul/16 ] |
Oh and for the avoidance of any doubt, that > 10 "internal IDs" mentioned by Black Hole are not sent over the wire. ffffffff01010764656661756c74 net.minecraft.network.play.server.SPacketRespawn@15cd52f[dimensionID=-1,difficulty=EASY,gameType=CREATIVE,worldType=net.minecraft.world.WorldType@48e490a5] 0000000001010764656661756c74 net.minecraft.network.play.server.SPacketRespawn@bb5f658[dimensionID=0,difficulty=EASY,gameType=CREATIVE,worldType=net.minecraft.world.WorldType@48e490a5] I think what you are seeing is either a result of 1) a buffer corruption/overrun in your client, or 2) a function of the copious unsupported plugins running on the abovementioned server (that hack into Spigot internals or perform protocol level manipulation, see: ProtocolLib) |
Comment by md_5 [ 23/Jul/16 ] |
Oh and I dumped the packets from the above server (64.34.190.101:28965) and didn't see what you described: 0000000000010764656661756c74 0000000001010764656661756c74 ffffffff00010764656661756c74 |
Comment by md_5 [ 23/Jul/16 ] |
Spigot does not modify the respawn packet at all. A dump of the respawn packet on my server (no plugins and hence no custom dimensions), reads as follows: |
Comment by Dorquemada [ 23/Jul/16 ] |
Well, the specific issue is that the ChunkData packet has an optional data array 'skylight' whether or not is this array present has to be derived from the current dimension. If the dimension is 0 (overworld), then the skylight is present, otherwise it is not. If you make a wrong assumption, the packet will be decoded incorrectly. If Spigot supports other dimensions, that's fine, but in the case the dimension is not 0, you should not include the skylight data in the ChunkData packets. What specifically triggered the investigation about this issue can be seen here: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-tools/2599886-mcbuild-a-custom-minecraft-client-with-auto-build?page=3 |
Comment by Black Hole [ 23/Jul/16 ] |
Spigot can handle more than the three default worlds. They are assigned dimension ids starting with 10. Is there any real issue with those dimension ids? |
Comment by Dorquemada [ 23/Jul/16 ] |
Note that the correct information about the dimension which is sent in Respawn and JoinGame packets is necessary to correctly decode ChunkData packets. Without correct dimension information, it can't be reliably determined whether the packets contain the skylight info or not - this could explain several bugs related to lighting being tracked right now. |