MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
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 
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.
TagsNo tags attached.
John
Attached Files

- Relationships

-  Notes
(0001279)
Shoozza (administrator)
2011-12-21 10:41

Is there an easy way to reproduce this bug?
(0001282)
Quantifier (reporter)
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 (reporter)
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 (administrator)
2015-04-13 02:42

Thanks ChrisGBK.
It should be fixed now ;)

- Issue History
Date Modified Username Field Change
2011-09-21 17:08 Quantifier New Issue
2011-12-21 10:41 Shoozza Note Added: 0001279
2011-12-21 10:41 Shoozza Status new => feedback
2011-12-21 11:10 Quantifier Note Added: 0001282
2011-12-21 11:10 Quantifier Status feedback => new
2012-02-16 12:22 Shoozza Status new => acknowledged
2012-12-01 22:44 Falcon Category General => Admin-Client Protocol
2015-04-11 06:27 chrisgbk Note Added: 0002392
2015-04-13 02:42 Shoozza Note Added: 0002393
2015-04-13 02:42 Shoozza Status acknowledged => resolved
2015-04-13 02:42 Shoozza Fixed in Version => 2.7.9
2015-04-13 02:42 Shoozza Resolution open => fixed
2015-04-13 02:42 Shoozza Assigned To => Shoozza


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker