Valid CDkey not reaching ?

(Theimon) #81

Here’s my Evenbalance troubleticket. http://www.evenbalance.com//troubleticket/update_ticket.php?ticketnumber=EB5696000027852&password=cff5a7d7491f88aa1a219e07a843f0
Note how he claims he hasn’t heard of this problem before. All the workarounds they suggest fail. My PB is up to date and I’m thinking it’s not an ISP problem, why is v2.55 still working like a charm? This bug never occured in that version, right?
When I keep trying to get on a server for 10-15 minutes I just get pissed, exit the game and turn on the TV, and I hate TV! (how’s that for pure-fun-online-gaming :?)

(Ragnar_40k) #82

Imho it has to do with the sucky ping/slow servers of evenbalance. Because the auth request cannot be handled in time you get that error. And with the latest update of ET and faster computers the startup time of ET has decreased significantly. Maybe the 2.60 patch also changed the point in time where the auth request is started.

And this problem always happens only on the 1st server I try to connect to. When I connect to another server right after this message everything works fine.

(Sauron|EFG) #83

I captured it in Ethereal, and it looks to me like the ET client starts connecting to the ET server before it gets the DNS response for etguidauth.evenbalance.com.
The fact that the time between DNS request and response is short leads me to believe (pure speculation) that the requests may be delayed for some reason when starting ET, leading to incorrect timeout.

There’s a lot of DNS requests btw:

216.40.250.82 et1.evenbalance.com
216.40.250.82 master1.evenbalance.com
216.240.146.139 master3.evenbalance.com
66.180.170.20 master4.evenbalance.com
192.246.40.80 id2.evenbalance.com
192.246.40.61 pbet1.idsoftware.com
192.246.40.60 etmaster.idsoftware.com
192.246.40.62 etguidauth.evenbalance.com

(SCDS_reyalP) #84

Hmmm, I did the same thing today. It looks like ET normally only talks to the guidauth server when you try to connect.

FWIW, when I used to get this error (I don’t seem to now) it seemed particularly common on a low ping server.

If it is indeed a problem with the DNS lookup of etguidauth taking too long, you could work around this by adding the entries to your hosts file. Of course, if they ever change the IPs (which they already have in the past) you would have to update.

A possible alternative would to force the DNS to get pre cached. Putting ping etguidauth.evenbalance.com in a batch file that starts ET, for example.

(Sauron|EFG) #85

I’ve tried that in the past, but it didn’t help.

I have no idea what the other servers in my previous post are for, but I’ll try adding all of them to the hosts file just to see. :stuck_out_tongue:

(Floris) #86

It does appear on ET 2.55… Not that often, but sometimes …

(Lekdevil.NL) #87

Yes, you are essentially correct in your findings. I captured a similar chain of events some time ago, so the out-of-order sending of the CD key to the ET GUID auth server is most likely at the root of the problem (or close to it). For your information, this is what should be happening if everything occurs in the right order:

[ol]
[li]Player issues a connect command in the client
[/li][li]Client performs DNS lookups for the servers as mentioned above
[/li][li]Client sends its CD key to the ETguid master
[/li][li]Clients sends connect message to the game server (the one you’re trying to connect to)
[/li][li]Game server receives the connect message, gets client’s GUID from the client infostring
[/li][li]Game server sends client’s IP address and GUID to the ETguid master for verification
[/li][li]ETguid master replies with either a GUID OK or GUID unknown message
[/li][li]If OK, the game server wil allow the client to connect; if not, it will send the dreaded “Valid CD Key not reaching…” error message to the client and drops the connection
[/li][li]The game server caches the ETguid master response for three minutes; all reconnects from the same IP address using the same GUID will fail instantly during that time if the ETguid master response was negative
[/li][/ol]
So, if, for whatever reason, the client connects to the game server before is has sent its CD key to the ETguid master, the game server will obviously receive a “unknown GUID” error in return, because the ETguid master did not receive the client’s CD key yet.

I think the slow DNS lookups on the client could be the key. Note that the game server connect process is most likely handled by a different thread (spawned by the client engine) than the whole ET key validation process (which is done by the PB client exclusively), so the problem might also be influenced by synchronisation issues between different threads. Not having access to the source, I must say this is pure speculation, though.

Note also that the problem is cause by a number of separate issues, that by themselves aren’t too problematic. Most natably the three minute caching by the game server causes some seemingly incomprehensible behaviour: when reconnecting, the client gets disconnected with the same error message instantly, but when then connecting to another game server, everything works fine. This can easily be explained if one knows the process steps involved, as I have shown above, but it must be baffling when one does not. Either way, it could be fixed easily, and it should.

(SCDS_reyalP) #88

I’ve tried that in the past, but it didn’t help.

[/quote]
If that doesn’t fix it, it is most likely the actual connection to the guidauth server causing the problem, rather than the DNS lookup.

In this case the work around seems to be to connect ot some server that you don’t want to play on first. Even if you get the guidauth error on that server, by the time you connect to the server you actually want to play on, the GUIDAUTH server should have your info…

I do suggest that everyone who experiences this problem open a support ticket with evenbalance. As lek says, this should be a solvable problem…

(Calzonzin) #89

Here’s a link to put in an ET ticket: http://www.evenbalance.com/troubleticket/new_ticket.php?game=et

(Ragnar_40k) #90

I do this since 14 days, but this solution is, ehm, suboptimal. Sometimes I simply forget to connect to the “wrong” server first.

A “wait 50” command in the autoexec.cfg seemed to help some players. But maybe its not enough and increasing it to 200 or 500 would be better.

(SCDS_reyalP) #91

A “wait 50” command in the autoexec.cfg seemed to help some players. But maybe its not enough and increasing it to 200 or 500 would be better.

My packet sniffing indicated that this won’t make any difference. The game doesn’t try to contact the GUIDAUTH server until it actually goes to connect. So a wait before connect delays both.

(Lekdevil.NL) #92

Indeed. Instead, the following might be a more useful set of commands to put in your autoexec.cfg:


pb_cdkeyver
wait 50

The pb_cdkeyver command sends the CD/ET key to the PB GUID master for verification, but I am not sure the master actually registers it as “in use”, or merely verifies it and returns the result. Needs testing.

(Sauron|EFG) #93

Looks like the Ethereal capture finally got me past first-line tech support; Tony Ray himself promised to take a look at it. :stuck_out_tongue:

(Sauron|EFG) #94

Wednesday 07.13.2005 [2:30PM]

Version 1.160 of the PB Server for ET has been released to our PB Master Servers for auto-update and to our website download page.

Release Notes for PB Server v1.160:

    * cdkey/guid authorization packets are cached for only 5 seconds (down from 3 minutes) to reduce kicking for unknown guids affecting players with slow DNS resolution

:lol:

(Jaquboss) #95

They can help more … but at least something :slight_smile:

(eRRoLfLyNN) #96

:]

(Calzonzin) #97
  • cdkey/guid authorization packets are cached for only 5 seconds (down from 3 minutes) to reduce kicking for unknown guids affecting players with slow DNS resolution

Hehehe! I love it, in other words, PB is saying it’s everyone else’s fault, don’t blame us! (Nevermind the problem never occurred in this magnitude before!). I’m sure they think if it works for them, having authoritative DNS servers that resolve their own domains in 2 ms, why can’t everyone else?

Anyway, it’s great they did this, it is sure to help.

(Sauron|EFG) #98

I see it as confirmation that they (hopefully) know what causes the problem. Time will tell if they intend to actually fix the problem, you shouldn’t assume they won’t. :wink:

(Calzonzin) #99

I have to stop saying stuff about PB, like someone else said, I’m getting more than my money’s worth as it is. I just wish they had a for-pay system that gave better service and quicker anti-cheat updates.

(Vaibhav) #100

[/img]

:angry: :angry: :angry: :angry: :angry: :angry: :angry: :banghead: :banghead: :banghead: :banghead: :banghead: :banghead: :banghead: :banghead: :bash: :bash: :bash: :bash: :bash: :bash: :eek2: :eek2: :eek2: