The purpose of the handshake is to determine the version of the protocol to be used. The handshake packets do not contain a packet type because their required order make it redundant.
Individual protocols will indicate what versions are available. Versions are zero-centered in the packets, so version 1 of a protocol will be negotiated with a byte value of 0.
Valid version numbers are 1 through 128, consequently the high bit of the version byte is unused for versioning. It is used, instead, to indicate the need for authentication. If the high bit is set, then the authentication phase is required.
On a sign controller, authentication will be waved for all connections coming in on the loopback network device, and required for all other connections. (This means that connections coming in via the multiplexer, which performs its own authentication, will not need to re-authenticate.)
The handshake packets are, in order:
Byte Count | Data Type | Value | Description |
1 | unsigned byte | The lower 7 bits represent the maximum version of the protocol which is supported, minus one. The high bit indicates that the authentication is required (set == authentication required). |
Byte Count | Data Type | Value | Description |
1 | unsigned byte | The version of the protocol to be used, minus one. This must be <= the maximum supported version sent by the Information Daemon. If the Information Daemon cannot support a version great enough, the client should simply drop the connection and report an error. |
If the Server → Client handshake packet indicates that authentication is required, the handshake is immediately followed by the authentication phase. In this case, no packets are permitted until the authentication is complete (and successful).
If the Server → Client handshake packet indicates that authentication is not required, then the authentication phase is skipped and the protocol should be considered already in an authenticated state.
Authentication is challenge-response based. The server first sends a challenge, followed by the client sending it's response, and the server returning the new status (good, or authentication rejected).
Like with the handshake, since the packets and their order are mandatory, there are no packet IDs for authentication packets.
Byte Count | Data Type | Value | Description |
1 | byte | challenge_len | The number of bytes in the challenge (may be any number in the range 8-64). |
challenge_len | byte | challenge — The challenge bytes. |
Byte Count | Data Type | Value | Description |
16 | byte | MD5(secret + challenge) |
Byte Count | Data Type | Value | Description | ||||||||
1 | unsigned byte | Result:
|
If the server reports any result but success, the server will then immediately sever the connection.