If a user holds down Ctrl+T for a min or so it will disconnect insim.

Doesn't disconnect all inSim applications. Although I don't think ours has a handler for this request. You might have to follow through with this on your inSim Lib programmer. I don't know the packet for this request, I really don't have any clue about inSim. Laugh if you will, but who knows the packet name for this so I can look if we even use it?

"Requested TCP packets for position updates"
2 & 1/2 mins held down.. no disconnect on CLC.

I would appreciate this too since I think I may start using dedi hosts now due to what has happened today.

my friend tried it on mutliple servers and it worked for him. Helps if you have more people doing it too. Its basically a dos.

Quote from JasonJ :

Doesn't disconnect all inSim applications. Although I don't think ours has a handler for this request. You might have to follow through with this on your inSim Lib programmer. I don't know the packet for this request, I really don't have any clue about inSim. Laugh if you will, but who knows the packet name for this so I can look if we even use it?

"Requested TCP packets for position updates"
2 & 1/2 mins held down.. no disconnect on CLC.

This works on every server. Some servers require more then 1 person doing it. (CLC,WS.C,etc)

Quote from elmohellno :

If a user holds down Ctrl+T for a min or so it will disconnect insim.

More details are required. Is this locally at the dedi console, or a remote issue? or both?

Presumably it's remote and is acheivable for non-admins?

With my experience (mostly guesswork) I am guessing it might be causing a

TCP ERROR : WOULDBLOCK

which is usually is the case when the buffer overflows.

No-one has access to our Dedi console, so if it occurs on CLC (as he says it does) then it is caused from remote players Ctrl+T'ing

I haven't tested it with multiple players, but I will try it out soon.

I beleive this exploit was used against the LTC servers earlier this morning.

I do have a username of who caused it.

I will get the LTC gang to test our for it tonight - and will post my findings!

Let me know if you find anything out Jason mate

EMOHELLNO - How many players are needed to crash it on CLC - do you know?

I just tried it with 7 players holding Ctrl+T for 30 seconds. Nothing lagged and no errors were produced and the inSim connection to the application wasn't lost. I just attached the server log extract for reference if required later. Ctrl-T CLC.zip
In this case the inSim remote connection was also active if that is of any relevance.

Tried with two on a server with about 14 people on earlier.

Will try with a full server later on tonight .

I believe this is caused from the backlog becoming too big. So only dedicated servers with a slower connection or slower performance are effected?

Also Krammeh what are the differences between your server1 and server2?

Quote from elmohellno :

I believe this is caused from the backlog becoming too big. So only dedicated servers with a slower connection or slower performance are effected?

Also Krammeh what are the differences between your server1 and server2?

Same server box, same insim app. Why?

I know you caused one of them to crash, but, how?

Quote from Krammeh :

Same server box, same insim app. Why?

I know you caused one of them to crash, but, how?

Server2 crashed easy with Ctrl+T, Server1 didn't.

Isn't server 2 the busy one. More traffic at this time? Just an observation.

Yeah it is - maybe its cause it requires more TCP information to obtain the cars positions.

I was unable to crash it *shrugs* perhaps it was when the server has having a good day

Probably can reproduce this very easily by sending a malformed TCP information packet. Will try later(on my own server).

I think its related to LFS Relay.... *shrugs*.

Could it be that its the MSO spam killing the InSim connection, or are you sure its a funked up TCP packet? There have been known issues with too many messages between client and server creating the INSIM ERROR : WOULDBLOCK.

Quote from Krammeh :

I think its related to LFS Relay.... *shrugs*.

A new guest is connecting
[TZ] Jøgge^L connected (gatebil94^L)
[TZ] Jøgge : ^L:)
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
.... (skipped lots, or you might bet bored)
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
INSIM ERROR : WOULDBLOCK
INSIM : Cleared emergency store InSim Relay
INSIM : Cleared emergency store InSim Relay
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
.... (skipped lots, or you might bet bored)
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
INSIM : Cleared emergency store InSim Relay
INSIM : Cleared emergency store InSim Relay
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
.... (skipped lots, or you might bet bored)
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
Using TCP packets to [TZ] Jøgge
InSim closed : LCS
InSim closed : LTS

oh, sorry for that...

Quote from mcgas001 :

Could it be that its the MSO spam killing the InSim connection, or are you sure its a funked up TCP packet? There have been known issues with too many messages between client and server creating the INSIM ERROR : WOULDBLOCK.

LCS creates graph information about how large buffers are, and it does not go up anymore than 3% while thats going on - so I doubt it

Yep,
there is something going on.
Our insim app crashes randomly, sometimes after a minute, sometimes after an hour. The amount of players is irrelevant.
It has nothing to do with ctrl-t <-- It's not being mentioned in the server's log.
I suspect a malformed tcp packet to be the cause.
Packet sniffer up and running, i am going to get this guy.
Oh well, LFS truly is going downhill - speed hackers, stats cheater and now an insim exploit.
And Scawen is playing around with shaders :-(

If InSim applications are now becoming unstable and are starting to crash on a regular basis, Then this is an issue. I don't beleive many people know how to corupt the TCP packets but it seems only a matter of time. I also don't beleive this will be fixed anytime soon.

I guess all you can do is make your own protection, or just suffer the crash's.

Quote from mcgas001 :

If InSim applications are now becoming unstable and are starting to crash on a regular basis, Then this is an issue. I don't beleive many people know how to corupt the TCP packets but it seems only a matter of time. I also don't beleive this will be fixed anytime soon.

I guess all you can do is make your own protection, or just suffer the crash's.

I'm going to add something into LCS that kicks the person after X amount of TCP packet requests.

And also kick for X amount of flood - well, LCS already does this after 9 messages (3 LTC spam alerts)

Quote from Krammeh :

I'm going to add something into LCS that kicks the person after X amount of TCP packet requests.

And also kick for X amount of flood - well, LCS already does this after 9 messages (3 LTC spam alerts)

A good idea, but if its funked TCP packets. They will only need to do it once for the crash to occur. I have also wondered something about this bug, Is the InSim client itself crashing. Or is LFS closing the InSim connection?

Unsure, it seems to create an EOF on the connection... So, could be just dropping the connection.

I think I need to sort out LCS's autoreload system - it kinda reloads, but not quite :P

edit: I think thats that sorted - could do with a full server test, but meh - also made "renters" "safe" on the reload