[dustinandband]

Traced the issue and it seems like this is what's causing my problem (update from post #4)
https://github.com/sbpp/sourcebans-p...Query.php#L260

PHP Code:

if( $Type !== self::S2A_INFO )
{
    throw new InvalidPacketException( 'GetInfo: Packet header mismatch. (0x' . DecHex( $Type ) . ')', InvalidPacketException::PACKET_HEADER_MISMATCH );
} 


Had the exception printed into sourcebans to see what was up

error connecting xPaw\SourceQuery\Exception\InvalidPacketException: GetInfo: Packet header mismatch. (0x41) in /usr/www/survival/public/sourcebans/includes/SourceQuery/SourceQuery.php:260 Stack trace: #0 /usr/www/survival/public/sourcebans/includes/sb-callback.php(1246): xPaw\SourceQuery\SourceQuery->GetInfo() #1 /usr/www/survival/public/sourcebans/includes/xajax.inc.php(1095): ServerHostPlayers('4', 'servers', '', '0', '0', '', '70') #2 /usr/www/survival/public/sourcebans/includes/xajax.inc.php(744): xajax->_callFunction('ServerHostPlaye...', Array) #3 /usr/www/survival/public/sourcebans/index.php(33): xajax->processRequests() #4 {main} (45.63.67.212:27015)

Not sure how to debug that further as byte operations are something a bit beyond my understanding. Any help appreciated

Edit:
Looks like it's expecting 0x49 instead of 0x41:

PHP Code:

$Type = $Buffer->GetByte( );

// Old GoldSource protocol, HLTV still uses it
if( $Type === self::S2A_INFO_OLD && $this->Socket->Engine === self::GOLDSOURCE )
{
    /**
     * If we try to read data again, and we get the result with type S2A_INFO (0x49)
     * That means this server is running dproto,
     * Because it sends answer for both protocols
     */ 


Edit #2

after some research on SourceQuery's 0x41 response:

Servers may respond with the data immediately. However, since this reply is larger than the request, it makes the server vulnerable to a reflection amplification attack. Instead, the server may reply with a challenge to the client using S2C_CHALLENGE ('A' or 0x41). In that case, the client should repeat the request by appending the challenge number. This change was introduced in December 2020 to address the reflection attack vulnerability, and all clients are encouraged to support the new protocol. See this post for more info.

source: https://developer.valvesoftware.com/wiki/Server_queries

Noticed that the last commit to "sourcebans-pp/web/includes/SourceQuery/SourceQuery.php" was in 2018, and the valve forum post was 2020.
So is this an error within sourcebans or something within my server configuration? Other people aren't having the same issue so probably the latter.
Also is there a way to just skip over to byte 0x49?

edit #3

adding this "if" statement into "sourcebans/includes/SourceQuery/SourceQuery.php" fixed the issue. credit . I didn't edit in other stuff from that example (this) but it's a temporary fix anyway until sourcebans officially updates SourceQuery include.

PHP Code:

$this->Socket->Write( self::A2S_INFO, "Source Engine Query\0" );
$Buffer = $this->Socket->Read( );

$Type = $Buffer->GetByte( );

if( $Type === self::S2A_CHALLENGE )
{
    $this->Challenge = $Buffer->Get( 4 );

    $this->Socket->Write( self::A2S_INFO, "Source Engine Query\0" . $this->Challenge );
    $Buffer = $this->Socket->Read( );
    $Type = $Buffer->GetByte( );
}

// Old GoldSource protocol, HLTV still uses it
if( $Type === self::S2A_INFO_OLD && $this->Socket->Engine === self::GOLDSOURCE )
{
    /**
     * If we try to read data again, and we get the result with type S2A_INFO (0x49)
     * That means this server is running dproto,
     * Because it sends answer for both protocols
     */ 


https://github.com/sbpp/sourcebans-pp/issues/734