The first 64 bit bug - SOLVED
The first 64 bit bug - SOLVED
There’s that neat server information box at the upper left on the main page. Its name is si2. How does it work?
There’s a PHP script that queries information from the given address in the same way that the game does when doig the “quick refresh”. The server response contains couple dozen bytes of data including the server name, numbe of players and such. The PHP script also queries detailed information about players, such as kills and onlinetime. The general information about the server can be fitted to one UDP packet, which are limited to 1400 bytes, but detailed player information could take more than 1400 bytes and it’d be splitted to multiple packets. This brings up some issues about the UDP protocol and how packets flow through the mysterious ‘net. The packet header must contain information about whether all the data was fitted in one packet or if there are multiple packets.
The server query protocol is described at http://developer.valvesoftware.com/wiki/Server_Queries#Protocol
The 64 bit bug is in the PHP script’s way of handling the packet header information.
This is the code block in file class_serverspy.php. The original code block is written by Daniel Luft, but it’s been used by Tim te Beek in si2. The code is GPL’d, so I’m not breaking the law by fixing it 
The original lines have been commented by #, followed by the fixed lines.
// 4 byte packet header
$header = unpack("Nint", substr($cache, 0, 4));
$packet_type = sprintf("%u", $header['int']);
# if($packet_type == 0xFFFFFFFF)
if($packet_type == sprintf("%u", -1))
{
// single packet
}
# elseif($packet_type == 0xFEFFFFFF)
elseif($packet_type == sprintf("%u", -2))
{
// multi packets
}
You can see that in the code the header information is taken from the full data, stored in $cache, and converted to integer value by unpack(”Nint”, …) where the “N” means “unsigned long (always 32 bit, big endian byte order)” [ http://fi2.php.net/pack ] and the “int” is the index name in the resulting associative array.
The next code line, $packet_type = sprintf(…), unnecessarily converts the integer value to integer value again. The “unnecessary” convert could have something to do when there is no data at all or something.
The following comparisons, if($packet_type == 0xFFFFFFFF), are the bug. On 32 bit system 0xFFFFFFFF is -1. On 64 bit system the value gets coverted to 0xFFFFFFFF00000000, which is something else. Big endian and little endian stuff on top of that and it’s all messed up. Nobody knows what the real value is after that
After both of the comparisons have failed because of the same cause, the PHP script thinks it got false data and stops there.
The fix is to compare against expected “real” value, which has been passed through the same sprintf() function to make sure that the values are in the same comparable format.
