Great... GUID reset... AGAIN

Tremulous
1

Well, I replaced my client once with a different executable… does that change your GUID? Because it seems that it sure did! Sorry for pestering everyone again, but can I ask for another reset?

Also, is it possible for my GUID to be less “unstable” as I like to call it? It seems to change with every small action I do.

2

Replacing your client can provide you with a new GUID if you didn’t have one previously. It should not be changing or “unstable” after that

3

i guess it’s possible if the 2 executables use different directories for configuration files (ie., maybe: the tjw client uses the current directory (eg. C:\Tremulous\qkey), while the TremFusion client uses a user-specific path (eg. C:\Users\NIGGERFACE\AppData\Tremulous\qkey)1); otherwise no GUID-change should happen. to test this, find all files named qkey on ur computer — r there multiple ? if yes, then replace all of them with one, the one which has worked before (check each).

no, such „instability” is expected if each client attempts to force its own behavior. also note that the GUID depends on the client’s cl_guidServerUniq setting, which should be 1 for security reasons, and on the server (eg. GrangerPub ≠ GrangerClub).

1 do not assume any precision in these concrete values/statements.

4 Likes
4

Yep, I think I once messed around with cl_guidserveruniq before once, by accident… what does it do?

5
  • cl_guidServerUniq = 0: calculate GUID from only the qkey.
    • PROBLEM: with this setting, ur GUID will be the same on all servers, so server1 can read ur GUID (when u connect to it) and impersonate u on server2 using this GUID, and vice versa.
  • cl_guidServerUniq = 1: calculate GUID from the qkey and IP address and port of the server to which the client connects.
    • PROBLEM: if the server changes its IP address, then u, as well as everyone else with this setting, will lose ur/his/her registration on that server.

the 2nd PROBLEM can often be controlled by the server operator, so is less of a PROBLEM than the 1st one. as such, in proper clients (such do not exist curretly), cl_guidServerUniq should be forced to 1; in almost-proper clients, cl_guidServerUniq should default to 1 (AFAIK, this is the case in all clients that support automatic setting of GUIDs).

2 Likes
6

There is another situation that can result in your GUID being different on some different clients.

For now, your GUID can also be different when connecting to a multiprotocol server using clients that use different protocols, Since at the moment, based on how the master server at master.tremulous.net currently works, three different ports are utilized for the three different Tremulous protocols (protocol 69 for 1.1, protocol 70 for gpp, and protocol 71 for the latest). As DevHC indicated, unique GUIDs are calculated from a combination of the qkey, the game server’s ip address, and the game server’s port.

In other words,using the same qkey file for a 1.1, for a gpp client, and for a newer client may result in different GUIDs on the same game server when connecting via the clients’ server browsers.

A solution to most of the problems mentioned about GUIDs and qkeys in this topic can be achieved through the implementation of RSA key authentication as an alternative, which is a feature that is in the works for the new 1.3 servers/clients. However, GUIDs/qkeys would still be used in the case of old clients connecting to 1.3 servers, and 1.3 clients connecting to old servers.

1 Like
7

ind33d, multi-protocol servers (currently: test7341, GrangerPub and GrangerClub) behave somewhat specially when u switch from a protocol-69 client to a protocol-70 client (or vice versa):

  • a single-protocol server supports only 1 protocol. as a consequence, u will see a wholly different set of single-protocol servers, to which u r able to connect. u won’t be able to play on the previous single-protocol servers.
  • multi-protocol servers support all protocols. u will still see the same set of multi-protocol servers.

a multi-protocol server achieves this possibility by exposing itself as 3 servers, supporting protocols 69, 70 and 71, respectively; and the 3 servers r „synchronized”. by this, the GUID business is handled naturally on a multi-protocol server: u will have different1 GUIDs, depending on what protocol ur client is using. however, when u switch from using one protocol to another, ur previous GUID’s registration on the server isn’t lost, and there is no resetting to be done on ur part: a high-level server admin should2 just register ur new GUID, keeping the registration for the previous protocol, in case u decide to switch back later.

1 if using the recommended GUID-related settings
2 i’d do it myself, but some DICKBUTTs r in my way of helping u, @Cheese.