Modem Tapping?

[Lance]

Originally Posted by Kaimetsu

In that it covers a wider range of exploits, including the one described in this thread. It tackles the undesirable phenomenon directly.

I disagree. In this case, I see the crazy movement speed as just a symptom of all those packets being sent at once. Why tackle the symptom and not the problem? Also, can you provide some examples of these other exploits?

As far as I know, the system we already have should catch these "modem tappers". I think the biggest problem is that many servers don't even use the speedhack detection system. A quick check of UN shows that it isn't used at all. Another quick check shows that Era is using it but has an unreasonably high value for the tolerance (290). A value of 90 should catch most speedhackers. Stefan's words were that simple lag would not set off the alarm with a value of 90. Still, if it happens just once, warn them. If it happens quite frequently, you've got an abuser on your hands.

[Kaimetsu]

Originally Posted by Lance

I disagree. In this case, I see the crazy movement speed as just a symptom of all those packets being sent at once

Movement packets are actually UDP datagrams, right? From what I understand of the protocol, it's a very fire-and-forget system. If the client tries to send them when the connection is down, they'll just fail and be forgotten. They don't enter any kind of queue, so it's not like the server will be receiving more than usual once the connection is reestablished.

Why tackle the symptom and not the problem?

Why tackle a single cause and not the problem?

The problem here is that players can move in ways that weren't intended. That is the problem. Your advised approach is like saying we should ban cigarettes so we don't have to bother looking for a cancer cure anymore.

Also, can you provide some examples of these other exploits?

Would it not currently be possible to send arbitrary movement packets? As long as I don't send too many of them, I can move as quickly as I want. I can warp randomly around the level as long as I don't exceed x packets per second.

[Lance]

Originally Posted by Kaimetsu

Movement packets are actually UDP datagrams, right? From what I understand of the protocol, it's a very fire-and-forget system. If the client tries to send them when the connection is down, they'll just fail and be forgotten. They don't enter any kind of queue, so it's not like the server will be receiving more than usual once the connection is reestablished.

I do not deny my ignorance of such protocols, but TCP is another option for Graal, and I do believe that TCP operates differently. If these packets were just ignored, then how would you explain this:

I've seen an individual player stop moving for some arbitrary length of time and then seen them start to move again, only they are moving faster than is possible along the paths they presumably walked along while they did not appear to move.

Why tackle a single cause and not the problem?

The problem here is that players can move in ways that weren't intended. That is the problem. Your advised approach is like saying we should ban cigarettes so we don't have to bother looking for a cancer cure anymore.

I still don't agree with your naming conventions here. I don't see the unintended movement as a problem of its own to address (like cancer is) but more as the visible effect of some other problems, much like a fever that is a symptom of some bacterial infection. Sure, you can take something to deal with the fever, but would it not be far more productive if you took something to deal with the bacteria? Sure, you can do both in this example, but I hardly think it's a good (or, better, as I initially inquired) idea to just treat the fever.

I just see a lot of problems with monitoring the player's actual speed. It just gets too complicated. What about servers that allow you to move quickly, staff boots, vehicles that allow you to move faster than you walk, etc.? Where do you draw the line? For example, if you don't let anyone move faster than, say, the trains on Graal2001, that's fast enough to render it relatively ineffective. Sure, the extreme moving-around would be limited, but you could still go as fast as a train.

Would it not currently be possible to send arbitrary movement packets? As long as I don't send too many of them, I can move as quickly as I want. I can warp randomly around the level as long as I don't exceed x packets per second.

If you had a method of sending such packets, could you not also use that method to cause some other trouble not related to movement? Then, would not the best method to deal with that problem be to remove the vulnerability that allows you to send such packets, rather than simply dealing with the movement packets you send?

[Kaimetsu]

Originally Posted by Lance

TCP is another option for Graal, and I do believe that TCP operates differently

Agreed. But only a minority of users are foolish enough to use TCP when UDP is a viable option.

Either way, operating the safeguard based on actual speed rather than packet frequency would solve the problem in both cases.

I've seen an individual player stop moving for some arbitrary length of time and then seen them start to move again, only they are moving faster than is possible

How does this suggest that undeliverable UDP datagrams are queued on the client computer? I would sooner think that all the player's movement packets have been sent, but traffic conditions force them into clumps somewhere between the player's client sending them, and you receiving the relays from the server.

I don't see the unintended movement as a problem of its own to address

Then perhaps we disagree on the definition of 'problem'. Clearly the movement is the part to which we object; it is the part that causes conflict with other users, grants unfair advantages, etc. It is the thing we want to stop.

I just see a lot of problems with monitoring the player's actual speed. It just gets too complicated. What about servers that allow you to move quickly, staff boots, vehicles that allow you to move faster than you walk, etc

Yes, I had considered this. It's quite a shame that we're not able to interact more directly with the gserver's code. It would be nice if we could completely redefine how the server reacts to each packet of information, according to various scripted conditions. The server knows if the character is on a vehicle, for example. In such a case, it should ignore all movement packets and let the NPC move the character.

Maximum speed would then be configurable per player, per situation, nullifying your objections.

If you had a method of sending such packets, could you not also use that method to cause some other trouble not related to movement?

Such as?

Then, would not the best method to deal with that problem be to remove the vulnerability that allows you to send such packets

What vulnerability? The only requirement is an internet connection and an understanding of Graal's protocols.

[Lance]

Originally Posted by Kaimetsu

Agreed. But only a minority of users are foolish enough to use TCP when UDP is a viable option.

It isn't a viable option for everyone, though. Some people are stuck behind routers and cannot set up port forwarding for those UDP packets. Other problems may exist, too. For example, when Nappa still used 56k, UDP was not working properly for him. Whenever he had Graal set to use UDP, it was horribly laggy. However, when setting it to use TCP, he did not have that problem.

Either way, operating the safeguard based on actual speed rather than packet frequency would solve the problem in both cases.

The movement would be removed, sure. However, I already mentioned the problems with basing the safeguard on the actual speed.

How does this suggest that undeliverable UDP datagrams are queued on the client computer? I would sooner think that all the player's movement packets have been sent, but traffic conditions force them into clumps somewhere between the player's client sending them, and you receiving the relays from the server.

I did not suggest that the undeliverable UDP datagrams were queued there. I was asking if the TCP option would allow for such a queur or if there was any other possible explanation for that behavior.

Then perhaps we disagree on the definition of 'problem'. Clearly the movement is the part to which we object; it is the part that causes conflict with other users, grants unfair advantages, etc. It is the thing we want to stop.

I'll attempt to clarify: Yes, the movement is a problem. However, I see it more as a symptom of another, perhaps more important problem (or problems) which need to be addressed.

Yes, I had considered this. It's quite a shame that we're not able to interact more directly with the gserver's code. It would be nice if we could completely redefine how the server reacts to each packet of information, according to various scripted conditions. The server knows if the character is on a vehicle, for example. In such a case, it should ignore all movement packets and let the NPC move the character.

Maximum speed would then be configurable per player, per situation, nullifying your objections.

It certainly would be nice, yes. Unfortunately, such is not the case, so it remains unfeasible.

Such as?

Pretty much anything the client can do, such as setting ganis, setting clothes properties, firing weapons, or sending triggeractions.

A question occurred to me: If you sent such a packet that told the server you moved somewhere else, would it display this movement on your screen?

What vulnerability? The only requirement is an internet connection and an understanding of Graal's protocols.

My apologies; I chose a poor word there. 'Oversight' would be more appropriate.

[Kaimetsu]

Originally Posted by Lance

It isn't a viable option for everyone, though. Some people are stuck behind routers and cannot set up port forwarding for those UDP packets

Yes. But these are a minority.

The movement would be removed, sure. However, I already mentioned the problems with basing the safeguard on the actual speed

And I already responded thereto :-p

I'll attempt to clarify: Yes, the movement is a problem. However, I see it more as a symptom of another, perhaps more important problem

Which is what? Disconnected cables, high-frequency packets? How are either of these, in themselves, problems?

It certainly would be nice, yes. Unfortunately, such is not the case, so it remains unfeasible

Such could be the case. We both know that the best way to get Stefan to add something awesome is to find something that appeals to him and show him that it requires your suggestion to be added

Pretty much anything the client can do, such as setting ganis, setting clothes properties, firing weapons, or sending triggeractions

Mostly not too big a deal, as long as the server does some simple checking.

A question occurred to me: If you sent such a packet that told the server you moved somewhere else, would it display this movement on your screen?

I don't know exactly how Graal works, internally. But a suitably skilled user could always edit his client such that it does.

My apologies; I chose a poor word there. 'Oversight' would be more appropriate.

Well, it is still not something that you can simply "remove".

[ApothiX]

Originally Posted by Kaimetsu

I don't know exactly how Graal works, internally. But a suitably skilled user could always edit his client such that it does.

I don't think it would display your new position on your screen if you simply sent the packets. Most trainers source code I have seen simply edit the memory address for the player's x and y coordinates, and leave it up to the Graal Client to send the packets with the new position, so the memory editing is probably vital to the whole 'warping around' action.