Talk:Protocol - Revision history

imported>Trejkaz: /* New packet 0x1A? */

2024-07-12T10:42:25Z

New packet 0x1A?

← Older revision		Revision as of 10:42, 12 July 2024
Line 852:		Line 852:

	: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again suggests use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)		: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again suggests use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)

			:: As far as my API currently treats it, the size is written before the packet, which is why it isn't in that dump. [[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 10:41, 12 July 2024 (UTC)

imported>LassiPulkkinen: /* New packet 0x1A? */ Typo.

2024-07-11T19:57:00Z

New packet 0x1A?: Typo.

← Older revision		Revision as of 19:57, 11 July 2024
Line 851:		Line 851:
	[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)		[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)

	: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again ~~suggest~~ use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)		: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again suggests use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)

imported>LassiPulkkinen: /* New packet 0x1A? */ Oops extra spacing.

2024-07-11T19:54:47Z

New packet 0x1A?: Oops extra spacing.

← Older revision		Revision as of 19:54, 11 July 2024
Line 850:		Line 850:

	[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)		[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)


	: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again suggest use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)		: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again suggest use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)

imported>LassiPulkkinen: /* New packet 0x1A? */

2024-07-11T19:54:17Z

New packet 0x1A?

← Older revision		Revision as of 19:54, 11 July 2024
Line 850:		Line 850:

	[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)		[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)


			: First of all, you're probably using an older Minecraft version. The newest version I found where 0x1A means Disconnect is 1.20; there may be others too. That would explain the weird packet ID. Second, are you sending a packet length field (not included in the dump shown)? If not, that might be it (the FF FF FF FF 0F gets parsed as a length, which is too long for the special 1-3 byte length field VarInt parser), though the response from 1.20 is slightly different (<code>{"translate":"disconnect.genericReason","with":["Internal Exception: io.netty.handler.codec.CorruptedFrameException: length wider than 21-bit"]}</code>), so it would have to have been a different version if that were the case. However, it does indeed use the Play protocol packet ID for Disconnect (0x1A), unlike newer versions I tested (which just silently disconnect). This again suggest use of an old version. After adding a length field the packet worked fine on 1.20, 1.20.4 and 1.21 (the handshake and status protocols are deliberately backward and forward-compatible, it's just that the older server was leaking the Disconnect packet from its incompatible play protocol to the handshake phase). So either the length field is wrong or missing, or there's a bug causing the sent packet to be different from what you showed. --[[User:LassiPulkkinen\|LassiPulkkinen]] ([[User talk:LassiPulkkinen\|talk]]) 19:53, 11 July 2024 (UTC)

imported>Trejkaz: Reformatting /* New packet 0x1A? */

2024-07-11T15:30:47Z

Reformatting New packet 0x1A?

← Older revision		Revision as of 15:30, 11 July 2024
Line 822:		Line 822:
	I received this packet the first time I tried talking to a server. It's packet type 0x1A, but neither of the type 0x1A listed seem to match it. New discovery?		I received this packet the first time I tried talking to a server. It's packet type 0x1A, but neither of the type 0x1A listed seem to match it. New discovery?

	1A		<pre>
	9B 01		1A (packet ID)
	7B 22 74 72 61 6E 73 6C 61 74 65 22 3A 22 64 69		9B 01 (length of following string data, varint 155)
			7B 22 74 72 61 6E 73 6C 61 74 65 22 3A 22 64 69 (The data is a JSON payload telling me why the server is disconnecting me...)
	73 63 6F 6E 6E 65 63 74 2E 67 65 6E 65 72 69 63		73 63 6F 6E 6E 65 63 74 2E 67 65 6E 65 72 69 63
	52 65 61 73 6F 6E 22 2C 22 77 69 74 68 22 3A 5B		52 65 61 73 6F 6E 22 2C 22 77 69 74 68 22 3A 5B
Line 834:		Line 835:
	78 63 65 70 74 69 6F 6E 3A 20 56 61 72 49 6E 74		78 63 65 70 74 69 6F 6E 3A 20 56 61 72 49 6E 74
	20 74 6F 6F 20 62 69 67 22 5D 7D		20 74 6F 6F 20 62 69 67 22 5D 7D
			</pre>
	~~The data is a JSON payload telling me why the server is disconnecting me.~~

	Currently we say "the protocol immediately switches to a different state after the client sends the first packet", but what if the first packet is invalid?		Currently we say "the protocol immediately switches to a different state after the client sends the first packet", but what if the first packet is invalid?
Line 841:		Line 841:
	What I sent:		What I sent:

	00 (packet ID, handshake)		<pre>
	FF FF FF FF 0F (protocol version -1)		00 (packet ID, handshake)
	0C 31 39 32 2E 31 36 38 2A 31 2E 35 36 (hostname, in this case a local network ip addr)		FF FF FF FF 0F (protocol version -1)
	63 DD (port, 25565)		0C 31 39 32 2E 31 36 38 2A 31 2E 35 36 (hostname, in this case a local network ip addr)
	01 (next state, Status)		63 DD (port, 25565)
			01 (next state, Status)
			</pre>

	[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)		[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)

imported>Trejkaz: /* New packet 0x1A? */

2024-07-11T15:28:31Z

New packet 0x1A?

← Older revision		Revision as of 15:28, 11 July 2024
Line 835:		Line 835:
	20 74 6F 6F 20 62 69 67 22 5D 7D		20 74 6F 6F 20 62 69 67 22 5D 7D

	The data is a JSON payload telling me why the server is disconnecting me. [[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)		The data is a JSON payload telling me why the server is disconnecting me.

			Currently we say "the protocol immediately switches to a different state after the client sends the first packet", but what if the first packet is invalid?

			What I sent:

			00 (packet ID, handshake)
			FF FF FF FF 0F (protocol version -1)
			0C 31 39 32 2E 31 36 38 2A 31 2E 35 36 (hostname, in this case a local network ip addr)
			63 DD (port, 25565)
			01 (next state, Status)


			[[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)

imported>Trejkaz: /* New packet 0x1A? */

2024-07-11T14:55:28Z

New packet 0x1A?

← Older revision		Revision as of 14:55, 11 July 2024
Line 835:		Line 835:
	20 74 6F 6F 20 62 69 67 22 5D 7D		20 74 6F 6F 20 62 69 67 22 5D 7D

	The data is a JSON payload telling me why the server is disconnecting me.		The data is a JSON payload telling me why the server is disconnecting me. [[User:Trejkaz\|Trejkaz]] ([[User talk:Trejkaz\|talk]]) 14:55, 11 July 2024 (UTC)

imported>Trejkaz: /* New packet 0x1A? */ new section

2024-07-11T14:54:49Z

New packet 0x1A?: new section

← Older revision		Revision as of 14:54, 11 July 2024
Line 817:		Line 817:

	"Select Advancements Tab" says that the Identifier can be any of the five vanilla root advancements, but in fact, judging from the identifiers matching the vanilla datapack, it seems that the identifier can be any arbitrary root that client knows about.[[User:WithLithum\|WithLithum]] ([[User talk:WithLithum\|talk]]) 03:05, 10 June 2024 (UTC)		"Select Advancements Tab" says that the Identifier can be any of the five vanilla root advancements, but in fact, judging from the identifiers matching the vanilla datapack, it seems that the identifier can be any arbitrary root that client knows about.[[User:WithLithum\|WithLithum]] ([[User talk:WithLithum\|talk]]) 03:05, 10 June 2024 (UTC)

			== New packet 0x1A? ==

			I received this packet the first time I tried talking to a server. It's packet type 0x1A, but neither of the type 0x1A listed seem to match it. New discovery?

			1A
			9B 01
			7B 22 74 72 61 6E 73 6C 61 74 65 22 3A 22 64 69
			73 63 6F 6E 6E 65 63 74 2E 67 65 6E 65 72 69 63
			52 65 61 73 6F 6E 22 2C 22 77 69 74 68 22 3A 5B
			22 49 6E 74 65 72 6E 61 6C 20 45 78 63 65 70 74
			69 6F 6E 3A 20 69 6F 2E 6E 65 74 74 79 2E 68 61
			6E 64 6C 65 72 2E 63 6F 64 65 63 2E 44 65 63 6F
			64 65 72 45 78 63 65 70 74 69 6F 6E 3A 20 6A 61
			76 61 2E 6C 61 6E 67 2E 52 75 6E 74 69 6D 65 45
			78 63 65 70 74 69 6F 6E 3A 20 56 61 72 49 6E 74
			20 74 6F 6F 20 62 69 67 22 5D 7D

			The data is a JSON payload telling me why the server is disconnecting me.

imported>WithLithum: /* 0x4A identifiers can be arbitrary */ oops

2024-06-10T03:05:50Z

0x4A identifiers can be arbitrary: oops

← Older revision		Revision as of 03:05, 10 June 2024
Line 816:		Line 816:
	== 0x4A identifiers can be arbitrary ==		== 0x4A identifiers can be arbitrary ==

	"Select Advancements Tab" says that the Identifier can be any of the five vanilla root advancements, but in fact, judging from the identifiers matching the vanilla datapack, it seems that the identifier can be any arbitrary root that client knows about.		"Select Advancements Tab" says that the Identifier can be any of the five vanilla root advancements, but in fact, judging from the identifiers matching the vanilla datapack, it seems that the identifier can be any arbitrary root that client knows about.[[User:WithLithum\|WithLithum]] ([[User talk:WithLithum\|talk]]) 03:05, 10 June 2024 (UTC)

imported>WithLithum: /* 0x4A identifiers can be arbitrary */ new section

2024-06-10T03:05:27Z

0x4A identifiers can be arbitrary: new section

← Older revision		Revision as of 03:05, 10 June 2024
Line 813:		Line 813:

	Taking a look at the source code of Minecraft 1.20.4, it seems the events for opening and closing doors (event IDs 1005-1008 and 1011-1014) have been removed. Event ID 1011 is now in use to stop a currently playing record, while event ID 1010 can no longer be used to achieve this.		Taking a look at the source code of Minecraft 1.20.4, it seems the events for opening and closing doors (event IDs 1005-1008 and 1011-1014) have been removed. Event ID 1011 is now in use to stop a currently playing record, while event ID 1010 can no longer be used to achieve this.

			== 0x4A identifiers can be arbitrary ==

			"Select Advancements Tab" says that the Identifier can be any of the five vanilla root advancements, but in fact, judging from the identifiers matching the vanilla datapack, it seems that the identifier can be any arbitrary root that client knows about.