Difference between revisions of "Network Protocol/STATUS"

From Custom Mario Kart
Jump to navigation Jump to search
m (→‎Type 06: Same Network (Skip NATNEG): New definition for STATUS-06.)
 
(18 intermediate revisions by 5 users not shown)
Line 1: Line 1:
This pages is related to [[MKWii Network Protocol]] and describes the record type '''STATUS'''.
+
== Overview ==
 +
This article describes the record type '''STATUS''' of the [[Network Protocol]].
  
 
The status packages are from one client to another in 3 different ways:
 
The status packages are from one client to another in 3 different ways:
Line 6: Line 7:
 
* Client to [[Server GPCM]] to client communication using a ''GPCM90vMAT'' message. The [[#head|message header]] is omitted. This is used for known friends.
 
* Client to [[Server GPCM]] to client communication using a ''GPCM90vMAT'' message. The [[#head|message header]] is omitted. This is used for known friends.
 
The used data structure is identical for all 3 communication ways, only the header is different. The members itself are mainly stored as little endian data.
 
The used data structure is identical for all 3 communication ways, only the header is different. The members itself are mainly stored as little endian data.
 
 
__TOC__
 
  
  
Line 17: Line 15:
 
|+ Message header of Status Messages
 
|+ Message header of Status Messages
 
|-
 
|-
! Offset !! Size !! Endian !! Description
+
! Offset !! Name !! Size !! Endian !! Description
 
|-
 
|-
| align=center | 0x00 || align=center | 4 || ?
+
| align=center | 0x00 || <tt>identifier</tt> || align=center | 4 || ?
 
| The '''magic''', always 0xbb49cc4d (big endian) = 0x4dcc49bb (little endian)  
 
| The '''magic''', always 0xbb49cc4d (big endian) = 0x4dcc49bb (little endian)  
 
|-
 
|-
| align=center | 0x04 || align=center | 4 || little
+
| align=center | 0x04 || <tt>version</tt> || align=center | 4 || little
| Always 90, maybe the »'''dwc_mver'''«.
+
| »'''dwc_mver'''«. Always 90 for MKWii.  
 
|-
 
|-
| align=center | 0x08 || align=center | 1 || &mdash;
+
| align=center | 0x08 || <tt>command</tt> || align=center | 1 || &mdash;
 
| The status '''type'''.
 
| The status '''type'''.
 
|-
 
|-
| align=center | 0x09 || align=center | 1 || &mdash;
+
| align=center | 0x09 || <tt>size</tt> || align=center | 1 || &mdash;
| The '''length of the extent''' (='''ELEN''').
+
| The '''length of the appended data'''.
 
|-
 
|-
| align=center | 0x0a || align=center | 2 || little
+
| align=center | 0x0a || <tt>qr2Port</tt> || align=center | 2 || little
 
| The '''public port''' of the sender client.
 
| The '''public port''' of the sender client.
 
|-
 
|-
| align=center | 0x0c || align=center | 4 || 4 bytes
+
| align=center | 0x0c || <tt>qr2IP</tt> || align=center | 4 || 4 bytes
 
| The '''public IPv4''' of the sender client, byte by byte (similar to big endian).
 
| The '''public IPv4''' of the sender client, byte by byte (similar to big endian).
 
|-
 
|-
| align=center | 0x10 || align=center | 4 || little
+
| align=center | 0x10 || <tt>profileID</tt> || align=center | 4 || little
 
| The '''profile id''' of the sender client.
 
| The '''profile id''' of the sender client.
 
|-
 
|-
| align=center | 0x14 || align=center | ELEN || &mdash;
+
| align=center | 0x14 || <tt>data</tt> || align=center | <tt>size</tt> || &mdash;
 
| The status type dependent '''extent'''.
 
| The status type dependent '''extent'''.
 
|-
 
|-
Line 49: Line 47:
 
|+ All extentions
 
|+ All extentions
 
|-
 
|-
! Type !! Size !! Transport !! Description
+
! Type !! Size !! Transport !! Name !! Description
 
|-
 
|-
 
| [[#S01|0x01]] || 0x24 || GPCM90vMAT<br/>MS+MASTER
 
| [[#S01|0x01]] || 0x24 || GPCM90vMAT<br/>MS+MASTER
| A player is asking for entrance
+
| <tt>RESERVATION</tt> || NAT negotiation reservation request
 
|-
 
|-
 
| [[#S02|0x02]] || 0x34 || GPCM90vMAT<br/>MS+MASTER
 
| [[#S02|0x02]] || 0x34 || GPCM90vMAT<br/>MS+MASTER
| The host allows the player to enter (answer to 0x01)
+
| <tt>RESV_OK</tt> || NAT negotiation reservation completion
 
|-
 
|-
 
| [[#S03|0x03]] || 0x04 || GPCM90vMAT<br/>MS+MASTER
 
| [[#S03|0x03]] || 0x04 || GPCM90vMAT<br/>MS+MASTER
| The host denies the entrance request because the room is full
+
| <tt>RESV_DENY</tt> || NAT negotiation reservation refusal
 
|-
 
|-
 
| [[#S04|0x04]] || 0x00 || GPCM90vMAT<br/>MS+MASTER
 
| [[#S04|0x04]] || 0x00 || GPCM90vMAT<br/>MS+MASTER
| Busy with NATNEG. Join request denied.
+
| <tt>RESV_WAIT</tt> || NAT negotiation reservation wait request
 
|-
 
|-
 
| [[#S05|0x05]] || 0x00 || GPCM90vMAT<br/>MS+MASTER
 
| [[#S05|0x05]] || 0x00 || GPCM90vMAT<br/>MS+MASTER
| Acknowlegdement for [[#S04|0x04]]
+
| <tt>RESV_CANCEL</tt> || NAT negotiation reservation cancellation request
 
|-
 
|-
 
| [[#S06|0x06]] || 0x08 || GPCM90vMAT
 
| [[#S06|0x06]] || 0x08 || GPCM90vMAT
| Local IP/port
+
| <tt>TELL_ADDR</tt> || NN starting address notification (NAT negotiation unnecessary)
 
|-
 
|-
 
| [[#S07|0x07]] || 0x08 || client to client
 
| [[#S07|0x07]] || 0x08 || client to client
| Host sends information about a new player to all clients
+
| <tt>NEW_PID_AID</tt> || New connection client profile ID and AID notification
 +
|-
 +
| [[#S08|0x08]] || 0x08 || client to client
 +
| <tt>LINK_CLS_REQ</tt> || Not used by MKWii. Request for connection between clients
 +
|-
 +
| [[#S09|0x09]] || 0x04 || client to client
 +
| <tt>LINK_CLS_SUC</tt> || Not used by MKWii. Notification of successful connection between clients
 +
|-
 +
| 0x0a || ? || ?
 +
| <tt>CLOSE_LINK</tt> || Not used by MKWii. Notification of closed connection when connection is established
 +
|-
 +
| 0x0b || ? || ?
 +
| <tt>RESV_PRIOR</tt> || Not used by MKWii. NAT negotiation priority reservation request
 +
|-
 +
| [[#S0c|0x0c]] || 0x04 || client to client
 +
| <tt>CANCEL</tt> || matchmaking cancel command
 
|-
 
|-
 
| [[#S0d|0x0d]] || 0x04 || client to client
 
| [[#S0d|0x0d]] || 0x04 || client to client
| Cancel SYN 0. Joining failed
+
| <tt>CANCEL_SYN</tt> || SYN for matchmaking cancellation synchronization
 
|-
 
|-
 
| [[#S0e|0x0e]] || 0x00 || client to client
 
| [[#S0e|0x0e]] || 0x00 || client to client
| Cancel SYN 1. Reply to [[#S0d|0x0d]] (sent by all clients)
+
| <tt>CANCEL_SYN_ACK</tt> || SYN-ACK for matchmaking cancellation synchronization
 
|-
 
|-
 
| [[#S0f|0x0f]] || 0x00 || client to client
 
| [[#S0f|0x0f]] || 0x00 || client to client
| Cancel SYN 2. Sent by Host when every client sent [[#S0e|0x0e]]. Half-connected client completely gone.
+
| <tt>CANCEL_ACK</tt> || ACK for matchmaking cancellation synchronization
 
|-
 
|-
| rowspan=3 | [[#S10|0x10]]
+
| [[#S10|0x10]] || 0x04 * '''n''' || GPCM90vMAT<br/>MS+MASTER<br/>client to client
| 0x00 || GPCM90vMAT<br/>MS+MASTER<br/>client to client
+
| <tt>SC_CLOSE_CL</tt> || Notification of unintentional disconnect for already connected clients. Host disconnects '''n''' players (contains all their PIDs)
| ?
 
 
|-
 
|-
| 0x04 || GPCM90vMAT<br/>MS+MASTER<br/>client to client
+
| 0x11 || 0x00 || ?
| ?
+
| <tt>POLL_TIMEOUT</tt> || Not used by MKWii. OPTION_MIN_COMPLETE timeout polling
 
|-
 
|-
| 0x08 || GPCM90vMAT<br/>MS+MASTER<br/>client to client
+
| 0x12 || 0x04 || ?
| ?
+
| <tt>POLL_TO_ACK</tt> || Not used by MKWii. ACK to OPTION_MIN_COMPLETE timeout polling
 +
|-
 +
| 0x13 || ? || ?
 +
| <tt>SC_CONN_BLOCK</tt> || Not used by MKWii. Reservation denied due to block by OPTION_SC_CONNECT_BLOCK
 +
|-
 +
| 0x20 || 0x04 || ?
 +
| <tt>FRIEND_ACCEPT</tt> || Not used by MKWii. new connection friend permission from client
 +
|-
 +
| [[#S40|0x40]] || 0x00 || ?
 +
| <tt>CL_WAIT_POLL</tt> || Not used by MKWii. client standby timeout polling
 +
|-
 +
| [[#S41|0x41]] || 0x00 || ?
 +
| <tt>SV_KA_TO_CL</tt> || Not used by MKWii. server keep-alive for the above polling
 
|-
 
|-
 
| [[#S52|0x52]] || 0x04 || client to client
 
| [[#S52|0x52]] || 0x04 || client to client
| New host request: Wii wants to be the new host
+
| <tt>SVDOWNQUERY</tt> || rowspan=4 | Somehow related to host negotiations - who will be the new host.<br/>Still need to look into how exactly these work.
 
|-
 
|-
 
| [[#S53|0x53]] || 0x00 || client to client
 
| [[#S53|0x53]] || 0x00 || client to client
| Client allows Wii to be the new host; or, Wii announces that it is now the new host
+
| <tt>SVDOWN_ACK</tt>
 
|-
 
|-
 
| [[#S54|0x54]] || 0x00 || client to client
 
| [[#S54|0x54]] || 0x00 || client to client
| Client disallows the Wii to be the new host
+
| <tt>SVDOWN_NAK</tt>
 
|-
 
|-
 
| [[#S55|0x55]] || 0x04 || client to client
 
| [[#S55|0x55]] || 0x04 || client to client
| Wii cancels host request, asks for someone else to become host
+
| <tt>SVDOWN_KEEP</tt>
 
|-
 
|-
 
| [[#S82|0x82]]
 
| [[#S82|0x82]]
 
| 0x08<br/>0x10 || MS+MASTER<br/>client to client
 
| 0x08<br/>0x10 || MS+MASTER<br/>client to client
| SUSPEND flag control, guests can request a suspend value, host sets it
+
| <tt>SUSPEND_MATCH</tt> || SUSPEND flag control, guests can request a suspend value, host sets it
 
|-
 
|-
 
| [[#S83|0x83]] || 0x0c || MS+MASTER<br/>client to client
 
| [[#S83|0x83]] || 0x0c || MS+MASTER<br/>client to client
| Contains a slot usage list. Sent by the host every 15 seconds
+
| <i>Unknown</i> || Contains a slot usage list. Sent by the host every 15 seconds (ServerPolling).
 
|}
 
|}
  
Line 122: Line 146:
 
=== New Player enters room ===
 
=== New Player enters room ===
  
If a knocker will enter a room, the following handshaking (only status packages reflected) is done with each room player that is already in the room:
+
When a new player enters a room, he connects to all players, one after another. To do so, either the joining client or a client that is already in the room (that seems to be random) sends a ST-01 (connection request) packet to the other. Then, the other player either answers with a ST-02, the players do NATNEG, connect to eachother, and continue with other players; or he sends a ST-04 (busy), gets a ST-05 as reply, and tries again later.
# Status 01 is send by room player.
 
# Status 04 is send by knocker.
 
# Status 05 is send by room player.
 
# Some seconds of silence.
 
# Either it starts again with step 1, or it continues
 
# Status  01 is send by knocker.
 
# Status  02 is send by room player.
 
  
 
=== Traceable public IP ===
 
=== Traceable public IP ===
Line 138: Line 155:
  
 
<div id="S01"></div>
 
<div id="S01"></div>
=== Type 01: Ask for entrance ===
+
=== <tt>RESERVATION</tt> (01): Connection request ===
  
 
This status packet is send from a '''knocker to each room player''', when the knocker will enter the room or group. There are 2 ways to transmit the message:
 
This status packet is send from a '''knocker to each room player''', when the knocker will enter the room or group. There are 2 ways to transmit the message:
Line 150: Line 167:
 
|-
 
|-
 
| align=center | 0x00 || align=center | 4 || little
 
| align=center | 0x00 || align=center | 4 || little
| '''Unknown (Friend Status?)''', 0 (80%) or 3 (20%)
+
| '''DWC_MATCH_TYPE'''. 0 = anybody, 1 = friend, 2 = SC_SV, 3 = SC_CL
 
|-
 
|-
 
| align=center | 0x04 || align=center | 4 || 4 bytes
 
| align=center | 0x04 || align=center | 4 || 4 bytes
Line 165: Line 182:
 
|-
 
|-
 
| align=center | 0x14 || align=center | 4 || little
 
| align=center | 0x14 || align=center | 4 || little
| '''Unknown''', always 1
+
| '''Unknown'''. Always 1. CTGP uses the highest byte for custom data.
 
|-
 
|-
 
| align=center | 0x18 || align=center | 4 || little
 
| align=center | 0x18 || align=center | 4 || little
Line 171: Line 188:
 
|-
 
|-
 
| align=center | 0x1c || align=center | 4 || little
 
| align=center | 0x1c || align=center | 4 || little
| '''Number of players''' at the knocker's console (1 or 2)
+
| '''Number of players''' at the console (1 or 2)
 
|-
 
|-
 
| align=center | 0x20 || align=center | 4 || little
 
| align=center | 0x20 || align=center | 4 || little
| An unique '''identfication number''' of this status packet. The reply of the player (status type [[#T-02|0x02]]) use the same ID.
+
| Unique '''identfication number''' of this status packet (<tt>resvCheckValue</tt>). The reply of the player (status type [[#T-02|0x02]]) use the same ID.
 
|-
 
|-
 
| align=center | 0x24
 
| align=center | 0x24
Line 183: Line 200:
 
<div id="S02"></div>
 
<div id="S02"></div>
  
=== Type 02: Allow entrance ===
+
=== <tt>RESV_OK</tt> (02): Allow connection ===
  
 
This status packet is send from the '''room player to the knocker''' as reply of a [[#T-01|type 0x01 message]] to confirm the entrance of the guest. There are 2 ways to transmit the message:
 
This status packet is send from the '''room player to the knocker''' as reply of a [[#T-01|type 0x01 message]] to confirm the entrance of the guest. There are 2 ways to transmit the message:
Line 198: Line 215:
 
|-
 
|-
 
| align=center | 0x04 || align=center | 4 || little
 
| align=center | 0x04 || align=center | 4 || little
| Most likely the '''client slot index''' of the sender (zero based, not player count).
+
| '''Client slot index''' of the sender (zero based, not player count).
 
|-
 
|-
 
| align=center | 0x08 || align=center | 4 || little
 
| align=center | 0x08 || align=center | 4 || little
Line 225: Line 242:
 
|-
 
|-
 
| align=center | 0x28 || align=center | 4 || little
 
| align=center | 0x28 || align=center | 4 || little
| Most likely the '''client slot index''' of the receiver (zero based, not player count).  
+
| '''Client slot index''' of the receiver (zero based, not player count).  
 
|-
 
|-
 
| align=center | 0x2c || align=center | 4 || little
 
| align=center | 0x2c || align=center | 4 || little
| Most likely the '''client/console count''' already in the room.  
+
| '''Client/console count''' already in the room.  
 
|-
 
|-
 
| align=center | 0x30 || align=center | 4 || little
 
| align=center | 0x30 || align=center | 4 || little
| The '''identfication number''' send by the guest (status type [[#T-01|0x01]]).
+
| The '''identfication number''' (<tt>resvCheckValue</tt>) send by the other player (status type [[#T-01|0x01]]).
 
|-
 
|-
 
| align=center | 0x34
 
| align=center | 0x34
Line 240: Line 257:
 
<div id="S03"></div>
 
<div id="S03"></div>
  
=== Type 03: Room full ===
+
=== <tt>RESV_DENY</tt> (03): Room full ===
  
 
This status packet is sent from the '''room player to the knocker''' when access is denied.  
 
This status packet is sent from the '''room player to the knocker''' when access is denied.  
Line 257: Line 274:
 
|}
 
|}
  
<div id="S04"></div><div id="S05"></div>
+
<div id="S04"></div>
 +
 
 +
=== <tt>RESV_WAIT</tt> (04): Busy doing NATNEG ===
 +
 
 +
0x04 is sent by a player as answer to [[#S01|0x01]] to deny a join request because the player is busy doing NATNEG.
 +
 
 +
<div id="S05"></div>
  
=== Type 04 and 05: Busy doing NATNEG ===
+
=== <tt>RESV_CANCEL</tt> (05): Abort connection ===
  
0x04 is sent by a player as answer to [[#S01|0x01]] to deny a join request because the player is busy doing NATNEG. 0x05 is a reply to 0x04.  
+
0x05 is sent by a player to another player to abort an ongoing NATNEG attempt with the target. It is commonly seen as a response to [[#S04|0x04]], but can also be triggered in other circumstances too, for instance, if the player receives a [[#S07|0x07]] packet from the host.
  
 
<div id="S06"></div>
 
<div id="S06"></div>
=== Type 06: Same Network (Skip NATNEG) ===
+
=== <tt>TELL_ADDR</tt> (06): Same Network (Skip NATNEG) ===
  
This packet contains the local IP of the player. This packet is sent after a received STATUS-02 to skip NATNEG for Wiis that are on the same network as each other.
+
This packet contains the local IP of the player. This packet is sent after a received STATUS-02 to skip NATNEG for Wiis that are on the same network as each other.  
  
 
{| id="T-06" class="textbox grid alt"
 
{| id="T-06" class="textbox grid alt"
Line 286: Line 309:
 
<div id="S07"></div>
 
<div id="S07"></div>
  
=== Type 07: New client ===
+
=== <tt>NEW_PID_AID</tt> (07): New client ===
  
 
Send by host when there joins a new player.  
 
Send by host when there joins a new player.  
Line 303: Line 326:
 
| align=center | 0x08
 
| align=center | 0x08
 
| colspan=3 {{unknown|End of the packet, 8 bytes total.}}
 
| colspan=3 {{unknown|End of the packet, 8 bytes total.}}
 +
|-
 +
|}
 +
 +
<div id="S0c"></div>
 +
 +
=== <tt>CANCEL</tt> (0c): Cancels a connection attempt ===
 +
 +
Sent under special circumstances when aborting a connection attempt. Cancel type/reason is only used for DWC Logs.
 +
 +
{| id="T-0C" class="textbox grid alt"
 +
|+ Status Type 0C
 +
|-
 +
! Offset !! Size !! Endian !! Description
 +
|-
 +
| align=center | 0x00 || align=center | 4 || little
 +
| Cancel type/reason
 +
|-
 +
| align=center | 0x04
 +
| colspan=3 {{unknown|End of the packet, 4 bytes total.}}
 
|-
 
|-
 
|}
 
|}
Line 308: Line 350:
 
<div id="S0d"></div>
 
<div id="S0d"></div>
  
=== Type 0D: Cancel SYN 0 ===
+
=== <tt>CANCEL_SYN</tt> (0d): Cancel SYN ===
  
 
This contains a little-endian PID and is sent by the host when a player tried to join, only connected partially, and then disconnected again. He hasn't done a full Natneg, so he can't send a disconnect himself, so the host sends a ST0D packet.  
 
This contains a little-endian PID and is sent by the host when a player tried to join, only connected partially, and then disconnected again. He hasn't done a full Natneg, so he can't send a disconnect himself, so the host sends a ST0D packet.  
  
 
<div id="S0e"></div>
 
<div id="S0e"></div>
=== Type 0E: Cancel SYN 1 ===
+
=== <tt>CANCEL_SYN_ACK</tt> (0e): Cancel SYN ACK ===
  
 
Other players acknowlegde a 0x0d with a 0x0e packet.  
 
Other players acknowlegde a 0x0d with a 0x0e packet.  
  
 
<div id="S0f"></div>
 
<div id="S0f"></div>
=== Type 0F: Cancel SYN 2 ===
+
=== <tt>CANCEL_ACK</tt> (0f): Cancel ACK ===
  
 
Type 0F is sent by the host after receiving all 0x0e packets to confirm the disconnection of the half-connected player.  
 
Type 0F is sent by the host after receiving all 0x0e packets to confirm the disconnection of the half-connected player.  
Line 324: Line 366:
 
<div id="S10"></div>
 
<div id="S10"></div>
  
=== Type 10: Host disconnect? ===
+
=== <tt>SC_CLOSE_CL</tt> (10): Host disconnect? ===
 +
 
 +
Disconnects one or many players. Can contain multiple PIDs after another.
  
 
{| id="T-10" class="textbox grid alt"
 
{| id="T-10" class="textbox grid alt"
Line 331: Line 375:
 
! Offset !! Size !! Endian !! Description
 
! Offset !! Size !! Endian !! Description
 
|-
 
|-
| align=center | 0x00 || align=center | 4 || little
+
| align=center | 0x04 * '''n''' || align=center | 4 || little
| some PID; optional
+
| PID to disconnect
|-
 
| align=center | 0x04 || align=center | 4 || little?
 
| some PID; optional
 
 
|-
 
|-
| align=center | 0x00,0x04,0x08
+
| align=center | 0x04 * '''n+1'''
| colspan=3 {{unknown|End of the packet, 0 or 4 or 8 bytes total.}}
+
| colspan=3 {{unknown|End of the packet.}}
 
|-
 
|-
 
|}
 
|}
Line 346: Line 387:
 
<div id="S52"></div>
 
<div id="S52"></div>
  
=== Type 52: New host request ===
+
=== <tt>SVDOWNQUERY</tt> (52): New host request ===
  
 
This packet is sent by a player when the current host disconnects. The wii which has been in the room for the longest (Dolphin may cause problems and room splits due to its wrong time ...) sends a ST52 record to every other Wii, with the only parameter being the time (minutes? seconds? races?) how long it has already been in the race.  
 
This packet is sent by a player when the current host disconnects. The wii which has been in the room for the longest (Dolphin may cause problems and room splits due to its wrong time ...) sends a ST52 record to every other Wii, with the only parameter being the time (minutes? seconds? races?) how long it has already been in the race.  
  
 
<div id="S53"></div>
 
<div id="S53"></div>
=== Type 53: New host request reply: Maybe ===
+
=== <tt>SVDOWN_ACK</tt> (53): New host request reply: Maybe ===
  
 
When a Wii sends a ST52 request, the other Wiis may respond with ST53 or ST54. Responding with ST53 means "I don't know if you should be the host", and then they receive another ST53 as acknowledgement.  
 
When a Wii sends a ST52 request, the other Wiis may respond with ST53 or ST54. Responding with ST53 means "I don't know if you should be the host", and then they receive another ST53 as acknowledgement.  
Line 358: Line 399:
  
 
<div id="S54"></div>
 
<div id="S54"></div>
=== Type 54: New host request reply: Yes ===
+
=== <tt>SVDOWN_NAK</tt> (54): New host request reply: Yes ===
  
 
When a Wii sends a ST52 request, the other Wiis may respond with ST53 or ST54. Responding with ST54 means "Yes, you are now the new host, I don't know any better candidate".  
 
When a Wii sends a ST52 request, the other Wiis may respond with ST53 or ST54. Responding with ST54 means "Yes, you are now the new host, I don't know any better candidate".  
Line 365: Line 406:
  
 
<div id="S55"></div>
 
<div id="S55"></div>
=== Type 55: I am the new host ===
+
=== <tt>SVDOWN_KEEP</tt> (55): I am the new host ===
  
 
ST55 is sent by the new host to every Wii which answered the host request with ST53.  
 
ST55 is sent by the new host to every Wii which answered the host request with ST53.  
  
 
<div id="S82"></div>
 
<div id="S82"></div>
=== Type 82: SUSPEND flag control ===
+
=== <tt>SUSPEND_MATCH</tt> (82): SUSPEND flag control ===
  
 
This status types are being used by the players to control and coordinate the SUSPEND status of the current room. The guests tell the host the status they want the room to be in, and the host tells the guests what status he is going to set the room to.  
 
This status types are being used by the players to control and coordinate the SUSPEND status of the current room. The guests tell the host the status they want the room to be in, and the host tells the guests what status he is going to set the room to.  
Line 641: Line 682:
 
</pre>
 
</pre>
  
<br/>
+
{{Network Protocol}}
{{MKWii Network Protocol}}
+
[[Category:Network Protocol|S]]
[[category: Network Protocol|S]]
 

Latest revision as of 19:42, 29 April 2023

Overview

This article describes the record type STATUS of the Network Protocol.

The status packages are from one client to another in 3 different ways:

  • Direct client to client communication
  • Client to Server MS to Server MASTER to client communication. Server MASTER itself prefixes the message by a master message of type 06.
  • Client to Server GPCM to client communication using a GPCM90vMAT message. The message header is omitted. This is used for known friends.

The used data structure is identical for all 3 communication ways, only the header is different. The members itself are mainly stored as little endian data.


Basic Message Header

All status records start with a 20 bytes long message header:

The total record length is the length of the header plus extent (20+ELEN). For GPCM90vMAT messages this header is omitted.

Naming

knocker
A player who wants to enter a room.
(room) player
A player of a room.
host
The host of a room. Exact one room player is host, all others are guests.
guest
All room players except the host.

Protocol

New Player enters room

When a new player enters a room, he connects to all players, one after another. To do so, either the joining client or a client that is already in the room (that seems to be random) sends a ST-01 (connection request) packet to the other. Then, the other player either answers with a ST-02, the players do NATNEG, connect to eachother, and continue with other players; or he sends a ST-04 (busy), gets a ST-05 as reply, and tries again later.

Traceable public IP

The value "traceable public IP" means the last reachable host on the route to the client. Do a traceroute on publicip and put the farthest reachable host here. This is the behaviour of the official server, but probably it'd be enough to simply put the public IP here.

Message Types

RESERVATION (01): Connection request

This status packet is send from a knocker to each room player, when the knocker will enter the room or group. There are 2 ways to transmit the message:


Status Type 01
Offset Size Endian Description
0x00 4 little DWC_MATCH_TYPE. 0 = anybody, 1 = friend, 2 = SC_SV, 3 = SC_CL
0x04 4 4 bytes Traceable public IPv4 of the sender, byte by byte (similar to big endian).
0x08 4 little Public port of the sender. Always the same value as the public port of the header.
0x0c 4 4 bytes Local IPv4 of the sender, byte by byte (similar to big endian).
0x10 4 little Local port of the sender.
0x14 4 little Unknown. Always 1. CTGP uses the highest byte for custom data.
0x18 4 little Player's Friend. 0 or 1.
0x1c 4 little Number of players at the console (1 or 2)
0x20 4 little Unique identfication number of this status packet (resvCheckValue). The reply of the player (status type 0x02) use the same ID.
0x24 End of the packet, 36 bytes total.

RESV_OK (02): Allow connection

This status packet is send from the room player to the knocker as reply of a type 0x01 message to confirm the entrance of the guest. There are 2 ways to transmit the message:


Status Type 02
Offset Size Endian Description
0x00 4 little Parameter »maxplayers« (not 100% sure) = Number of possible guests. Always 11.
0x04 4 little Client slot index of the sender (zero based, not player count).
0x08 4 little Parameter »dwc_pid«. It is the same as the profile id of the header.
0x0c 4 4 bytes Traceable public IPv4 of the sender, byte by byte (similar to big endian).
0x10 4 little Public port of the sender. Always the same value as the public port of the header.
0x14 4 4 bytes Local IPv4 of the sender, byte by byte (similar to big endian).
0x18 4 little Local port of the sender.
0x1c 4 little Unknown, always 1
0x20 4 little Number of players at the room player's console.
0x24 4 little Parameter »dwc_groupid« (not 100% sure).
0x28 4 little Client slot index of the receiver (zero based, not player count).
0x2c 4 little Client/console count already in the room.
0x30 4 little The identfication number (resvCheckValue) send by the other player (status type 0x01).
0x34 End of the packet, 52 bytes total.

RESV_DENY (03): Room full

This status packet is sent from the room player to the knocker when access is denied.

Status Type 03
Offset Size Endian Description
0x00 4 little Error ID.
0x10 = room is full (but not on suspend) (never seen in-game, but is implemented in the game code)
0x11 = Room has already started playing since you tried joining
0x12 = Room is on suspend.
0x04 End of the packet, 4 bytes total.

RESV_WAIT (04): Busy doing NATNEG

0x04 is sent by a player as answer to 0x01 to deny a join request because the player is busy doing NATNEG.

RESV_CANCEL (05): Abort connection

0x05 is sent by a player to another player to abort an ongoing NATNEG attempt with the target. It is commonly seen as a response to 0x04, but can also be triggered in other circumstances too, for instance, if the player receives a 0x07 packet from the host.

TELL_ADDR (06): Same Network (Skip NATNEG)

This packet contains the local IP of the player. This packet is sent after a received STATUS-02 to skip NATNEG for Wiis that are on the same network as each other.

Status Type 06
Offset Size Endian Description
0x00 4 4-byte Local IP.
0x04 4 little Local port.
0x08 End of the packet, 8 bytes total.

NEW_PID_AID (07): New client

Send by host when there joins a new player.

Status Type 07
Offset Size Endian Description
0x00 4 little PID of new guest
0x04 4 little slot ID of new guest
0x08 End of the packet, 8 bytes total.

CANCEL (0c): Cancels a connection attempt

Sent under special circumstances when aborting a connection attempt. Cancel type/reason is only used for DWC Logs.

Status Type 0C
Offset Size Endian Description
0x00 4 little Cancel type/reason
0x04 End of the packet, 4 bytes total.

CANCEL_SYN (0d): Cancel SYN

This contains a little-endian PID and is sent by the host when a player tried to join, only connected partially, and then disconnected again. He hasn't done a full Natneg, so he can't send a disconnect himself, so the host sends a ST0D packet.

CANCEL_SYN_ACK (0e): Cancel SYN ACK

Other players acknowlegde a 0x0d with a 0x0e packet.

CANCEL_ACK (0f): Cancel ACK

Type 0F is sent by the host after receiving all 0x0e packets to confirm the disconnection of the half-connected player.

SC_CLOSE_CL (10): Host disconnect?

Disconnects one or many players. Can contain multiple PIDs after another.

Status Type 10
Offset Size Endian Description
0x04 * n 4 little PID to disconnect
0x04 * n+1 End of the packet.

Seems to be sent by the host when he disconected joining player(s) because the room doesn't go on suspend.

SVDOWNQUERY (52): New host request

This packet is sent by a player when the current host disconnects. The wii which has been in the room for the longest (Dolphin may cause problems and room splits due to its wrong time ...) sends a ST52 record to every other Wii, with the only parameter being the time (minutes? seconds? races?) how long it has already been in the race.

SVDOWN_ACK (53): New host request reply: Maybe

When a Wii sends a ST52 request, the other Wiis may respond with ST53 or ST54. Responding with ST53 means "I don't know if you should be the host", and then they receive another ST53 as acknowledgement.

The new host then replys with ST55 to tell the Wii that he is now the new host.

SVDOWN_NAK (54): New host request reply: Yes

When a Wii sends a ST52 request, the other Wiis may respond with ST53 or ST54. Responding with ST54 means "Yes, you are now the new host, I don't know any better candidate".

The new host then replys with another ST52 just to acknowledge, which is again acknowledged with a ST53.

SVDOWN_KEEP (55): I am the new host

ST55 is sent by the new host to every Wii which answered the host request with ST53.

SUSPEND_MATCH (82): SUSPEND flag control

This status types are being used by the players to control and coordinate the SUSPEND status of the current room. The guests tell the host the status they want the room to be in, and the host tells the guests what status he is going to set the room to.

Guest requests SUSPEND = 1

This is sent by every guest when he wants to enable SUSPEND

Status Type 82 - request SUSPEND = 1 (16 bytes)
Offset Size Endian Description
0x00 4 little PID of host.
0x04 4 little host flag. 0 for this record type, since this is sent by guests.
0x08 4 little 1, the wanted suspend value
0x0c 4 little Slot of guest
0x10 End of the packet, 16 bytes total.

Host sets SUSPEND = 1

The host has received requests from every client to enable suspend, confirms SUSPEND has been enabled.

Status Type 82 - set SUSPEND = 1 (16 bytes)
Offset Size Endian Description
0x00 4 little PID of host.
0x04 4 little Host flag, 1 as this is sent by the host
0x08 4 little 1, to indicate the wanted SUSPEND value
0x0c 4 little slot usage mask. bit 1 for used slot, bit 0 for empty slot
0x10 End of the packet, 16 bytes total.

Guests request SUSPEND = 0

Guest is ready to disable SUSPEND.

Status Type 82 - request SUSPEND = 0 (16 bytes)
Offset Size Endian Description
0x00 4 little PID of host.
0x04 4 little Host flag - 0, because it's sent by guests
0x08 4 little 0 to indicate the guest wants to turn off SUSPEND
0x0c 4 little Client slot
0x10 End of the packet, 16 bytes total.

Host sets SUSPEND = 0

This is sent by the host to indicate he is turning off suspend.

Status Type 82 - set SUSPEND = 0 (16 bytes)
Offset Size Endian Description
0x00 4 little PID of host.
0x04 4 little Host value, always 1
0x08 4 little 0, the new suspend value
0x0c 4 little slot usage mask. bit 1 for used slot, bit 0 for empty slot
0x10 End of the packet, 16 bytes total.

Client acknowledge

This is just an acknowledge to a client's request, sent by the host.

Status Type 82 - Client acknowledge (8 bytes)
Offset Size Endian Description
0x00 4 little PID of host.
0x04 4 little host flag, so, 1.
0x08 End of the packet, 8 bytes total.


Type 83: Polling

This packet is sent by the host to every other player every 15 seconds. It contains a list of used slots.

Status Type 83
Offset Size Endian Description
0x00 4 little PID of player.
0x04 4 little Slot usage mask (12 bit data, 20 bit padding)
0x08 4 ? unknown ID, changes when new client joins
0x0c End of the packet, 12 bytes total.

Statistics

This is a summary of all status packages of 286 dumps (mostly private room versus races).

----------------------------------
        msg   status
  count type type+size
----------------------------------
   9126 GPCM90 01 24 by-server
    704 STATUS 01 24 by-server

   3669 GPCM90 02 34 by-server
    327 STATUS 02 34 by-server

    195 GPCM90 03 04 by-server
     41 STATUS 03 04 by-server

   4887 GPCM90 04 00 by-server
    376 STATUS 04 00 by-server

   3203 GPCM90 05 00 by-server
    503 STATUS 05 00 by-server

      4 GPCM90 06 08 by-server

   7105 STATUS 07 08 peer-to-peer

   1151 STATUS 0d 04 peer-to-peer

   1191 STATUS 0e 00 peer-to-peer

   1169 STATUS 0f 00 peer-to-peer

      3 GPCM90 10 00 by-server
     13 STATUS 10 00 peer-to-peer
      7 GPCM90 10 04 by-server
     22 STATUS 10 04 peer-to-peer
      1 GPCM90 10 08 by-server
      3 STATUS 10 08 peer-to-peer

    262 STATUS 52 04 peer-to-peer

    436 STATUS 53 00 peer-to-peer

     31 STATUS 54 00 peer-to-peer

     23 STATUS 55 04 peer-to-peer

     13 STATUS 82 08 by-server
  19987 STATUS 82 08 peer-to-peer
     20 STATUS 82 10 by-server
  29343 STATUS 82 10 peer-to-peer

    237 STATUS 83 0c by-server
 320349 STATUS 83 0c peer-to-peer

Old data structures

This is the old data structure in GNU C notation used by mkw-ana from the beginning. It is deprecated and will be removed later.

typedef struct udp_status_t
{
  /*00*/    u32		record_id;	// always 0xbb49cc4d (be)
  /*04*/    u32		unknown_04;	// always 0x5a000000 (be)
  /*08*/    u8		subtype_id;     // indicating the record sub type
  /*09*/    u8		ext_len;	// length of record extension
					//   total_record_len := '0x14 + ext_len'
  /*0a*/    u16		user_id[3];	// unique user id for this session ?
  /*10*/    u32		cid;		// client id:
					//   last 4 bytes of FC in reverse order
  /*14*/

    union
    {
	struct	// send by host, any anouncement?
	{
  /*14*/    u32		obj_cid;	// client id of object
  /*18*/
	} s04;

	struct	// assign slot
		// => exception 'x x 7100 0514' found in 2013-01-24-ct-24h
	{
  /*14*/    u32		obj_cid;	// client id of object
  /*18*/    u8		slot;		// assign slot to 'obj_cid'
  /*19*/    u8		padding_19[3];	// always 0
  /*1c*/
	} s08;

	struct	// send by host, client mask
	{
  /*14*/    u32		copy_of_cid;	// copy of 'cid' above
  /*18*/    u16		slot_mask;	// slot usage mask in little endian
					//   each 1-bit represents one active client
  /*1a*/    u16		unknown_1a;	// always 0
  /*1e*/    u32		unknown_1c;	// any checksum or random token?
  /*20*/
	} s0c;

	struct	// to host, verify assigned slot?
	{
  /*14*/    u32		obj_cid;	// copy of 'cid' above
  /*18*/    u16		unknown_18;	// always 0x0000|0x0100 (be)
  /*1a*/    u16		unknown_1a;	// always 0
  /*1c*/    u16		unknown_1c;	// always 0x0000|0x0100 (be)
  /*1e*/    u16		unknown_1e;	// always 0
  /*20*/    u8		slot;		// assigned slot of 'obj_cid'
					//   or 0x1f or 0xff
  /*21*/    u8		padding_21[3];	// always 0
  /*22*/
	} s10;
    };
}
__attribute__ ((packed)) udp_status_t;