Dear Jeetu,
it looks like the hash check for plugins.
I guess you have to allow/approve the new hash once in the gui.
And then it should also pass the nogui-client check(which seems to miss the
functionality to ask for approval).
?Anyway have you received my mail which was sent directly to you(instead to the
mailing list?) . Afaik also Gio wrote to you.
Best regards
Cave
Am 24. Oktober 2016 12:30:36 MESZ, schrieb "jeetu.gol...@gmail.com"
<jeetu.gol...@gmail.com>:
>Hi,
>
>As stated in my last mail, when I run retroshare-nogui, it rejects my
>plugin with the following message :
>
>RsPluginManager::loadList():
> Reference executable hash: 2bf0bcb5ace17e7dfad6681b051ff083cee1e531
> Accepted hash: 89dc2a00adae7a2b4e7bce01d287b6457b3d8eea
>(WW) Executable hashes do not match. Executable hash has changed.
>Discarding the list of accepted/rejected plugins.
>Found plugin /home/jeetu/.retroshare/extensions6/libEmptyPlugin.so
> Loading plugin...
> Loading plugin /home/jeetu/.retroshare/extensions6/libEmptyPlugin.so
> -> hashing.
> -> hash = 89dc2a00adae7a2b4e7bce01d287b6457b3d8eea
> -> hash rejected. Giving up plugin.
>Examined a total of 1 plugins.
>PluginManager: saving list.
>Saving current executable hash:
>537e4a87038d4b18df08f9ab00b0ef7069e82985
> 89dc2a00adae7a2b4e7bce01d287b6457b3d8eea : REJECTED
>
>
>Is there something I need to do in my plugin to get it to work within
>retroshare-nogui?
>
>I need to test out this plugin with retroshare running in headless
>mode.
>
>Would appreciate if someone could help me here.
>
>Thank you.
>
>Regards,
>Jeetu
>
>
>
>On Mon, Oct 17, 2016 at 7:20 PM, jeetu.gol...@gmail.com
><jeetu.gol...@gmail.com> wrote:
>> Hi Cyril,
>>
>> *Warning - a really really long read below, am truly sorry for that*
>>
>>>I suggest that you use your SSH tunnel manually: send clear packets
>with some ID in them (packet
>>>number, whatever you prefer)
>>>and make sure that you get them all on the other end of the tunnel,
>without major delay. Normally
>>>this should work,
>>
>> I have been trying to get my head around this issue (yet). I have
>been
>> taking a lot of trials, including what you suggested above. The
>> following are my findings :
>>
>> - I wrote a python client and server to stress test the tunnel in a
>> few ways and didn't find anything untoward. Of course, one thing I
>> would probably like to do at some point is repeat this along with a
>> hash of each packet being sent to verify integrity of data. Right
>now,
>> my tests were a little crude.
>>
>> - SSH X Forwarding through my tunnel works absolutely well if I am
>> using the Chromium browser remotely, for some strange reason. It
>> routinely fails with gnome-calculator, gedit, libreoffice.
>>
>>
>> - I have been in discussion with the Xorg team too to see if this had
>> any co-relation with a possible graphics and / or the X server and
>> they have been very helpful and we have tried out various tests to
>> check if this was related to GL, etc. Have tried different desktop
>> environments - Xfce, Enlightenment,etc. So far all of that has turned
>> up empty.
>>
>>
>> - I have collected Wireshark data to see what is happening on the
>> wire. These packets show that failure always occurs (so far) when :
>>
>> SSH Server sends a packet (Usually 118 bytes) -> this gets received
>by
>> the SSH client through the tunnel.
>> The SSH Client then sends a packet (Usually 166 bytes) -> this gets
>> received by the SSH server through the tunnel
>>
>> From here on there is a lot of traffic going on where the SSH client
>> keeps sending stuff to the RS tunnel port on the same machine,
>however
>> this data doesn't get received by the server.
>>
>> The SSH server also sends a few packets down the pipe, but these
>don't
>> get received by the client.
>>
>> *The above is (almost) consistently what I see when the desktop has
>> frozen and I stop recording Wireshark data.*
>>
>> Please feel free to ask for the wireshark data if need be.
>>
>>
>>
>> - What is most interesting, and this is what I realized just this
>> weekend, is that the following network configurations causes the X
>> forwarding over my RS tunnel to predictably and consistently either
>> succeed or fail :
>>
>> Scenario a)
>>
>> Machine 1 - Desktop with Debian Unstable; acting as X Server; SSH
>> client connects to this end of the RS tunnel
>>
>> Machine 2 - Laptop with Debian Testing; hosts the X clients, SSH
>> server is at this end.
>>
>> Result : If the program being run is Chromium or something simple
>like
>> xterm, sclock all is well, otherwise the X client will surely hang at
>> some point.
>>
>> Scenario b)
>>
>> Machine 1 (Host VM) - Desktop with Debian Unstable as host;
>> Retroshare's GUI and my tunnel plugin will run here; neither SSH
>> client nor server will run on this machine.
>>
>> Machine 2 (Guest VM) - Ubuntu / Debian Testing / Debian Unstable as
>> guest in a VM; SSH client will connect from here to the RS tunnel end
>> point on Machine 1. X server will be inside the VM.
>>
>> Machine 3 - Laptop with Debian Testing; hosts the X clients, SSH
>> server is at this end.
>>
>> Result: All applications will work absolutely perfectly without
>hanging at all.
>>
>> Scenario c)
>>
>> Machine 1 (Guest VM) - Ubuntu / Debian Testing / Debian Unstable as
>> guest in a VM (OS is same as above); RS GUI and my tunnel plugin will
>> run inside the VM; SSH client connects to this end of the RS tunnel;
>> X server will be inside this VM.
>>
>> Machine 2 - Laptop with Debian Testing; hosts the X clients, SSH
>> server is at this end.
>>
>> Result : If the program being run is Chromium or something simple
>like
>> xterm, sclock all is well, otherwise the X client will surely hang at
>> some point.
>>
>>
>> Scenario b) had lead me to believe this could be an issue related to
>X
>> server, GL / GLX or the graphics drivers running on bare metal with
>> accelerated graphics, however Scenario c) behaving exactly like
>> Scenario a) puts a spanner in the works to that theory.
>>
>> I am unable to see the full picture here. If my tunnel is faulty then
>> why work in Scenario b)? Why do things fail in configuration such as
>> Scenario c) and a)?
>>
>> One co-relation "could" be that as soon as the X server is the same
>> as the machine with the RS GUI things fail. Yes I know this is a
>> stretch.
>>
>> The RS client is a Qt client and could it be that when the X server
>> for the remote X client is on the same machine there is a lock up
>> somewhere causing a freeze. I really don't know how / why this could
>> be....but am desperate.
>>
>> To rule out the above I wanted to run RS in non-gui mode with my
>> plugin coming up and then try out the tests.
>>
>> When running retroshare-nogui however my plugin doesn't come up. I
>see
>> the following on the console :
>>
>> Found plugin /home/jeetu/.retroshare/extensions6/libEmptyPlugin.so
>> Loading plugin...
>> Loading plugin
>/home/jeetu/.retroshare/extensions6/libEmptyPlugin.so
>> -> hashing.
>> -> hash = 89dc2a00adae7a2b4e7bce01d287b6457b3d8eea
>> -> hash rejected. Giving up plugin.
>> Examined a total of 1 plugins.
>> PluginManager: saving list.
>> Saving current executable hash:
>537e4a87038d4b18df08f9ab00b0ef7069e82985
>> 89dc2a00adae7a2b4e7bce01d287b6457b3d8eea : REJECTED
>>
>>
>> I'm probably doing something wrong and I admit I haven't gone through
>> the manual in depth to figure out if I need to change my plugin in
>> some way to run with RS-nogui. Could you please let me know how I can
>> get the plugin to work in headless mode.
>>
>> Also I would really appreciate any thoughts on any of the above? I
>> have no clue where to turn from here.
>>
>>
>> Once again, truly apologise for the extremely long read above. Been
>at
>> it for months now and had a lot to report :)
>>
>> Thank you for your time.
>>
>> Regards,
>> Jeetu
>>
>>
>> On Sat, Jul 30, 2016 at 11:13 PM, jeetu.gol...@gmail.com
>> <jeetu.gol...@gmail.com> wrote:
>>> Hi Cyril,
>>>
>>> Thanks for the reply.
>>>
>>> Yes this sounds like a good strategy. I will try to go ahead and
>build a
>>> python based program that will stress tests this tunnel with packets
>of
>>> varying sizes in a bi-directional fashion. Hopefully I will be able
>to
>>> reproduce this error and we can come closer to understanding where
>the
>>> problem lies.
>>>
>>> Thank you for your help thus far and your offer to look at
>libretroshare :)
>>>
>>> Regards,
>>> Jeetu
>>>
>>>
>>> On 28 Jul 2016 13:45, "Cyril Soler" <cso...@users.sourceforge.net>
>wrote:
>>>>
>>>> I suggest that you use your SSH tunnel manually: send clear packets
>with
>>>> some ID in them (packet
>>>> number, whatever you prefer)
>>>> and make sure that you get them all on the other end of the tunnel,
>>>> without major delay. Normally
>>>> this should work,
>>>> but if it does not, and if you're able to create a working
>prototype that
>>>> shows the bug, I can take
>>>> a look at libretroshare to find the problem for you.
>>>>
>>>> Otherwise, because problems occur mainly when X is used, it might
>be that
>>>> X expects some particular
>>>> params of the SSH connection (which you get probably when doing
>"ssh -X or
>>>> ssh -Y" but not using
>>>> your own tunnel system). It's probably worth looking into this.
>>>>
>>>> On 28/07/2016 10:04, jeetu.gol...@gmail.com wrote:
>>>> > Hello Cyril,
>>>> >
>>>> > To report back, I tried out the latest RS master codebase from
>github
>>>> > with my plugin as per your suggestion. Unfortunately the issue is
>>>> > still the same.
>>>> >
>>>> > While I said earlier most of the times (say 90%) the failure
>occurs
>>>> > when there are many small bytes of approx 172 bytes following by
>>>> > something like 7556 bytes or some such number (usually above 3000
>>>> > bytes).
>>>> >
>>>> > However, there are instances when the freeze-up occurs with a
>>>> > relatively short number of bytes....maybe as low as 60 or 70
>bytes. So
>>>> > when I tried running gedit, during startup itself, the ssh client
>end
>>>> > froze. While most of the time I will get the main interface
>window to
>>>> > the X client and it freezes somewhere along the line, there are
>also
>>>> > moments such as these when it just hands early on itself.
>>>> >
>>>> > I also tried to log in to just a SSH console session via the RS
>tunnel
>>>> > plugin and did a "du" on my root directory just to generate a lot
>of
>>>> > text traffic in the form of file names scrolling as du goes
>through my
>>>> > directory. This worked fine and didn't baulk. However this
>situation
>>>> > is a little different from a SSH X forward since here there is
>only
>>>> > unidrectional traffic (from ssh server to ssh client). Whereas
>with a
>>>> > SSH forward there is a lot of bi-directional traffic. Dunno if
>that
>>>> > helps, just trying to get as many clues as possible,
>>>> >
>>>> > I am also not using any message queue or buffer within my own
>code, so
>>>> > as information comes in from ssh client or server I push it down
>the
>>>> > pipe via sendItem. Not sure if somehow the information coming in
>from
>>>> > these ends is going out of sync and causing a freeze-up.
>>>> >
>>>> > Your suggestion of this being related to the bug you had closed
>>>> > wherein the SSL stream would lock up on occasion waiting for
>another
>>>> > packed, definitely seemed to fit the profile of the above
>behaviour.
>>>> >
>>>> > Is there some other way we can capture additional data from
>within RS
>>>> > that would help you confirm or rule out if this problem still
>persists
>>>> > or that would help us concretely ascertain if my code is messing
>up
>>>> > things or not?
>>>> >
>>>> > Since the SSH traffic is all encrypted, I am unable to verify if
>the
>>>> > data itself gets corrupted somewhere along the line. Though if
>that
>>>> > were to happen the SSH client / server should cut off connection
>with
>>>> > a bad MAC / bad HMAC / Bad Packet Length or some such message if
>I
>>>> > understand it correctly. Though to rule this out I am considering
>>>> > building a python client and server that will try to push through
>>>> > controlled data to and fro this pipe, and try to replicate this
>>>> > freeze....hopefully something there will then be able to clarify
>if
>>>> > data corruption is occurring and is the problem.
>>>> >
>>>> > As you can say I am fast approaching a state where I am desperate
>for
>>>> > ideas ;).....any help or suggestion would help my sanity to a
>great
>>>> > deal :)
>>>> >
>>>> > Thank you so much for your time and help :)
>>>> >
>>>> > Bye for now.
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Jul 25, 2016 at 11:46 PM, jeetu.gol...@gmail.com
>>>> > <jeetu.gol...@gmail.com> wrote:
>>>> >> Hi Cyril,
>>>> >>
>>>> >> Thank you so much for taking the time to reply :)
>>>> >>
>>>> >>> This does not seem like a crazy amount of traffic either. I'm
>not sure
>>>> >>> which >version of RS you're
>>>> >> I've been working with RS v0.6.0
>>>> >>
>>>> >>> using, but a few weeks ago, I fixed a bug that would cause SSL
>packets
>>>> >>> to >hang in the pipeline until
>>>> >>> a new packet arrives. This could be the reason as your X server
>is
>>>> >>> maybe >waiting for the stream to
>>>> >>> reach a given point before continuing.
>>>> >> Oh wow :) so there is hope :).....I shall download the latest
>master
>>>> >> of RS and try again with that....will keep you posted on the
>progress
>>>> >> I make :)
>>>> >>
>>>> >>> As I understand, you developed a RS service that streams SSL
>>>> >>> connection >binary items through RS
>>>> >>> friend connections?
>>>> >>> You're most probably using RsItem objects then. Their size is
>limited
>>>> >>> to >262144 bytes. Any packet
>>>> >>> larger gets dropped.
>>>> >> Yes I have been using RsItem objects...and this explains so much
>>>> >> :).....is there some other class object I should use wherein
>this
>>>> >> limit is not there / or more relaxed? Though at this moment this
>isn't
>>>> >> a problem for me since I chunk the data and then send it.
>However it
>>>> >> would be good to know what my options here are :)
>>>> >>
>>>> >>
>>>> >> This definitely has given me quite a bit of clarity and
>hope.....I
>>>> >> shall try with the latest code and well fingers crossed
>:)....will
>>>> >> report back asap.
>>>> >>
>>>> >> Thank you.
>>>> >>
>>>> >> Bye for now
>>>> >>
>>>> >>
>>>> >> On Mon, Jul 25, 2016 at 7:51 PM, Cyril Soler
>>>> >> <cso...@users.sourceforge.net> wrote:
>>>> >>> Hi!
>>>> >>>
>>>> >>> Congrats for your project!
>>>> >>> It's nice to see that you managed to develop a plugin! See
>below some
>>>> >>> possible answers to your problem:
>>>> >>>
>>>> >>> On 25/07/2016 08:09, jeetu.gol...@gmail.com wrote:
>>>> >>>> Hi everyone,
>>>> >>>>
>>>> >>>> First, let me thank all of you for giving us Retroshare. Works
>>>> >>>> beautifully :) Thanks.
>>>> >>>>
>>>> >>>> I am one of the developers of the open source project
>eBrainPool
>>>> >>>> (http://ebrain.in) and for this project I have been toying
>with a RS
>>>> >>>> plugin that will allow me to tunnel SSH traffic between RS
>users. The
>>>> >>>> idea is to SSH forward X clients tunneled via RS.
>>>> >>>>
>>>> >>>> I have extended the EmtyPluginRS and taken inspiration from
>the VOIP
>>>> >>>> plugin to extend Retroshare 0.6.0.
>>>> >>>>
>>>> >>>> I have managed to successfully create a tunnel between two end
>points
>>>> >>>> - it's a very dirty hack - but I can essentially do a ssh
>login and
>>>> >>>> work within a console session without any problem. SSH
>forwarding of
>>>> >>>> simpler X clients such as xclock, xcalc,etc work without any
>issues
>>>> >>>> either.
>>>> >>>>
>>>> >>>> With more sophisticated X clients such as gnome-calculator,
>gedit,etc
>>>> >>>> somewhere along as I use it, my ssh client with the entire X
>>>> >>>> environment freezes up. This usually happens when huge amounts
>of
>>>> >>>> data
>>>> >>>> need to be sent together by the SSH client. For e.g. if a
>button is
>>>> >>>> pressed in gnome-calculator then at times it is liable to
>freeze up.
>>>> >>>>
>>>> >>>> On further investigation I have realized that the button press
>>>> >>>> translates to a huge number of messages coming in from the SSH
>client
>>>> >>>> of 170 bytes or so and a final message of approx 3556 bytes or
>so
>>>> >>>> before things freeze up. I then have to kill my ssh client in
>console
>>>> >>>> to regain access to my X environment.
>>>> >>> This does not seem like a crazy amount of traffic either. I'm
>not sure
>>>> >>> which version of RS you're
>>>> >>> using, but a few weeks ago, I fixed a bug that would cause SSL
>packets
>>>> >>> to hang in the pipeline until
>>>> >>> a new packet arrives. This could be the reason as your X server
>is
>>>> >>> maybe waiting for the stream to
>>>> >>> reach a given point before continuing.
>>>> >>>> I have tried both approaches in my plugin - with a separate
>thread to
>>>> >>>> accept input to / from the client, and also without a separate
>>>> >>>> thread.
>>>> >>>> The issue and point of failure is the same.
>>>> >>>>
>>>> >>>> Granted I definitely do not understand the RS architecture
>well
>>>> >>>> enough
>>>> >>>> and I fear that it is this lack of understanding that is
>causing this
>>>> >>>> problem.
>>>> >>>>
>>>> >>>> I am not using any sort of message queue and as data is being
>>>> >>>> received
>>>> >>>> from the client or server I am simply pushing it down the pipe
>(via
>>>> >>>> sendItem).
>>>> >>>>
>>>> >>>> I have noticed that extremely large blocks of data (say 100k
>or such)
>>>> >>>> simply disappear and are not received at the other end.
>Therefore I
>>>> >>>> chunk data from ssh server or client into blocks of 16384. I
>have
>>>> >>>> tried different block sizes but it doesn't help the bug I have
>above.
>>>> >>> As I understand, you developed a RS service that streams SSL
>>>> >>> connection binary items through RS
>>>> >>> friend connections?
>>>> >>> You're most probably using RsItem objects then. Their size is
>limited
>>>> >>> to 262144 bytes. Any packet
>>>> >>> larger gets dropped.
>>>> >>> I don't know about the released version, but the current trunk
>>>> >>> displays some information about that
>>>> >>> when it happens.
>>>> >>>
>>>> >>>
>>>>
>>>
>
>------------------------------------------------------------------------------
>Check out the vibrant tech community on one of the world's most
>engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>_______________________________________________
>Retroshare-devel mailing list
>Retroshare-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/retroshare-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Retroshare-devel mailing list
Retroshare-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/retroshare-devel
