Which OS?

[Ghell]

OK, the current server binary for windows is pretty rubbish so unless a new, stable version comes out or i have the time (and permission?) to write a C# dedicated server that runs the same on nix/mono and win/dotnet the only option for a stable dedicated server is to run unix or unix-like (eg linux)

But there are so many distributions of linux and there is always BSD etc. My server runs Windows Server 2003 x64 and has VMWare Workstation 5.5 for running virtual servers underneath it so I would only be running as a virtual machine. The only linux distribution I am familiar with is Fedora core 4 and I didn't install it on that system, it also seems like a bit of a mammoth for just running a few dedicated soldat servers on. I have also looked into debian and ubuntu but as I have never used either it is hard to work out if either are worth using and I have done pretty much no research on BSD at all (though I know a fair bit about it in general and would probably be using OpenBSD out of the 3).

Can anyone recommend a good operating system to run on a virtual machine for running multiple simultaneous soldat dedicated servers with little impact on system performance (as i use the Windows Server for some pretty heavy things too)

It would have to be relatively easy to set up and have no chance of going wrong as I run buisness critical applications (like MSSQL 2005 x64) on the server.

The server runs on dual xeons (em64t) and the base OS is Windows Server 2003 x64 Standard but as its a virtual machine I also dont know if i need an x86 or an x86_64 build.

[EnEsCe]

Ubuntu base system is what I used on my VMWare workstation.
But note: Hosting Soldat Servers under an emulated OS will result in high ping fluxuations for all players.

And you wont be able to code your own C# soldat server.

[Ghell]

Hmm thats weird, I run another system under vmware running ws2k3 because one of its dlls wont run directly under x64 (even with wow64)

EDIT: The average ping of the 200 simultaneous users on the other service running on virtual ws2k3 x86 std is ~20 so why would it flux on virtual ubuntu running soldat

When you said i wouldnt be able to make it in C# were you saying i wouldnt get permission or you don't think I can?

[EnEsCe]

Regarding flux's, thats just from my own experiences. My old server was emulated, and everyone had fluxes -50|+50.

Im not saying you dont have permission[probably wont anyway], im saying you just wont be able to because of how Soldat and the server communicate.

[Ghell]

I haven't asked for permission though I don't know if an emulated server would technically need permission as they are generally used as legal bypasses for "no private server" laws but I wouldn't make one without permission anyway.

I have had a look at the protocols and transmissions with ethereal and it doesnt actually seem that complicated, especially compared to other games. Writing a client would be a different story though but the server seems simple. I am an experienced software engineer and have contributed to emulators for games as big as mu online (http://www.globalmuonline.com/) by webzen inc (http://www.webzengames.com/) though don't run those servers incase of doubt of legality. The hardest thing would most likely be keeping up to date with changes made to the protocols to keep the client compatible (though its backwards compatible anyway I think).

I'm writing my own game at the moment though (I've always wanted to program something that I would actually enjoy to use for a change instead of end-user systems and the like) so don't have much time and was hoping a better release of the windows binary for soldat would appear.

I tried running the dedicated server directly on ws2k3 x64 std and most pings were at the 16 mark (though a friend of mine who uses that other service on the ws2k3 x86 virtual server with no problem tried and he had a ping of 3000 for some reason, and only to this server not to other solday servers, I have no clue why.)

EDIT: (I'm editing a lot today) I am, of course aware of your involvement in soldat servers.

[EnEsCe]

When I say "emulated server" I am not referring to emulated game servers like WoW private servers or Ragnarok crap, I mean running Linunx under VMWare..... If someone made a 3rd party soldat server, I think that would really kill Soldat alot; too many fucked up things will arise and eventually nurf the game.

Oh, and saying "is pretty rubbish" doesnt quite help much, how about actually saying what is wrong... Besides that, the Soldat Server is NOT 64-Bit compatible, so if you try and use some 64-Bit program that makes 32-bit programs "compatible", ofcourse its going to be rubbish...

[Ghell]

I wasn't refering to emulated as in virtual (as this is not infact emulated) I was refering to "a 3rd party soldat server" which would be "an emulated soldat server". Emulated WoW servers are just 3rd party server software anyway so please do not correct me when I'm not wrong.

http://en.wikipedia.org/wiki/Server_emulator

I am running x64 not ia64 so x86 software should in theory run fine on it via WOW64 (windows on windows not world of warcraft .. actually WOW64 technically IS an emulator though). Infact it does run exactly the same on x86 as x64 on windows. The other service runs fine on x64 as well but one of its dlls hooks into an exe and has been written poorly, because of how it is written it cant hook under x64.

I did not list the problems with the windows binary because there are a lot of them and everyone here knows them. There are the same problems under 32bit as 64bit (if there were different problems under 64bit it would only be that it couldn't start in the first place).
Some of these include:
- The server crashing out totally
- Kills stop working
- Everyone disconnects randomly
- Nobody can conenct randomly

Infact I'm pretty sure it was you on the old forum who told me to not bother trying to run it under windows because it is so unstable even under x86.

[EnEsCe]

Yes, the windows binary is infact less stable... No reason why, other than its windows. The linux binary is the exact same thing, yet its fine.

But, the point was, use Ubuntu or any other Debian distro for running it. Linux soldat servers have been known to run for a couple of weeks straight without having to be restarted due to lobby desync or crashes etc.

[Ghell]

Ok, sorry if i offended anyone saying its a bit rubbish I just didnt want to go into listing the problems as I assumed everyone knew them.

I dont know why a windows port would be less stable either but oh well. Thanks for answering my question earlier I will try ubuntu sorry for going offtopic.

Out of curiosity why would a 3rd party emulated soldat server cause "too many ****ed up things will arise and eventually nurf the game"? I don't see how it would hurt appart from maybe if it was open source pretty much spelling out the protocols for hackers (I'm aware even compiled C# is pretty much open source, I actually use themida on windows to secure it but there isnt much for linux that is as secure as far as I know)

[FliesLikeABrick]

"too many fucked up things will arise" meaning that if someone created a third party server, their code could then be modified to do very, very strange and potentially malicious things.  The odds of you successfully creating a 3rd party server are extremely slim since neither the client or server is open-source and the protocol is encrypted.

[Ghell]

The muonline protocol is encrypted with 4 different types of encryption (C1 - C4) and consists of over 600 opcodes, it didn't stop me then.

I don't see how a 3rd party server (even if it was open source, and I didnt say I would release the source if I made one, hell i didnt even say I would release the binary) could be altered to do malicious things.

Do you have a few examples of these very, very strange and potentially malicious things?

Anyway as I said I don't really have the time to bother with making an emulator I was told on the old forums that someone (EnEsCe? i dont know) was testing the new dedi server on windows and it was up for 6 days stable or something at the time.

[chrisgbk]

The muonline protocol is encrypted with 4 different types of encryption (C1 - C4) and consists of over 600 opcodes, it didn't stop me then.

I don't see how a 3rd party server (even if it was open source, and I didnt say I would release the source if I made one, hell i didnt even say I would release the binary) could be altered to do malicious things.

Do you have a few examples of these very, very strange and potentially malicious things?

Anyway as I said I don't really have the time to bother with making an emulator I was told on the old forums that someone (EnEsCe? i dont know) was testing the new dedi server on windows and it was up for 6 days stable or something at the time.

Exploitation of errors in the client-server protocol to cause such things as buffer overruns that could result in remote installation of trojans etc. Not that these actually exist, mind you, but it is an example.

[Ghell]

A 3rd party server would not cause any problems which aren't there already. As far as I can see the soldat client is pretty safe from such things and if the 3rd party server was written in a managed language like C# then it would be too. This just leaves MITM attacks which could be done in exactly the same way on an official server.

Again, I never said I would release the source (or even binary, though I can protect that from tampering on windows) or run it as an open source project or anything, so it wouldn't be spelling the protocols out for a casual hacker to abuse.

Its all redundant anyway as I don't have the time at the moment to write one but I don't see any security problems with it (providing, of course, that the author doesnt put any in on purpose or neglect things like buffer overruns as you have said) in general.

Hows about releasing a better dedicated server binary instead someone?

[FliesLikeABrick]

A 3rd party server would not cause any problems which aren't there already. As far as I can see the soldat client is pretty safe from such things and if the 3rd party server was written in a managed language like C# then it would be too. This just leaves MITM attacks which could be done in exactly the same way on an official server.

well it just so happens that you attracted the attention of chrisgbk and EnEsCe, the two people who develop and maintain the server binaries.  "As far as I can see the soldat client is pretty safe..." means nothing if you're talking to them, they know what they're talking about.  Your guesses versus their knowledge doesn't mean much.

an exploit that first came to mind for me is the ability to use the file server code to distribute something malicious to clients as they connect.  The file server is quite flexible and I don't think there is anything that would stop the server from sending out a trojan disguised as something else.  it is only a matter of time before someone would get curious and go click on "fluffykittenlove.exe" in their maps or other folder (maybe it could even be put in their Soldat root directory

[Ghell]

I didn't mention doing anything in the way of a file distribution server and all these attacks rely on the person who is actually WRITING the server to want to do malicious things, if someone wrote a stable server with good intent the malicous user would only be able to do such things with the same ease as they would already be able to, infact if the file server is so insecure a rewritten one could even be more secure (less flexible) and make sure nothing of that nature is transmitted.

Also my "guess", which isn't actually a guess it's just nothing immediately obvious shows up if you take the time to look at it, actually agrees with chrisgbk's "Not that these actually exist, mind you, but it is an example." it does not go against it so there is no "Your guesses versus their knowledge doesn't mean much."

Please do not treat me as if I am an idiot.

Date Posted: August 04, 2006, 10:23:20 AMOk, back on topic, running ubuntu on vmware workstation 5.5 I left soldat on for one night and looked at the terminal window and noticed that the only things which showed up were join attempts (fig1) so I tried to join myself and on the client it looks even weirder (fig2)

fig1:


fig2:


Also, the ports everywhere are set to 23073 and the TCP is definately on that port because I can telnet to it and get the admin text up, but it seems that people have to connect on 1412, any ideas why?

[EnEsCe]

Your using NAT for Ubuntu's network connection arent you...
You need to use Bridged.
If you are using Bridged, then you may want to check your router or something.

[Ghell]

The fibre hosting I use only allocates me one IP address, its the same address for LAN as for external (ie the static LAN IP I have set in windows and can see with "ipconfig /all" is my external IP) so I have to use NAT. Does this cause the problems in soldat or just the port to be wrong?

(Edit: When you have vmware set to NAT you essentially make the host OS and vmware the router anyway so it should still be possible to achieve exactly the same effect. I have set port forwarding on 23073 in vmware too and it seemed to work at ~28/32 players for 12 hours or so before things started to go weird.)

Also, further to your "Ubuntu base system is what I used on my VMWare workstation, but note: Hosting Soldat Servers under an emulated OS will result in high ping fluxuations for all players." I have been informed by the guys over at VMWare that ubuntu has performance issues under VMWare Workstation 5.5.0 only and is fixed in later versions (5.5.2 is also comming out soon) it also seems to work fine under the latest VMWare Server (infact in the latest versions there is actually an option for ubuntu and ubuntu 64bit in the list of linux distributions when you make a new virtual guest)

[EnEsCe]

Yeah NAT will randomise the port so it can translate it, unless you forward it ofcourse.
--
Thanks for that info, oh well. I got rid of my Windows server and switched to Debian Stable instead anyway, no more VMWare

[Ghell]

Yea that was it, I thought I had forwarded UDP as well but it turned out I had only forwarded TCP (I'm sure that UDP section was camoflagued with the dialogue from the previous menu )