From darrellroot at mac.com Mon Mar 4 15:07:35 2019 From: darrellroot at mac.com (Darrell Root) Date: Mon, 4 Mar 2019 13:07:35 -0800 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence Message-ID: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> netrek-dev, I’m working on a Swift Netrek client for the Mac. I’m having trouble getting through the login sequence. I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 with no active players as a test target. In my packet traces below the server is at 192.168.0.10. I’m able to successfully play on my test server with the MacTrek client. Here’s a count of the packets I’ve been able to send/receive and process (not in order): 31 "Received SP_FLAGS" 32 "Received SP_HOSTILE" 32 "Received SP_KILLS" 1 "Received SP_LOGIN" 40 "Received SP_PLANET_LOC" 32 "Received SP_PLAYER" 52 "Received SP_PLAYER_INFO" 32 "Received SP_PL_LOGIN" 32 "Received SP_PSTATUS" 1 "Received SP_YOU" 1 "Sending CP_FEATURE 60" 1 "Sending CP_LOGIN 8" 1 "Sending CP_OUTFIT 9" 1 "Sending CP_SOCKET 27" Here’s the end of the sequence: ... "Received SP_LOGIN" "Sending CP_FEATURE 60" "Sending CP_OUTFIT 9" No response to CP_OUTFIT. The server logs an inability to do a DNS reverse lookup on 192.168.0.31, but I don’t think that is related (and it doesn’t stop the MacTrek Objective-C client from playing). I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, or that some other packet is required to login on the server. Here’s my CP_FEATURE: 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags [P.], seq 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 ecr 1657847922], length 88 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 0x0090: 0000 0000 0000 0000 0000 Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks correct. 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: Flags [P.], seq 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr 1642419149], length 88 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 0x0090: 0000 0000 0000 0000 0000 For reference here’s reference information on that structure: #define CP_FEATURE 60 struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 */ char type; char feature_type; /* either 'C' or 'S' */ char arg1, arg2; int value; char name[80]; }; struct feature_var feature_vars[] = { {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, Here’s my CP_OUTFIT when I try to login as fed (I also tried setting team to 0 at 0x0044 since that is what MacTrek appears to do). 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val 516594969 ecr 1657848989], length 4 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 0x0040: c49d 0901 0200 Here’s info on that struct: #define CP_OUTFIT 9 /* outfit to new ship */ struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ char type; char team; char ship; char pad1; }; Could the problem be with my earlier packets? They got responses. But here they are for completeness: CP_SOCKET: (note that my client does not support UDP) 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val 512991468 ecr 1654229963], length 8 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 0x0040: 8bcb 1b04 0a00 0000 8020 #define CP_SOCKET 27 /* new socket for reconnection */ struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ char type; char version; char udp_version; /* was pad2 */ char pad3; u_int socket; }; CP_LOGIN: (hardcoded to guest as the username, password and login empty) 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val 512992524 ecr 1654231039], length 52 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 */ char type; char query; char pad2; char pad3; char name[NAME_LEN]; char password[NAME_LEN]; char login[NAME_LEN]; }; Any ideas what I need to correct or what else I need to supply to successfully login as guest? Darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at laptop.org Mon Mar 4 16:19:02 2019 From: quozl at laptop.org (James Cameron) Date: Tue, 5 Mar 2019 09:19:02 +1100 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> Message-ID: <20190304221902.GH3274@laptop.org> G'day Darrell, According to protocol, you should expect SP_YOU in response to CP_LOGIN and CP_FEATURE. You say you have it in the count of packets, but you don't have it in the end of the sequence. Can you show the whole sequence? Also, see these references; 1. netrek protocol https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 2. sending CP_FEATURE of FEATURE_PACKETS immediately after CP_SOCKET, https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: > netrek-dev, > > I’m working on a Swift Netrek client for the Mac. I’m having trouble getting > through the login sequence. > > I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 with no active > players as a test target. In my packet traces below the server is at > 192.168.0.10. > > I’m able to successfully play on my test server with the MacTrek client. > > Here’s a count of the packets I’ve been able to send/receive and process (not > in order): > > 31 "Received SP_FLAGS" > 32 "Received SP_HOSTILE" > 32 "Received SP_KILLS" > 1 "Received SP_LOGIN" > 40 "Received SP_PLANET_LOC" > 32 "Received SP_PLAYER" > 52 "Received SP_PLAYER_INFO" > 32 "Received SP_PL_LOGIN" > 32 "Received SP_PSTATUS" > 1 "Received SP_YOU" > 1 "Sending CP_FEATURE 60" > 1 "Sending CP_LOGIN 8" > 1 "Sending CP_OUTFIT 9" > 1 "Sending CP_SOCKET 27" > > Here’s the end of the sequence: > > ... > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > No response to CP_OUTFIT. > The server logs an inability to do a DNS reverse lookup on 192.168.0.31, but I > don’t think that is related (and it doesn’t stop the MacTrek Objective-C client > from playing). > > I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, or that some > other packet is required to login on the server. > > Here’s my CP_FEATURE: > > 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags [P.], seq > 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 ecr 1657847922], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 > 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 > 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks correct. > > 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: Flags [P.], seq > 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr 1642419149], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 > 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 > 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > For reference here’s reference information on that structure: > > #define CP_FEATURE 60 > > struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 */ > char type; > char feature_type; /* either 'C' or 'S' */ > char arg1, > arg2; > int value; > char name[80]; > }; > > struct feature_var feature_vars[] = { > {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, > > Here’s my CP_OUTFIT when I try to login as fed (I also tried setting team to 0 at 0x0044 since that is what MacTrek appears to do). > > 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val 516594969 ecr 1657848989], length 4 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 > 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 > 0x0040: c49d 0901 0200 > > Here’s info on that struct: > > #define CP_OUTFIT 9 /* outfit to new ship */ > > struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ > char type; > char team; > char ship; > char pad1; > }; > > Could the problem be with my earlier packets? They got responses. But here they are for completeness: > > CP_SOCKET: (note that my client does not support UDP) > > 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val 512991468 ecr 1654229963], length 8 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 > 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 > 0x0040: 8bcb 1b04 0a00 0000 8020 > > #define CP_SOCKET 27 /* new socket for reconnection */ > > struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ > char type; > char version; > char udp_version; /* was pad2 */ > char pad3; > u_int socket; > }; > > CP_LOGIN: (hardcoded to guest as the username, password and login empty) > > 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val 512992524 ecr 1654231039], length 52 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 > 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 > 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 > > struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 */ > char type; > char query; > char pad2; > char pad3; > char name[NAME_LEN]; > char password[NAME_LEN]; > char login[NAME_LEN]; > }; > > Any ideas what I need to correct or what else I need to supply to successfully login as guest? > > Darrell > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.netrek.org/ From darrellroot at mac.com Mon Mar 4 16:26:14 2019 From: darrellroot at mac.com (Darrell Root) Date: Mon, 4 Mar 2019 14:26:14 -0800 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: <20190304221902.GH3274@laptop.org> References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> <20190304221902.GH3274@laptop.org> Message-ID: I’ll take a look at those documents although I’m already all over packets.h from the distribution. Here’s the full sequence in order. SP_YOU comes early before I send my login authentication as guest. Darrell "Sending CP_PACKET 27" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_PLAYER_INFO" "Received SP_YOU" "Sending CP_LOGIN 8" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PL_LOGIN" "Received SP_HOSTILE" "Received SP_PLAYER_INFO" "Received SP_KILLS" "Received SP_PSTATUS" "Received SP_FLAGS" "Received SP_PLAYER" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_PLANET_LOC" "Received SP_LOGIN" "Sending CP_FEATURE 60" "Sending CP_OUTFIT 9" > On Mar 4, 2019, at 2:19 PM, James Cameron wrote: > > G'day Darrell, > > According to protocol, you should expect SP_YOU in response to > CP_LOGIN and CP_FEATURE. You say you have it in the count of packets, > but you don't have it in the end of the sequence. Can you show the > whole sequence? > > Also, see these references; > > 1. netrek protocol > > https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > > 2. sending CP_FEATURE of FEATURE_PACKETS immediately after CP_SOCKET, > > https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 > > On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: >> netrek-dev, >> >> I’m working on a Swift Netrek client for the Mac. I’m having trouble getting >> through the login sequence. >> >> I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 with no active >> players as a test target. In my packet traces below the server is at >> 192.168.0.10. >> >> I’m able to successfully play on my test server with the MacTrek client. >> >> Here’s a count of the packets I’ve been able to send/receive and process (not >> in order): >> >> 31 "Received SP_FLAGS" >> 32 "Received SP_HOSTILE" >> 32 "Received SP_KILLS" >> 1 "Received SP_LOGIN" >> 40 "Received SP_PLANET_LOC" >> 32 "Received SP_PLAYER" >> 52 "Received SP_PLAYER_INFO" >> 32 "Received SP_PL_LOGIN" >> 32 "Received SP_PSTATUS" >> 1 "Received SP_YOU" >> 1 "Sending CP_FEATURE 60" >> 1 "Sending CP_LOGIN 8" >> 1 "Sending CP_OUTFIT 9" >> 1 "Sending CP_SOCKET 27" >> >> Here’s the end of the sequence: >> >> ... >> "Received SP_LOGIN" >> "Sending CP_FEATURE 60" >> "Sending CP_OUTFIT 9" >> >> No response to CP_OUTFIT. >> The server logs an inability to do a DNS reverse lookup on 192.168.0.31, but I >> don’t think that is related (and it doesn’t stop the MacTrek Objective-C client >> from playing). >> >> I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, or that some >> other packet is required to login on the server. >> >> Here’s my CP_FEATURE: >> >> 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags [P.], seq >> 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 ecr 1657847922], >> length 88 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 >> 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 >> 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 >> 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 >> 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0090: 0000 0000 0000 0000 0000 >> >> Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks correct. >> >> 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: Flags [P.], seq >> 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr 1642419149], >> length 88 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 >> 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 >> 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 >> 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 >> 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0090: 0000 0000 0000 0000 0000 >> >> For reference here’s reference information on that structure: >> >> #define CP_FEATURE 60 >> >> struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 */ >> char type; >> char feature_type; /* either 'C' or 'S' */ >> char arg1, >> arg2; >> int value; >> char name[80]; >> }; >> >> struct feature_var feature_vars[] = { >> {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, >> >> Here’s my CP_OUTFIT when I try to login as fed (I also tried setting team to 0 at 0x0044 since that is what MacTrek appears to do). >> >> 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val 516594969 ecr 1657848989], length 4 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 >> 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 >> 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 >> 0x0040: c49d 0901 0200 >> >> Here’s info on that struct: >> >> #define CP_OUTFIT 9 /* outfit to new ship */ >> >> struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ >> char type; >> char team; >> char ship; >> char pad1; >> }; >> >> Could the problem be with my earlier packets? They got responses. But here they are for completeness: >> >> CP_SOCKET: (note that my client does not support UDP) >> >> 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val 512991468 ecr 1654229963], length 8 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 >> 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 >> 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 >> 0x0040: 8bcb 1b04 0a00 0000 8020 >> >> #define CP_SOCKET 27 /* new socket for reconnection */ >> >> struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ >> char type; >> char version; >> char udp_version; /* was pad2 */ >> char pad3; >> u_int socket; >> }; >> >> CP_LOGIN: (hardcoded to guest as the username, password and login empty) >> >> 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val 512992524 ecr 1654231039], length 52 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 >> 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 >> 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 >> 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 >> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 >> >> struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 */ >> char type; >> char query; >> char pad2; >> char pad3; >> char name[NAME_LEN]; >> char password[NAME_LEN]; >> char login[NAME_LEN]; >> }; >> >> Any ideas what I need to correct or what else I need to supply to successfully login as guest? >> >> Darrell >> > >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > -- > James Cameron > http://quozl.netrek.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at laptop.org Mon Mar 4 16:52:35 2019 From: quozl at laptop.org (James Cameron) Date: Tue, 5 Mar 2019 09:52:35 +1100 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> <20190304221902.GH3274@laptop.org> Message-ID: <20190304225235.GK3274@laptop.org> Here's a packet dump from Gytha just now. http://dev.laptop.org/~quozl/z/1h0wOC.txt Note how CP_FEATURE is sent early, and there's a burst of SP_FEATURE after CP_LOGIN and before SP_LOGIN. Also, I was wrong in previous mail, SP_YOU is seen before CP_LOGIN, but with zero flags. On Mon, Mar 04, 2019 at 02:26:14PM -0800, Darrell Root wrote: > I’ll take a look at those documents although I’m already all over packets.h > from the distribution. > > Here’s the full sequence in order. SP_YOU comes early before I send my login > authentication as guest. > > Darrell > > "Sending CP_PACKET 27" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_YOU" > "Sending CP_LOGIN 8" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > On Mar 4, 2019, at 2:19 PM, James Cameron <[1]quozl at laptop.org> wrote: > > G'day Darrell, > > According to protocol, you should expect SP_YOU in response to > CP_LOGIN and CP_FEATURE. You say you have it in the count of packets, > but you don't have it in the end of the sequence. Can you show the > whole sequence? > > Also, see these references; > > 1. netrek protocol > > [2]https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > > 2. sending CP_FEATURE of FEATURE_PACKETS immediately after CP_SOCKET, > > https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 > > On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: > > netrek-dev, > > I’m working on a Swift Netrek client for the Mac. I’m having trouble > getting > through the login sequence. > > I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 with no > active > players as a test target. In my packet traces below the server is at > 192.168.0.10. > > I’m able to successfully play on my test server with the MacTrek > client. > > Here’s a count of the packets I’ve been able to send/receive and > process (not > in order): > > 31 "Received SP_FLAGS" > 32 "Received SP_HOSTILE" > 32 "Received SP_KILLS" > 1 "Received SP_LOGIN" > 40 "Received SP_PLANET_LOC" > 32 "Received SP_PLAYER" > 52 "Received SP_PLAYER_INFO" > 32 "Received SP_PL_LOGIN" > 32 "Received SP_PSTATUS" > 1 "Received SP_YOU" > 1 "Sending CP_FEATURE 60" > 1 "Sending CP_LOGIN 8" > 1 "Sending CP_OUTFIT 9" > 1 "Sending CP_SOCKET 27" > > Here’s the end of the sequence: > > ... > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > No response to CP_OUTFIT. > The server logs an inability to do a DNS reverse lookup on > 192.168.0.31, but I > don’t think that is related (and it doesn’t stop the MacTrek > Objective-C client > from playing). > > I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, or > that some > other packet is required to login on the server. > > Here’s my CP_FEATURE: > > 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags > [P.], seq > 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 ecr > 1657847922], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 > 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 > 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks > correct. > > 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: Flags > [P.], seq > 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr > 1642419149], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 > 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 > 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > For reference here’s reference information on that structure: > > #define CP_FEATURE 60 > > struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 */ > char type; > char feature_type; /* either 'C' or 'S' */ > char arg1, > arg2; > int value; > char name[80]; > }; > > struct feature_var feature_vars[] = { > {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, > > Here’s my CP_OUTFIT when I try to login as fed (I also tried setting > team to 0 at 0x0044 since that is what MacTrek appears to do). > > 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags > [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val > 516594969 ecr 1657848989], length 4 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 > 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 > 0x0040: c49d 0901 0200 > > Here’s info on that struct: > > #define CP_OUTFIT 9 /* outfit to new ship */ > > struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ > char type; > char team; > char ship; > char pad1; > }; > > Could the problem be with my earlier packets? They got responses. But > here they are for completeness: > > CP_SOCKET: (note that my client does not support UDP) > > 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags > [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val 512991468 ecr > 1654229963], length 8 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 > 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 > 0x0040: 8bcb 1b04 0a00 0000 8020 > > #define CP_SOCKET 27 /* new socket for reconnection > */ > > struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ > char type; > char version; > char udp_version; /* was pad2 */ > char pad3; > u_int socket; > }; > > CP_LOGIN: (hardcoded to guest as the username, password and login > empty) > > 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags > [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val 512992524 > ecr 1654231039], length 52 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 > 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 > 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 > > struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 */ > char type; > char query; > char pad2; > char pad3; > char name[NAME_LEN]; > char password[NAME_LEN]; > char login[NAME_LEN]; > }; > > Any ideas what I need to correct or what else I need to supply to > successfully login as guest? > > Darrell > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -- > James Cameron > http://quozl.netrek.org/ > > References: > > [1] mailto:quozl at laptop.org > [2] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.netrek.org/ From darrellroot at mac.com Mon Mar 4 17:57:26 2019 From: darrellroot at mac.com (Darrell Root) Date: Mon, 4 Mar 2019 15:57:26 -0800 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: <20190304225235.GK3274@laptop.org> References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> <20190304221902.GH3274@laptop.org> <20190304225235.GK3274@laptop.org> Message-ID: <7BEEF23C-B4A9-4F4F-8257-1F171BFF4BA8@mac.com> Thank you for that packet dump in netrek format. I’ll have to upgrade my logs to be that helpful. ;-) I’m actively troubleshooting using your data. On a general netrek-dev note, programming with Swift for most things is cool. I’m using Apple’s new Network framework to send my data (I believe they are working with the IETF on that), so no more BSD socket API. My TCP reader/writer is around 100 lines (have not implemented UDP). Packet analyzer is larger of course. One Swift pain point is generating arbitrary packets. In C you can just send a struct out a network interface. But Swift does not guarantee the layout of native-Swift Structs, particularly Structs with arrays. Swift also does not have arrays of predefined sizes. For simple structs with no arrays/strings, it works to create the Struct natively in Swift and spit it out the network interface (at least for Swift 4.2).. But whenever I have a struct with an array or String, I have to define the struct in C and import it into Swift. This makes it “difficult” to layout the packet in Swift, although I’m now past that challenge. I remember looking at the Netrek source code back in 1991. I was impressed, but the C was mostly beyond my abilities. I looked at it again recently. It's still beyond my abilities. Swift just works better with the way my brain is wired. I salute you all! Darrell > On Mar 4, 2019, at 2:52 PM, James Cameron wrote: > > Here's a packet dump from Gytha just now. > > http://dev.laptop.org/~quozl/z/1h0wOC.txt > > Note how CP_FEATURE is sent early, and there's a burst of SP_FEATURE > after CP_LOGIN and before SP_LOGIN. > > Also, I was wrong in previous mail, SP_YOU is seen before CP_LOGIN, > but with zero flags. > > On Mon, Mar 04, 2019 at 02:26:14PM -0800, Darrell Root wrote: >> I’ll take a look at those documents although I’m already all over packets.h >> from the distribution. >> >> Here’s the full sequence in order. SP_YOU comes early before I send my login >> authentication as guest. >> >> Darrell >> >> "Sending CP_PACKET 27" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_YOU" >> "Sending CP_LOGIN 8" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_LOGIN" >> "Sending CP_FEATURE 60" >> "Sending CP_OUTFIT 9" >> >> On Mar 4, 2019, at 2:19 PM, James Cameron <[1]quozl at laptop.org > wrote: >> >> G'day Darrell, >> >> According to protocol, you should expect SP_YOU in response to >> CP_LOGIN and CP_FEATURE. You say you have it in the count of packets, >> but you don't have it in the end of the sequence. Can you show the >> whole sequence? >> >> Also, see these references; >> >> 1. netrek protocol >> >> [2]https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 >> >> 2. sending CP_FEATURE of FEATURE_PACKETS immediately after CP_SOCKET, >> >> https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 >> >> On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: >> >> netrek-dev, >> >> I’m working on a Swift Netrek client for the Mac. I’m having trouble >> getting >> through the login sequence. >> >> I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 with no >> active >> players as a test target. In my packet traces below the server is at >> 192.168.0.10. >> >> I’m able to successfully play on my test server with the MacTrek >> client. >> >> Here’s a count of the packets I’ve been able to send/receive and >> process (not >> in order): >> >> 31 "Received SP_FLAGS" >> 32 "Received SP_HOSTILE" >> 32 "Received SP_KILLS" >> 1 "Received SP_LOGIN" >> 40 "Received SP_PLANET_LOC" >> 32 "Received SP_PLAYER" >> 52 "Received SP_PLAYER_INFO" >> 32 "Received SP_PL_LOGIN" >> 32 "Received SP_PSTATUS" >> 1 "Received SP_YOU" >> 1 "Sending CP_FEATURE 60" >> 1 "Sending CP_LOGIN 8" >> 1 "Sending CP_OUTFIT 9" >> 1 "Sending CP_SOCKET 27" >> >> Here’s the end of the sequence: >> >> ... >> "Received SP_LOGIN" >> "Sending CP_FEATURE 60" >> "Sending CP_OUTFIT 9" >> >> No response to CP_OUTFIT. >> The server logs an inability to do a DNS reverse lookup on >> 192.168.0.31, but I >> don’t think that is related (and it doesn’t stop the MacTrek >> Objective-C client >> from playing). >> >> I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, or >> that some >> other packet is required to login on the server. >> >> Here’s my CP_FEATURE: >> >> 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags >> [P.], seq >> 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 ecr >> 1657847922], >> length 88 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 >> 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 >> 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 >> 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 >> 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0090: 0000 0000 0000 0000 0000 >> >> Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks >> correct. >> >> 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: Flags >> [P.], seq >> 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr >> 1642419149], >> length 88 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 >> 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 >> 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 >> 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 >> 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0090: 0000 0000 0000 0000 0000 >> >> For reference here’s reference information on that structure: >> >> #define CP_FEATURE 60 >> >> struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 */ >> char type; >> char feature_type; /* either 'C' or 'S' */ >> char arg1, >> arg2; >> int value; >> char name[80]; >> }; >> >> struct feature_var feature_vars[] = { >> {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, >> >> Here’s my CP_OUTFIT when I try to login as fed (I also tried setting >> team to 0 at 0x0044 since that is what MacTrek appears to do). >> >> 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: Flags >> [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val >> 516594969 ecr 1657848989], length 4 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 >> 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 >> 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 >> 0x0040: c49d 0901 0200 >> >> Here’s info on that struct: >> >> #define CP_OUTFIT 9 /* outfit to new ship */ >> >> struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ >> char type; >> char team; >> char ship; >> char pad1; >> }; >> >> Could the problem be with my earlier packets? They got responses. But >> here they are for completeness: >> >> CP_SOCKET: (note that my client does not support UDP) >> >> 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags >> [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val 512991468 ecr >> 1654229963], length 8 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 >> 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 >> 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 >> 0x0040: 8bcb 1b04 0a00 0000 8020 >> >> #define CP_SOCKET 27 /* new socket for reconnection >> */ >> >> struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ >> char type; >> char version; >> char udp_version; /* was pad2 */ >> char pad3; >> u_int socket; >> }; >> >> CP_LOGIN: (hardcoded to guest as the username, password and login >> empty) >> >> 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: Flags >> [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val 512992524 >> ecr 1654231039], length 52 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 >> 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 >> 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 >> 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 >> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 >> >> struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 */ >> char type; >> char query; >> char pad2; >> char pad3; >> char name[NAME_LEN]; >> char password[NAME_LEN]; >> char login[NAME_LEN]; >> }; >> >> Any ideas what I need to correct or what else I need to supply to >> successfully login as guest? >> >> Darrell >> >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> -- >> James Cameron >> http://quozl.netrek.org/ >> >> References: >> >> [1] mailto:quozl at laptop.org >> [2] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > -- > James Cameron > http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at laptop.org Mon Mar 4 18:20:07 2019 From: quozl at laptop.org (James Cameron) Date: Tue, 5 Mar 2019 11:20:07 +1100 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: <7BEEF23C-B4A9-4F4F-8257-1F171BFF4BA8@mac.com> References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> <20190304221902.GH3274@laptop.org> <20190304225235.GK3274@laptop.org> <7BEEF23C-B4A9-4F4F-8257-1F171BFF4BA8@mac.com> Message-ID: <20190305002006.GP3274@laptop.org> No worries. You may be interested in the Gytha client TCP and UDP module, at 300 lines. https://github.com/quozl/gytha/blob/master/gytha/client.py Our earlier use of the socket API for networking was because it was the lowest common denominator on UNIX systems. Socket API also appears in the Gytha client for same reason. When you're building on top of a larger stack, interoperability becomes a challenge. On Mon, Mar 04, 2019 at 03:57:26PM -0800, Darrell Root wrote: > Thank you for that packet dump in netrek format. I’ll have to upgrade my logs > to be that helpful. ;-) > > I’m actively troubleshooting using your data. > > On a general netrek-dev note, programming with Swift for most things is cool. > I’m using Apple’s new Network framework to send my data (I believe they are > working with the IETF on that), so no more BSD socket API. My TCP reader/ > writer is around 100 lines (have not implemented UDP). Packet analyzer is > larger of course. > > One Swift pain point is generating arbitrary packets. In C you can just send a > struct out a network interface. But Swift does not guarantee the layout of > native-Swift Structs, particularly Structs with arrays. Swift also does not > have arrays of predefined sizes. > > For simple structs with no arrays/strings, it works to create the Struct > natively in Swift and spit it out the network interface (at least for Swift > 4.2).. But whenever I have a struct with an array or String, I have to define > the struct in C and import it into Swift. This makes it “difficult” to layout > the packet in Swift, although I’m now past that challenge. > > I remember looking at the Netrek source code back in 1991. I was impressed, > but the C was mostly beyond my abilities. I looked at it again recently. It's > still beyond my abilities. Swift just works better with the way my brain is > wired. I salute you all! > > Darrell > > On Mar 4, 2019, at 2:52 PM, James Cameron <[1]quozl at laptop.org> wrote: > > Here's a packet dump from Gytha just now. > > [2]http://dev.laptop.org/~quozl/z/1h0wOC.txt > > Note how CP_FEATURE is sent early, and there's a burst of SP_FEATURE > after CP_LOGIN and before SP_LOGIN. > > Also, I was wrong in previous mail, SP_YOU is seen before CP_LOGIN, > but with zero flags. > > On Mon, Mar 04, 2019 at 02:26:14PM -0800, Darrell Root wrote: > > I’ll take a look at those documents although I’m already all over > packets.h > from the distribution. > > Here’s the full sequence in order. SP_YOU comes early before I send my > login > authentication as guest. > > Darrell > > "Sending CP_PACKET 27" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_YOU" > "Sending CP_LOGIN 8" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > On Mar 4, 2019, at 2:19 PM, James Cameron <[1][3]quozl at laptop.org> > wrote: > > G'day Darrell, > > According to protocol, you should expect SP_YOU in response to > CP_LOGIN and CP_FEATURE. You say you have it in the count of > packets, > but you don't have it in the end of the sequence. Can you show the > whole sequence? > > Also, see these references; > > 1. netrek protocol > > [2][4]https://github.com/quozl/netrek-server/blob/master/include/ > packets.h#L24 > > 2. sending CP_FEATURE of FEATURE_PACKETS immediately after > CP_SOCKET, > > [5]https://github.com/quozl/gytha/blob/master/gytha/__init__.py# > L5644 > > On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: > > netrek-dev, > > I’m working on a Swift Netrek client for the Mac. I’m having > trouble > getting > through the login sequence. > > I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 > with no > active > players as a test target. In my packet traces below the server > is at > 192.168.0.10. > > I’m able to successfully play on my test server with the MacTrek > client. > > Here’s a count of the packets I’ve been able to send/receive and > process (not > in order): > > 31 "Received SP_FLAGS" > 32 "Received SP_HOSTILE" > 32 "Received SP_KILLS" > 1 "Received SP_LOGIN" > 40 "Received SP_PLANET_LOC" > 32 "Received SP_PLAYER" > 52 "Received SP_PLAYER_INFO" > 32 "Received SP_PL_LOGIN" > 32 "Received SP_PSTATUS" > 1 "Received SP_YOU" > 1 "Sending CP_FEATURE 60" > 1 "Sending CP_LOGIN 8" > 1 "Sending CP_OUTFIT 9" > 1 "Sending CP_SOCKET 27" > > Here’s the end of the sequence: > > ... > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > No response to CP_OUTFIT. > The server logs an inability to do a DNS reverse lookup on > 192.168.0.31, but I > don’t think that is related (and it doesn’t stop the MacTrek > Objective-C client > from playing). > > I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, > or > that some > other packet is required to login on the server. > > Here’s my CP_FEATURE: > > 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: > Flags > [P.], seq > 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 > ecr > 1657847922], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 > 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 > 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks > correct. > > 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: > Flags > [P.], seq > 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr > 1642419149], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 > 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 > 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > For reference here’s reference information on that structure: > > #define CP_FEATURE 60 > > struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 > */ > char type; > char feature_type; /* either 'C' or 'S' */ > char arg1, > arg2; > int value; > char name[80]; > }; > > struct feature_var feature_vars[] = { > {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, > > Here’s my CP_OUTFIT when I try to login as fed (I also tried > setting > team to 0 at 0x0044 since that is what MacTrek appears to do). > > 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: > Flags > [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val > 516594969 ecr 1657848989], length 4 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 > 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 > 0x0040: c49d 0901 0200 > > Here’s info on that struct: > > #define CP_OUTFIT 9 /* outfit to new ship */ > > struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ > char type; > char team; > char ship; > char pad1; > }; > > Could the problem be with my earlier packets? They got > responses. But > here they are for completeness: > > CP_SOCKET: (note that my client does not support UDP) > > 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: > Flags > [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val > 512991468 ecr > 1654229963], length 8 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 > 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 > 0x0040: 8bcb 1b04 0a00 0000 8020 > > #define CP_SOCKET 27 /* new socket for > reconnection > */ > > struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ > char type; > char version; > char udp_version; /* was pad2 */ > char pad3; > u_int socket; > }; > > CP_LOGIN: (hardcoded to guest as the username, password and > login > empty) > > 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: > Flags > [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val > 512992524 > ecr 1654231039], length 52 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 > 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 > 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 > > struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 > */ > char type; > char query; > char pad2; > char pad3; > char name[NAME_LEN]; > char password[NAME_LEN]; > char login[NAME_LEN]; > }; > > Any ideas what I need to correct or what else I need to supply > to > successfully login as guest? > > Darrell > > _______________________________________________ > netrek-dev mailing list > [6]netrek-dev at us.netrek.org > [7]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -- > James Cameron > [8]http://quozl.netrek.org/ > > References: > > [1] [9]mailto:quozl at laptop.org > [2] [10]https://github.com/quozl/netrek-server/blob/master/include/ > packets.h#L24 > > _______________________________________________ > netrek-dev mailing list > [11]netrek-dev at us.netrek.org > [12]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -- > James Cameron > [13]http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > [14]netrek-dev at us.netrek.org > [15]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > References: > > [1] mailto:quozl at laptop.org > [2] http://dev.laptop.org/~quozl/z/1h0wOC.txt > [3] mailto:quozl at laptop.org > [4] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > [5] https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 > [6] mailto:netrek-dev at us.netrek.org > [7] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [8] http://quozl.netrek.org/ > [9] mailto:quozl at laptop.org > [10] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > [11] mailto:netrek-dev at us.netrek.org > [12] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [13] http://quozl.netrek.org/ > [14] mailto:netrek-dev at us.netrek.org > [15] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.netrek.org/ From darrellroot at mac.com Mon Mar 4 21:55:43 2019 From: darrellroot at mac.com (Darrell Root) Date: Mon, 4 Mar 2019 19:55:43 -0800 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: <20190305002006.GP3274@laptop.org> References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> <20190304221902.GH3274@laptop.org> <20190304225235.GK3274@laptop.org> <7BEEF23C-B4A9-4F4F-8257-1F171BFF4BA8@mac.com> <20190305002006.GP3274@laptop.org> Message-ID: <13BF7F99-21E1-4F1D-AF56-D997AB6E5BC5@mac.com> Success! My problem was I set query=1 in my CP_LOGIN. It looks like the MacTrek client opens one socket, does a query, then closes that socket and opens a second socket to play. I think I spotted a query=1 in the first socket and emulated that. Doh! Thank you for including this line in your debugging info: > CP_LOGIN query= 0 name= guest Now I have a bunch of other packet types to parse. The universe is eager to be updated! ;-) Hopefully I’ll get started on some drawing code tomorrow. Darrell > On Mar 4, 2019, at 4:20 PM, James Cameron wrote: > > No worries. You may be interested in the Gytha client TCP and UDP > module, at 300 lines. > > https://github.com/quozl/gytha/blob/master/gytha/client.py > > Our earlier use of the socket API for networking was because it was > the lowest common denominator on UNIX systems. Socket API also > appears in the Gytha client for same reason. > > When you're building on top of a larger stack, interoperability > becomes a challenge. > > On Mon, Mar 04, 2019 at 03:57:26PM -0800, Darrell Root wrote: >> Thank you for that packet dump in netrek format. I’ll have to upgrade my logs >> to be that helpful. ;-) >> >> I’m actively troubleshooting using your data. >> >> On a general netrek-dev note, programming with Swift for most things is cool. >> I’m using Apple’s new Network framework to send my data (I believe they are >> working with the IETF on that), so no more BSD socket API. My TCP reader/ >> writer is around 100 lines (have not implemented UDP). Packet analyzer is >> larger of course. >> >> One Swift pain point is generating arbitrary packets. In C you can just send a >> struct out a network interface. But Swift does not guarantee the layout of >> native-Swift Structs, particularly Structs with arrays. Swift also does not >> have arrays of predefined sizes. >> >> For simple structs with no arrays/strings, it works to create the Struct >> natively in Swift and spit it out the network interface (at least for Swift >> 4.2).. But whenever I have a struct with an array or String, I have to define >> the struct in C and import it into Swift. This makes it “difficult” to layout >> the packet in Swift, although I’m now past that challenge. >> >> I remember looking at the Netrek source code back in 1991. I was impressed, >> but the C was mostly beyond my abilities. I looked at it again recently. It's >> still beyond my abilities. Swift just works better with the way my brain is >> wired. I salute you all! >> >> Darrell >> >> On Mar 4, 2019, at 2:52 PM, James Cameron <[1]quozl at laptop.org > wrote: >> >> Here's a packet dump from Gytha just now. >> >> [2]http://dev.laptop.org/~quozl/z/1h0wOC.txt >> >> Note how CP_FEATURE is sent early, and there's a burst of SP_FEATURE >> after CP_LOGIN and before SP_LOGIN. >> >> Also, I was wrong in previous mail, SP_YOU is seen before CP_LOGIN, >> but with zero flags. >> >> On Mon, Mar 04, 2019 at 02:26:14PM -0800, Darrell Root wrote: >> >> I’ll take a look at those documents although I’m already all over >> packets.h >> from the distribution. >> >> Here’s the full sequence in order. SP_YOU comes early before I send my >> login >> authentication as guest. >> >> Darrell >> >> "Sending CP_PACKET 27" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_PLAYER_INFO" >> "Received SP_YOU" >> "Sending CP_LOGIN 8" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PL_LOGIN" >> "Received SP_HOSTILE" >> "Received SP_PLAYER_INFO" >> "Received SP_KILLS" >> "Received SP_PSTATUS" >> "Received SP_FLAGS" >> "Received SP_PLAYER" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_PLANET_LOC" >> "Received SP_LOGIN" >> "Sending CP_FEATURE 60" >> "Sending CP_OUTFIT 9" >> >> On Mar 4, 2019, at 2:19 PM, James Cameron <[1][3]quozl at laptop.org > >> wrote: >> >> G'day Darrell, >> >> According to protocol, you should expect SP_YOU in response to >> CP_LOGIN and CP_FEATURE. You say you have it in the count of >> packets, >> but you don't have it in the end of the sequence. Can you show the >> whole sequence? >> >> Also, see these references; >> >> 1. netrek protocol >> >> [2][4]https://github.com/quozl/netrek-server/blob/master/include/ >> packets.h#L24 >> >> 2. sending CP_FEATURE of FEATURE_PACKETS immediately after >> CP_SOCKET, >> >> [5]https://github.com/quozl/gytha/blob/master/gytha/__init__.py# >> L5644 >> >> On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: >> >> netrek-dev, >> >> I’m working on a Swift Netrek client for the Mac. I’m having >> trouble >> getting >> through the login sequence. >> >> I’m using netrek-server-vanilla netrek-server-vanilla-2.19.0 >> with no >> active >> players as a test target. In my packet traces below the server >> is at >> 192.168.0.10. >> >> I’m able to successfully play on my test server with the MacTrek >> client. >> >> Here’s a count of the packets I’ve been able to send/receive and >> process (not >> in order): >> >> 31 "Received SP_FLAGS" >> 32 "Received SP_HOSTILE" >> 32 "Received SP_KILLS" >> 1 "Received SP_LOGIN" >> 40 "Received SP_PLANET_LOC" >> 32 "Received SP_PLAYER" >> 52 "Received SP_PLAYER_INFO" >> 32 "Received SP_PL_LOGIN" >> 32 "Received SP_PSTATUS" >> 1 "Received SP_YOU" >> 1 "Sending CP_FEATURE 60" >> 1 "Sending CP_LOGIN 8" >> 1 "Sending CP_OUTFIT 9" >> 1 "Sending CP_SOCKET 27" >> >> Here’s the end of the sequence: >> >> ... >> "Received SP_LOGIN" >> "Sending CP_FEATURE 60" >> "Sending CP_OUTFIT 9" >> >> No response to CP_OUTFIT. >> The server logs an inability to do a DNS reverse lookup on >> 192.168.0.31, but I >> don’t think that is related (and it doesn’t stop the MacTrek >> Objective-C client >> from playing). >> >> I presume that something is wrong with my CP_OUTFIT or CP_LOGIN, >> or >> that some >> other packet is required to login on the server. >> >> Here’s my CP_FEATURE: >> >> 12:46:33.444140 IP 192.168.0.31.62943 > 192.168.0.10.netrek: >> Flags >> [P.], seq >> 61:149, ack 5873, win 2048, options [nop,nop,TS val 516594040 >> ecr >> 1657847922], >> length 88 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 >> 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 >> 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 >> 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 >> 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0090: 0000 0000 0000 0000 0000 >> >> Here’s a packet dump of a MacTrek CP_FEATURE packet. Mine looks >> correct. >> >> 08:29:02.233675 IP 192.168.0.31.60481 > 192.168.0.10.netrek: >> Flags >> [P.], seq >> 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 ecr >> 1642419149], >> length 88 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 >> 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 >> 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 >> 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 >> 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0090: 0000 0000 0000 0000 0000 >> >> For reference here’s reference information on that structure: >> >> #define CP_FEATURE 60 >> >> struct feature_cpacket { /* CP_FEATURE py-struct "!bcbbi80s" #60 >> */ >> char type; >> char feature_type; /* either 'C' or 'S' */ >> char arg1, >> arg2; >> int value; >> char name[80]; >> }; >> >> struct feature_var feature_vars[] = { >> {"FEATURE_PACKETS", &F_client_feature_packets, NULL}, >> >> Here’s my CP_OUTFIT when I try to login as fed (I also tried >> setting >> team to 0 at 0x0044 since that is what MacTrek appears to do). >> >> 12:46:34.381240 IP 192.168.0.31.62943 > 192.168.0.10.netrek: >> Flags >> [P.], seq 149:153, ack 5873, win 2048, options [nop,nop,TS val >> 516594969 ecr 1657848989], length 4 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 >> 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 >> 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 >> 0x0040: c49d 0901 0200 >> >> Here’s info on that struct: >> >> #define CP_OUTFIT 9 /* outfit to new ship */ >> >> struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ >> char type; >> char team; >> char ship; >> char pad1; >> }; >> >> Could the problem be with my earlier packets? They got >> responses. But >> here they are for completeness: >> >> CP_SOCKET: (note that my client does not support UDP) >> >> 11:46:12.530856 IP 192.168.0.31.62508 > 192.168.0.10.netrek: >> Flags >> [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val >> 512991468 ecr >> 1654229963], length 8 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 >> 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 >> 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 >> 0x0040: 8bcb 1b04 0a00 0000 8020 >> >> #define CP_SOCKET 27 /* new socket for >> reconnection >> */ >> >> struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" #27 */ >> char type; >> char version; >> char udp_version; /* was pad2 */ >> char pad3; >> u_int socket; >> }; >> >> CP_LOGIN: (hardcoded to guest as the username, password and >> login >> empty) >> >> 11:46:13.591234 IP 192.168.0.31.62508 > 192.168.0.10.netrek: >> Flags >> [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS val >> 512992524 >> ecr 1654231039], length 52 >> 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 >> 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 >> 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 >> 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 >> 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 >> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 >> 0x0070: 0000 0000 0000 >> >> struct login_cpacket { /* CP_LOGIN py-struct '!bbxx16s16s16s' #8 >> */ >> char type; >> char query; >> char pad2; >> char pad3; >> char name[NAME_LEN]; >> char password[NAME_LEN]; >> char login[NAME_LEN]; >> }; >> >> Any ideas what I need to correct or what else I need to supply >> to >> successfully login as guest? >> >> Darrell >> >> _______________________________________________ >> netrek-dev mailing list >> [6]netrek-dev at us.netrek.org >> [7]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> -- >> James Cameron >> [8]http://quozl.netrek.org/ >> >> References: >> >> [1] [9]mailto:quozl at laptop.org >> [2] [10]https://github.com/quozl/netrek-server/blob/master/include/ >> packets.h#L24 >> >> _______________________________________________ >> netrek-dev mailing list >> [11]netrek-dev at us.netrek.org >> [12]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> -- >> James Cameron >> [13]http://quozl.netrek.org/ >> _______________________________________________ >> netrek-dev mailing list >> [14]netrek-dev at us.netrek.org >> [15]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> >> References: >> >> [1] mailto:quozl at laptop.org >> [2] http://dev.laptop.org/~quozl/z/1h0wOC.txt >> [3] mailto:quozl at laptop.org >> [4] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 >> [5] https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 >> [6] mailto:netrek-dev at us.netrek.org >> [7] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> [8] http://quozl.netrek.org/ >> [9] mailto:quozl at laptop.org >> [10] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 >> [11] mailto:netrek-dev at us.netrek.org >> [12] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev >> [13] http://quozl.netrek.org/ >> [14] mailto:netrek-dev at us.netrek.org >> [15] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > -- > James Cameron > http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at laptop.org Mon Mar 4 22:11:25 2019 From: quozl at laptop.org (James Cameron) Date: Tue, 5 Mar 2019 15:11:25 +1100 Subject: [netrek-dev] Swift Netrek client for the Mac development: Having trouble with login sequence In-Reply-To: <13BF7F99-21E1-4F1D-AF56-D997AB6E5BC5@mac.com> References: <890B3745-02A6-420E-A98E-932538A47F1A@mac.com> <20190304221902.GH3274@laptop.org> <20190304225235.GK3274@laptop.org> <7BEEF23C-B4A9-4F4F-8257-1F171BFF4BA8@mac.com> <20190305002006.GP3274@laptop.org> <13BF7F99-21E1-4F1D-AF56-D997AB6E5BC5@mac.com> Message-ID: <20190305041125.GT3274@laptop.org> Yay. On Mon, Mar 04, 2019 at 07:55:43PM -0800, Darrell Root wrote: > Success! My problem was I set query=1 in my CP_LOGIN. > > It looks like the MacTrek client opens one socket, does a query, then closes > that socket and opens a second socket to play. I think I spotted a query=1 in > the first socket and emulated that. Doh! > > Thank you for including this line in your debugging info: > > > CP_LOGIN query= 0 name= guest > > Now I have a bunch of other packet types to parse. The universe is eager to be > updated! ;-) Hopefully I’ll get started on some drawing code tomorrow. > > Darrell > > On Mar 4, 2019, at 4:20 PM, James Cameron <[1]quozl at laptop.org> wrote: > > No worries. You may be interested in the Gytha client TCP and UDP > module, at 300 lines. > > [2]https://github.com/quozl/gytha/blob/master/gytha/client.py > > Our earlier use of the socket API for networking was because it was > the lowest common denominator on UNIX systems. Socket API also > appears in the Gytha client for same reason. > > When you're building on top of a larger stack, interoperability > becomes a challenge. > > On Mon, Mar 04, 2019 at 03:57:26PM -0800, Darrell Root wrote: > > Thank you for that packet dump in netrek format. I’ll have to upgrade > my logs > to be that helpful. ;-) > > I’m actively troubleshooting using your data. > > On a general netrek-dev note, programming with Swift for most things is > cool. > I’m using Apple’s new Network framework to send my data (I believe they > are > working with the IETF on that), so no more BSD socket API. My TCP > reader/ > writer is around 100 lines (have not implemented UDP). Packet analyzer > is > larger of course. > > One Swift pain point is generating arbitrary packets. In C you can > just send a > struct out a network interface. But Swift does not guarantee the > layout of > native-Swift Structs, particularly Structs with arrays. Swift also > does not > have arrays of predefined sizes. > > For simple structs with no arrays/strings, it works to create the > Struct > natively in Swift and spit it out the network interface (at least for > Swift > 4.2).. But whenever I have a struct with an array or String, I have to > define > the struct in C and import it into Swift. This makes it “difficult” to > layout > the packet in Swift, although I’m now past that challenge. > > I remember looking at the Netrek source code back in 1991. I was > impressed, > but the C was mostly beyond my abilities. I looked at it again > recently. It's > still beyond my abilities. Swift just works better with the way my > brain is > wired. I salute you all! > > Darrell > > On Mar 4, 2019, at 2:52 PM, James Cameron <[1][3]quozl at laptop.org> > wrote: > > Here's a packet dump from Gytha just now. > > [2][4]http://dev.laptop.org/~quozl/z/1h0wOC.txt > > Note how CP_FEATURE is sent early, and there's a burst of SP_FEATURE > after CP_LOGIN and before SP_LOGIN. > > Also, I was wrong in previous mail, SP_YOU is seen before CP_LOGIN, > but with zero flags. > > On Mon, Mar 04, 2019 at 02:26:14PM -0800, Darrell Root wrote: > > I’ll take a look at those documents although I’m already all > over > packets.h > from the distribution. > > Here’s the full sequence in order. SP_YOU comes early before I > send my > login > authentication as guest. > > Darrell > > "Sending CP_PACKET 27" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_PLAYER_INFO" > "Received SP_YOU" > "Sending CP_LOGIN 8" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PL_LOGIN" > "Received SP_HOSTILE" > "Received SP_PLAYER_INFO" > "Received SP_KILLS" > "Received SP_PSTATUS" > "Received SP_FLAGS" > "Received SP_PLAYER" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_PLANET_LOC" > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > On Mar 4, 2019, at 2:19 PM, James Cameron <[1][3][5] > quozl at laptop.org> > wrote: > > G'day Darrell, > > According to protocol, you should expect SP_YOU in response > to > CP_LOGIN and CP_FEATURE. You say you have it in the count of > packets, > but you don't have it in the end of the sequence. Can you > show the > whole sequence? > > Also, see these references; > > 1. netrek protocol > > [2][4][6]https://github.com/quozl/netrek-server/blob/master/ > include/ > packets.h#L24 > > 2. sending CP_FEATURE of FEATURE_PACKETS immediately after > CP_SOCKET, > > [5][7]https://github.com/quozl/gytha/blob/master/gytha/ > __init__.py# > L5644 > > On Mon, Mar 04, 2019 at 01:07:35PM -0800, Darrell Root wrote: > > netrek-dev, > > I’m working on a Swift Netrek client for the Mac. I’m > having > trouble > getting > through the login sequence. > > I’m using netrek-server-vanilla > netrek-server-vanilla-2.19.0 > with no > active > players as a test target. In my packet traces below the > server > is at > 192.168.0.10. > > I’m able to successfully play on my test server with the > MacTrek > client. > > Here’s a count of the packets I’ve been able to send/ > receive and > process (not > in order): > > 31 "Received SP_FLAGS" > 32 "Received SP_HOSTILE" > 32 "Received SP_KILLS" > 1 "Received SP_LOGIN" > 40 "Received SP_PLANET_LOC" > 32 "Received SP_PLAYER" > 52 "Received SP_PLAYER_INFO" > 32 "Received SP_PL_LOGIN" > 32 "Received SP_PSTATUS" > 1 "Received SP_YOU" > 1 "Sending CP_FEATURE 60" > 1 "Sending CP_LOGIN 8" > 1 "Sending CP_OUTFIT 9" > 1 "Sending CP_SOCKET 27" > > Here’s the end of the sequence: > > ... > "Received SP_LOGIN" > "Sending CP_FEATURE 60" > "Sending CP_OUTFIT 9" > > No response to CP_OUTFIT. > The server logs an inability to do a DNS reverse lookup > on > 192.168.0.31, but I > don’t think that is related (and it doesn’t stop the > MacTrek > Objective-C client > from playing). > > I presume that something is wrong with my CP_OUTFIT or > CP_LOGIN, > or > that some > other packet is required to login on the server. > > Here’s my CP_FEATURE: > > 12:46:33.444140 IP 192.168.0.31.62943 > > 192.168.0.10.netrek: > Flags > [P.], seq > 61:149, ack 5873, win 2048, options [nop,nop,TS val > 516594040 > ecr > 1657847922], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d37b 87ce 7c2f 8018 > 0x0030: 0800 96e5 0000 0101 080a 1eca 9978 62d0 > 0x0040: c072 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > Here’s a packet dump of a MacTrek CP_FEATURE packet. > Mine looks > correct. > > 08:29:02.233675 IP 192.168.0.31.60481 > > 192.168.0.10.netrek: > Flags > [P.], seq > 9:97, ack 1, win 2058, options [nop,nop,TS val 501230260 > ecr > 1642419149], > length 88 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 008c 0000 4000 4006 b8f2 c0a8 001f c0a8 > 0x0020: 000a ec41 0a20 47c9 bead f710 babe 8018 > 0x0030: 080a b569 0000 0101 080a 1de0 2ab4 61e5 > 0x0040: 53cd 3c53 0000 0000 0001 4645 4154 5552 > 0x0050: 455f 5041 434b 4554 5300 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 > > For reference here’s reference information on that > structure: > > #define CP_FEATURE 60 > > struct feature_cpacket { /* CP_FEATURE py-struct "! > bcbbi80s" #60 > */ > char type; > char feature_type; /* either 'C' or > 'S' */ > char arg1, > arg2; > int value; > char name[80]; > }; > > struct feature_var feature_vars[] = { > {"FEATURE_PACKETS", &F_client_feature_packets, > NULL}, > > Here’s my CP_OUTFIT when I try to login as fed (I also > tried > setting > team to 0 at 0x0044 since that is what MacTrek appears to > do). > > 12:46:34.381240 IP 192.168.0.31.62943 > > 192.168.0.10.netrek: > Flags > [P.], seq 149:153, ack 5873, win 2048, options > [nop,nop,TS val > 516594969 ecr 1657848989], length 4 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0038 0000 4000 4006 b946 c0a8 001f c0a8 > 0x0020: 000a f5df 0a20 187e d3d3 87ce 7c2f 8018 > 0x0030: 0800 0e95 0000 0101 080a 1eca 9d19 62d0 > 0x0040: c49d 0901 0200 > > Here’s info on that struct: > > #define CP_OUTFIT 9 /* outfit to new > ship */ > > struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 > */ > char type; > char team; > char ship; > char pad1; > }; > > Could the problem be with my earlier packets? They got > responses. But > here they are for completeness: > > CP_SOCKET: (note that my client does not support UDP) > > 11:46:12.530856 IP 192.168.0.31.62508 > > 192.168.0.10.netrek: > Flags > [P.], seq 1:9, ack 1, win 2058, options [nop,nop,TS val > 512991468 ecr > 1654229963], length 8 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 003c 0000 4000 4006 b942 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28a2 549c ed30 8018 > 0x0030: 080a 67e8 0000 0101 080a 1e93 a0ec 6299 > 0x0040: 8bcb 1b04 0a00 0000 8020 > > #define CP_SOCKET 27 /* new socket for > reconnection > */ > > struct socket_cpacket { /* CP_SOCKET py-struct "!bbbxI" # > 27 */ > char type; > char version; > char udp_version; /* was pad2 */ > char pad3; > u_int socket; > }; > > CP_LOGIN: (hardcoded to guest as the username, password > and > login > empty) > > 11:46:13.591234 IP 192.168.0.31.62508 > > 192.168.0.10.netrek: > Flags > [P.], seq 9:61, ack 5769, win 2048, options [nop,nop,TS > val > 512992524 > ecr 1654231039], length 52 > 0x0000: 685b 3589 0a04 1410 9fd7 77b1 0800 4500 > 0x0010: 0068 0000 4000 4006 b916 c0a8 001f c0a8 > 0x0020: 000a f42c 0a20 c97b 28aa 549d 03b8 8018 > 0x0030: 0800 a51c 0000 0101 080a 1e93 a50c 6299 > 0x0040: 8fff 0801 0000 6775 6573 7400 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0070: 0000 0000 0000 > > struct login_cpacket { /* CP_LOGIN py-struct '! > bbxx16s16s16s' #8 > */ > char type; > char query; > char pad2; > char pad3; > char name[NAME_LEN]; > char password[NAME_LEN]; > char login[NAME_LEN]; > }; > > Any ideas what I need to correct or what else I need to > supply > to > successfully login as guest? > > Darrell > > _______________________________________________ > netrek-dev mailing list > [6][8]netrek-dev at us.netrek.org > [7][9]http://mailman.us.netrek.org/mailman/listinfo/ > netrek-dev > > -- > James Cameron > [8][10]http://quozl.netrek.org/ > > References: > > [1] [9][11]mailto:quozl at laptop.org > [2] [10][12]https://github.com/quozl/netrek-server/blob/master/ > include/ > packets.h#L24 > > _______________________________________________ > netrek-dev mailing list > [11][13]netrek-dev at us.netrek.org > [12][14]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -- > James Cameron > [13][15]http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > [14][16]netrek-dev at us.netrek.org > [15][17]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > References: > > [1] [18]mailto:quozl at laptop.org > [2] [19]http://dev.laptop.org/~quozl/z/1h0wOC.txt > [3] [20]mailto:quozl at laptop.org > [4] [21]https://github.com/quozl/netrek-server/blob/master/include/ > packets.h#L24 > [5] [22]https://github.com/quozl/gytha/blob/master/gytha/__init__.py# > L5644 > [6] [23]mailto:netrek-dev at us.netrek.org > [7] [24]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [8] [25]http://quozl.netrek.org/ > [9] [26]mailto:quozl at laptop.org > [10] [27]https://github.com/quozl/netrek-server/blob/master/include/ > packets.h#L24 > [11] [28]mailto:netrek-dev at us.netrek.org > [12] [29]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [13] [30]http://quozl.netrek.org/ > [14] [31]mailto:netrek-dev at us.netrek.org > [15] [32]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > _______________________________________________ > netrek-dev mailing list > [33]netrek-dev at us.netrek.org > [34]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > -- > James Cameron > [35]http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > [36]netrek-dev at us.netrek.org > [37]http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > References: > > [1] mailto:quozl at laptop.org > [2] https://github.com/quozl/gytha/blob/master/gytha/client.py > [3] mailto:quozl at laptop.org > [4] http://dev.laptop.org/~quozl/z/1h0wOC.txt > [5] mailto:quozl at laptop.org > [6] https://github.com/quozl/netrek-server/blob/master/include/ > [7] https://github.com/quozl/gytha/blob/master/gytha/__init__.py# > [8] mailto:netrek-dev at us.netrek.org > [9] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [10] http://quozl.netrek.org/ > [11] mailto:quozl at laptop.org > [12] https://github.com/quozl/netrek-server/blob/master/include/ > [13] mailto:netrek-dev at us.netrek.org > [14] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [15] http://quozl.netrek.org/ > [16] mailto:netrek-dev at us.netrek.org > [17] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [18] mailto:quozl at laptop.org > [19] http://dev.laptop.org/~quozl/z/1h0wOC.txt > [20] mailto:quozl at laptop.org > [21] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > [22] https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L5644 > [23] mailto:netrek-dev at us.netrek.org > [24] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [25] http://quozl.netrek.org/ > [26] mailto:quozl at laptop.org > [27] https://github.com/quozl/netrek-server/blob/master/include/packets.h#L24 > [28] mailto:netrek-dev at us.netrek.org > [29] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [30] http://quozl.netrek.org/ > [31] mailto:netrek-dev at us.netrek.org > [32] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [33] mailto:netrek-dev at us.netrek.org > [34] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > [35] http://quozl.netrek.org/ > [36] mailto:netrek-dev at us.netrek.org > [37] http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.netrek.org/ From darrellroot at mac.com Sun Mar 10 16:15:29 2019 From: darrellroot at mac.com (Darrell Root) Date: Sun, 10 Mar 2019 14:15:29 -0700 Subject: [netrek-dev] Having trouble with CP_MESSAGE format, first screenshot of Swift Netrek client for Mac! Message-ID: <3C28F3F6-695E-4E6D-A869-533A39DF3406@mac.com> I’m making good progress on my MacOS/Swift netrek client. It’s playable! I’ve even gotten a couple kills. I’m hoping to release an alpha version Friday March 15th. “Beware the ides of March”. I’ve attached a screenshot at the bottom. I’m having trouble understanding the CP_MESSAGE format. At first it looks simple: struct mesg_cpacket { /* CP_MESSAGE py-struct "!bBBx80s" #1 */ char type; char group; char indiv; /* does this break anything? -da */ char pad1; char mesg[MSG_LEN]; }; I captured a packet trace of a distress call to the Rom team with 4 in the group (MTEAM?) and 2 in the indiv (TEAM=ROM?) fields. But I’m having trouble sending messages with the MacTrek client so I don’t have a full set of packet traces to work with. Other client headers below but let me ask a couple specific questions: 1) If I want to send a message to ALL, what do I put in group/indiv? 2) If I want to send a message to TEAM ROM, what do I put in group/indiv (I think group=4 (MTEAM) and indiv=2 (ROM)). 3) If I want to send a message to individual player #3 what do I put in the group/indiv fields? 4) At startup, client is supposed to send the following message: CP_MESSAGE (MINDIV|MCONFIG, self, "@clientname clientversion") MINDIV is 0x02 MCONFIG is 0x04 So I guess 0x06 goes in the group field. What is the “self” that (presumably) goes in the indiv field? Is that my PlayerID (0 through 31)? Darrell ----------- Looking at the existing source code I’m finding a bunch of different things to put in the group and indiv fields (although I may be getting CP_MESSAGE and SP_MESSAGE mixed up). The team flags are as follows: IND=0x0 FED=0x1 ROM=0x2 KLI=0x4 ORI=0x8 Below is the message header source I’ve dug up. #define MVALID 0x01 #define MGOD 0x10 #define MMOO 0x12 #ifdef TOOLS #define MTOOLS 0x14 #endif /* order flags by importance (0x100 - 0x400) */ /* restructuring of message flags to squeeze them all into 1 byte - jmn */ /* hopefully quasi-back-compatible: MVALID, MINDIV, MTEAM, MALL, MGOD use up * 5 bits. this leaves us 3 bits. since the server only checks for those * flags when deciding message related things and since each of the above * cases only has 1 flag on at a time we can overlap the meanings of the * flags */ #define MINDIV 0x02 /* these go with MINDIV flag */ #ifdef STDBG #define MDBG 0x20 #endif #define MCONFIG 0x40 /* config messages from * * * server */ #define MDIST 0x60 /* flag distress type * * * messages properly */ #ifdef MULTILINE_MACROS #define MMACRO 0x80 #endif #define MTEAM 0x04 /* these go with MTEAM flag */ #define MTAKE 0x20 #define MDEST 0x40 #define MBOMB 0x60 #define MCOUP1 0x80 #define MCOUP2 0xA0 #define MDISTR 0xC0 /* flag distress type * messages */ #define MALL 0x08 /* these go with MALL flag */ #define MGENO 0x20 /* MGENO is not used in INL * here */ #define MCONQ 0x20 /* not enought bits to * distinguish MCONQ/MGENO :-( */ #define MKILLA 0x40 #define MKILLP 0x60 #define MKILL 0x80 #define MLEAVE 0xA0 #define MJOIN 0xC0 #define MGHOST 0xE0 /* MMASK not used in INL server */ #define MWHOMSK 0x1f /* mask with this to find * who msg to */ #define MWHATMSK 0xe0 /* mask with this to find * what message about */ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Swift-netrek-screenshot-1.png Type: image/png Size: 599100 bytes Desc: not available URL: From quozl at laptop.org Sun Mar 10 17:22:39 2019 From: quozl at laptop.org (James Cameron) Date: Mon, 11 Mar 2019 09:22:39 +1100 Subject: [netrek-dev] Having trouble with CP_MESSAGE format, first screenshot of Swift Netrek client for Mac! In-Reply-To: <3C28F3F6-695E-4E6D-A869-533A39DF3406@mac.com> References: <3C28F3F6-695E-4E6D-A869-533A39DF3406@mac.com> Message-ID: <20190310222239.GB17689@laptop.org> On Sun, Mar 10, 2019 at 02:15:29PM -0700, Darrell Root wrote: > I’m making good progress on my MacOS/Swift netrek client. It’s > playable! I’ve even gotten a couple kills. I’m hoping to release > an alpha version Friday March 15th. “Beware the ides of March”. > I’ve attached a screenshot at the bottom. Looks good. Ships inbound to Draconis ought to be cloaked; please add the code to hide them somehow. Team colours are unconventional; we would normally use a red or orange colour for Romulan team, and a yellow colour for Federation. This would make is easier for people to move to another client and fit existing documentation. Most clients allow the colours to be customised. > I’m having trouble understanding the CP_MESSAGE format. At first it > looks simple: > > struct mesg_cpacket { /* CP_MESSAGE py-struct "!bBBx80s" #1 */ > char type; > char group; > char indiv; /* does this break anything? -da */ > char pad1; > char mesg[MSG_LEN]; > }; > > I captured a packet trace of a distress call to the Rom team with 4 > in the group (MTEAM?) and 2 in the indiv (TEAM=ROM?) fields. But > I’m having trouble sending messages with the MacTrek client so I > don’t have a full set of packet traces to work with. Run another client. MacTrek did not mature. > Other client headers below but let me ask a couple specific questions: > > 1) If I want to send a message to ALL, what do I put in group/indiv? Deriving from source code; MALL in group. zero in indiv. https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L2266 https://github.com/quozl/netrek-client-cow/blob/master/smessage.c#L221 > 2) If I want to send a message to TEAM ROM, what do I put in > group/indiv (I think group=4 (MTEAM) and indiv=2 (ROM)). Deriving from source code; MTEAM in group. ROM in indiv. https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L2270 https://github.com/quozl/netrek-client-cow/blob/master/smessage.c#L227 > 3) If I want to send a message to individual player #3 what do I put > in the group/indiv fields? Deriving from source code; MINDIV in group. ship number in indiv. https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L2290 https://github.com/quozl/netrek-client-cow/blob/master/smessage.c#L248 > 4) At startup, client is supposed to send the following message: > CP_MESSAGE (MINDIV|MCONFIG, self, "@clientname clientversion") > MINDIV is 0x02 > MCONFIG is 0x04 > So I guess 0x06 goes in the group field. What is the “self” that > (presumably) goes in the indiv field? Is that my PlayerID (0 > through 31)? p_no https://github.com/quozl/netrek-client-cow/blob/master/dmessage.c#L278 But it probably does not matter, as the server does not check it; https://github.com/quozl/netrek-server/blob/master/ntserv/socket.c#L1704 https://github.com/quozl/netrek-server/blob/master/ntserv/socket.c#L1953 > Darrell > ----------- > > Looking at the existing source code I’m finding a bunch of different things to put in the group and indiv fields (although I may be getting CP_MESSAGE and SP_MESSAGE mixed up). > > The team flags are as follows: > > IND=0x0 > FED=0x1 > ROM=0x2 > KLI=0x4 > ORI=0x8 > > Below is the message header source I’ve dug up. > > #define MVALID 0x01 > #define MGOD 0x10 > #define MMOO 0x12 > > #ifdef TOOLS > #define MTOOLS 0x14 > #endif > > /* order flags by importance (0x100 - 0x400) */ > /* restructuring of message flags to squeeze them all into 1 byte - jmn */ > /* hopefully quasi-back-compatible: MVALID, MINDIV, MTEAM, MALL, MGOD use up > * 5 bits. this leaves us 3 bits. since the server only checks for those > * flags when deciding message related things and since each of the above > * cases only has 1 flag on at a time we can overlap the meanings of the > * flags */ > > #define MINDIV 0x02 > /* these go with MINDIV flag */ > > #ifdef STDBG > #define MDBG 0x20 > #endif > > #define MCONFIG 0x40 /* config messages from * * > * server */ > #define MDIST 0x60 /* flag distress type * * > * messages properly */ > #ifdef MULTILINE_MACROS > #define MMACRO 0x80 > #endif > > #define MTEAM 0x04 > /* these go with MTEAM flag */ > #define MTAKE 0x20 > #define MDEST 0x40 > #define MBOMB 0x60 > #define MCOUP1 0x80 > #define MCOUP2 0xA0 > #define MDISTR 0xC0 /* flag distress type > * messages */ > #define MALL 0x08 > /* these go with MALL flag */ > #define MGENO 0x20 /* MGENO is not used in INL > * here */ > #define MCONQ 0x20 /* not enought bits to > * distinguish MCONQ/MGENO :-( */ > #define MKILLA 0x40 > #define MKILLP 0x60 > #define MKILL 0x80 > #define MLEAVE 0xA0 > #define MJOIN 0xC0 > #define MGHOST 0xE0 > /* MMASK not used in INL server */ > > #define MWHOMSK 0x1f /* mask with this to find > * who msg to */ > #define MWHATMSK 0xe0 /* mask with this to find > * what message about */ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.netrek.org/ From sven-netrek-dev at sven.de Sun Mar 10 17:42:55 2019 From: sven-netrek-dev at sven.de (Sven Neuhaus) Date: Sun, 10 Mar 2019 23:42:55 +0100 Subject: [netrek-dev] HiDPI support Message-ID: <3daed5ba-f588-656f-a2e8-a825e0478632@sven.de> Hi there, has there been any work on HiDPI support? I tried playing on a Dell XPS 13 with a 3200x2000 13.3" display using COW on Ubuntu 18.04 and the text is pretty much unreadable. Pixel doubling would do the trick I guess. Cheers, -Sven From quozl at laptop.org Sun Mar 10 18:13:57 2019 From: quozl at laptop.org (James Cameron) Date: Mon, 11 Mar 2019 10:13:57 +1100 Subject: [netrek-dev] HiDPI support In-Reply-To: <3daed5ba-f588-656f-a2e8-a825e0478632@sven.de> References: <3daed5ba-f588-656f-a2e8-a825e0478632@sven.de> Message-ID: <20190310231357.GC17689@laptop.org> No work that I've seen. Yes, doubling would work. Another method is a scalable vector rendering. Imagine each object as an SVG. Plenty of resources in modern CPUs to render all necessary objects on each change of resolution or window dimensions. We would also need vector artwork. On Sun, Mar 10, 2019 at 11:42:55PM +0100, Sven Neuhaus wrote: > Hi there, > > has there been any work on HiDPI support? I tried playing on a > Dell XPS 13 with a 3200x2000 13.3" display using COW on Ubuntu 18.04 and the > text is pretty much unreadable. > > Pixel doubling would do the trick I guess. > > Cheers, > -Sven > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- James Cameron http://quozl.netrek.org/ From darrellroot at mac.com Sun Mar 10 18:22:38 2019 From: darrellroot at mac.com (Darrell Root) Date: Sun, 10 Mar 2019 16:22:38 -0700 Subject: [netrek-dev] Having trouble with CP_MESSAGE format, first screenshot of Swift Netrek client for Mac! In-Reply-To: <20190310222239.GB17689@laptop.org> References: <3C28F3F6-695E-4E6D-A869-533A39DF3406@mac.com> <20190310222239.GB17689@laptop.org> Message-ID: Thank you! Good catch on the need to implement cloaker logic. Bitmaps are not set so I’ll pay attention to the colors used by existing clients when I get to that point. Darrell > On Mar 10, 2019, at 3:22 PM, James Cameron wrote: > > On Sun, Mar 10, 2019 at 02:15:29PM -0700, Darrell Root wrote: >> I’m making good progress on my MacOS/Swift netrek client. It’s >> playable! I’ve even gotten a couple kills. I’m hoping to release >> an alpha version Friday March 15th. “Beware the ides of March”. >> I’ve attached a screenshot at the bottom. > > Looks good. Ships inbound to Draconis ought to be cloaked; please add > the code to hide them somehow. > > Team colours are unconventional; we would normally use a red or orange > colour for Romulan team, and a yellow colour for Federation. This > would make is easier for people to move to another client and fit > existing documentation. Most clients allow the colours to be > customised. > >> I’m having trouble understanding the CP_MESSAGE format. At first it >> looks simple: >> >> struct mesg_cpacket { /* CP_MESSAGE py-struct "!bBBx80s" #1 */ >> char type; >> char group; >> char indiv; /* does this break anything? -da */ >> char pad1; >> char mesg[MSG_LEN]; >> }; >> >> I captured a packet trace of a distress call to the Rom team with 4 >> in the group (MTEAM?) and 2 in the indiv (TEAM=ROM?) fields. But >> I’m having trouble sending messages with the MacTrek client so I >> don’t have a full set of packet traces to work with. > > Run another client. MacTrek did not mature. > >> Other client headers below but let me ask a couple specific questions: >> >> 1) If I want to send a message to ALL, what do I put in group/indiv? > > Deriving from source code; > > MALL in group. > zero in indiv. > > https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L2266 > https://github.com/quozl/netrek-client-cow/blob/master/smessage.c#L221 > >> 2) If I want to send a message to TEAM ROM, what do I put in >> group/indiv (I think group=4 (MTEAM) and indiv=2 (ROM)). > > Deriving from source code; > > MTEAM in group. > ROM in indiv. > > https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L2270 > https://github.com/quozl/netrek-client-cow/blob/master/smessage.c#L227 > >> 3) If I want to send a message to individual player #3 what do I put >> in the group/indiv fields? > > Deriving from source code; > > MINDIV in group. > ship number in indiv. > > https://github.com/quozl/gytha/blob/master/gytha/__init__.py#L2290 > https://github.com/quozl/netrek-client-cow/blob/master/smessage.c#L248 > >> 4) At startup, client is supposed to send the following message: >> CP_MESSAGE (MINDIV|MCONFIG, self, "@clientname clientversion") >> MINDIV is 0x02 >> MCONFIG is 0x04 >> So I guess 0x06 goes in the group field. What is the “self” that >> (presumably) goes in the indiv field? Is that my PlayerID (0 >> through 31)? > > p_no > > https://github.com/quozl/netrek-client-cow/blob/master/dmessage.c#L278 > > But it probably does not matter, as the server does not check it; > > https://github.com/quozl/netrek-server/blob/master/ntserv/socket.c#L1704 > https://github.com/quozl/netrek-server/blob/master/ntserv/socket.c#L1953 > >> Darrell >> ----------- >> >> Looking at the existing source code I’m finding a bunch of different things to put in the group and indiv fields (although I may be getting CP_MESSAGE and SP_MESSAGE mixed up). >> >> The team flags are as follows: >> >> IND=0x0 >> FED=0x1 >> ROM=0x2 >> KLI=0x4 >> ORI=0x8 >> >> Below is the message header source I’ve dug up. >> >> #define MVALID 0x01 >> #define MGOD 0x10 >> #define MMOO 0x12 >> >> #ifdef TOOLS >> #define MTOOLS 0x14 >> #endif >> >> /* order flags by importance (0x100 - 0x400) */ >> /* restructuring of message flags to squeeze them all into 1 byte - jmn */ >> /* hopefully quasi-back-compatible: MVALID, MINDIV, MTEAM, MALL, MGOD use up >> * 5 bits. this leaves us 3 bits. since the server only checks for those >> * flags when deciding message related things and since each of the above >> * cases only has 1 flag on at a time we can overlap the meanings of the >> * flags */ >> >> #define MINDIV 0x02 >> /* these go with MINDIV flag */ >> >> #ifdef STDBG >> #define MDBG 0x20 >> #endif >> >> #define MCONFIG 0x40 /* config messages from * * >> * server */ >> #define MDIST 0x60 /* flag distress type * * >> * messages properly */ >> #ifdef MULTILINE_MACROS >> #define MMACRO 0x80 >> #endif >> >> #define MTEAM 0x04 >> /* these go with MTEAM flag */ >> #define MTAKE 0x20 >> #define MDEST 0x40 >> #define MBOMB 0x60 >> #define MCOUP1 0x80 >> #define MCOUP2 0xA0 >> #define MDISTR 0xC0 /* flag distress type >> * messages */ >> #define MALL 0x08 >> /* these go with MALL flag */ >> #define MGENO 0x20 /* MGENO is not used in INL >> * here */ >> #define MCONQ 0x20 /* not enought bits to >> * distinguish MCONQ/MGENO :-( */ >> #define MKILLA 0x40 >> #define MKILLP 0x60 >> #define MKILL 0x80 >> #define MLEAVE 0xA0 >> #define MJOIN 0xC0 >> #define MGHOST 0xE0 >> /* MMASK not used in INL server */ >> >> #define MWHOMSK 0x1f /* mask with this to find >> * who msg to */ >> #define MWHATMSK 0xe0 /* mask with this to find >> * what message about */ > >> _______________________________________________ >> netrek-dev mailing list >> netrek-dev at us.netrek.org >> http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > > -- > James Cameron > http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From billbalcerski at gmail.com Sun Mar 10 18:24:05 2019 From: billbalcerski at gmail.com (Bill Balcerski) Date: Sun, 10 Mar 2019 19:24:05 -0400 Subject: [netrek-dev] HiDPI support In-Reply-To: <3daed5ba-f588-656f-a2e8-a825e0478632@sven.de> References: <3daed5ba-f588-656f-a2e8-a825e0478632@sven.de> Message-ID: Hi Sven, Resolution scaling is present in Netrek XP 2010, so text can scale up to be readable. I don't think this was present in Netrek XP Mod (Netrek Classic). I just checked and out of the box, the message window text is much smaller in XP Mod. I also added the high resolution bitmaps from Pascal and controllable scaling of the tactical window to support up to 4x normal size (normal being 500x500 pixel, support up to 2000x2000 pixels). Galaxy map can be resized as well but does not use the higher resolution that tactical window can use. I use a 1680x1050 resolution for main window, 750x750 for tactical and galaxy. Bill On Sun, Mar 10, 2019 at 6:50 PM Sven Neuhaus wrote: > Hi there, > > has there been any work on HiDPI support? I tried playing on a > Dell XPS 13 with a 3200x2000 13.3" display using COW on Ubuntu 18.04 and > the text is pretty much unreadable. > > Pixel doubling would do the trick I guess. > > Cheers, > -Sven > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darrellroot at mac.com Thu Mar 14 23:48:47 2019 From: darrellroot at mac.com (Darrell Root) Date: Thu, 14 Mar 2019 21:48:47 -0700 Subject: [netrek-dev] Announcing the alpha release of the new Netrek MacOS client: written in Swift Message-ID: <25722203-64B7-41A8-82A8-698757D3063A@mac.com> I am pleased to announce the alpha release of the new Netrek MacOS client. 100% written in Swift! A few screenshots below. Here’s my webpage with info and the download: https://networkmom.net/netrek/ Here’s a direct link to the binary: netrek-alpha.zip The binary is signed by my Apple developer account, notarized by Apple, and uses “Apple’s hardened runtime” feature to protect you from malicious software. The only access it requests is “outbound network connections”, which is obviously required to play. The app requires MacOS 10.14 Mojave. I am committed to making the source code freely available. But hope you’ll forgive me for waiting until after Mac App Store approval before doing that. The app will be free. I’m hoping having it in the app store will get us some new players. My next milestone is a beta “Mac app store candidate” release Friday March 21. If anyone has a nice 80x80 .jpg set of ships that would be great. I’ve removed ships which could be considered “Star Trek” copyright infringement. But that’s left the fleet a bit sparse. A new “yellow” fleet for the Federation is most needed. I thank all the previous developers (particularly James for answering questions) and server maintainers. Please send me feedback, even if it’s just “I played it and it pretty much worked” or “I played it and the 10fps was awful”. For reference, Swift Netrek comes in at about 5000 lines of code (although it is not yet complete). For comparison: MacTrek: 31000 lines of source code Gytha: 7650 lines BRMH-2.4.0: 36000 lines of source code COW-3.2.8: 52000 lines of source code Current known issues: • Set login information needs to be toggled back and forth to trigger non-guest login. • Client may ignore your “preferred team" • Need to allow keymapping of all keys • A few commands may not be implemented (speed 11? speed 12?) • Player list needs more information • Experiment with position extrapolation to allow faster than 10fps updates (should make this a switch) • Improved 80x80 ship bitmaps • Need to review planet names and messages to avoid copyright infringement. • Select server still has my test server at 192.168.0.10 hardcoded. Need to remove that and allow login to arbitrary server. Darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: phaser-hit.png Type: image/png Size: 20278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: phaser-miss.png Type: image/png Size: 19548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: full-screenshot.png Type: image/png Size: 308156 bytes Desc: not available URL: From johnny at solbu.net Fri Mar 15 12:32:16 2019 From: johnny at solbu.net (Johnny A. Solbu) Date: Fri, 15 Mar 2019 18:32:16 +0100 Subject: [netrek-dev] Announcing the alpha release of the new Netrek MacOS client: written in Swift In-Reply-To: <25722203-64B7-41A8-82A8-698757D3063A@mac.com> References: <25722203-64B7-41A8-82A8-698757D3063A@mac.com> Message-ID: <201903151832.20518.johnny@solbu.net> On Friday 15 March 2019 05:48, Darrell Root wrote: > I am committed to making the source code freely available. But hope you�ll forgive me for waiting until after Mac App Store approval before doing that. The app will be free. Which License do you plan on using? -- Johnny A. Solbu web site, http://www.solbu.net PGP key ID: 0x4F5AD64DFA687324 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From darrellroot at mac.com Fri Mar 15 17:05:54 2019 From: darrellroot at mac.com (Darrell Root) Date: Fri, 15 Mar 2019 15:05:54 -0700 Subject: [netrek-dev] Announcing the alpha release of the new Netrek MacOS client: written in Swift In-Reply-To: <201903151832.20518.johnny@solbu.net> References: <25722203-64B7-41A8-82A8-698757D3063A@mac.com> <201903151832.20518.johnny@solbu.net> Message-ID: I just managed to natively create the last 3 packet types in Swift so the last bit of source from the original 1989 netrek (packets.h), is eliminated from my project. I use the netrek network API’s, plus some graphics from via Gytha from Pascal Gagnon (creative commons attribution license), and some graphics from MacTrek (source unknown, possibly Judith Lukassen). Here’s a summary of the licenses used by Netrek over the years: 1986 XTrek: copyright.h 1989 Netrek: copyright.h, copyright2.h COW: copyright.h, copyright2.h, plus some others from source I didn’t even look at Gytha: GNU GPL v2 from 1991 BRMH: copyright.h, copyright2.h netrek-server-vanilla: copyright.h, copyright2.h MacTrek had a custom license I’ve included copyright.h and copyright2.h below. Do you have a license suggestion? I’m pretty happy with copyright.h and copyright2.h. It’s also consistent with the licensing from the original authors of XTrek and Netrek. The only problem is it is not one of the “standard” GitHub licenses. Darrell copyright.h /* Copyright (c) 1986 Chris Guthrie Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. Copyright 1989 Kevin P. Smith Scott Silvey ditto. Copyright (c) 1993 Tedd Hadley Heiko Wengler (Short packets code, formerly marked with a #define SHORT_PACKETS) ditto. */ copyright2.h /* Copyright 1989 Kevin P. Smith Scott Silvey Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies. */ > On Mar 15, 2019, at 10:32 AM, Johnny A. Solbu wrote: > > On Friday 15 March 2019 05:48, Darrell Root wrote: >> I am committed to making the source code freely available. But hope you’ll forgive me for waiting until after Mac App Store approval before doing that. The app will be free. > > Which License do you plan on using? > > -- > Johnny A. Solbu > web site, http://www.solbu.net > PGP key ID: 0x4F5AD64DFA687324 > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From quozl at laptop.org Fri Mar 15 17:13:17 2019 From: quozl at laptop.org (James Cameron) Date: Sat, 16 Mar 2019 09:13:17 +1100 Subject: [netrek-dev] Announcing the alpha release of the new Netrek MacOS client: written in Swift In-Reply-To: References: <25722203-64B7-41A8-82A8-698757D3063A@mac.com> <201903151832.20518.johnny@solbu.net> Message-ID: <20190315221317.GB4941@laptop.org> I've no license suggestion. I used GPLv2+ for Gytha. -- James Cameron http://quozl.netrek.org/ From netrek at gmail.com Fri Mar 15 20:06:44 2019 From: netrek at gmail.com (Zachary Uram) Date: Fri, 15 Mar 2019 21:06:44 -0400 Subject: [netrek-dev] Announcing the alpha release of the new Netrek MacOS client: written in Swift In-Reply-To: <20190315221317.GB4941@laptop.org> References: <25722203-64B7-41A8-82A8-698757D3063A@mac.com> <201903151832.20518.johnny@solbu.net> <20190315221317.GB4941@laptop.org> Message-ID: Nice work! Zach On Fri, Mar 15, 2019 at 6:13 PM James Cameron wrote: > I've no license suggestion. I used GPLv2+ for Gytha. > > -- > James Cameron > http://quozl.netrek.org/ > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -- http://www.fidei.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.lukassen at gmail.com Sat Mar 16 03:31:35 2019 From: chris.lukassen at gmail.com (Chris Lukassen) Date: Sat, 16 Mar 2019 09:31:35 +0100 Subject: [netrek-dev] netrek-dev Digest, Vol 96, Issue 10 In-Reply-To: References: Message-ID: <74557FB1-4D60-40CC-AEF3-E069841B545C@gmail.com> *decloaking* yep, and feel free to use. Looking forward to a new Mac client Chris ---- Sent from my iPhone please excuse brevity and typos > On 16 Mar 2019, at 02:07, netrek-dev-request at us.netrek.org wrote: > > and some graphics from MacTrek (source unknown, possibly Judith Lukassen). From darrellroot at mac.com Thu Mar 28 19:14:30 2019 From: darrellroot at mac.com (Darrell Root) Date: Thu, 28 Mar 2019 17:14:30 -0700 Subject: [netrek-dev] keepalive timer on continuum.us.netrek.org? how does the client pick a preferred team? Message-ID: <0C462672-03A5-4427-8F51-C63D2F5D3FA9@mac.com> netrek-dev folks, Question 1: On continuum.us.netrek.org , if my client doesn’t send any commands for 20-30 seconds, I get ghostbusted. It seems like the server wants some sort of activity keepalive. Any ideas? There is a SP_PING and a CP_PING_RESPONSE, but I don’t see a CP_PING. What should I send periodically? Question 2: I’m having trouble with the “picking team” logic in my netrek client. The server sends an SP_MASK packet: struct mask_spacket { /* SP_MASK py-struct "!bbxx" #19 */ char type; char mask; char pad1; char pad2; }; Here’s what the currently online servers send: continuum.us.netrek.org sends mask = 15 (fed + rom + kli + ori) netrek.beesenterprises.com sends mask = 3 (fed + rom) pickled.netrek.org sends mask = 2 (rom) Then the client sends a CP_OUTFIT packet: struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ char type; char team; char ship; char pad1; }; It looks like the “Team” has to be an integer between 0 and 3 inclusive: netrek-server-vanilla/ntserv/getentry.c: if (teamPick < 0 || teamPick > 3) { new_warning(UNDEF,"Get real!"); sendPickokPacket(0); teamPick= -1; continue; } On beesenterprises.com , when I send team = 0 I end up rom. Anything else I am rejected. On pickled.netrek.org when I send team = 0 I end up rom. Anything else I am rejected. On continuum.us.netrek.org , when I send team = 0, I end up rom. Anything else I am rejected. Is there a way to select teams? What does the team = 0 or 1 or 2 or 3 mean in the CP_OUTFIT packet? I have a pulldown menu with the “preferred team”, but it doesn’t work the way a player would expect. Darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From apsillers at gmail.com Fri Mar 29 07:57:46 2019 From: apsillers at gmail.com (Andrew Sillers) Date: Fri, 29 Mar 2019 08:57:46 -0400 Subject: [netrek-dev] keepalive timer on continuum.us.netrek.org? how does the client pick a preferred team? In-Reply-To: <0C462672-03A5-4427-8F51-C63D2F5D3FA9@mac.com> References: <0C462672-03A5-4427-8F51-C63D2F5D3FA9@mac.com> Message-ID: In the web client, I did a periodic CP_UPDATES packet, which just repeatedly requests the server to keep using the same update rate we're already using: https://github.com/apsillers/html5-netrek/blob/e99e25d10166dda662c534a671689142f62d4301/js/main.js#L246 setInterval(function() { net.sendArray(CP_UPDATES.data(UPDATE_RATE)); }, 10000); I'm also curious if there's a better way or not. Andrew On Thu, Mar 28, 2019, 8:14 PM Darrell Root wrote: > netrek-dev folks, > > Question 1: On continuum.us.netrek.org, if my client doesn’t send any > commands for 20-30 seconds, I get ghostbusted. It seems like the server > wants some sort of activity keepalive. Any ideas? There is a SP_PING and > a CP_PING_RESPONSE, but I don’t see a CP_PING. What should I send > periodically? > > Question 2: > > I’m having trouble with the “picking team” logic in my netrek client. > > The server sends an SP_MASK packet: > > struct mask_spacket { /* SP_MASK py-struct "!bbxx" #19 */ > char type; > char mask; > char pad1; > char pad2; > }; > > Here’s what the currently online servers send: > > continuum.us.netrek.org sends mask = 15 (fed + rom + kli + ori) > netrek.beesenterprises.com sends mask = 3 (fed + rom) > pickled.netrek.org sends mask = 2 (rom) > > Then the client sends a CP_OUTFIT packet: > > struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ > char type; > char team; > char ship; > char pad1; > }; > > It looks like the “Team” has to be an integer between 0 and 3 inclusive: > > netrek-server-vanilla/ntserv/getentry.c: > > if (teamPick < 0 || teamPick > 3) { > > new_warning(UNDEF,"Get real!"); > sendPickokPacket(0); > teamPick= -1; > continue; > } > > On beesenterprises.com, when I send team = 0 I end up rom. Anything else I am rejected. > On pickled.netrek.org when I send team = 0 I end up rom. Anything else I am rejected. > On continuum.us.netrek.org, when I send team = 0, I end up rom. Anything else I am rejected. > > Is there a way to select teams? What does the team = 0 or 1 or 2 or 3 mean in the CP_OUTFIT packet? > > I have a pulldown menu with the “preferred team”, but it doesn’t work the way a player would expect. > > Darrell > > > > > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darrellroot at mac.com Fri Mar 29 19:33:51 2019 From: darrellroot at mac.com (Darrell Root) Date: Fri, 29 Mar 2019 17:33:51 -0700 Subject: [netrek-dev] Mac Swift Netrek client v0.5 now available Message-ID: netrek-dev folks, I’m a week late, but my Mac Swift Netrek Client v0.5 is now available on https://networkmom.net/netrek/ Direct binary link: https://networkmom.net/download/netrek-v0.5.app.zip This binary is scanned/notarized by Apple and my developer ID. Updates too numerous to list. My thanks to Andrew Sillers for his CP_Updates suggestion. Idle users don’t get Ghostbusted on continuum.us.netrek.org any more. I’m still stumped by team selection per my earlier email, and would appreciate any suggestions (preferably without implementing the “generic” packet type 32). I have support for “basic tips” (in green) and “advanced tips” (in red) which cycle every 5 seconds when not playing (and can be turned off in preferences). I’m happy to accept pointers to any “list of advanced tips” to further populate it. Bug reports appreciated, but to avoid too much spam consider sending them only to me if they are not of general interest. Darrell darrellroot AT mac.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-03-29 at 5.15.25 PM.png Type: image/png Size: 24004 bytes Desc: not available URL: From billbalcerski at gmail.com Sat Mar 30 09:24:39 2019 From: billbalcerski at gmail.com (Bill Balcerski) Date: Sat, 30 Mar 2019 10:24:39 -0400 Subject: [netrek-dev] Mac Swift Netrek client v0.5 now available In-Reply-To: References: Message-ID: Here's a pastebin with hints from our windows client. Gytha has hints too I believe, couldn't find them in cursory review of gytha source docs. https://pastebin.com/C1JTLRK3 On Fri, Mar 29, 2019 at 8:34 PM Darrell Root wrote: > netrek-dev folks, > > I’m a week late, but my Mac Swift Netrek Client v0.5 is now available on > https://networkmom.net/netrek/ > Direct binary link: https://networkmom.net/download/netrek-v0.5.app.zip > This binary is scanned/notarized by Apple and my developer ID. > > Updates too numerous to list. > > My thanks to Andrew Sillers for his CP_Updates suggestion. Idle users > don’t get Ghostbusted on continuum.us.netrek.org any more. > > I’m still stumped by team selection per my earlier email, and would > appreciate any suggestions (preferably without implementing the “generic” > packet type 32). > > I have support for “basic tips” (in green) and “advanced tips” (in red) > which cycle every 5 seconds when not playing (and can be turned off in > preferences). I’m happy to accept pointers to any “list of advanced tips” > to further populate it. > > Bug reports appreciated, but to avoid too much spam consider sending them > only to me if they are not of general interest. > > Darrell > darrellroot AT mac.com > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2019-03-29 at 5.15.25 PM.png Type: image/png Size: 24004 bytes Desc: not available URL: From keyos at keyos.org Sun Mar 31 08:05:56 2019 From: keyos at keyos.org (Stas Pirogov) Date: Sun, 31 Mar 2019 16:05:56 +0300 (IDT) Subject: [netrek-dev] Mac Swift Netrek client v0.5 now available In-Reply-To: References: Message-ID: Hi Darrell, I deleted your original message with team selection question, so replying in this one. >Question 2: > >I’m having trouble with the “picking team” logic in my netrek client. > >The server sends an SP_MASK packet: >struct mask_spacket { /* SP_MASK py-struct "!bbxx" #19 */ > char type; > char mask; > char pad1; > char pad2; >}; >Here’s what the currently online servers send: >continuum.us.netrek.org sends mask = 15 >(fed + rom + kli + ori) >netrek.beesenterprises.com sends >mask = 3 (fed + rom) >pickled.netrek.org sends mask = 2 (rom) > So this one is pretty simple, each server sends current allowed teams as bitmap. I can also confirm that I get same values (that's what I have as allowed teams in selection tiles) >Then the client sends a CP_OUTFIT packet: >struct outfit_cpacket { /* CP_OUTFIT py-struct "!bbbx" #9 */ > char type; > char team; > char ship; > char pad1; >}; >It looks like the “Team” has to be an integer between 0 and 3 inclusive: >netrek-server-vanilla/ntserv/getentry.c: > if (teamPick < 0 || teamPick > 3) { > new_warning(UNDEF,"Get real!"); > sendPickokPacket(0); > teamPick= -1; > continue; > } > So after reading netrekxpmod sources I can see that team selection is based on teams numerical order: 0 - FED 1 - ROM 2 - KLI 3 - ORI You send CP_OUTFIT that contains your desired team and ship type. In response you should expect SP_PICKOK packet with either 1 (approved) or 0 (rejected) >On beesenterprises.com , when I send team = 0 >I end up rom. Anything else I am rejected. >On pickled.netrek.org when I send team = 0 I >end up rom. Anything else I am rejected. >On continuum.us.netrek.org , when I send >team = 0, I end up rom. Anything else I am rejected. > So here you'll have to expand on what do you mean by "I end up rom or get rejected". If you send 0 as team you're supposed to become federation player, not romulan Also I would suggest running your own vanilla server which will allow you enabling debugging and actually seeing what's wrong. That's the way I used to code the client >Is there a way to select teams? What does the team = 0 or 1 or 2 or 3 >mean in the CP_OUTFIT packet? > >I have a pulldown menu with the “preferred team”, but it doesn’t work the >way a player would expect. > >Darrell Hope this helps Stas On Fri, 29 Mar 2019, Darrell Root wrote: > Date: Fri, 29 Mar 2019 17:33:51 -0700 > From: Darrell Root > Reply-To: Netrek Development Mailing List > To: Netrek Development Mailing List > Subject: [netrek-dev] Mac Swift Netrek client v0.5 now available > > netrek-dev folks, > > I’m a week late, but my Mac Swift Netrek Client v0.5 is now available on https://networkmom.net/netrek/ > Direct binary link: https://networkmom.net/download/netrek-v0.5.app.zip > This binary is scanned/notarized by Apple and my developer ID. > > Updates too numerous to list. > > My thanks to Andrew Sillers for his CP_Updates suggestion. Idle users don’t get Ghostbusted on continuum.us.netrek.org any more. > > I’m still stumped by team selection per my earlier email, and would appreciate any suggestions (preferably without implementing the “generic” packet type 32). > > I have support for “basic tips” (in green) and “advanced tips” (in red) which cycle every 5 seconds when not playing (and can be turned off in preferences). I’m happy to accept pointers to any “list of advanced tips” to further populate it. > > Bug reports appreciated, but to avoid too much spam consider sending them only to me if they are not of general interest. > > Darrell > darrellroot AT mac.com > >