Hey guys, I am currently working on a proxy server for Minecraft (actually it is going to be an extensible packet filtering and redirecting stuff thing ). Now the problem is that even though all packets should pass the proxy flawlessly, I cannot connect to a server(Bukkit). After about one second the message "end of stream" appears in the client window, although the server keeps sending packets to the proxy. I had the packets logged and what I observed is the following (all in hexadecimal notation): 1. Handshaking on both ends seems to work fine (packets: 02,FD,FC,FC,CD[actually passed through]) the onscreen message in the client changes to "downloading terrain" 2.The server writes 01,FA,06,CA,04,03 now the client sends a CC then a 0D, this is the last packet from the client, server continues with a bunch of 03s,C9,0D,04,68,67 then 23 and 18 alternating for a time. The first chunk data (33) is sent about one second after the completion of the handshake. The last packet from the client is sent about 500ms after completion of the handshake. The server continues to send a diversity of packets for over 15 seconds after the client lost connection (then I stopped the proxy). If the complete log would help I can upload it somewhere. The lag introduced by the proxy is never more than 1-3ms so I think that shouldn't be a problem and since the major bottleneck is en-\decryption it isn't really improvable either. The proxy is based on netty if this information helps. So the question is: Why does the client quit after sending the 0D? What does it expect but fails to receive? The protocol documentation says that the server should send this and the client should answer with the same packet but with two fields swapped. But obviously the client sends it itself and the server does not seem to expect an answer to its own 0D. Thanks in advance.