sl_proxy 1.10.1 is released.

sl_proxy 1.10.1 is released.

Download is http://www.nsl.tuis.ac.jp/xoops/modules/d3downloads/index.php?page=singlefile&cid=4&lid=1
Wiki is http://www.nsl.tuis.ac.jp/xoops/modules/xpwiki/?sl_proxy%20%28E%29

May I make a suggestion? Rather than using symbolic links for the files that are shared between subdirectories, make instead a common lib or include path. When untarring, some operating systems do not re-create symbolic links correctly.

Hi kittin,

The date management will become troublesome if files are copied.

Is it Windows XP or others?
Does Windows XP (or others) support Hard Link?

Thanks.

Specifically, I was untarring on Windows 7 with the latest Cygwin. Mac and Linux performed fine.

To fix it locally, I just re-created the links. Yes, Windows NTFS supports hard links, I believe. I don't think FAT32 does. I don't have much experience with hard links in Win32. There is no command like 'ln' that is distributed with Windows that I know of. There is some information here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx

Could the configure step build the symbolic links? Autotools support some custom steps based on OS. I had a Cygwin linking problem and did some cygwin-specific stuff here: http://code.google.com/p/rlvibe/source/browse/trunk/configure.ac

ummmm,

Windows vista and 7 are supported symbolic.
-----
C:\>mklink
Creates a symbolic link.

MKLINK [[/D] | [/H] | [/J]] Link Target

/D Creates a directory symbolic link. Default is a file
symbolic link.
/H Creates a hard link instead of a symbolic link.
/J Creates a Directory Junction.
Link specifies the new symbolic link name.
Target specifies the path (relative or absolute) that the new link
refers to.

The links aren't being restored correctly when untarring. Worse, it's not even consistent.

For example:

/tmp> uname -a
CYGWIN_NT-6.1 calypso 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
/tmp> md5sum sl_proxy-1.10.1.tar.gz
aceb3f8d36650da969a2b516ea9afd01 *sl_proxy-1.10.1.tar.gz
/tmp> tar xzf sl_proxy-1.10.1.tar.gz
/tmp> find . -size 0b -iname "*.h"
./sl_proxy-1.10.1/sl_voice_relay/sip_forwarder.h
./sl_proxy-1.10.1/sl_voice_relay/sip_fwdmain.h
./sl_proxy-1.10.1/sl_voice_relay/sl_tools.h
/tmp> find . -size 0b -iname "*.c"
./sl_proxy-1.10.1/sl_cache/sl_command.c
./sl_proxy-1.10.1/sl_cache/sl_tools.c
./sl_proxy-1.10.1/sl_cache/tools/sl_tools.c
./sl_proxy-1.10.1/sl_info/tools/sl_info_tools.c
./sl_proxy-1.10.1/sl_voice_relay/sip_fwdmain.c
./sl_proxy-1.10.1/sl_voice_relay/sl_command.c

And then doing it again:

/tmp> rm -rf INSTALL JunkBox_Lib junkbox_lib-1.3.0/ sl_proxy-1.10.1
/tmp> ls
sl_proxy-1.10.1.tar.gz
/tmp> tar xzf sl_proxy-1.10.1.tar.gz
/tmp> find . -size 0b -iname "*.c"
./sl_proxy-1.10.1/sl_info/sl_tools.c
./sl_proxy-1.10.1/sl_info/tools/sl_info_tools.c
/tmp> find . -size 0b -iname "*.h"
./sl_proxy-1.10.1/sl_cache/sl_relay_cache_io.h
./sl_proxy-1.10.1/sl_voice_relay/sl_tools.h

Since the behavior is inconsistent, the conclusion is that symbolic links within a tar under Cygwin in Windows 7 (and probably any other version of windows) are unreliable. Therefore, if you wish to support Cygwin, don't use symbolic links. If you don't want to support Cygwin, then this is academic.

I'm not sure if this is a Firestorm or sl_proxy-1.10.1 problem, but I entered a bug on the Firestorm Jira and am copying it here. There is a problem with seeing links.

Please see http://jira.phoenixviewer.com/browse/FIRE-3674 for a screenshot example.

Hi kittin,

If there is no error with no use sl_proxy.
And if there are errors with use sl_proxy.

So, in this case, this is problem of sl_proxy.
It is not responsible for FireStorm at all.

I'll check this problem. But, sorry, I am very busy now ..... :(

Thank you. Yes, I understand "very busy"! I am also very busy right now, too.

Hi Kittin,

I am sorry to have kept you long waiting.

I am analyzing the problem now.

Please wait a little more.

Hi

Same error are occurred in OpenSim(0.7.2) and it is not using sl_proxy.
http://www.nsl.tuis.ac.jp/xoops/modules/d3xcgal/albums/userpics/10001/normal_FS.jpg

It seems that FireStome writes slurl_base to grids.user.xml automatically, when it connects to not SL.
And I think that slurl_base is not specified by gridinfo protocol.

Can FireStome specify slurl_base (and app_slurl_base) by gridinfo protocol?
If it is so, please edit /usr/local/etc/sl_proxy/sl_gridinfo.xml



By the way, I find typo mistake now. sorry.

default /usr/local/etc/sl_proxy/sl_relay.conf L50


But, if you correct this, a above problem will not be solved.

Due to a change in SL, there's now a problem with sl_proxy. It is no longer possible to edit and save notecards or scripts.

Errors show up on save. Example:

Unable to upload 830ca006-2f82-8b00-85fe-e306e234e59 due to the following reason: Please try again later.

I've confirmed this happens in both the Standard LL viewer as well as Firestorm. Connecting directly, without sl_proxy, and the problem goes away.

Thank you for your Bug report.

I will check it.

Hi kittin,

I mistook processing of HTTP chunk mode when gzip Content-Encoding is used.
I corrected it, and will update package. Please wait a moment.


By the way, I received "HTTP/1.1 200 None" header message from Apache Server(Debian) of Linden, when notecard is updated.
Usually, it must be "HTTP/1.1 200 OK".
I saw "200 None" message for the first time.
Does someone know the meaning of "200 None"?

It is my understanding that 200 is the value you are interested in. "None" or "OK" is simply TEXT information and can safely be ignored. Software should react to the HTTP code, the TEXT is just human-readable information.

Quote:
Thanks
1.10.2 was released.

Yes, I upgraded my server to 1.10.2 last night and tested building on both Mac and Cygwin. Both systems compiled without any problems. Tested under Mac and found I could edit and save notecards again. Yay! Thank you!

Another new problem. Firestorm 4.1.1 (28744) has been released. It now complains:

Could not add 192.168.1.11 to the grid list.
Server didn't provide grid info: 499 STATUS_EXPIRED
Please check if the loginuri is correct and contact support of 192.168.1.11.

192.168.1.11 is my sl_proxy host.

I am going to install latest FireStorm.

Hi kittin,

When FireStorm 4.1.1 connects to SL, it adds "/cgi-bin/login.cgi" to Login URL automatically.
So, You can not input "/cgi-bin/login.cgi" at "Add new grid" field.

I corrected sl_relay that it adds "/cgi-bin/login.cgi" to Login URL automatically, too.
1.10.3 will be released soon.

Please input "http://192.168.1.11:8100" at "Add new grid" field without "/cgi-bin/login.cgi".


added code:

Thanks.

1.10.3 is released now.

sl_proxy 1.10.4 is working great. However, Mesh doesn't seem to be working right. Using Firestorm, if I connect directly, I can see mesh fine. If I connect via sl_proxy, mesh either will not show, or doesn't show at the right LOD level.

Note, I had to modify Firestorm to not treat sl_proxy as OpenSim in fsgridmanager.cpp.

I wanted to test this with the original viewer, but --loginuri no longer seems to be a valid startup parameter.

Hi,

Ummm... ?

My firestorm-4.2.2 and sl_proxy-1.10.4 are working well.

http://www.nsl.tuis.ac.jp/xoops/modules/d3xcgal/index.php?page=displayimage&pid=903&fullsize=1

How is your firestorm displayed?

Quote:
What is fsgridmanager.cpp ?
I can not find fsgridmanager.cpp in source code of 4.2.2.29837

I'm sorry, fsgridhandler.cpp. indra/newview/fsgridhandler.cpp

I've turned on a few additional features (hardware skinning, I think) and can see Objects. I did find some additional settings to make viewing rezzed Mesh Objects visible without difficulty.

However, worn mesh objects appear 100% transparent. I'm never able to see them when connected through sl_proxy. ...the next time I'm someplace where someone is wearing mesh, I'll take a screenshot. I cannot see mesh hair, mesh clothing -- anything attached to an avatar.

But, one interesting bit of data is I can see the mesh object if it has first been rezzed on the ground, picked up, and then worn. It's very strange.

If I connect directly and see worn mesh, then reconnect with sl_proxy, the locally cached mesh object is rendered correctly.

Hi,

OK. I will check it.

--
By the way,
Quote:
I don't understand your environment, sorry.
Do you use SL or OpenSim?
If you use re-compiled Firestorm, you can specify HAS_OPENSIM_SUPPORT option with autobuild command.
So, gridmanager will be available.

Thanks.

I am using SL. Because I connect to sl_proxy with the gridhandler, it assumes I'm not on SL and in OpenSim. L$ becomes OS$ and search is redirected to MetaVerse, etc.

I made a change to force isMainGrid() to always return true and isOpenSim() to return false. ((this is from memory, so the method names may not be correct)). This was the only way I could get profiles to display properly. Otherwise, instead of usernames I got hop://10.0.2.2:8100/..... Please see: http://jira.phoenixviewer.com/secure/attachment/14084/Fire-SS.png

I think the major problem is this: http://www.hypergridbusiness.com/2012/08/linden-lab-cuts-viewer-link-to-opensim/ And Firestorm believing that sl_proxy is an OpenSim implementation, not the main grid.

I see

I will try to build environment that is same your environment.

Thanks.

Here are the screenshots of a mesh shirt. Screenshot 1 is with sl_proxy.
https://docs.google.com/open?id=0Bzpb75eLPfp1NThKQ3RSY2xKZDg

Screenshot 2 is directly connecting to SL without sl_proxy.
https://docs.google.com/open?id=0Bzpb75eLPfp1cUN3dWw1RkdlZkk

I can send you a copy of the shirt in SL if you'll IM me (Kittin Ninetails).

These are the changes I made to firestorm:

diff -r 9c50e8d76194 indra/newview/fsgridhandler.cpp
--- a/indra/newview/fsgridhandler.cpp Sun Sep 02 17:25:54 2012 +0200
+++ b/indra/newview/fsgridhandler.cpp Sat Sep 22 14:21:59 2012 -0700
@@ -178,7 +178,7 @@

// <AW opensim>
LLGridManager::LLGridManager()
-: mIsInSLMain(false),
+: mIsInSLMain(true),
mIsInSLBeta(false),
mIsInOpenSim(false),
mReadyToLogin(false),
@@ -1250,7 +1250,7 @@
// <AW opensim>
void LLGridManager::updateIsInProductionGrid()
{
- mIsInSLMain = false;
+ mIsInSLMain = true;
mIsInSLBeta = false;
mIsInOpenSim = false;

@@ -1291,8 +1291,8 @@
return;
}

- LL_DEBUGS("GridManager")<< "uri: "<< login_uri.authority() << " set IsInOpenSim" << LL_ENDL;
- mIsInOpenSim = true;
+ //LL_DEBUGS("GridManager")<< "uri: "<< login_uri.authority() << " set IsInOpenSim" << LL_ENDL;
+ mIsInSLMain = true;
}
// </AW opensim>

It's interesting that if I wear the mesh, it sometimes shows up. If someone else is wearing mesh, I rarely if ever see it.

Hi Kittin,

Thank you for the shirt.
But I can not recognize the problem.
http://youtu.be/pHkQ5FAbSsE

Have I overlooked some?


----
By the way.

I read fsgridhandler.cpp, and I noticed.

If you specify "http://10.0.0.2:8100/" without ''cgi-bin/login.cgi" as Login URI at "OpenSim" Menu, I think that you do not see x-grid-location-info:: string like http://jira.phoenixviewer.com/secure/attachment/14084/Fire-SS.png

In my case: http://www.nsl.tuis.ac.jp/xoops/modules/d3xcgal/albums/userpics/10004/SL_Proxy.png

Do I mistake?

No, I don't think you've overlooked anything. I don't understand why it appears to work for you but doesn't for me.

Yes, since 1.10.4, I've been able to drop the cgi-bin/login.cgi portion and things are working fine. Yet to avoid having my search going to MetaVerse, I still have to make my changes to fsgridhandler.

I'm not sure what steps to take next. I've seen completely invisible avatars because they're wearing mesh and I'm not able to see them when connecting through sl_proxy. But if I'm the only one affected by this, then it's a minor issue.

Hello, it's me again! Your favorite neko!

A slightly different bug with scripts has popped up. Saving a notecard and script works.
However, if there is an error in the script, like a missing ; then the error message is "Failed to upload UUID" rather than what should be "(4, 0) : ERROR : Syntax error" for a ; missing on line 4.

I don't think I noticed this before because I usually write my LSL in LSLEditor and then upload to test. Now that I'm on a Mac almost all the time, I can't use LSLEditor, so found this bug.

I've confirmed that connecting directly into SL does not produce this error.

Hi kittin,

I have recognized this problem.
I'm researching about this problem, now.

Please wait.

Thanks.

I checked HTTP packets.

Post from viewer is

And answer from SL is

Ummm.... Bracket <> is not closed, and answer length is just 180byte.
I think that perhaps this is bug of SL server.

I will modify my XML library to able to parse this xml.

I correct.

Answer message is gzip.

My ungzip code may be wrong.....

Hi Kittin,

At last, it seems that answer gzip packet from SL server is broken.
I modified XML and HTTPS receiving Library.

Please use http://www.nsl.tuis.ac.jp/DownLoad/SoftWare/Linux/sl_proxy-1.10.5.tar.gz

But, it may have any side effects.
If you find other bugs, please teach me.

Thanks

Thank you! I will test it and let you know.

=^.^=

So far, so good! I've not had any trouble yet.

Here are some notes I took for how to install on Mac OS X Mountain Lion (10.8.2).

First, install Xcode command-line tools.
Second, install Mac Ports and add a package that needs X11, such as gimp or wine.
sudo port install gimp
Third, edit configure.ac in junkbox and add -I/opt/local/include -I/opt/local/include/X11
Forth, mkdir -p /usr/local/bin /usr/local/etc /etc/init.d

Finally, build and install as usual.

)\._.,--....,'``.
/, _.. \ _\ ;`._ ,.
fL `._.-(,_..'--(,_..'`-.;.'

Thanks

I've found a problem. It's a little difficult to explain. Normally, I run sl_proxy on my Mac Mini, which acts as a network gateway. It has two NICs in it: 192.168.1.11 and 10.0.2.2. My Mac Pro is where I run my client. It's 10.0.2.*, on DHCP. I start sl_proxy daemons on the Mini with the -i 10.0.2.2 parameter. All of your changes recently are working fine in that setup.

However, if I run sl_proxy on my Pro, the same system that my client runs on, I have upload problems again. I've tried starting with and without the -i parameter. I have more luck connecting to SL with -i 127.0.0.1. But I can't edit notecards or scripts.

The Mac Mini is running OSX 10.6 while my Pro is running 10.8. Just to be sure, I copied the binaries I build on 10.6 to my 10.8 machine and have the same problems.

Unfortunately, my normal ISP is down at the moment and I'm using my cellphone to connect to the internet. I would like to test running sl_proxy locally, but still using my mini as the gateway and see if that works.

Are there any log files I can send you? I don't know where to look for the errors you were seeing. And I'm not familiar enough with Mac yet to know what tools exist like tcpdump and wireshark.

Hi,

Is it such things?

Quote:
Does "upload problems" mean that you can not see error message of LSL, or you can not upload image data?

If your Mac Pro has only one network interface, you must not specify -i option.
How details of the problem at this case (without -i option)?


Quote:
Please send me output of sl_relay with -d option.
And when you execute sl_relay with -xt option, sl_relay outputs full HTTP packets at working folder.
But it is a lot of data. Please attach to e-mail and send.
My e-mail address is iseki@solar-system.tuis.ac.jp

Please try to use
http://www.nsl.tuis.ac.jp/DownLoad/SoftWare/Linux/sl_proxy-1.10.6.tar.gz

I add -lm option. That means sl_proxy and Viewer are executed at same PC.
But this is non-secure mode.

Thanks.