G'day Chris, No, tcpdump doesn't really help me ... I use packet decoding logic in the Linux client to figure out what is going on. We don't have this in the server yet, but it's something I'm pondering. On Sat, May 20, 2006 at 10:50:24PM +0200, Chris en Judith wrote: > roughly the server responds to my CP_SOCKET and CP_FEATURE message > with a SP_MOTD and a SP_MOTD_PIC the remainder of the buffer is > filled with a 0 and gets flushed. (i might accidently have read an > entire frame 1536 in stead of what was really in the buffer but > what the hack. You'd better clarify this. Packets are sent appended to each other, and unless you get the sizes exactly right (their size is not in the data stream usually) then you will lose alignment and crash. > i was expecting a message SP_S_PLAYER to set which slot i'd been > allocated but i might be fully off here. After SP_MOTD you get SP_YOU with your player number, then a batch of (SP_PL_LOGIN, SP_HOSTILE, SP_PLAYER_INFO, SP_KILLS, SP_PSTATUS and SP_PLAYER) for each of the 32 slots. Then you get all the SP_PLANET_LOCs for each planet, then all the SP_FEATURE packets, then an SP_LOGIN prompt packet. Your reply at this point should be CP_LOGIN. See http://quozl.linux.org.au/netrek/login.log.gz for an example of a connection and login sequence. > What is going wrong and what should i have done ? Read and understand the working protocol and crosscheck against your code. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/