Problems after the last SL update

Hello

I could not find a thread about this so i wil start it.
After the last SL update it seems a lot of things are messed up in world.
Vendors are not working anymore as the supposed to do.
The slingo games are not working anymore.
Mail is not working as it has to do.

And these are only the thing i have experienced.

Could you give us an update on this issues please?

Regards

Lucky Donaldo

yep me too, I've just had to take ALL my vendors offline

my servers are not finding all my vendors either

My animated benches are broken as well. Menu driven to change positions works some of the time, but when the av goes to stand up, it remains in the last sitting postion it was in on the bench. This can't be a good thing.

Edit: Found out if the av flies a short distance from being in the "stuck animation" it clears it.

How are your vendors supposed to work? Can you provide any more details?

edit mistake!

Please see this thread for more information. Thanks to everyone who helped us find the problem!

I have 1000s of units all around the grid that communicate via email and many what use XMLRPC. I'm not having any problems with the comms per-se, but functions that use llXorBase64Strings seem to behave differently. Namely, I think it now produces different results in some cases. I'm not certain yet - it could be llMD5String instead.

I'm still working to get a concrete example together.

The problem has been narrowed down to the llXorBase64Strings() lsl function. It prematurely stop xor-ing the binary character array if there are embedded nulls. This can happen when you xor a character with itself, eg:

secret = '104385'
password = 'abc321'

...which when xor'd will embed a NULL where the '3' appears in both strings.

This has been fixed and will be deployed once it has been more thoroughly tested.

Thanks Brent - a couple of things I was working on used that and I was wondering why it started failing - after a couple of people with vendor issues asked for my advice I was trying to narrow it down - I got it down to that and Email functions.

I'm glad it's that - I'll turn my projects off till it's fixed - but I know a LOT of vendors out there use this function to encode data sent back and forth.
I would say that there will be a substantial amount of people using networked vendors will be effected by this - and not all of them will be reading the forums - can they be told whats going on via an alternative method (MOTD perhaps in non-technical terms?)

You ain't kidding, I'd posted this last night, no-one had noticed by then.

I suspected encryption because it was the only common link between the vendors and the voting system.

hey ho ... just hope I don't have to wait another week before I can turn on the vendors again !

On a positive note - thats one way to see if certain vendor makers started encoding their data after a compromise

If it works - then nope!

We are on top of this and testing a fix as we speak. We will let you all know when we deploy the fix. Thanks for your patience, patients and patents! Heck, I'll throw Patton's in there too, for all you Jessieites.

Salvation is at hand! A rolling update is now underway and the XOR problem should be fixed across the grid today.

The rolling update is complete. The XOR problem is fixed and you should all be able to bring your vendor machines back online! Thanks for your patience!

Way To Go !

Unfortunately, though the behaviour may have changed, it still isn't correct or doesn't match the pre-1.9.0(1 behaviour.
[and hence I still have 1000s of devices accross the grid I can't contact!]

Here is a concrete example: (run the script code at end to see)

Xor these two strings:
1) "OnAxODcyMzRhYmNkZWZnaGkgYWJjZEBlZmdoLmlqa2wubW5v"
2) "QUJDREVGR0hJSktMTQ=="

and previous to the update you'd get:
"ezJyfHJ0dHwoKCgoKGJzTF1kNQYX4NTB0qO4byspLyloKiYm"

but now you get:
"ezJyfHJ0dHwoKCgoKCclKy1lJyUrLQouKiopbCouLippJScl"



PS: Notice the result string prefix is the same. Could it be that the new implementation is concatenating the 2nd argument to itself in string/byte form (i.e. on 8bit boundary), instead of concatenating the bit strings? (which may not be a multiple of 8 bits long). just an initial thought (that I'll look into).

PPS: Found the difference is due to s2 bit padding - see my later post.

        // Script snippet to test llXorBase64Strings

        // strings to Xor together
        string orig_cmdStr = "OnAxODcyMzRhYmNkZWZnaGkgYWJjZEBlZmdoLmlqa2wubW5v";
        string xorwith = "QUJDREVGR0hJSktMTQ==";
        
        // result
        string xor_cmdStr = llXorBase64Strings(orig_cmdStr,xorwith);

        // result obtained prior to 1.9.0(18) update
        string xor_cmdStr_prev = "ezJyfHJ0dHwoKCgoKGJzTF1kNQYX4NTB0qO4byspLyloKiYm";
        
        llSay(0,"llXorBase64Strings(\""+orig_cmdStr+"\", \""+xorwith+"\")=\""+xor_cmdStr+"\"");
        
        if (xor_cmdStr != xor_cmdStr_prev) {
            llSay(0,"FAIL.  pre 1.9.0(18) result was=\""+xor_cmdStr_prev+"\"");
        }
        else {
            llSay(0,"SUCCESS, behaviour matches pre 1.9.0(18)");
        }        

Thank you, I've forwarded this to a developer.

My main problem is that I need to be able to match the behaviour of the LSL implementation on my server end.
When I first implemented my version, I discovered that the examples, in several languages, posted to the LSL Wiki only matched the LSL implementation for a small subset of cases.
It took me quite a while to reverse engineer the LSL implementation to duplicate its behaviour.

Now that behaviour has changed

Any chance LL could just thow us out (or post to the llXorBase64String Wiki entry) a snippet of code that comes straight out of the LSL source base?

Then we would know how to duplicate the behaviour, regardless if it is correct/incorrect or different from previous versions.
If not, I guess I'll have to spend a lot of time reverse engineering your broken version (!).

Until I can match it, I have 1000s of devices across the grid and 100s of 'customers' that won't be happy about upgrading and loosing their data/income.

Would be appreciated.
Thankyou.

PS: I've emailed LL (Brent) my C# implementation for comparison. It isn't efficient (i.e. probably unsuitable for use in LSL VM), but does match the old behaviour (and I believe the intuitively correct behaviour).

I have tested the strings you passed in.

>>> base64.decodestring('OnAxODcyMzRhYmNkZWZnaGkgYWJjZEBlZmdoLmlqa2wubW5v');
':p187234abcdefghi abcd@efgh.ijkl.mno'
>>> base64.decodestring('QUJDREVGR0hJSktMTQ==')                             
'ABCDEFGHIJKLM'

And wrote a program to manually xor those two character arrays:

#include <iostream>
int main(int argc, char** argv)
{
	char s1[] = ":p187234abcdefghi abcd@efgh.ijkl.mno";
	char s2[] = "ABCDEFGHIJKLM";
	unsigned char* str1 = (unsigned char*)s1;
	unsigned char* str2 = (unsigned char*)s2;
	unsigned char x;
	while(*str1)
	{
		x = *str1 ^ *str2;
		std::cout << (int)x << ":" << x << " ";
		++str1;
		++str2;
		if(!*str2) str2 = (unsigned char*)s2;
	}
	std::cout << std::endl;
	return 0;
}

Which output:

123:{ 50:2 114:r 124:| 114:r 116:t 116:t 124:| 40:( 40:( 40:( 40:( 40:( 39:' 37:% 43:+ 45:- 101:e 39:' 37:% 43:+ 45:- 10:
 46:. 42:* 42:* 41:) 108:l 42:* 46:. 46:. 42:* 105:i 37:% 39:' 37:%

cryptic and difficult to read, but if we compare it to the output of the older version, it does not match. (!)

>>> base64.decodestring('ezJyfHJ0dHwoKCgoKGJzTF1kNQYX4NTB0qO4byspLyloKiYm')
'{2r|rtt|(((((bsL]d5\x06\x17\xe0\xd4\xc1\xd2\xa3\xb8o+)/)h*&&'

While comparing it to the output from the latest version, it matches.

>>> base64.decodestring('ezJyfHJ0dHwoKCgoKCclKy1lJyUrLQouKiopbCouLippJScl') 
"{2r|rtt|((((('%+-e'%+-\n.**)l*..*i%'%"

I rewrote the base64 lsl functions because it was possible to crash the older version. This walkthrough matches the basic process for the doing the xor.

1) decode s1
2) decode s2
3) iterate over all of s1, resetting s2 if it is shorter, and xor every byte.
4) encode the result of the iteration and return it

I think I've found what the updated LSL version is doing differently.

Here is the pseudo-code for what I was doing to be compatible with the old version:

a) s1 -> bit string
b) s2 -> bit string
c) pad s2 to a multiple of 6bits. (One base64 char - I don't know why the LSL function did this - bug?)
d) repeatedly concatenate s2 bit string to itself until longer than bit string for s1
(result may not be multiple of 8 bits)
e) Xor bit strings together
f) convert back to bytes & back to base64

If I skip step c) above, I get the same result as the current LSL implementation, post update.

The definition of the function in the LSL guide isn't very precise. So one might argue the new implementation is more 'correct' than the old, though different.
At least comms between in-world objects should be ok, as it is consistient.

Hope that help.
-Cenji.

I think this may be your difference. Because base64 encoding operates on 3 bytes at a time, there can be padding if s2 isn't a multiple of 3 bytes. I suspect the original code before the re-write xors the bit strings, not the byte strings. So, s2 gets repeated with padding - so could be 'reset' on any 6bit boundary, which might not be a multiple of 8bits.

Bascially, the old implementation just converted each Base64 character into 6bits and xor'd those. That isn't quite right because a base64 char at the end can include '0' bit padding to make it a multiple of 6 bits when the original byte sequence wasn't a multiple of 3 bytes long. (e.g. 2bytes = 8*2 = 16bits = 6bits*2 +4bits of pad).

While this straight-forward byte-to-byte based xor'ing is simpler and seems a more intuitive implementation (to least to me), it isn't what was implemented before.
(it was how I implemented it first, but promptly discovered it didn't match the LSL function. It took me several days to get right)

My comms between server and in-world is operational again after I switched my implementaion over to match what you have deployed now.
The only objects now effected by this change will be ones that have cached the result from pre-update (e.g. as a 'password' string or something - like some vendors).

So, I guess you have to evaluate the impact on existing scripts accross the grid that depend on the old behaviour in that way. Perhaps most problems can be addressed by residents resetting scripts or updating passwords - but I don't know what's out there

Cheers.

We try to evaluate the impact of changes like these in every instance. For example, I completely changed the implementation and definition of llBase64ToInteger and llIntegerToBase64 to resolve what I felt were problems serious enough for a complete rewrite. I also changed the behavior of on_rez and on_attach getting called after teleport since that was really a bug, and replaced that with the on_change for region and teleport.

In this case, I did not notice that the old version was doing 6-bit expansion and re-encoding. I would propose that the new behavior is better since it allows simpler integration with languages which do not support easy bit-twiddling and only requires a base64 library or implementation that works on character arrays. I sincerely apologize for not realizing how the old library worked. Other than llEmail and xmlrpc, ur internal tests are wholly in-world, so this change escaped detection.

I promise to never change from this basic implementation (decode strings, xor arrays, encode result) if you will accept it.

I can't dispute that the old library was incorrect, perhaps dreadfully so, but it was a bug that was broadly relied upon by just about every scripted device of commerce.

To my reading you are proposing that if the customers will accept your change - no matter how "incorrect" the old results were or how many scripts and commerce systems will have to be recoded - and have the customers (some of whom may no longer play SL) bear the cost of recoding, that the library call will not be modified in the future?

If I am understanding you correctly, insofar as an API is a "contract" between library and user it seems that you could take this principle one step back, retain the bug-for-bug compatibility, declare the old behavior "correct" and save much aggregate work. If the old behavior was so bad or imposes a grave limitation on future projects, would it not be more efficient to retain and deprecate the old function and instantiate the new under a new name? The ll*() namespace certainly has room left. Am I missing something?

Yes, I agree with that.


The new behaviour suits me personally, as I have already adapted to it (after I figured out what was different), but I am only one.

I think your decision about keeping this new behaviour or maintaining bug-for-bug backward compatibility (as Introvert put it), should be based on an evaluation of how much disruption it is causing residents accross the grid.

If it is going to cost hundreds or thousands of residents time to re-code their vendors, games and other devices, perhaps causing large sums of RL income loss, job loss and people to leave SL, then it wouldn't be worth the change just for esthetics, in my opinion.

However, while I don't follow all the forums closely, I can't hear too much noise at the moment - though it is possible residents haven't figured out why their devices aren't working yet.
Especially as the old and new behaviour are identical if s2 is a multiple of 3 bytes or is longer than s1.

For example, I know a lot of people use the popular JEVN line of netwoked vendors and are having a lot of trouble still. That could be carry-over from configuring/resetting them when the Xor truncation problem was still in effect though.
LL is in a better position to assess the damage.

Thanks for your responses.