LSL Protocol/Restrained Love Relay/Bugs and Pending Features

1.02

Version 1.02 reintroduces all the problems listed in 1.014.

Relay Crash in Ask mode

Description

A malicious objects scans for all avatars within the sensor range. For each avatar a new object is rezes out of the content. This objects sends 10 messages to the relay each of about 1000 characters causing sPendingMessage to overflow. After the 10 messages are send these objects die making tracking very difficult.

Note

Some relays accept commands from objects more than 20100 meters away so the attacking objects can be hidden far away.

Workaround

None

Open

although fixed in version 1.15 it was reintroduced by the revert in version 1.02

1.015

The below problems are fixed here

1.014

The following problems occured in version 1.014 and have been fixed:

Stuck: Accepting Permission Dialog after !release

Discovered by

Maike Short

Workaround

Don't accept requests after you have been freed. In case it happend, reenter the cage / sit down again; relog.

Fixed

in 1.015

Force Sit during Login on the control object instead of the forced-sit one

Discovered by

Azoth Amat

Workaround

Always send a "@sit:<id>=force" command if you want a forced sit on relog, even if the victim is already sitting.

Fix

change in timer(): sendRLCmd ("@sit:"+(string)kSource+"=force"); to sendRLCmd ("@sit:"+(string)lastForceSitDestination+"=force");

Note

This prevents @unsit to work in case the person set down without being forced if the furniture in question hasn't sent a @sit:<id>=force command. (This should probably be considered a bug in the furniture, not the relay.)

Fixed

in 1.015 (but that fix breaks other things, forcing sits when not appropriate), and 1.02 if the workaround above is used

Stuck on crash/relog with objects asking for relay upon being sat on

Discovered by

Gregor Mougin

Problem

Many objects check for presence of a relay and the RR viewer by asking for the !version when sat on. If the user crashes, and the object was used by someone else in the meantime (or, for testing, reset), the relay enforces all previous restrictions whereas the object doesn't know of them.

Workaround

none

Suggested fix

<lsl> --- RLV_v1.014a 2008-07-06 23:17:14.000000000 +0200 +++ RLV_v1.014a-xxx 2008-07-06 23:18:32.000000000 +0200 @@ -545,10 +545,16 @@

                loginPendingForceSit = FALSE;
                releaseRestrictions();
            }

- else - { - sendRLCmd ("@sit:"+(string)kSource+"=force"); - } + // XXX + // DON'T do it here + // Some (many?) objects ask the relay for the !version upon + // sitting on it. Since the !version is interpreted the same + // as !pong, the relay would think the object is still available + // and put all restrictions on the wearer unconditionally. + //else + //{ + // sendRLCmd ("@sit:"+(string)kSource+"=force"); + //}

        }
 
        if (!loginPendingForceSit && !loginWaitingForPong)

@@ -583,6 +589,18 @@

            loginWaitingForPong = FALSE; // whatever the message, it is for me => it satisfies the ping request
 

+ // XXX + // force sit here instead of unconditionally in the timer event + if (loginPendingForceSit) + { + integer agentInfo = llGetAgentInfo(llGetOwner()); + + loginPendingForceSit = FALSE; + if (!(agentInfo & AGENT_SITTING)) + sendRLCmd ("@sit:"+(string)kSource+"=force"); + } + // end XXX +

            if (!isObjectKnow(id))
            {
                debug("asking for permission because kSource is NULL_KEY");

</lsl>

Fixed

in 1.015 by specially looking for the !pong reply so that the fix works for cages as well (no "force sit" in this situation but a collision detection which is triggered on login, too).