Description:
When using the library to send multiple say commands (or any command that triggers a server message, type 0x02), the client hangs or times out on the second command. This does not happen with commands that return a CommandResponse (type 0x01), such as version.
According to the BattlEye RCon protocol (see rcon.txt, "Server message packet" section), the client must acknowledge each server message with a specific ACK. If the server does not receive the ACK, it will re-send the message up to 5 times and may disconnect the client. The current library implementation does not handle this correctly, causing the client to get stuck in a loop of repeated server messages and never process new responses.
Minimal Reproducible Example:
import time
from rcon.battleye import Client
if __name__ == "__main__":
with Client("127.0.0.1", 1234, passwd="xxx") as client:
print(client.run('say -1 First message'))
time.sleep(10)
print(client.run('say -1 Second message')) # This message never arrives, client hangs or times out
- The first
say works and the server message is received.
- The second
say never completes, because the client is stuck receiving repeated server messages from the first command (the server never accepts the ACK).
Expected behavior:
- The client should properly acknowledge each server message, allowing subsequent commands to complete.
- The client should not hang or time out after sending multiple say commands in a row.
Refernce:
- See BattlEye RCon protocol spec, "Server message packet" section:
The client has to acknowledge with the following packet: 0x02 | received 1-byte sequence number. The server's BE RCon tries to send a server message packet 5 times for 10 seconds. If the client fails to acknowledge the packet within this time, it will be removed from BE RCon's list of authenticated clients and will no longer be able to issue any commands.
Environment:
Library version: Commit #0bf3ab5
Python version: 3.12.3
Server: DayZ/BattlEye 1.27/1.219
OS: Ubuntu 24.04.2 LTS
Additional context:
- This issue only occurs with server messages (type 0x02), not with command responses (type 0x01).
- All known protocol-compliant ACK formats have been tried (8-byte header, 7-byte header, payload only), and the ACK is sent to the correct address/port, but the server never accepts it.
Please advise on a fix or provide a workaround. Thank you!