Hello Hosters,

Here is the fifth test of the long requested console based dedicated host. The fourth test seems to have been working well. The text input system has been made more efficient so you can send text into your host using the Windows SendMessage function. Two other bugs have been fixed. If this test works well we may release it as an official version of the dedicated host. Maybe we will not release the old style "grey window" dedicated host again.

Changes from TEST4 to TEST5 :

FIX : Excessive console text input could cause freeze or crash
https://www.lfsforum.net/showt ... php?p=1800156#post1800156

FIX : Number of laps was not cleared in Live Host Progress by /pitlane or /pit_all
https://www.lfsforum.net/showt ... php?p=1799225#post1799225

FIX : Spectator to garage from game setup screen wrongly set LFSW status to "in pits"
https://www.lfsforum.net/showt ... php?p=1768629#post1768629

Changes from original 0.6E to TEST4 :

- More protection against hackers
- More logging in the joining process
- Network debug is enabled by default.
- Use of skin not found on LFS World causes player to be spectated

Some Notes on the console version :

This version makes it easier to run LFS on Linux servers (e.g. using Wine) because fewer Windows functions are used. It is a true console program with no graphical output or pixel rendering. There is no real hesitation for the screen update, saving CPU and allowing network packets to be forwarded as quickly as possible.

When a player joins or leaves, some status information is output to the console, including which track is selected, a list of the connected user names and the time and date. You can also get one of those status messages any time by pressing ENTER without typing anything.

You can input text using the keyboard but it is invisible while you type. This is to separate stdin and stdout which can be helpful.

HOW TO USE :

Save DCon.exe into a DEDI folder then you can run it as usual with a command line or a setup.cfg file.

EDIT : TEST6 is now available for download with an important fix : https://www.lfsforum.net/showt ... php?p=1805551#post1805551

Untill now sent about 100 000 messages, and everthing is great
also other fixes are working
Thank You

Thanks

I have problem here i'm running my server with linux & wine everything is fine but sometimes when i write this command /reinit to restart the server i see this problem in log file and the server still down

NameLFH : BL1 race 5 laps (1)
asercom - lfs
May 25 11:23:08 2013
Host will restart in 3 seconds
TCP Socket : bind failed
InSim - TCP : InSim Relay


TCP Socket : bind failed and also when the hole master server is down and back online it's still offline

asercom, that is a really unusual problem. I don't think it is a bug in LFS, but some problem with the configuration of your computer. Your case is the only time I can remember hearing of this.

"bind failed" normally means that LFS cannot listen on a TCP socket because another program is already listening on the port that you want to use. For example this error message would come up correctly if you started two instances of LFS host using the same port number. But the /reinit command closes the original listening socket before trying to open the new one, so the bind should not fail in that case.

I guess that for some reason, Wine or Linux is reporting that the port is still in use for a while after the socket was closed, so LFS cannot bind to it.

Quote from Scawen :

I guess that for some reason, Wine or Linux is reporting that the port is still in use for a while after the socket was closed, so LFS cannot bind to it.

Good guess. WINE holds that socket for about 30 seconds after the LFS instance has been closed / or LFS freed that socked.

Quote from Scawen :

asercom, that is a really unusual problem. I don't think it is a bug in LFS, but some problem with the configuration of your computer. Your case is the only time I can remember hearing of this.

"bind failed" normally means that LFS cannot listen on a TCP socket because another program is already listening on the port that you want to use. For example this error message would come up correctly if you started two instances of LFS host using the same port number. But the /reinit command closes the original listening socket before trying to open the new one, so the bind should not fail in that case.

I guess that for some reason, Wine or Linux is reporting that the port is still in use for a while after the socket was closed, so LFS cannot bind to it.

yes maybe because what you guess after close my host the port still work for a while .. actually i do not need to restart my server with /reinit command but why i test the command, when the master server is down and back fast the host still down because the port already used that is the problem i hope you Scawen find solve for this or made new dedi for linux hosters. another point is when i type /reinit on the console screen of the dedi and no one in the server it's works fine it's restart and back again .. but when some players in the server is'nt work i don't know why is the problem happen to me


Thanks and sorry for my bad English

My server now runs on TEST5, so far nothing to report. I have one futile suggestion though. Wouldn't it make more sense to replace the playernames by usernames (especially in the log file)? The username makes it easier to distinguish players offline in my opinion. It would make the log file easier to read but I suppose it would also make LFS code unnecessary complicated or is there another pertinent reason?

Example:

playername

Quote :

May 28 14:32:31 C^hing : ^LHello World

username

Quote :

May 28 14:32:31 sicotange : ^LHello World

I saw this happening couple of times now;

Quote :

ELF 68462000-68575000 Deferred ole32<elf>
\-PE 68480000-68575000 \ ole32
ELF 68575000-685a5000 Deferred ws2_32<elf>
\-PE 68580000-685a5000 \ ws2_32
ELF 685a5000-6863d000 Deferred libfreetype.so.6
ELF 686b4000-687ed000 Deferred libx11.so.6
ELF 687ed000-6880d000 Deferred libxcb.so.1
ELF 6880d000-68810000 Deferred libxau.so.6
ELF 6bff1000-6bfff000 Deferred libnss_files.so.2
ELF 6e379000-6e3a1000 Deferred msacm32<elf>
\-PE 6e380000-6e3a1000 \ msacm32
ELF 6e8ee000-6e953000 Deferred advapi32<elf>
\-PE 6e900000-6e953000 \ advapi32
ELF 70ca5000-70cae000 Deferred librt.so.1
ELF 7226e000-722e5000 Deferred rpcrt4<elf>
\-PE 72280000-722e5000 \ rpcrt4
ELF 774df000-7758f000 Deferred winmm<elf>
\-PE 774f0000-7758f000 \ winmm
ELF 79351000-79491000 Dwarf libwine.so.1
ELF 7b800000-7b902000 Deferred kernel32<elf>
\-PE 7b810000-7b902000 \ kernel32
ELF 7bc00000-7bcc5000 Deferred ntdll<elf>
\-PE 7bc10000-7bcc5000 \ ntdll
ELF 7bf00000-7bf03000 Deferred <wine-loader>
Threads:
process tid prio (all id:s are in hex)
0000000e services.exe
0000001d 0
0000001c 0
00000014 0
00000010 0
0000000f 0
00000012 winedevice.exe
00000019 0
00000017 0
00000013 0
0000001a plugplay.exe
0000001f 0
0000001e 0
0000001b 0
00000022 (D) Z:\LFS\DCon.exe
00000023 0 <==
00000031 DCon.exe
00000032 0
000004ac explorer.exe
000004ad 0

No idea why. (With 4 and now also with test5)

Its still a pretty rare crash though.

Hmm, I have no idea what that means.

I managed to also get LFS to spin up the WineConsole process to 100%. I started wine and Dedi with nohup. I noticed after a few hours that the CPU usage was at 100% for WineConsole. I'm not sure why either. I didn't get any useful logs from it.

Quote from Scawen :

Hmm, I have no idea what that means.

I was afraid of that.. Didnt look that useful to me too.. Will try to get more debug info when it happens again. (Its missing because cant scroll back in "screen" ).

But it maybe can take weeks before it happens again.

Dave: I use byobu (it's similar to screen). you should be able to hit F7 to scrollback.

Quote from Scawen :

Hmm, I have no idea what that means.

This is what a crash dump from WINE looks like. It's much more useful to debug WINE itself rather than the application that is run through it.

Any idea how to reproduce it Dave? If it's a bug in WINE, I might be able to track it down...

I doubt the problem is Wine to be honest because I see it happening on different machines with different Wine versions. And no, no idea how to reproduce, it just seem to happen randomly and rarely.

Btw that socket problem, I wonder if thats Wine related. Isn't it just an incorrect closing/reset by LFS dedi concerning the TCP socket?

I have not much experience with other games/programs running under Wine but if this is a 'Wine issue' half the internet should be filled with bug reports about this I think?

Honestly, spectator because our skin/helmet is not uploaded it adds absolutely nothing to me. Unless a aditional spam the chat.

What exactly is the goal of this restriction?
Because it always adds much lag to server ..

Some people do not read and never will read.
is it possible to add an additional function in setup.cfg example "checkskin=yes/no" ?

Took shorter then I expected;


No idea if this is of any use.

(By the way to scroll in "screen" its Ctrl+a followed by [ and then j/k ...)

Quote from MrSam :

What exactly is the goal of this restriction?
Because it always adds much lag to server ..

In fact it is to make the server run more smoothly. Apparently there are sometimes problems caused to others when people run with non-uploaded skins. You are right, people often don't read - that's why they ignored the message about their skins. So we had to act to stop this strange behaviour.

Quote from cargame.nl :

Took shorter then I expected;

Thanks, will look and see if that crash address leads to anything...

I think it will fine to change the skin stuff. Also it adds an extra restriction to demo users who want to just run custom skins

I encountered 2 issues related to TEST5 today:

1) DCon5.exe crash

I updated my server to the latest TEST5 dedi on June the 21st. It ran smoothly but crashed today evening. DDOS attacks might be to blame but I can't recall a crash with LFS dedi 0.6E (even though it suffered alot of DDOS attacks too).

Quote :

Problem signature:
Problem Event Name: APPCRASH
Application Name: DCon5.exe
Application Version: 0.0.0.0
Application Timestamp: 519f7910
Fault Module Name: DCon5.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 519f7910
Exception Code: c0000005
Exception Offset: 0000495e
OS Version: 6.0.6001.2.1.0.272.2882382797
Locale ID: 1033
Additional Information 1: f31a
Additional Information 2: b96ba43fc1974f7ba7f10ff9f90e31a4
Additional Information 3: 6808
Additional Information 4: cbc58c2b574b0aa56b2acc5c4f969ae8

EDIT: My InSim application may have caused the crash although it did not crash when Dcon5 did.

2) Excess : 127.0.0.1

Unrelated to the above issue, while testing my InSim application offline. It occurs after I join specific host and immediately disconnect when connected. Repeat approximately 10-15 times in a row to trigger it.

When the "Excess : 127.0.0.1" message is logged I can't join the server. I get the "Did not receive track info" notification. After ~10-20 seconds I can connect again. I could not reproduce this with LFS dedi 0.6E.

It's easy to reproduce though. Could someone do ~10-15 quick joins/disconnects in a row offline to confirm this (no InSim app has to be connected) ?

reproduced Excess : 127.0.0.1

Same 495e crash... Interesting

Sorry I only got round to looking at that crash today. It's a frustrating one because the crash address is between two instructions. That means that somehow the instruction pointer has been set to an invalid value. This can be caused by a function that writes to the stack, in a way that it should not - for example off the end of an array, so corrupting the return address from that function. The trouble is that, with the stack corrupted and the instruction pointer now in an invalid position, I can't see where the program was when it did actually corrupt the stack.

The "Excess" message isn't a bug, it's just a simple security measure to slow down hackers attempting to join your host.

Is it possible to add few more simple checks?
- Kick guests using invalid gears (e.g. XFG with 6 gears)
- Kick guests driving faster than maximum defined speed

From my point of view it isnt too much job and doesn't need any physics calculation

I'll carry on with this in the morning. I've got more info from that stack dump, but it's making my head spin now. There is a possible cause I can think of but it may be a false lead. We'll see tomorrow.

Quote from Scawen :

Sorry I only got round to looking at that crash today.

No problem, I don't see it as a priority because it's very hard to get this crash. Besides, lack of vitamin D leads to far bigger (or even terminal) problems so any sunny day need to be profited from right now