MantisBT - Soldat Dedicated Server
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000061Soldat Dedicated ServerAdmin-Client Protocolpublic2011-09-21 17:082015-04-13 02:42
ReporterQuantifier 
Assigned ToShoozza 
PriorityurgentSeveritymajorReproducibilityrandom
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version2.7.0 
Target VersionFixed in Version2.7.9 
John
Summary0000061: Ambiguous admin protocol with REFRESH packet
DescriptionWhen admin client sends raw command REFRESHX, the server responds with line "REFRESHX\r\n", then 1992 octets of binary data.

Sometimes, the binary data does not immediately follow, when by race condition server sends a different line. Actual data is then misaligned with what admin client has read.

Trailer of the packet is then read in line mode, possibly causing client to not recognize next "REFRESHX\r\n" line.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-09-21 17:08QuantifierNew Issue
2011-12-21 10:41ShoozzaNote Added: 0001279
2011-12-21 10:41ShoozzaStatusnew => feedback
2011-12-21 11:10QuantifierNote Added: 0001282
2011-12-21 11:10QuantifierStatusfeedback => new
2012-02-16 12:22ShoozzaStatusnew => acknowledged
2012-12-01 22:44FalconCategoryGeneral => Admin-Client Protocol
2015-04-11 06:27chrisgbkNote Added: 0002392
2015-04-13 02:42ShoozzaNote Added: 0002393
2015-04-13 02:42ShoozzaStatusacknowledged => resolved
2015-04-13 02:42ShoozzaFixed in Version => 2.7.9
2015-04-13 02:42ShoozzaResolutionopen => fixed
2015-04-13 02:42ShoozzaAssigned To => Shoozza

Notes
(0001279)
Shoozza   
2011-12-21 10:41   
Is there an easy way to reproduce this bug?
(0001282)
Quantifier   
2011-12-21 11:10   
Unfortunately no, you only can create favorable conditions.
Which are server script which produces lots of output, and modified admin client that request REFRESH a dozen or so times a second.
Then just wait.
(0002392)
chrisgbk   
2015-04-11 06:27   
Not sure if this has ever been fixed yet.

This is caused by the server having writeln('REFRESHX'), then a separate line to write the rest of the REFRESHX packet. Under load, due to multithreading, a chat message, script message, or any other notification can slip in between the two calls, resulting in the end of the REFRESHX packet being treated as text. And probably containing a NUL byte that breaks everything.

The easy fix is to move the 'REFRESHX' string, with appropriate line endings, into the start of the REFRESHX record itself, so when the record gets sent it happens all at once (or alternatively create a temporary buffer, write the string to that buffer, copy the record in at the end of the string, then send the buffer at once)
(0002393)
Shoozza   
2015-04-13 02:42   
Thanks ChrisGBK.
It should be fixed now ;)