Raknet Protocol

Remember that this page is a WIP. Come back later to see a more complete page.

---

RakNet is a networking library used by Minecraft Bedrock Edition. You might want to also look at the documentation for the Bedrock Protocol. This is based on the old Pocket Edition Protocol Documentation and may be incomplete or outdated. The source code for the RakNet Library can be found here. RakNet uses UDP as its networking protocol. The key differences from TCP are that not all packets are guaranteed to reach the destination at all or in order (it isn't reliable) and it uses messages with a specified length instead of streams of data. RakNet compensates for the out-of-order delivery and makes it reliable.

NOTE: You may want to use an existing library if one exists for your language of choice. Here is an incomplete list. Not all of these are maintained or complete. If these are outdated you may need to change the protocol version to 11 before it can work. The protocol doesn't seem to have had any significant changes since the official implementation was discontinued in 2014, so as long as you bump the protocol version older libraries are likely to still work.

Name	Description	Language	License	Active development
PieRakNet	Network System used for PieMC written in Python	Python	GPL-3	Yes
NukkitX Network	Network components used within NukkitX, but with great support for general use as well	Java	Apache License	Yes
rak-net	rak-net is the first updated and fully working RakNet implementation written in Python to run a Minecraft Bedrock Edition server. This library was mainly created for Podrum, although it can be used in other projects too and can be installed via pip.	Python	MIT	Yes
JRakNet	JRakNet is a networking library for Java which implements the UDP based protocol RakNet	Java	MIT	Yes
netty-raknet	High performance implementation of RakNet for netty, following strict netty patterns.	Java	MIT	Yes
JSRakNet	JSRakNet is the first up to date and fully working raknet implementation written in Javascript to run a Minecraft PE server, designed mainly for JSPrismarine, but the implementation offers a general use	Javascript	MIT	Yes
JRakLibPlus	A library for easy creation of RakNet servers, based on RakLib and JRakLib.	Java	LGPL	No
RakLib	RakNet server implementation written in PHP. This library is very lightweight on actual implementation - it provides the bare minimum to get a Minecraft Pocket Edition server functional. It only currently provides server functionality, and does not support most RakNet features.	PHP	GPL	Yes
raknet	UDP network library that follows the RakNet protocol for Node.js	Javascript	MIT	No
PyRakLib	PyRakLib is a networking library that follows the RakNet protocol for MCPE. It is ported from the PHP library RakLib.	Python	GPL	No
rust-raknet	RakNet Protocol implementation by Rust.	Rust	MIT	Yes
Raknet (official)	The official implementation. Outdated and mostly for reference purposes. May not work with the latest Bedrock.	C++	BSD	No

Data types

	Size (Bytes)	Range	Notes
byte	1	0 to 255
Long	8	-2^63 to 2^63-1	Signed 64-bit Integer
Magic	16	00ffff00fefefefefdfdfdfd12345678	Always those hex bytes, corresponding to RakNet's default OFFLINE_MESSAGE_DATA_ID
short	2	-32768 to 32767
unsigned short	2	0 to 65535
string	unsigned short + string	N/A	Prefixed by a short containing the length of the string in characters. It appears that only the following ASCII characters can be displayed: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
boolean	1	0 to 1	True is encoded as 0x01, false as 0x00.
address	7		1 byte for the IP version (4 or 6), followed by (for IPv4) 4 bytes for the IP and an unsigned short for the port number
uint24le	3		3-byte little-endian unsigned integer

Handshake sequence

1. C→S: Open Connection Request 1
2. S→C: Open Connection Reply 1
3. C→S: Open Connection Request 2
4. S→C: Open Connection Reply 2

From here on, the RakNet connection is established and all RakNet messages are contained in a Frame Set Packet.

1. C→S: Connection Request
2. S→C: Connection Request Accepted
3. C→S: New Incoming Connection

Next packets should be Game Packet

Packets

Unconnected Ping

Packet ID	Field Name	Field Type	Notes
0x01, 0x02	Time	Long
	MAGIC	magic
	Client GUID	Long

0x02 is only replied to if there are open connections to the server. Note: as of 0.15.6 it seems that the game refreshes it's LAN world list every 4-5 seconds, however it seems the game will still ping in 1 second intervals.
This packet should be responded to with unconnected Pong.

Unconnected Pong

Packet ID	Field Name	Field Type	Notes
0x1c	Time	Long
	Server GUID	Long
	MAGIC	magic
	Server ID string	string	Used for the MOTD. See below for details.

Server ID string format

For Minecraft Bedrock this is separated by semicolons and uses the following format:
Edition (MCPE or MCEE for Education Edition);MOTD line 1;Protocol Version;Version Name;Player Count;Max Player Count;Server Unique ID;MOTD line 2;Game mode;Game mode (numeric);Port (IPv4);Port (IPv6);
Example:
MCPE;Dedicated Server;390;1.14.60;0;10;13253860892328930865;Bedrock level;Survival;1;19132;19133;
Result:

The Game mode and Game mode (numeric) values seem to not be used by the client.

Connected Ping

Packet ID	Field Name	Field Type	Notes
0x00	Time	Long

Connected Pong

Packet ID	Field Name	Field Type	Notes
0x03	Ping Time	Long
	Pong Time	Long

Open Connection Request 1

Packet ID	Field Name	Field Type	Notes
0x05	Magic	MAGIC
	Protocol version	byte	Currently 11
	MTU	Zero padding	The MTU sent in the response appears to be somewhere around the size of this padding + 46 (28 udp overhead, 1 packet id, 16 magic, 1 protocol version). This padding seems to be used to discover the maximum packet size the network can handle.

The client sends these to the target server with ever decreasing MTU until the server responds. This is used to discover the MTU size for the connection. According to the official docs, "The MTU size is the maximum size of a packet RakNet will generate", and "if you set the MTU size larger than your or any router along the network path takes, then the network will split the packet at best, or drop it at worst", so this process of sending decreasingly padded packets (compensating for the size of the packet itself and UDP overhead, which together make 48 bytes) seem to be used to discover the maximum packet size the network can handle. See the official documentation page for more info about the MTU size. If the RakNet protocol does not match your own, respond with the Incompatible protocol packet.

You should always respond to the first of these packets that you receive with Open Connection Reply 1, containing an MTU size of the amount of padding you received in bytes plus 46.

Open Connection Reply 1

Packet ID	Field Name	Field Type	Notes
0x06	Magic	MAGIC
	Server GUID	Long
	Use security	boolean	Make sure this is false, it is vital for the login sequence to continue!
	MTU	short	see Open Connection Request 1

Open Connection Request 2

Packet ID	Field Name	Field Type	Notes
0x07	Magic	MAGIC
	Server Address	address
	MTU	short
	Client GUID	Long

Open Connection Reply 2

Packet ID	Field Name	Field Type	Notes
0x08	Magic	MAGIC
	Server GUID	Long
	Client Address	address
	MTU	short
	Encryption enabled?	boolean

Connection Request

Packet ID	Field Name	Field Type	Notes
0x09	GUID	Long
	Time	Long

Connection Request Accepted

Packet ID	Field Name	Field Type	Notes
0x10	Client address	address
	System index	short	Unknown what this does. 0 works as a value.
	Internal IDs	10x address	Unknown what these do. 255.255.255.255:19132 for all of them seems to work, any other address will probably work as well.
	Request time	Long
	Time	Long

New Incoming Connection

Packet ID	Field Name	Field Type	Notes
0x13	Server address	address
	Internal address	address	Unknown what this is used for.

Disconnect

Packet ID
0x15

Incompatible Protocol

Packet ID	Field Name	Field Type	Notes
0x19	Protocol	byte
	Magic	MAGIC
	Server GUID	Long

Unconnected Ping

Packet ID	Field Name	Field Type	Notes
0x01, 0x02	Time	Long
	GUID	Long

Frame Set Packet

Packet ID	Field Name			Field Type	Notes
0x80..0x8d	Sequence number			uint24le
	Frames	Flags		byte	Top 3 bits are reliability type, fourth bit is 1 when the frame is fragmented and part of a compound.
		Length IN BITS		unsigned short	Length of the body in bits.
		Reliable frame index		uint24le	only if reliable
		Sequenced frame index		uint24le	only if sequenced
		Order	Ordered frame index	uint24le	only if ordered
			Order channel	byte
		Fragment	Compound size	int	only if fragmented
			Compound ID	short
			Index	int
		Body	ceil(length/8) bytes

The reliability types are as follows:

ID	Name	Reliable	Ordered	Sequenced
0	unreliable
1	unreliable sequenced		x	x
2	reliable	x
3	reliable ordered	x	x
4	reliable sequenced	x	x	x
5	unreliable (+ ACK receipt)
6	reliable (+ ACK receipt)	x
7	reliable ordered (+ ACK receipt)	x	x

Sequenced implies ordered.

Game Packet

Packet ID	Field Name	Field Type	Notes
0xfe	Body	bytes	Single packet of the GAME protocol. The packet is usually compressed.

NACK

Packet ID	Field Name			Field Type	Notes
0xa0	Record count			short
	Record	Single Sequence number?		boolean	False for range, True for no range
		No Range	Sequence number	uint24le	Number of sequence to not acknowledge
		Range	Start Sequence number	uint24le
			End Sequence number	uint24le

ACK

Packet ID	Field Name			Field Type	Notes
0xc0	Record count			short
	Record	Single Sequence number?		boolean	False for range, True for no range
		No Range	Sequence number	uint24le	Number of sequence to acknowledge
		Range	Start Sequence number	uint24le
			End Sequence number	uint24le