RCON (Server & Client)

[Mauler125]

This pull request contains:

• Full CNetAdr class rewrite in modern C++ (protocol agnostic)
• Full CSocketCreator rebuild (based on Valve's implementation, but protocol agnostic)
• RCON for server (dedicated only)
• RCON for client
• Non-game net console client to connect to dedicated server without needing any files of the game itself (just the netcon, link MFC static to the netconsole if maximum portability is desired, since then user doesn't need to install vc runtime)

Information regarding using RCON: SERVER:

• The password must be at least 8 characters long (ConVar: rcon_password)
• To disable RCON, simply keep rcon_password empty.
• To send logs to connected net consoles, set sv_rcon_sendlogs to 1, or send a SERVERDATA_REQUEST_SEND_CONSOLE_LOG message
• The RCON server will bind to the same port as the hostport ConVar used by the game for UDP sockets, both IPv4 and IPv6 (dual stack)
• The server will automatically ban IP's of spammers or hackers. It will not kick them out of game, just remove access to server remote access. Game kicking/banning could be implemented if desired.
• It is recommended that the user sets a sv_rcon_whitelist_address, this will never get banned for failed attempts, or get 'cleaned' when max sockets (defined by sv_rcon_maxsockets) gets reached.
• The server will automatically close the listen socket once a net console has successfully authenticated with the server
• The listen socket gets reopened if connection to net console gets closed in any way (for example, when your game crashes or when you issued a disconnect)
• Auto executes rcon_server.cfg on launch. You can put your configs in here.

CLIENT:

• To connect to server, in the console set 'rcon_address' to the address of the RCON server you wish to connect to (default: [127.0.0.1]:37015)
• Then enter command rcon. This will try to establish a connection to address stored in rcon_address ConVar.
• To authenticate with the server: rcon PASS yourRCONpassword321.
• To send commands to server: rcon "your commands here".
• To disconnect from RCON server: rcon_disconnect.
• • Auto executes rcon_client.cfg on launch. You can put your configs in here.

NETCONSOLE:

• Same as CLIENT, but in this case you do not need to use the rcon command prefix to send queries to RCON server.
• Follow instructions in the terminal.

Additional information:

• Port forwarding is required for this to work. Its the same range as the UDP protocol (37015-37020), but it has to be opened for TCP as well (RCON ports are equal to the UDP port of the game, which you could retrieve with the 'status' command or various tools available for Windows).

[wolf109909]

I love this. Thank you Amos :D

[Vexbane]

Thanks for all your hard work Amos!

[abarichello]

Had some problems while testing this, changing convars worked fine but running server scripts gave me this error: Left: dedicated server output | Right: NetConsole

[abarichello]

Inviting others to test/review since there's a lot of code to cover

[Mauler125]

Had some problems while testing this, changing convars worked fine but running server scripts gave me this error: Left: dedicated server output | Right: NetConsole

Hi, I fixed this issue on the latest commit. It should now work properly on commands, setting convars and running scripts

[GeckoEidechse]

As someone with very little Windows dev experience, how do I actually go about building the NetConsole part? ^^

[Mauler125]

As someone with very little Windows dev experience, how do I actually go about building the NetConsole part? ^^

NetConsole gets build among with the rest of the solution. The resulting binary should be 'netcon.exe'.

[GeckoEidechse]

Aight, so there's a lot of desire and need to get this merged so I drafted up a bit of a rough roadmap on what we should still take into consideration for merging:

• [ ] Mention NetConsole in BUILD.md

Build instructions aren't really needed as it just builds as part of Launcher when creating the build in VS. We should however update BUILD.md as part of this PR to include mention of NetConsole.

• [x] Usage instructions for server hosters.

Assuming they have already downloaded the necessary files, what would be the steps they need to perform to get everything setup? Basically a quickstart guide to go from working server -> can RCON into server.

These instructions would then be added to wiki on merge to tell server hosters how to use RCON interface.

• [x] Maybe some way of disabling RCON via cli flag and/or at compile time.

I'm thinking, what happens if we for some reason find critical bug in RCON? We would obviously bump min version on master server to next release that fixes it so that unpatched servers cannot expose themselves to clients via server browser. But what if no one's available to fix the underlying issue. Say you're on holiday for example. If we can disable RCON at compile time we can make a "hotfix" that just disables it until we fix the underlying bug. Ofc, if RCON is not exposed to outside via port-forwarding by hoster, this is not really an issue.

• [ ] Checking CI to not include NetConsole in release files.

This one's for me. Obviously we want to distribute RCON in some pre-compiled fashion but we shouldn't put it in the main release zip as its contents end up in the Titanfall2 folder on players' machines. NetConsole should be kinda separate to avoid cluttering players Titanfall2 folder.

pg mentioned wanting to change the way we build releases where we build inside Launcher and Mods on tagging and in release repo we just pull in the files from those releases on tag. This would help with distributing NetConsole for those that need it as we can just link to Launcher release files.
However it's still gonna be a bit until that happens, so in the meantime I guess we can just chug the pre-compiled exe somewhere, assuming it doesn't change too often.

• [x] Some preliminary testing using this branch with server hosters.

Basically, we make an "RCON release" for server hosters to test it and play around with it to get feedback. We do need the instructions mentioned above for it though.

• [ ] Reviews

I need 1-2 people with decent understanding of the Northstar codebase to review this PR

[Mauler125]

RCON is fully disabled if password length is < 8 characters (user could leave the password ConVar 'rcon_password' empty), there is a boolean that gets tested every frame (CRConServer::m_bInitialized), it gets set by CRConServer::Init() when it has been properly initialized (a password of min 8 chars). No socket will be created and no parts of the RCON system is ran if password length was < 8 and/or m_bInitialized is false. You could still comment 'g_pRConServer->RunFrame()' to compile it out, but the system for disabling it is very simple and will never fail so this isn't necessary.

For distributing 'netcon.exe' and perhaps any other uncommon binaries, I recommend just putting them in the 'bin' folder to reduce clutter (this is what we do in r5reloaded). I also recommend putting the Northstar dll's etc in the bin folder since its irrelevant to the end user. Only the executable is relevant.

The instructions for running RCON is in the commit description, no external files are required. For anyone willing to format it for the wiki, the above should be all you need to get it running.

I updated the commit description to also mention port forwarding is required, its the same as the game's UDP ports, but TCP also needs to be forwarded. The same range (37015-37020) or further if you host more servers.

[laundmo]

The server will automatically ban IP's of spammers or hackers.

Are we sure this behaviour is good? With how often home IPs can change, CGNAT, VPNs etc, IP bans can easily lead to banning the wrong IP.

Would also like some clarification of "automatically" here: how does it detect spammers and hackers? why was automatic spam and hacker detection part of a rcon PR?

[HeatherComputer]

The server will automatically ban IP's of spammers or hackers.

Are we sure this behaviour is good? With how often home IPs can change, CGNAT, VPNs etc, IP bans can easily lead to banning the wrong IP.

Would also like some clarification of "automatically" here: how does it detect spammers and hackers? why was automatic spam and hacker detection part of a rcon PR?

IMO this should be optional, with an option to clear the bans on reboot

[Mauler125]

The server will automatically ban IP's of spammers or hackers.

Are we sure this behaviour is good? With how often home IPs can change, CGNAT, VPNs etc, IP bans can easily lead to banning the wrong IP.

Would also like some clarification of "automatically" here: how does it detect spammers and hackers? why was automatic spam and hacker detection part of a rcon PR?

The system automatically bans the user from remote console access when they entered the wrong password, or ignored the no-auth message too often (which can be controlled by the ConVar's ''sv_rcon_maxfailures" and "sv_rcon_maxignores"), the server owner doesn't need to perform any actions manually to ban a user. You can set those ConVar's to a very high number if you wish to effectively 'disable' it (no netconsole (rcon client) data is remembered upon reboot).

The reason why its part of the PR is that the average person wouldn't have the easy indefinite chance to brute force your >7 character long password, it is also a time waster for anyone trying it. It of course wouldn't stop everyone, but it should be good enough for the time frame of init to closing the listen socket if the owner has a good enough password.

[Mauler125]

The server will automatically ban IP's of spammers or hackers.

Are we sure this behaviour is good? With how often home IPs can change, CGNAT, VPNs etc, IP bans can easily lead to banning the wrong IP. Would also like some clarification of "automatically" here: how does it detect spammers and hackers? why was automatic spam and hacker detection part of a rcon PR?

IMO this should be optional, with an option to clear the bans on reboot

Bans are cleared upon reboot, they are stored in a runtime vector. For disabling, you can set the 'sv_rcon_maxfailures' or 'sv_rcon_maxignores' ConVar's to a very high number, or modify the code to implement a disable feature. I personally see no reason to implement one, since this occurrence is rare, and in case it happens, just restart the server (you are supposed to restart them every 3 hours anyways).

[laundmo]

The system automatically bans the user from remote console access when they entered the wrong password, or ignored the no-auth message too often

Ah, this was a misunderstanding then. In the PR text i understood "spammers and hackers" to mean people spamming ingame chat or using a "hacked" game to gain a unfair advantage. I didn't even think you could mean brute force attacks with that.

[Mauler125]

To clear things up, the system only bans people trying to get in who shouldn't. People that got banned from RCON are not kicked or banned from joining your server's game, they are only banned from remote access. If you wish you could link it up to also kick or ban them from your game server, but that will require work like porting the netchannel stuff we have in r5reloaded.

[Mauler125]

Found a bug in testing where starting a match is not possible on dedicated server from game client. Video: out.mp4

To reproduce:

1. Install Northstar v1.9.0

2. Get CI artifacts and copy `Northstar.dll` and `Northstar.exe` into Titanfall2 folder

3. Set `rcon_password` and `ns_server_password`

4. Start dedicated server via `r2ds.bat`

5. Start Northstar client on same machine

6. Join your own dedicated server via server browser

7. Press "start match"

8. Countdown timer gets stuck

EDIT:

If I set server to launch into game, e.g. by setting +setplaylist ctf +mp_gamemode ctf +map mp_glitch in dedi startup args and then try to join from client, I then error out on client with:

Are the server and client running the same dll (the Northstar.dll obtained from the CI artifacts)? Or is the client running a different (from the main branch with no RCON) dll?

[GeckoEidechse]

Are the server and client running the same dll (the Northstar.dll obtained from the CI artifacts)? Or is the client running a different (from the main branch with no RCON) dll?

Both are running the same dll. I just ran client and server from the same Northstar/Titanfall2 install ^^

[BulletMemes]

Had this bug while testing on a live server of mine, mind you this is running using pg's docker container, could be the culprit but not sure. https://youtu.be/WNU4hS2bFFY

[BulletMemes]

I've also noticed a few seperate things,

1. You can't initiate the RCON request without having a value in the rcon_password ConVar.
2. Running rcon PASS PasswordHere will not read the password from the arg if there is a different value in the rcon_password ConVar on the Client end.

[Mauler125]

Do any of you have '-netconport' and/or '-netconpassword' set?

Also, could anyone try running the server on windows and run 'ns_server_password' and 'rcon_password' simultaneously? i can't auth to the master server for some reason, even after a full reinstall of the game and Northstar, and keep experiencing the timescale bug. Also, just to make sure, is there any place in Northstar that opens a TCP socket using the same port as the UDP port of the game protocol?

None of these issues happen on r5reloaded, and the RCON implementation is identical, which is why this bug is interesting.

[Mauler125]

I've also noticed a few seperate things,

1. You can't initiate the RCON request without having a value in the rcon_password ConVar.

2. Running `rcon PASS PasswordHere` will not read the password from the arg if there is a different value in the rcon_password ConVar on the Client end.

Thanks for your feedback, i added the option to use the third argument from the command as rcon password. See latest commit.

[BulletMemes]

I've also noticed a few seperate things,

1. You can't initiate the RCON request without having a value in the rcon_password ConVar.

2. Running `rcon PASS PasswordHere` will not read the password from the arg if there is a different value in the rcon_password ConVar on the Client end.

Thanks for your feedback, i added the option to use the third argument from the command as rcon password. See latest commit.

Oh, I thought that was built in from the start from looking at your guide in the PR

[Mauler125]

I've also noticed a few seperate things,

1. You can't initiate the RCON request without having a value in the rcon_password ConVar.

2. Running `rcon PASS PasswordHere` will not read the password from the arg if there is a different value in the rcon_password ConVar on the Client end.

Thanks for your feedback, i added the option to use the third argument from the command as rcon password. See latest commit.

Oh, I thought that was built in from the start from looking at your guide in the PR

It was only implemented on the standalone netconsole client, not the game client.

[RoyalBlue1]

While compiling this

[GeckoEidechse]

Aight, for anyone wanting to test RCON here are some instructions on how to get the necessary files (no compilation etc required)

0. Before starting, make sure you have a working and up-to-date Northstar install and you're logged into GitHub with your GitHub account (downloading files from CI only works while logged into any GitHub account)!

1. In order to use RCON you'll need to download the modified NorthstarLauncher binaries.

   1. Head to the bottom of the page of the PR and click on "Show all checks"

   2. For "CI / build (pull_request)" click on "Details"

   3. From here click on "Summary"

   4. And then click on "NorthstarLauncher-XXXXXXX"

   5. Once downloaded, open the zip:

      • Copy Northstar.dll and NorthstarLauncher.exe to the Northstar install on your server.
      • netcon.exe is a standalone application to connect to your RCON-enabled server and can be used in any client. It does NOT have to be copied to your Titanfall2 install folder.

2. :warning: In order to actually enable RCON on the server, refer to the instructions at the top of the PR. For example RCON will NOT be enabled unless you set a password that fulfils the necessary requirements mentioned in the instructions.

[GeckoEidechse]

Auto executes 'rcon_server.cfg' on launch. You can put your configs in here.

What's the location of that file? Root Titanfall2 folder?

[GeckoEidechse]

So on a new attempt I using the newest CI build at the time I now get:

Checking dedi console a (long enough) password is set:

Trying to connect on in-game client it says:

And, yes I verified I properly added the files from CI as logs say version is dev (I was running stock v1.9.1 launcher before).

[cpdt]

I have a few questions about the RCON protocol, after writing my own client (https://github.com/cpdt/northstar-rcon-client)

• What are SERVERDATA_REQUEST_VALUE, SERVERDATA_REQUEST_SEND_REMOTEBUG, SERVERDATA_RESPONSE_VALUE, SERVERDATA_RESPONSE_UPDATE, SERVERDATA_RESPONSE_STRING and SERVERDATA_RESPONSE_REMOTEBUG for? Seems like none of them are used.
• Why do requests and responses have a requestID that is always set to -1 and ignored on the other end?
• A bit more nit-picky, but since we're using protobuf can't we have separate message types for each response and request type, with the fields they each actually need? That would be less error-prone and make the protocol a bit more self documenting.

[GeckoEidechse]

So on a new attempt I using the newest CI build at the time I now get:

Checking dedi console a (long enough) password is set:

Trying to connect on in-game client it says:

And, yes I verified I properly added the files from CI as logs say version is dev (I was running stock v1.9.1 launcher before).

Okay for some reason I cannot reproduce that issue anymore so I guess consider it solved ig :P

[Mauler125]

So on a new attempt I using the newest CI build at the time I now get: Checking dedi console a (long enough) password is set: Trying to connect on in-game client it says: And, yes I verified I properly added the files from CI as logs say version is dev (I was running stock v1.9.1 launcher before).

Okay for some reason I cannot reproduce that issue anymore so I guess consider it solved ig :P

This most likely happened because the hostport of the dedi isn't 37015. By default (when no args are passed to netconsole or the rcon command in-game), the netconsole will attempt to connect to localhost::37015. If your server happens to have port 37016 or anything non 37015, which happens if you have multiple servers running, or started a game client before the dedi, or could also happen if something else uses that socket, then you need to specify the correct ip and port manually.