Sauerbraten engine development |
by Aardappel
on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1351223 views, last view: 12/09/2021 02:33 |
 |
|
This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.
|
 |
|

Board Index

|
 |
#1505: Server crash |
|
by virtualblackfox
on 06/20/2006 01:31
|
 |
|
Today i had a crash to my server do to a cheater, here is what appened :
---------------------------
client connected (168-103-233-110.ptld.qwest.net)
[NewPlayer] Name: Paul
status: 6 remote clients, 13.2 send, 2.7 rec (K/sec)
[MapChange] New map:
[Chat] . : gg
[Chat] . : lol
status: 6 remote clients, 14.2 send, 2.8 rec (K/sec)
[MapChange] New map:
status: 6 remote clients, 17.1 send, 3.4 rec (K/sec)
status: 6 remote clients, 17.8 send, 3.5 rec (K/sec)
disconnected client
[MapChange] New map:
status: 5 remote clients, 11.0 send, 2.7 rec (K/sec)
[MapChange] New map:
status: 5 remote clients, 9.9 send, 2.4 rec (K/sec)
status: 5 remote clients, 9.8 send, 2.4 rec (K/sec)
[MapChange] New map:
status: 5 remote clients, 9.3 send, 2.3 rec (K/sec)
[MapChange] New map:
status: 5 remote clients, 9.0 send, 2.2 rec (K/sec)
status: 5 remote clients, 8.6 send, 2.1 rec (K/sec)
status: 5 remote clients, 8.3 send, 2.0 rec (K/sec)
status: 5 remote clients, 9.0 send, 2.2 rec (K/sec)
client connected
[NewPlayer] Name: Homo
disconnected client
disconnected client
client connected
[NewPlayer] Name: .
status: 5 remote clients, 10.0 send, 2.2 rec (K/sec)
[MapChange] New map:
disconnected client
status: 4 remote clients, 8.4 send, 2.3 rec (K/sec)
client connected
[NewPlayer] Name: Rareware
sending request to sauerbraten.org...
masterserver reply:
your server was registered
[NameChange] Rareware -> Homonculus
[MapChange] New map:
status: 5 remote clients, 9.5 send, 2.5 rec (K/sec)
[Chat] . : paul you are a cheater
[Chat] Homonculus : goddamn respawn limit
[Chat] Homonculus : >:I
[Chat] Homonculus : this is retarded :3
status: 5 remote clients, 11.2 send, 2.8 rec (K/sec)
[Chat] . : dnx, kick paul please
disconnected client
[MapChange] New map:
[Chat] . : paul go home
status: 4 remote clients, 8.8 send, 2.6 rec (K/sec)
[Chat] Paul : sorry
status: 4 remote clients, 7.1 send, 2.3 rec (K/sec)
[MapChange] New map:
disconnected client
client connected
[NewPlayer] Name: .
disconnected client
client connected
[NewPlayer] Name: .
disconnected client
status: 3 remote clients, 6.1 send, 2.0 rec (K/sec)
client connected
[NewPlayer] Name: .
client connected
[NewPlayer] Name: unnamed
status: 5 remote clients, 7.2 send, 2.1 rec (K/sec)
[Chat] . : /kick Paul
[Chat] . : doesn't work :(
[MapChange] New map:
status: 5 remote clients, 9.8 send, 2.4 rec (K/sec)
[Kick] dnx
client (168-103-233-110.ptld.qwest.net) disconnected because: kicked/banned
disconnected client (168-103-233-110.ptld.qwest.net)
---------------------------
My server does some printf on events so you could see what appened.
After the last line (dnx having kicked the cheater) the server crash with this stack trace :
---------------------------
sauerbraten_debug.exe!fpsserver::captureserv::movebases(const char * team=0x00000108, const vec & oldpos={...}, const vec & newpos={...}) Line 381 + 0x3 bytes C++
sauerbraten_debug.exe!fpsserver::captureserv::leavebases(const char * team=0x00000108, const vec & o={...}) Line 396 C++
sauerbraten_debug.exe!fpsserver::clientdisconnect(int n=0) Line 596 C++
sauerbraten_debug.exe!serverslice(int seconds=1150756441, unsigned int timeout=5) Line 439 + 0x1c bytes C++
sauerbraten_debug.exe!initserver(bool dedicated=true) Line 532 + 0x12 bytes C++
---------------------------
When i break i see some things :
"char * team=0x00000108" is an invalid adress (just a function offset on NULL pointer) due to the fact that getinfo returned NULL (because clients[i]->type==ST_EMPTY).
So we have a playing client (num=0) that had type==ST_EMPTY but i don't known how he managed to do that. Also note that if m_capture has been false no crash would have hapened.
I don't known if it was something wanted by the cheater by some reason or if it is just a random bug that hapenned to a cheater but could have hapenned to everyone.
Just adding a "if (ci == NULL) return;" could solve this particular problem but it think that maybe it is a chance to find the root cause.
I will let my debugger breaked on this error till tomorrow so if you have questions about the program state just ask (too late for me to do debugging :D)
reply to this message
|
 |
#1506: Re: Server crash |
|
by Passa
on 06/20/2006 02:19, refers to #1505
|
 |
|
That guy was hacking on my server too. And thats a bug with the current binaries, luckily I got a patch for Windows for my server, so if you guys want a more stable server, head over to mine for now, or ask eihrul to give you a patch.
Thats the same IP of the guy who was hacking for me. Hes a dumbshit, he just got that downloadable hack that someone posted a link to.
reply to this message
|
 |
#1507: .. |
|
by virtualblackfox
on 06/20/2006 09:33
|
 |
|
I patched with the changes in CVS i hope that the correction was commited.
Anyway eihrul i will be happy to known from where this crash really come from.
For the cheaters i don't mind them to connect to my server because most of the time waiting a few minutes is enough to see them go but if they crash the server it really annoy me :-D.
reply to this message
|
 |
#1508: Re: .. |
|
by eihrul
on 06/20/2006 09:37, refers to #1507
|
 |
|
CVS isn't compatible with the release, nor is it compatible with itself from day to day currently. Careful with that.
reply to this message
|
 |
#1509: .. |
|
by virtualblackfox
on 06/20/2006 09:49
|
 |
|
I know i cherry-pick the changes :D (Even if CVS is not very suited to that)
Any plan to switch at least to SVN (As sourceforge support it) ? or even better SVK or Bazaar-NG ?
reply to this message
|
 |
#1510: Re: Server crash |
|
by hampus_
on 06/20/2006 11:44, refers to #1506
|
 |
|
You could block his IP in your firewall.
reply to this message
|
 |
#1511: Re: Server crash |
|
by Passa
on 06/20/2006 12:49, refers to #1510
|
 |
|
Hey, who removed the IP address from the post? :P
Nice idea hampus, I will try that.. once I install a firewall on the server :S
reply to this message
|
 |
#1512: .. |
|
by virtualblackfox
on 06/20/2006 13:20
|
 |
|
Ok after some test kicking someone in capture make the server crash everytime it seem :D
reply to this message
|
 |
#1513: another crash |
|
by absinth
on 06/20/2006 13:29
|
 |
|
Thread 0 Crashed:
0 libSystem.B.dylib 0x900037a8 szone_malloc + 240
1 libSystem.B.dylib 0x90003380 malloc + 632
2 sauerbraten 0x0004099c enet_malloc + 32 (callbacks.c:36)
3 sauerbraten 0x000413b0 enet_packet_create + 64 (packet.c:30)
4 sauerbraten 0x00043ad8 enet_host_service + 2580 (protocol.c:431)
5 sauerbraten 0x00004d30 gets2c() + 624 (client.cpp:191)
6 sauerbraten 0x000718fc fpsclient::updateworld(vec&, int, int) + 5844 (fps.cpp:184)
reply to this message
|
 |
#1514: Re: .. |
|
by Passa
on 06/20/2006 13:49, refers to #1512
|
 |
|
Yeah its a bug with the current release. Server crashes, that is.
reply to this message
|
 |
#1515: Re: Server crash |
|
by xoltra
on 06/21/2006 06:22, refers to #1505
|
 |
|
I've had problems with the same IP address (cheating via modified weapons and using my nick). He's figured out a way to defeat /kick, but he's now permanently firewalled out of my server.
reply to this message
|
 |
#1516: Re: Server crash |
|
by Passa
on 06/21/2006 06:29, refers to #1515
|
 |
|
How did he defeat kick? I was under the impression he was a total n00b, I think he is using that downloadable hack.
What firewall did you use to block him? I can't find a way to block him using my Sygate firewall.
reply to this message
|
 |
#1517: Re: Server crash |
|
by xoltra
on 06/22/2006 08:07, refers to #1516
|
 |
|
I may be wrong about him defeating kick. Previously when I ran into him and I was master I thought kicking him by clientnum did nothing, but I may be confused. Or he may have been logged in with multiple clients. Or whatever.
Later I came across him again on another server and asked him how he defeated /kick. He said he hadn't, but he'd try. I don't see any obvious problems with the code (putting the client in a list of banned IPs and enet disconnecting it). So I wouldn't worry about it.
I don't know if he downloaded something, or he just figured it out by looking at the code. Adjusting weapon characteristics is pretty straightforward (no need to go into detail).
Since I'm running Linux I use iptables, which is the CLI interface to the firewall that comes with the OS. So, in my /etc/sysconfig/iptables I added
-A RH-Firewall-1-INPUT -j REJECT -s AA.BB.CC.DD --reject-with icmp-host-prohibited
just before the lines that allow the stuff into the Sauerbraten ports. Note that I hid his IP address since this forum may not like that.
I think you run the server in Australia and you also added a message of the day to your server. Maybe we can compare notes since I did the same to mine. You can find my patch at the bottom of my Sauerbraten page:
http://home.austin.rr.com/selliott4/sauerbraten
reply to this message
|
 |
#1518: Re: Server crash |
|
by xoltra
on 06/22/2006 08:13, refers to #1517
|
 |
|
As far as you know you did the MOTD thing first. Just wanted to clarify that it wasn't my idea.
reply to this message
|
 |
#1519: Re: Server crash |
|
by Passa
on 06/22/2006 08:21, refers to #1517
|
 |
|
Yup my server is run in Australia, obviously by it reprinting the message like 50 times everytime someone joins :P
Problem is that it prints it everytime someone joins, for each player, so if I have 10 people connected, and an 11th joins, it prints it 11 times.
Oh and on my MOTD, its actually one line of code. And that line of code wasn't even by me, it was by dbox, I just figured out where to put it. I aint a coder :P
eihrul: could you possibly add xoltra's new patch to the next release? I like the idea of it dumping the console output to a file. Plus it includes hostname details for each player. And the MOTD support looks solid. Nice stuff xoltra.
reply to this message
|
 |
#1520: Re: Server crash |
|
by xoltra
on 06/22/2006 08:54, refers to #1518
|
 |
|
I meant as far as *I* know. Ok, I think I've got it (finally).
reply to this message
|
 |
#1521: Re: Server crash |
|
by xoltra
on 06/22/2006 09:06, refers to #1519
|
 |
|
Thanks for the positive feedback on my patch. It could use some work to make it more consistent with the other sauer code. The MOTD stuff could be more object oriented (I just did everything there). And I dunno if its reentrant enough with the static vars.
Also, I just added the timestamp to a few of the lines a I added. There should probably be a logging API that prepends a timestamp to every line.
I'm just redirecting the output of the server with 2>& | tee -a log_file. It might be nice if the server just wrote to a log file by default.
If nothing else this line:
setvbuf(stdout, (char *)NULL, _IOLBF, 0);
would be great to have in CVS. It just makes the output of the server line buffered so it can be redirected to a file. It should not be very demanding at all (a line every now and then).
reply to this message
|
 |
#1522: Re: Server crash |
|
by rpointon
on 06/22/2006 09:51, refers to #1521
|
 |
|
Classic unix - redirect via (or fork within) a psuedo-terminal and then you wont need to change the server source. Google for 'pty program'...
reply to this message
|
 |
#1523: Re: Server crash |
|
by xoltra
on 06/22/2006 16:02, refers to #1522
|
 |
|
That is true. stdout is line buffered when writing to a terminal and block buffered when writing to an ordinary file. But adding the one line I suggested should easier, and a pretty safe change.
reply to this message
|
 |
#1524: Making SV_POS updates more scalable |
|
by xoltra
on 06/23/2006 08:45
|
 |
|
Unless I'm misunderstanding the code the position of clients update each other with their current position by:
1) The client sending an SV_POS event with, among other things, the XYZ coordinates of the client at most 30 times per second.
2) The server echoing the packet to each client.
The total bandwidth required is roughly proportional to the square of the number of clients. I believe SV_POS messages make up a majority of the bandwidth during normal game play.
Have you considered determining which clients are visible to which other clients and only sending SV_POS to clients if it makes a visible change for that client? This may not be too hard to do because you probably already have logic that each time a frame is rendered determines whether each client is occluded (not visible). Perhaps each client could send a bitmask of the clients visible to it based on the occlusion calculations to the server. The bitmask would be only be sent each time of the bits change (another client becomes visible or not). One way of implementing this would be to have a global boolean that would indicate if any the occlude status of any dynent has changed since the last frame. When the frame is rendered if any of the dynents iterated through changed in occlude status the boolean would be set, and the bitmast would be sent to the server.
The server would would consider bitmask each time a SV_POS was received so that it would only be multicast to the clients that could see the change.
reply to this message
|
 |
 |
|

Board Index

|
 |