FrozenSand / UrbanTerror4

Official bug tracker for the game Urban Terror 4.x - www.urbanterror.info
77 stars 18 forks source link

Authserver issue - 4.018 and 4.019 #105

Closed barfingskull closed 10 years ago

barfingskull commented 10 years ago

I'm having issues with the authentication server. It happens on both 4.018 and 4.019, I retained a copy of the older version. It started happening right around the time 4.019 was released, on 9/14. I'm running Ubuntu 14.04. Since this happens prior to connecting to any server, it appears to be just with the authentication system. I can connect to servers (although my server list appears to be missing a lot of servers, even after 'Get New'). I always get "No authservers available" (or something to that effect). It worked under 4.018 for the longest time with no issues. Here's the relevant console log:

Hostname: carcass
IP: 127.0.1.1
IP: 192.168.100.9
Started tty console (use +set ttycon 0 to disable)
SDL_SetGammaRamp: success
------ Urban Terror Auth System ------
auth: resolving authserver address 
auth: resolved 
auth: sending authorize request for your key (try 1).
--------------------------------------
auth: sending authorize request for your key (try 2).
auth: sending authorize request for your key (try 3).
auth: the authserver doesn't answer after 3 tries 
auth: please, retry later 
----- CL_Shutdown -----
Closing SDL audio device...
SDL audio device shut down.
RE_Shutdown( 1 )
-----------------------
Shutdown tty console

I've been doing wireshark traces on this. In the above example, no network traffic to 178.33.22.116 was attempted by the client. Only once has the client attempted to send packets to the authserver, and it did get a reply, but the effect was the same, no answer. I also used netcat to verify I could ping the auth server on port 27952 UDP. So it's not a firewall or router issue.

authserver.urbanterror.info is an alias for fs6.urbanterror.info. fs6.urbanterror.info has address 178.33.22.116

I've also tried changing my auth key once. Again, I highly suspect something with client not actually sending anything, and when it does, something that's not correct.

Let me know if any other sort of information would be helpful.

barfingskull commented 10 years ago

As an update, the auth key works fine on my Mac laptop, 4.019. Same network, so no firewall issue. Sadly, it's a laptop and the screen resolutions keep messing up, plus I've never been able to tweak the mouse acceleration on OSX to my liking. It's not really a platform I'd want to play on.

Could it be something in the config, or one of the .pak files? Errant map of some sort - but again, this happens before I load anything else.

barfingskull commented 10 years ago

One more oddity, when I start UrT from the 4.2.019 directory (I chmod'ed the 018 directory 000, to make sure I wasn't using it) the version on the main screen in the lower right hand corner still says 4.2.018...not sure where it gets that info? When I run the updater in that same directory, it says I'm up to date at 4.2.019....

thelionroars commented 10 years ago

If you see 4.2.018 on the main screen then you're not fully updated. The current updater can run into problems. Delete one of the small zpaks from the q3ut4 subfolder, such as zUrT42_009.pk3 and run it again. Alternatively, you can download and copy over the contents of the 18 to 19 update zip from the downloads section.

barfingskull commented 10 years ago

I tried a full clean install, new directory, nothing there except the updater - same problem. HOWEVER, I tried starting with an empty .q3a folder. It works now, and shows 4.2.019 AND lets me auth. So something in .q3a is causing it. I'd really like to have my configs back (and maps, but I can copy those)...so maybe I'll start with q3config.cfg and see if that's the issue....

barfingskull commented 10 years ago

Okay....copied my original q3config.cfg - everything still works so it's not the config. I have to now guess it's some sinister .pk3 sitting in .q3a/q3ut4/ - but I have 366 of those. I'd like to know which one is the problem....so that I can copy over the rest, and if others run into this we can identify the troublemaker. Any ideas on finding the culprit?

barfingskull commented 10 years ago

Also, nothing newer than September 14th in my maps, and I haven't tried to play freeze. However, the aztek map is a little suspicious. Wish I remembered where I got that one....these are my most recent.

-rw-rw-r-- 1 lolz lolz 13652921 Aug 21 21:17 ut4_trug.pk3 -rw-rw-r-- 1 lolz lolz 36904901 Aug 26 17:40 ut4_area3_b4.pk3 -rw-rw-r-- 1 lolz lolz 5665439 Aug 26 21:58 ut4_servicio_beta3.pk3 -rw-rw-r-- 1 lolz lolz 40304106 Aug 28 00:40 ut4_metro_b2.pk3 -rw-rw-r-- 1 lolz lolz 44910174 Aug 28 21:57 ut4_superman2_beta.pk3 -rw-rw-r-- 1 lolz lolz 10074987 Aug 30 00:08 farwest.pk3 -rw-rw-r-- 1 lolz lolz 4006669 Aug 31 01:48 ut4_bleirrilla_a8.pk3 -rw-rw-r-- 1 lolz lolz 1733819 Sep 7 16:19 ut4_treeway.pk3 -rw-rw-r-- 1 lolz lolz 7298182 Sep 12 17:12 ut4_aztek_ruins_v1.pk3

JRandomNoob commented 10 years ago

Yes, ut4_aztek_ruins_v1.pk3 is another of those malicious maps, although as it turns out the QVMs in this one are five days older and result in a different behavior. Delete it and change your auth key, OK?

barfingskull commented 10 years ago

Done, seems to work well now. Odd behavior, though. I suppose it was trying to make itself look like 4.2.018. Anyway, it is cast into the ethereal abyss. I wasn't aware that the client looked at all the .pk3's in the q3ut4 dir....

Thanks all for the help!

-BS