Talk:Pocket Minecraft Protocol
Contents
Not receiving any packets when client tries to join server
When my vanilla client tries to connect to my custom server, I don't receive any packets, although it does show up in the server list! Please help!
VeryAwkwardCake 20:03, 03 January 2015 (GMT)
Got 0x1c when I sent 0x02 to a server
I've been playing around with this protocol and acting as a connecting client, I found that the protocol seems to be different than what is listed on this page. I sent these hex values to my iPod running Minecraft PE (full) v0.1.2 alpha: 02 00 00 00 00 00 a1 a2 41 00 ff ff 00 fe fe fe fe fd fd fd fd 12 34 56 78. It replied with 1c 00 00 00 00 00 a1 a2 41 00 00 00 00 79 1b 2d 6d 00 ff ff 00 fe fe fe fe fd fd fd fd 12 34 56 78 00 0b 4d 43 43 50 50 3b 44 65 6d 6f 3b 00 00 00 00 00 00 or 1c 00 00 00 00 00 a1 a2 41 00 00 00 00 79 1b 2d 6d 00 ff ff 00 fe fe fe fe fd fd fd fd 12 34 56 78 00 11 4d 43 43 50 50 3b 44 65 6d 6f 3b 6f 78 67 75 79 33. This is almost exactly like 0x0d, but it's got a different ID - 0x0c.
Here's a more readable way of writing this. I sent:
- int8 = 0x02 (packet type ID)
- int64 = ping ID
- MAGIC
The server replied:
- int8 = 0x1c (packet type ID)
- int64 = ping ID from client
- int64 = unknown (server ID??),
00 00 00 00 79 1b 2d 6d - MAGIC
- int8 = 0x00
- int8 = 0x11 is server is visible, 0x0b if server is invisible
- the string "MCCPP;Demo;username" (username is omitted if invisible)
Make of this what you will. I'm hoping to do more protocol analysis with two devices running Minecraft PE soon. -Oxguy3 20:58, 1 December 2011 (MST)
- Oh yeah, also, usernames are limited to 24 characters max, a client listening for 0x1c packets should capture a total of 70 bytes to avoid cutting off the username (my capture above was only 52 because I hadn't figured out the username stuff then). -Oxguy3 21:02, 1 December 2011 (MST)
- I also received a 0x1C when contacting Minecraft PE 1.3 lite. However, the second to last field (the one that switched between 0x11 and 0x0B) came back as a 15 for me (server was visible). --Bobtwinkles 20:32, 26 December 2011 (MST)
- AHA. Figured out the two int8s after the MAGIC in the 0x1C packet. It's the size of the string. The difference you observed was the string getting shorter because the username was omitted. So they are actually on int16--Bobtwinkles 20:32, 26 December 2011 (MST)
0x06 packet
Intresting note on the 0x06 packet. When sent a 0x05 0f size 1446, the 1.3 iPad lite server will reply with a 0x05C2 as the last two bytes. This implies that it is either getting extra data (not likely) or our assumption about it being the MTU size is wrong. However, I need to perform more testing on this front before drawing any conclusions. If you know something about the Java implementation of DatagramSockets that would tack on an extra 20 bytes of data, I'd like to know! --Bobtwinkles 21:19, 26 December 2011 (MST)
- I just realized that that 1446 should have been a 1464. The updated size request results in the server giving me a 0x5D4, or 1492 in decimal. It's now only 18 bytes to big... --Bobtwinkles 21:30, 26 December 2011 (MST)
- Also, it appears that the client will only send 3 0x05 packets of size 1464. --Bobtwinkles 09:10, 27 December 2011 (MST)
- AHA. Figured this one out. I was wrong about the inconsistent size differences - the size MCPE expects is always 28 bytes bigger, because it includes the size of the UDP and IP headers. --Bobtwinkles 08:31, 29 December 2011 (MST)
- Also, it appears that the client will only send 3 0x05 packets of size 1464. --Bobtwinkles 09:10, 27 December 2011 (MST)
Another note, not related only to the 0x06 packet. The serverID field (int 1.3 iPade lite) seems to change from session to session. --Bobtwinkles 21:23, 26 December 2011 (MST)
Ping ID fluctuates
Receiving an 0x02 packet from client v0.1.3j alpha demo on android:
Using python, unpacking the ping ID as a signed long makes the number fluctuate up and down (between the negatives), but when unpacking it as a unsigned long, it still fluctuates, but less.
Signed long data: (3765585432574689280,) (4559344866898739200,) (4560470766805581824,) (2976329597878009856,) (1824533993178005504,) (384508012326289408,) (-479338691198713856,) (-694385573405655040,) (99655335895105536,) (-475960991478185984,) (-1411583814064406528,) (-1050169943967924224,) (-2418138330781712384,) (-1840551678571446272,) (-3424692847499018240,)
Unsigned long data:
(7569157892377411584,) (5912959129411911680,) (4328817960484339712,) (3249079949822263296,) (2601687503387754496,) (1882237462915317760,) (874557046291169280,) (17880993664172294144,) (17882119564079136768,) (17162669523606700032,)
Am I just unpacking this data as the wrong type? Those are the only 2 options that support the size of the id. Or does the ID normally just rollercoaster up and down?
EDIT: Turns out I was just reading it as small endian. Needed to be big endian.
Survival Update port seems to be 19132 still
Netstat when scanning for games:
# netstat Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN tcp 0 0 10.0.2.15:5555 10.0.2.2:53493 ESTABLISHED udp 0 0 0.0.0.0:54331 0.0.0.0:* CLOSE
Netstat in game:
# netstat Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5555 0.0.0.0:* LISTEN tcp 0 0 10.0.2.15:5555 10.0.2.2:53493 ESTABLISHED udp 0 0 0.0.0.0:19132 0.0.0.0:* CLOSE
This is with Pocket Edition Demo 0.2.0 in Survival mode on the Android Ice Cream Sandwich Emulator.
Zhuowei 11:22, 25 February 2012 (MST)
Merge duplicate page
There is currently a second page regarding the Pocket Edition protocol which should probably be integrated with this older one. That should preferably be done by someone actually working on the protocol who knows which information is the up to date one. I suspect it is the one from the other page as it seems to have some information that this one misses. But at other parts this one is missing information? --Phoenix616 (talk) 19:11, 14 October 2017 (UTC)
