No output captured and returned when sending commands to Arma Reforger

[Jakerino]

I could definitely be doing something wrong - but I get no error - and a return of

OK

If I use bercon.exe It works fine - but I need this on linux to integrate with a discord bot - so it's important I can get the player data returned for this project. Feel free to close out if you don't have time etc to look into this - but I just wanted to take a shot in the dark here. Thanks!

[WoozyMasta]

Because the response format was changed in Arma Reforger, BattlEye responds to all 0x01 (Command packet) commands with 0x00 as an empty response, and the real response lines come later (without guarantee and expected timeframes) as separate messages in 0x02 (Server message packet)

The utility was designed as a simple automation application, just execute commands and finish the job, I did not plan to make an interactive CLI.

I think I could add the output of all Server message packet, but I don't know how long to wait for a response, because it is not guaranteed now. I will think about the solution, maybe I will add an interactive mode, or maybe I will come up with something better.

[Jakerino]

I appreciate the response and explanation - I've got a bash script sftp-ing my console log - determining whos still connected to the server based on lack of disconnect log entry - and then writing to my discord server the players that are online. So I've overcome the need to an extent. Now I just the BI or BE to re-add the init command to force the server to refresh its config file on restart.

Thanks again!

[WoozyMasta]

@Jakerino, if you are only interested in the number of players on the server without specifying the player name and uuid, the A2S protocol may be more suitable for you

For example, using this tool https://github.com/WoozyMasta/a2s you can make a request A2S_INFO and get information for the server browser.

a2s-cli info 127.0.0.1:17777

Property        Value
==================================================
Query type:     Source
Protocol:       0
Server name:    Woozy Test
Map on server:  #AR-Campaign_ScenarioName_Everon
Game folder:
Game name:      Arma Reforger
Steam AppID:    0
Players/Slots:  1/64
Bots count:     0
Server type:    Dedicated
Server OS:      Linux
Need password:  false
VAC protected:  false
Game version:   1.3.0.130
Port:           28997
Server ping:    0 ms
==================================================
A2S_INFO response for 127.0.0.1:17777

And for programmatic processing use json data output

a2s-cli info 127.0.0.1:17777 -j | jq -er .players

[Jakerino]

Unfortunately I am interested in the full details - But I really like the way it turned out

even if it is over engineered - it works really well for what I need it for.

Thank you though!!

[marwanbd83487]

@WoozyMasta

Hi WoozyMasta,

First off, thanks for creating bercon-cli! im trying to use it (from source, latest master branch commit as of ~Apr 26, 2025, on Windows) to interact with an Arma Reforger game server via BattlEye RCON.

it seems sending commands that are expected to return potentially large lists, specifically players and #ban list (note: #bans list resulted in "unknown command" in packet captures), bercon-cli only outputs "OK" or the initial "Logged In!" message, rather than the full list content. Other simple commands seem to work correctly.

Steps to Reproduce:

1. Compile bercon-cli from the latest source.
2. Run commands against an Arma Reforger server (replace connection details):

   ./cli.exe -i <IP> -p <PORT> -P <PASS> -- players
   ./cli.exe -i <IP> -p <PORT> -P <PASS> -- "#ban list" 

Expected Behavior:

The tool should output the complete player list or ban list as returned by the server. (We've confirmed the official BattlEye RCON client retrieves these lists successfully from the same server).

Actual Behavior:

The tool outputs only:

OK

or sometimes (after adding debugging):

Logged In! Client ID: #X

ive compared the official BattlEye RCON Protocol Specification (BERConProtocol.txt), a third-party technical reference based on reverse-engineering (Rentry Technical Reference), and packet captures (packets2.txt, via Wireshark) from connecting to the Arma Reforger server with the official BE Rcon client. We also added extensive logging to bercon-cli's pkg/bercon/connection.go.

Key Findings:

1. Response Packet Type Discrepancy:
   • The official BERConProtocol.txt states command responses are Type 0x01.
   • The Rentry Technical Reference (matching our packet captures) states command responses are actually Type 0x02 (Server Message).
2. Arma Reforger Behavior (Capture Analysis & Rentry Confirmation): For commands like #players and #ban list, the Arma Reforger server behavior aligns with the Rentry document regarding the type but adds complexity with sequence numbers:
   • It acknowledges the initial Type 0x01 command packet (e.g., Seq N) with an empty Type 0x01 packet (Seq N), as expected by the official spec.
   • However, it then sends the actual response data (including initial "Processing..." messages and the list content) as a sequence of Type 0x02 (Server Message) packets, as described in the Rentry document.
   • Crucially, our captures show these subsequent Type 0x02 packets use new, incrementing sequence numbers (e.g., Seq N+1, Seq N+2, Seq N+3...), not the original command sequence number N. This specific incrementing sequence number behavior for response parts doesn't seem explicitly detailed in either reference document.
   • Each of these Type 0x02 packets requires a specific Type 0x02 ACK from the client using the received sequence number (N+1, N+2, etc.) before the server sends the next packet (confirmed by both protocol docs and captures).
   • Neither the Type 0x01-style multi-part header (from official spec) nor the Type 0x02-style multi-part header (00 | num_packets | index, from Rentry doc) were observed in our Arma Reforger packet captures for these responses.
3. bercon-cli Handling:
   • bercon-cli appears designed expecting command responses primarily as Type 0x01 (per the official spec), potentially handling multi-part 0x01 responses using the original sequence number (N).
   • Our debugging logs confirm that bercon-cli receives and correctly ACKs the subsequent Type 0x02 packets (Seq N+1, N+2, etc.) from the server.
   • However, because these packets are Type 0x02 and have different sequence numbers than the original command (N), the current logic in startListening (even with our modifications attempting to route Type 0x02 based on an expectingResponse flag) fails to associate them back to the response being awaited by getResponse(N). They are treated as unrelated broadcast messages instead of being appended to the buffer for sequence N.

To handle this specific Arma Reforger RCON behavior (Type 0x02 responses with incrementing sequence numbers), bercon-cli's connection logic likely needs to manage state differently. When a command is sent with sequence N, the client needs to:

1. Receive the initial acknowledgment packet(s) with sequence N.
2. Enter a state where it anticipates subsequent Type 0x02 packets (potentially starting with Seq N+1) belonging to the response for command N.
3. Correctly ACK each incoming Type 0x02 packet using its own sequence number.
4. Buffer the data from all related Type 0x02 packets (Seq N+1, N+2...) and associate them back with the original command N.
5. Reliably determine when the complete sequence of Type 0x02 packets for the response has ended (since the multi-part headers seem unreliable/unused here, perhaps using a configurable short timeout after the last received packet is the most practical approach, or maybe parsing response content for known terminators like "(X players in total)").
6. Return the fully assembled response data associated with the original command N.

This requires a more complex state management mechanism to correlate responses across different packet types and incrementing sequence numbers.

i'd appreciate it if you could look into supporting this multi-sequence Type 0x02 response pattern apparently used by Arma Reforger. i can provide detailed logs from our modified client or the relevant sections of the packet capture if needed.

Thanks again for your work on this tool!

you may find this useful
https://rentry.co/q6cgv5gf
https://rentry.co/8i5yoere

[WoozyMasta]

@marwanbd83487 Thank you for such a detailed breakdown! Yes, this is exactly the issue I noticed when looking into this earlier. You’ve very accurately described the discrepancies between the official specification and the actual behavior of Arma Reforger.

You’re absolutely right. I originally implemented the client strictly following the official BattlEye specification, which assumes responses come in type 0x01 packets with the same sequence number. However, in Reforger, BI has deviated from this standard for some reason and instead uses a stream of 0x02packets with new sequence numbers

Your point about delivery guarantees is also spot on. The main challenges are:

1. Detecting whether we’re dealing with Reforger (or another server with similar behavior)
2. Reliably assembling a response from scattered 0x02packets
3. Doing this without breaking compatibility with other games

Currently, the code already has the Connection.Messages channel, where all such packets end up. The quickest solution would be to implement an interactive mode that simply outputs all messages sequentially. However, for automation, we need something more structured.

I think the right approach would be:

1. Add a special flag (e.g., --events-response)
2. When enabled, the client would:
   • Send the command as usual
   • Collect all subsequent 0x02 messages for N seconds
   • Return them as part of the response

For JSON (since we can't guarantee precise serialization in a stream of events), we could structure it like this:

{
  "initial_response": "OK",
  "messages": ["msg1", "msg2"]
}

It’s a shame BI moved away from the standard, the original protocol was much more automation-friendly. But since that’s how it is now, we’ll have to adapt.

I can’t commit to a specific timeline yet, but I’ll definitely revisit this improvement when time allows. Thanks again for such a thorough analysis, it’ll be a huge help during implementation!

[WoozyMasta]

About the original client: It works precisely because it’s minimal—it just dumps all messages in real-time as raw text. Its simplicity is its strength for interactive use.

Meanwhile, I’m tackling the opposite problem: building a one-shot CLI for automation that:

• Executes a single command
• Captures and structures the response
• Returns everything in parseable JSON

Trade-offs, trade-offs…

[marwanbd83487]

About the original client: It works precisely because it’s minimal—it just dumps all messages in real-time as raw text. Its simplicity is its strength for interactive use.

Meanwhile, I’m tackling the opposite problem: building a one-shot CLI for automation that:

* Executes a single command

* Captures and structures the response

* Returns everything in parseable JSON

Trade-offs, trade-offs…

@WoozyMasta

Hi again!

I recently discovered that Arma Reforger supports two RCON implementations:

1. the Classic BattlEye RCON
2. Reforger's native RCON

use BattlEye CLI RCON client here to test both:
https://www.battleye.com/downloads/
Command reference:
https://www.battleye.com/support/documentation/

---

1. BattlEye RCON

• Location: battleye folder in the server directory
• Config File: BEServer_x64.cfg

Example configuration:

File: battleye/BEServer_x64.cfg

GameID armar
MasterPort 2001
RConPort 7117
RConPassword 1522853

---

2. Reforger Built-in RCON

• Location: Server configuration file (typically config.json or server.json)

Example configuration:

{
  "rcon": {
    "enabled": true,
    "bindAddress": "0.0.0.0",
    "port": 25575,
    "password": "your_secure_password"
  }
}

---

Useful links:

• https://community.bistudio.com/wiki/Arma_Reforger:Server_Config#rcon_2
• https://community.bistudio.com/wiki/Arma_Reforger:Server_Management

---

Notes:

• Both RCON protocols can be used simultaneously.
• They differ in command sets, response output, and overall behavior