Star Trek: Armada could be played basically via one of the following network means:

1. TCP/IP LAN play,
2. IPX LAN play and
3. WON internet play.

The actual game play is facilitated by DirectPlay connections. The queries for open games are slightly different for the above mentioned types of connection/game set-up. But in essence DirectPlay is always involved. As WON worked differently in terms of how to gain a list of open games, it will not be described here. But for the LAN play options, see below. They all do DirectPlay game queries, giving them the information of where a game is open, and what properties it does have (e.g. game name or map being used).

Basically it is not really relevant, how exactly the TCP/IP connection or the IPX connection is established. The actual contents sent by the game must of course be transported properly to the other peers. But whether it is a native IPX connection or an RFC 1234 IPX server, are details the game will know nothing about. Same goes for TCP via some VPN solution. It is just important to note, that when doing an analysis of network traffic, one must of course keep in mind, that overhead from other protocols (e.g. RFC 1234 UDP headers and IPX headers) is to be excluded from any analysis for DirectPlay game queries.

When receiving the TCP packages, the following socket header is considered to be part of the DirectPlay header by WireShark. Considering that it is not part of the IPX packages, it stands to reason, that this based on a wrong assumption that it is part of the DirectPlay contents. It must be skipped to get to the actual DirectPlay contents.

So in total a length of 20 bytes can be skipped, to get to the DirectPlay contents. The offsets below are all based on the assumption, that this socket header is already stripped from the data.

For the analysis of the game's sent and received data Wireshark was used on a LAN, once with direct TCP/IP packages used and once with an RFC 1234 UDP-IPX-server in-between the peers. This already requires to carefully look at the results. Apparently Wireshark does not know about RFC 1234 wrapped IPX messages. It does recognize the UDP connection and also that there is IPX payload inside of the UDP datagram. But it does not recognize the DirectPlay payload inside the IPX package as such. However, when connecting directly via TCP/IP it does indeed recognize DirectPlay contents for what they are and gives a detailed analysis of the different parts of each DirectPlay package, like headers or what kind of fields and flags are being used.

When looking at the packages sent back and forth between a peer having an open game lobby, and a peer requesting open lobbies via broadcast from everyone else on the same subnet, the contents are fairly the same for TCP/IP and IPX. The network headers are different of course (the IPX header being removed leaves the very same contents, as are present via TCP/IP, while TCP/IP seems to add socket headers before those).

So for the analysis of IPX sent DirectPlay the TCP/IP representation was taken as a base of reference. Headers that have nothing to do with DirectPlay were removed, leaving only the following contents:

The open game query is actually rather short, once headers of TCP or IPX are removed:

Session Flags (Sess.Flags) are a bit field with the following meanings:

The game queries all games, not filtering for anything. The filtering happens on the client side. So the in-game selection field does not control which contents come from the peers having a session opened.

These messages are sent to the broadcast address. For TCP/IP that is 255.255.255.255, for IPX it is ff:ff:ff:ff:ff:ff. Note: In case of the TCP/IP broadcast, the game apparently only uses the primary network card (whose metric is the lowest). Meaning, if you are connected to multiple networks, only on of them is actually considered. If that is some VPN solution's network card, then an actual LAN game cannot be found in this fashion.

The answer to such a request is relatively long, but mostly because the payload needs actual space:

Session Description Flags are a bit field of length 32 bits/4 bytes with the following meaning:

Note: The Session Description Flags like Can Join have nothing to do with the actual Armada information about the match, e.g. whether the game is closed off, or not. Some of that information can be found in the Description 1 block.

Reserved 1 and Description 1 seem to change. The rest is (aside from the obvious GUIDs) static. Description 1 holds at least the following information. The offset values are 0-based in relation to the entire DirectPlay block (first byte has number 0, values only start at 72). The bits are 1 based.