MantisBT - Soldat Dedicated Server
View Issue Details
0000061Soldat Dedicated ServerAdmin-Client Protocolpublic2011-09-21 17:082015-04-13 02:42
0000061: Ambiguous admin protocol with REFRESH packet
When 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.
No tags attached.
Issue History
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

2011-12-21 10:41   
Is there an easy way to reproduce this bug?
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.
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)
2015-04-13 02:42   
Thanks ChrisGBK.
It should be fixed now ;)