Collected some informations:

Final Error on Crash:

Code:
10:Le pape Love War EXE_TIMEDOUT
Client 990 connecting with 100 challenge ping from 94.69.14.205:26662
94.69.14.205:26662:reconnect
Going from CS_FREE to CS_CONNECTED for  (num 13 guid 1217107)
SV_ReadPackets: fixing up a translated port
WARNING: bad command byte 7 for client 13
WARNING: bad command byte 6 for client 13
SV_ReadPackets: fixing up a translated port
SV_ReadPackets: fixing up a translated port
WARNING: bad command byte 4 for client 13
cmdCount < 1
WARNING: bad command byte 4 for client 13
./server.sh: line 37:  2228 Segmentation fault      $cod2 $args



Example-code from Enemy Territory (look at end):

Code:
/*
===================
SV_ExecuteClientMessage

Parse a client packet
===================
*/
void SV_ExecuteClientMessage( client_t *cl, msg_t *msg ) {
    int c;
    int serverId;

    MSG_Bitstream( msg );

    serverId = MSG_ReadLong( msg );
    cl->messageAcknowledge = MSG_ReadLong( msg );

    if ( cl->messageAcknowledge < 0 ) {
        // usually only hackers create messages like this
        // it is more annoying for them to let them hanging
#ifndef NDEBUG
        SV_DropClient( cl, "DEBUG: illegible client message" );
#endif
        return;
    }

    cl->reliableAcknowledge = MSG_ReadLong( msg );

    // NOTE: when the client message is fux0red the acknowledgement numbers
    // can be out of range, this could cause the server to send thousands of server
    // commands which the server thinks are not yet acknowledged in SV_UpdateServerCommandsToClient
    if ( cl->reliableAcknowledge < cl->reliableSequence - MAX_RELIABLE_COMMANDS ) {
        // usually only hackers create messages like this
        // it is more annoying for them to let them hanging
#ifndef NDEBUG
        SV_DropClient( cl, "DEBUG: illegible client message" );
#endif
        cl->reliableAcknowledge = cl->reliableSequence;
        return;
    }
    // if this is a usercmd from a previous gamestate,
    // ignore it or retransmit the current gamestate
    //
    // if the client was downloading, let it stay at whatever serverId and
    // gamestate it was at.  This allows it to keep downloading even when
    // the gamestate changes.  After the download is finished, we'll
    // notice and send it a new game state
    //
    // show_bug.cgi?id=536
    // don't drop as long as previous command was a nextdl, after a dl is done, downloadName is set back to ""
    // but we still need to read the next message to move to next download or send gamestate
    // I don't like this hack though, it must have been working fine at some point, suspecting the fix is somewhere else
    if ( serverId != sv.serverId && !*cl->downloadName && !strstr( cl->lastClientCommandString, "nextdl" ) ) {
        if ( serverId >= sv.restartedServerId && serverId < sv.serverId ) { // TTimo - use a comparison here to catch multiple map_restart
            // they just haven't caught the map_restart yet
            Com_DPrintf( "%s : ignoring pre map_restart / outdated client message\n", cl->name );
            return;
        }
        // if we can tell that the client has dropped the last
        // gamestate we sent them, resend it
        if ( cl->messageAcknowledge > cl->gamestateMessageNum ) {
            Com_DPrintf( "%s : dropped gamestate, resending\n", cl->name );
            SV_SendClientGameState( cl );
        }

        // read optional clientCommand strings
        do {
            c = MSG_ReadByte( msg );
            if ( c == clc_EOF ) {
                break;
            }
            if ( c != clc_clientCommand ) {
                break;
            }
            if ( !SV_ClientCommand( cl, msg, qtrue ) ) {
                return; // we couldn't execute it because of the flood protection
            }
            if ( cl->state == CS_ZOMBIE ) {
                return; // disconnect command
            }
        } while ( 1 );

        return;
    }

    // read optional clientCommand strings
    do {
        c = MSG_ReadByte( msg );
        if ( c == clc_EOF ) {
            break;
        }
        if ( c != clc_clientCommand ) {
            break;
        }
        if ( !SV_ClientCommand( cl, msg, qfalse ) ) {
            return; // we couldn't execute it because of the flood protection
        }
        if ( cl->state == CS_ZOMBIE ) {
            return; // disconnect command
        }
    } while ( 1 );

    // read the usercmd_t
    if ( c == clc_move ) {
        SV_UserMove( cl, msg, qtrue );
        c = MSG_ReadByte( msg );
    } else if ( c == clc_moveNoDelta ) {
        SV_UserMove( cl, msg, qfalse );
        c = MSG_ReadByte( msg );
    }

    if ( c != clc_EOF ) {
        Com_Printf( "WARNING: bad command byte for client %i\n", cl - svs.clients );
    }

    SV_ParseBinaryMessage( cl, msg );

//    if ( msg->readcount != msg->cursize ) {
//        Com_Printf( "WARNING: Junk at end of packet for client %i\n", cl - svs.clients );
//    }
}
The actual Code:

Code:
    if ( c != clc_EOF ) {
        Com_Printf( "WARNING: bad command byte for client %i\n", cl - svs.clients );
    }

    SV_ParseBinaryMessage( cl, msg );
So its saying bad-command-byte but its still parsing the message. Maybe a forgotten return; in the if. That should disconnect the user and prevents further harm.

Also strange in the crash:

Code:
SV_ReadPackets: fixing up a translated port
That looks like a dynamic port-change of the client. Maybe the router of the greece guy is messing ports up? That could confuse the server and ends up in the segmentation fault.



BTW, there are two Bad-Command-Byte errors: one is just happening on a player (cant connect, needs to retry) and the other one is happening on the server (ends up in a crash).