MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001457Zandronum[All Projects] Suggestionpublic2013-08-10 18:082018-09-30 21:33
ReporterDusk 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.1.1 
Target VersionFixed in Version1.2 
Summary0001457: Extended diagnostics for level auth failures
Description
Quote

[19:54:41] <Dusk> speaking of which Torr_Samaho i've wondered would it be possible to let the server try provide diagnostics for the level auth errors
[19:54:52] <Dusk> from what i can tell it can get very frustrating
[19:55:15] <edward-san> it doesn't tell which wads are conflicting...
[19:55:21] <Dusk> exactly
[19:55:26] <Torr_Samaho> Because it doesn't know.
[19:55:29] <Dusk> yeah
[19:55:50] <edward-san> what? can't the server send the checksum to client?
[19:55:50] <Torr_Samaho> If it's actually a map related problem, the error message could be a bit more informative.
[19:55:57] <Dusk> edward-san, the checksum wouldn't help
[19:56:16] <Dusk> but yea i wondered that if the level auth fails, the client could send in md5sums of each separate wads and the server could tell which one doesn't match
[19:56:32] <Torr_Samaho> The non-map related check only checks a single checksum encoding all protected lumps.
[19:56:36] <edward-san> no I was thinking about the contrary
[19:56:42] <Dusk> although the server puts the client on a throttle immediately after this error
[19:56:45] <edward-san> the server SHOULD send it to client
[19:57:00] <edward-san> agh
[19:57:07] <Torr_Samaho> We could surely extend the system.
[19:57:14] <Dusk> hmm or what if the server could send the combined md5sum to the client
[19:57:22] <Dusk> and let the client do the diagnostics
[19:57:52] <Dusk> "combined md5sum" = md5sums of each wad loaded
[19:57:55] <Torr_Samaho> It think it may be the easiest if the server sends the md5 of each loaded wad to the client separetely.
[19:58:03] <Dusk> yeah that's what i meant
[19:58:31] <Torr_Samaho> Let me have a look. This shouldn't be that hard to implement.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0001517closed  improving outlook of network errors 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-08-10 18:08DuskNew Issue
2013-08-10 18:08DuskStatusnew => assigned
2013-08-10 18:08DuskAssigned To => Torr Samaho
2013-08-10 18:34Torr SamahoNote Added: 0006981
2013-08-10 19:28Torr SamahoNote Added: 0006984
2013-08-10 19:28Torr SamahoStatusassigned => needs testing
2013-08-11 08:16ZzZomboNote Added: 0006989
2013-08-11 08:34Torr SamahoNote Added: 0006991
2013-08-13 15:56ArcoNote Added: 0007009
2013-08-13 22:35QentNote Added: 0007015
2013-08-16 20:30DuskNote Added: 0007032
2013-08-16 20:31DuskNote Edited: 0007032bug_revision_view_page.php?bugnote_id=7032#r3946
2013-08-16 20:31DuskNote Edited: 0007032bug_revision_view_page.php?bugnote_id=7032#r3947
2013-10-08 01:53ArcoRelationship addedrelated to 0001517
2013-10-08 01:55ArcoStatusneeds testing => resolved
2013-10-08 01:55ArcoFixed in Version => 1.2
2013-10-08 01:55ArcoResolutionopen => fixed
2018-09-30 21:33Blzut3Statusresolved => closed

Notes
(0006981)
Torr Samaho   
2013-08-10 18:34   
I have a first version up and running:'https://bitbucket.org/Torr_Samaho/zandronum/commits/c871012fee8108141f146eed93e5fadabad8d67b [^]'
(0006984)
Torr Samaho   
2013-08-10 19:28   
Here is a binary for testing.
(0006989)
ZzZombo   
2013-08-11 08:16   
Wouldn't the server sends the correct checksums approach be exploitable by a malicious client so it just reconnects but with the checksums send instead of its own?
(0006991)
Torr Samaho   
2013-08-11 08:34   
This is not meant to prevent malicious clients from joining, but to help players figure out why their authentication failed. The server doesn't reveal any secret information. You can obtain the information the server sends now, by simply downloading the proper wads and calculate the md5 hashes.
(0007009)
Arco   
2013-08-13 15:56   
Works perfectly.
(0007015)
Qent   
2013-08-13 22:35   
Why does the server give a hash of the file that failed, but not the lump that failed? Since the file hashes are allowed to be different, I think that the lump hashes could be given for completeness, unless it would mean spamming the console with every single failed lump.

As the "wads" CCMD in this build is nice enough also to give you the PWADs' hashes, could it give the IWAD's hash as well? Maybe even match it to a version number if it's a hash that is recognized. (Is that worth a new ticket?)
(0007032)
Dusk   
2013-08-16 20:30   
(edited on: 2013-08-16 20:31)
The server doesn't know what lumps failed, it just tells the client its own hashes. Passing all the hashes of every single protected lump would be... quite overkill as far as bandwidth goes. Especially since there can be an arbitrary amount of PWADs.

The point about the IWAD hash is valid IMO though. Sometimes I've seen that outdated IWADs have caused level auth problems for users.

I wonder could the client then match the hashes based on filenames and color-code the result?