Trouble connecting a Windows client to GS 3.5.x

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
Hello everybody,

I have a GsDevKit_home server up and running. The server side seems to
be ok. I can create, start, stop and delete several stones. I created
teststones of product versions 3.4.3, 3.4.4, 3.5.0 and 3.5.1. (I skipped
3.4.5 because it is not included in the latest Jade release so far)

On the client side I'm working on a Windows 10 64bit box and use ssh
with port tunneling to connect to the server. I can connect to the 3.4.x
stones using Jade as well as tODE with a GsDevKit_home client setup.

But: I spent some frustrating hours trying to connect to the 3.5.x
stones. Neither Jade nor tODE let me connect. Both error out, telling me
I should check the netldi or gem logs. But there is nothing written to
the netldi log. It seems that no network traffic at all takes place.
Assuming that there isn't any conceptual difference from the users point
of view between configuring a connection for 3.4 and 3.5, I have
absolutely no clue what I might do wrong. May there be a general issue
with the client gci libs for 3.5.x under Windows?

Any ideas are very much appreciated.

Best regards,

Ralph


_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list

Ralph,

This is indeed puzzling ... in the tODE client, can you try the Client>Test Login><stone-name> menu item and send us the resulting information? You should get a window with diagnostic information in it, like the following:

The test login, records a bit more information about the login and suggests solutions for some of the more common problems ... and then we'll go from there.

Dale

On 3/18/20 1:10 PM, Ralph Mauersberger via Glass wrote:
Hello everybody,

I have a GsDevKit_home server up and running. The server side seems to
be ok. I can create, start, stop and delete several stones. I created
teststones of product versions 3.4.3, 3.4.4, 3.5.0 and 3.5.1. (I skipped
3.4.5 because it is not included in the latest Jade release so far)

On the client side I'm working on a Windows 10 64bit box and use ssh
with port tunneling to connect to the server. I can connect to the 3.4.x
stones using Jade as well as tODE with a GsDevKit_home client setup.

But: I spent some frustrating hours trying to connect to the 3.5.x
stones. Neither Jade nor tODE let me connect. Both error out, telling me
I should check the netldi or gem logs. But there is nothing written to
the netldi log. It seems that no network traffic at all takes place.
Assuming that there isn't any conceptual difference from the users point
of view between configuring a connection for 3.4 and 3.5, I have
absolutely no clue what I might do wrong. May there be a general issue
with the client gci libs for 3.5.x under Windows?

Any ideas are very much appreciated.

Best regards,

Ralph


_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list

Dale,

the output of the test login is just:

Error running testLogin:

'Error:  For further information about login failures, check the gem log file'

    NOTE: netldi log can be found in the file: '$GS_HOME/server/stones/<stone-name>/logs/netldi.log'.

Starting or stopping the ssh port tunnel doesn't make any difference, the error stays the same. That is why I assume that no network traffic at all takes place. Otherwise I would expect an error like "letldi not found on  host". Before I downloaded the 3.5.x products on the client side, I got comprehensible errors, telling me that specific versions of the gci libs are missing.

By the way: Jade just says: "Unable to create a session, check netldi and gem log files".

Br,

Ralph




Am 18.03.2020 um 22:54 schrieb Dale Henrichs via Glass:

Ralph,

This is indeed puzzling ... in the tODE client, can you try the Client>Test Login><stone-name> menu item and send us the resulting information? You should get a window with diagnostic information in it, like the following:

The test login, records a bit more information about the login and suggests solutions for some of the more common problems ... and then we'll go from there.

Dale

On 3/18/20 1:10 PM, Ralph Mauersberger via Glass wrote:
Hello everybody,

I have a GsDevKit_home server up and running. The server side seems to
be ok. I can create, start, stop and delete several stones. I created
teststones of product versions 3.4.3, 3.4.4, 3.5.0 and 3.5.1. (I skipped
3.4.5 because it is not included in the latest Jade release so far)

On the client side I'm working on a Windows 10 64bit box and use ssh
with port tunneling to connect to the server. I can connect to the 3.4.x
stones using Jade as well as tODE with a GsDevKit_home client setup.

But: I spent some frustrating hours trying to connect to the 3.5.x
stones. Neither Jade nor tODE let me connect. Both error out, telling me
I should check the netldi or gem logs. But there is nothing written to
the netldi log. It seems that no network traffic at all takes place.
Assuming that there isn't any conceptual difference from the users point
of view between configuring a connection for 3.4 and 3.5, I have
absolutely no clue what I might do wrong. May there be a general issue
with the client gci libs for 3.5.x under Windows?

Any ideas are very much appreciated.

Best regards,

Ralph


_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
In reply to this post by GLASS mailing list
Hi,

With GS 3.5.1, Jade and Windows 8 i can connect without problems.

Do you have a wireless internet modem ?

I have one Huawei modem and when i connect it to the computer --> i can NOT
log to GS from my windows client. I have to switch to Wifi to login.

May be not your case but ....

regards,
bruno



--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
Hello Bruno,
thank you for your reply and sorry for my delay!
No, I'm not working over a mobile network, I'm connected via Wifi and a
standard internet router setup on a fixed line.

I found the time and spent another few hours on that issue.
Now my findings are as follows:
* I still can connect with tODE/Jade to the GS 3.4.x stones through the
SSH tunnel. (Gem host is localhost in this case)
* I still can NOT connect with tODE/Jade to the GS 3.5.x stones through
the SSH tunnel. (Gem host is localhost in this case)
* If I try to connect to the 3.5.x stones through the SSH tunnel using a
session configuration for 3.4.x, this doesn't work, but netldi logs:
"accept failed,  invalid response (old version client?) Invalid client
connectKind". This proves, that the 3.5.x netldi is listening and the
SSH tunnel is working.
* If I open the firewall on my server and expose the netldi port of the
3.5.x stone to the internet (which probably is not the best idea) I can
connect to the 3.5.x stones! (Gem host is set to the public IP of the
server)
* When I try to connect to 3.5.x though the SSH tunnel using localhost
as Gem host, there is absolutely no network traffic on the netldi port.
(Monitored with Wireshark)

So it is kind of weird, but for me it looks as if the 3.5.x  gci libs
don't support localhost as a valid destination address...

Best regards,
Ralph

Am 20.03.2020 um 00:15 schrieb BrunoBB via Glass:

> Hi,
>
> With GS 3.5.1, Jade and Windows 8 i can connect without problems.
>
> Do you have a wireless internet modem ?
>
> I have one Huawei modem and when i connect it to the computer --> i can NOT
> log to GS from my windows client. I have to switch to Wifi to login.
>
> May be not your case but ....
>
> regards,
> bruno
>
>
>
> --
> Sent from: http://forum.world.st/GLASS-f1460844.html
> _______________________________________________
> Glass mailing list
> [hidden email]
> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
Ralph,

First, I assume that you are using the instructions found here[1] to set
up your ssh tunnel?

Second, I assume that you are using two tunnels, one for each netldi?

Third, I assume that you have checked that the port in the session file
($GS_HOME/sys/local/sessions/<stone-name>) matches the port that the 3.5
netldi is actually listening on. You should edit both the client and
server session files and use the same port number in both and the port
needs to match the ssh tunnel port ... if you haven't edited the server
session file, then on restart the netldi will use a different port ...
It looks like the server-side detail is missing from the instructions ...

If so, then we need to make sure that the ssh tunnels are set up correctly.

I'd like to see a `stones -r` report on your server machine so that I
can see which ports are being used on the server for both 3.4 and 3.5.

And then I'd like to see the ssh commands that you are using to set up
the ssh tunneling.

Dale

[1]
https://github.com/GsDevKit/GsDevKit_home/blob/ebc8e7b1c1f2a5b4e9cf11f924164152a342367f/docs/installation/installDevKitClient.md#setup-ssh-port-forwarding

On 3/23/20 11:57 AM, Ralph Mauersberger via Glass wrote:

> Hello Bruno,
> thank you for your reply and sorry for my delay!
> No, I'm not working over a mobile network, I'm connected via Wifi and a
> standard internet router setup on a fixed line.
>
> I found the time and spent another few hours on that issue.
> Now my findings are as follows:
> * I still can connect with tODE/Jade to the GS 3.4.x stones through the
> SSH tunnel. (Gem host is localhost in this case)
> * I still can NOT connect with tODE/Jade to the GS 3.5.x stones through
> the SSH tunnel. (Gem host is localhost in this case)
> * If I try to connect to the 3.5.x stones through the SSH tunnel using a
> session configuration for 3.4.x, this doesn't work, but netldi logs:
> "accept failed,  invalid response (old version client?) Invalid client
> connectKind". This proves, that the 3.5.x netldi is listening and the
> SSH tunnel is working.
> * If I open the firewall on my server and expose the netldi port of the
> 3.5.x stone to the internet (which probably is not the best idea) I can
> connect to the 3.5.x stones! (Gem host is set to the public IP of the
> server)
> * When I try to connect to 3.5.x though the SSH tunnel using localhost
> as Gem host, there is absolutely no network traffic on the netldi port.
> (Monitored with Wireshark)
>
> So it is kind of weird, but for me it looks as if the 3.5.x  gci libs
> don't support localhost as a valid destination address...
>
> Best regards,
> Ralph
>
> Am 20.03.2020 um 00:15 schrieb BrunoBB via Glass:
>> Hi,
>>
>> With GS 3.5.1, Jade and Windows 8 i can connect without problems.
>>
>> Do you have a wireless internet modem ?
>>
>> I have one Huawei modem and when i connect it to the computer --> i
>> can NOT
>> log to GS from my windows client. I have to switch to Wifi to login.
>>
>> May be not your case but ....
>>
>> regards,
>> bruno
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/GLASS-f1460844.html
>> _______________________________________________
>> Glass mailing list
>> [hidden email]
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>
> _______________________________________________
> Glass mailing list
> [hidden email]
> https://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
You can see what SSL is doing by setting this env var to be a writable
directory on both the client and server side:

GS_DEBUG_SSL_LOG_DIR=<writableDirectoryPath>

on Linux you could use:

GS_DEBUG_SSL_LOG_DIR=/tmp

on windows you need to specify the path in windows format:

GS_DEBUG_SSL_LOG_DIR=C:\Users\Norm\Downloads

This will cause every SSL call to be logged to a text file containing the
PID of the process making the SSL call.

Hope this helps.

Norm




--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
In reply to this post by GLASS mailing list

Dale,

I think all your assuptions are true.

This is from the server:

[fox@srv6223 ~]$ stones -r
Running Stones:
        Status       Version    Owner    Pid   Port   Started     Type       Name
        -------     --------- --------- ----- ----- ------------ ------      ----
        exists       3.4.4     fox          20332 36333 Mär 23 21:44 Stone       teststone344
        exists       3.5.1     fox          20430 44055 Mär 23 21:45 Stone       teststone351
Running Netldis:
        Status       Version    Owner    Pid   Port   Started     Type       Name
        -------     --------- --------- ----- ----- ------------ ------      ----
        exists       3.4.4     fox          20267 50379 Mär 23 21:44 Netldi      teststone344_ldi
        exists       3.5.1     fox          20293 50380 Mär 23 21:44 Netldi      teststone351_ldi
[fox@srv6223 ~]$


[fox@srv6223 sessions]$ cat teststone344
TDSessionDescription {
        #name : 'teststone344',
        #stoneHost : 'srv6223',
        #stoneName : 'teststone344',
        #gemHost : 'localhost',
        #netLDI : 'teststone344_ldi',
        #netLDIPort : '50379',
        #gemTask : 'gemnetobject',
        #userId : 'DataCurator',
        #password : 'swordfish',
        #osUserId : nil,
        #osPassword : nil,
        #dataDirectory : nil,
        #backupDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone344/backups/',
        #snapshotDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone344/snapshots/',
        #gemstoneVersion : '3.4.4',
        #gciLibraryName : nil,
        #adornmentColor : nil,
        #serverGitRoot : nil,
        #serverTodeRoot : '/opt/gemstone/GsDevKit_home',
        #authorId : nil
}
[fox@srv6223 sessions]$ cat teststone351
TDSessionDescription {
        #name : 'teststone351',
        #stoneHost : 'srv6223',
        #stoneName : 'teststone351',
        #gemHost : 'localhost',
        #netLDI : 'teststone351_ldi',
        #netLDIPort : '50380',
        #gemTask : 'gemnetobject',
        #userId : 'DataCurator',
        #password : 'swordfish',
        #osUserId : nil,
        #osPassword : nil,
        #dataDirectory : nil,
        #backupDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone351/backups/',
        #snapshotDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone351/snapshots/',
        #gemstoneVersion : '3.5.1',
        #gciLibraryName : nil,
        #adornmentColor : nil,
        #serverGitRoot : nil,
        #serverTodeRoot : '/opt/gemstone/GsDevKit_home',
        #authorId : nil
}
[fox@srv6223 sessions]$

[fox@srv6223 sessions]$ cat /etc/services
...
gs64ldi         50377/tcp        # Gemstone netldi
teststone344_ldi 50379/tcp
teststone351_ldi 50380/tcp

And this from the client:

ramauers@Yoga370 MINGW64 ~/GsDevKit_home/sys/local/sessions (gsdevkit)
$ cat teststone344
TDSessionDescription {
        #name : 'teststone344',
        #stoneHost : 'srv6223',
        #stoneName : 'teststone344',
        #gemHost : 'localhost',
        #netLDI : 'teststone344_ldi',
        #netLDIPort : '50379',
        #gemTask : 'gemnetobject',
        #userId : 'DataCurator',
        #password : 'swordfish',
        #osUserId : nil,
        #osPassword : nil,
        #dataDirectory : nil,
        #backupDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone344/backups/',
        #snapshotDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone344/snapshots/',
        #gemstoneVersion : '3.4.4',
        #gciLibraryName : nil,
        #adornmentColor : nil,
        #serverGitRoot : nil,
        #serverTodeRoot : '/opt/gemstone/GsDevKit_home',
        #authorId : nil
}
ramauers@Yoga370 MINGW64 ~/GsDevKit_home/sys/local/sessions (gsdevkit)
$ cat teststone351
TDSessionDescription {
        #name : 'teststone351',
        #stoneHost : 'srv6223',
        #stoneName : 'teststone351',
        #gemHost : 'localhost',
        #netLDI : 'teststone351_ldi',
        #netLDIPort : '50380',
        #gemTask : 'gemnetobject',
        #userId : 'DataCurator',
        #password : 'swordfish',
        #osUserId : nil,
        #osPassword : nil,
        #dataDirectory : nil,
        #backupDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone351/backups/',
        #snapshotDirectory : '/opt/gemstone/GsDevKit_home/server/stones/teststone351/snapshots/',
        #gemstoneVersion : '3.5.1',
        #gciLibraryName : nil,
        #adornmentColor : nil,
        #serverGitRoot : nil,
        #serverTodeRoot : '/opt/gemstone/GsDevKit_home',
        #authorId : nil
}
ramauers@Yoga370 MINGW64 ~/GsDevKit_home/sys/local/sessions (gsdevkit)
$


If I substitute...
        #gemHost : 'localhost',
with...
        #gemHost : 'myFullQualifiedDomainName',
...the connect will work.


SSH is done with Putty and the following tunnels:


Best regards,

Ralph


Am 23.03.2020 um 20:31 schrieb Dale Henrichs via Glass:
Ralph,

First, I assume that you are using the instructions found here[1] to set up your ssh tunnel?

Second, I assume that you are using two tunnels, one for each netldi?

Third, I assume that you have checked that the port in the session file ($GS_HOME/sys/local/sessions/<stone-name>) matches the port that the 3.5 netldi is actually listening on. You should edit both the client and server session files and use the same port number in both and the port needs to match the ssh tunnel port ... if you haven't edited the server session file, then on restart the netldi will use a different port ... It looks like the server-side detail is missing from the instructions ...

If so, then we need to make sure that the ssh tunnels are set up correctly.

I'd like to see a `stones -r` report on your server machine so that I can see which ports are being used on the server for both 3.4 and 3.5.

And then I'd like to see the ssh commands that you are using to set up the ssh tunneling.

Dale

[1] https://github.com/GsDevKit/GsDevKit_home/blob/ebc8e7b1c1f2a5b4e9cf11f924164152a342367f/docs/installation/installDevKitClient.md#setup-ssh-port-forwarding

On 3/23/20 11:57 AM, Ralph Mauersberger via Glass wrote:
Hello Bruno,
thank you for your reply and sorry for my delay!
No, I'm not working over a mobile network, I'm connected via Wifi and a
standard internet router setup on a fixed line.

I found the time and spent another few hours on that issue.
Now my findings are as follows:
* I still can connect with tODE/Jade to the GS 3.4.x stones through the
SSH tunnel. (Gem host is localhost in this case)
* I still can NOT connect with tODE/Jade to the GS 3.5.x stones through
the SSH tunnel. (Gem host is localhost in this case)
* If I try to connect to the 3.5.x stones through the SSH tunnel using a
session configuration for 3.4.x, this doesn't work, but netldi logs:
"accept failed,  invalid response (old version client?) Invalid client
connectKind". This proves, that the 3.5.x netldi is listening and the
SSH tunnel is working.
* If I open the firewall on my server and expose the netldi port of the
3.5.x stone to the internet (which probably is not the best idea) I can
connect to the 3.5.x stones! (Gem host is set to the public IP of the
server)
* When I try to connect to 3.5.x though the SSH tunnel using localhost
as Gem host, there is absolutely no network traffic on the netldi port.
(Monitored with Wireshark)

So it is kind of weird, but for me it looks as if the 3.5.x  gci libs
don't support localhost as a valid destination address...

Best regards,
Ralph

Am 20.03.2020 um 00:15 schrieb BrunoBB via Glass:
Hi,

With GS 3.5.1, Jade and Windows 8 i can connect without problems.

Do you have a wireless internet modem ?

I have one Huawei modem and when i connect it to the computer --> i can NOT
log to GS from my windows client. I have to switch to Wifi to login.

May be not your case but ....

regards,
bruno



-- 
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
Ralph,

So then setting the gemHost to point to `myFullQualifiedDomainName` was
the missing ingredient?

If so, I'm glad that we've got it figured out ... the remote netldi
configuration can indeed be complicated:)

Dale

On 3/23/20 2:22 PM, Ralph Mauersberger via Glass wrote:
>
> If I substitute...
>         #gemHost : 'localhost',
> with...
>         #gemHost : 'myFullQualifiedDomainName',
> ...the connect will work.
>
>
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Trouble connecting a Windows client to GS 3.5.x

GLASS mailing list
Dale,

no, unfortunately the situation did not change. What I wanted to express
with 'myFullQualifiedDomainName' is: If I change the configuration from
gemHost being set to localhost and enter the DNS-Name or alternatively
the public IPv4-Address of the server instead, then the connect works.
But in this case the SSH-Tunnel gets bypassed and the connection from
the client to the netldi is done directly through the internet. This
requires that the netldi port is accessible from the internet, what is
probably not the recommended way to go. I assume, that access to netldi
should be limited to trusted networks.

If I consider all the results of my different tests, the only conclusion
I can reach is, that it is still not possible -- for whatever reason --
to connect a Windows client to a GS 3.5.x stone if the gemHost in the
session configuration equals localhost, as it is necessary if a
SSH-tunnel should be used.

I assume the I'm a rare species, since probably most guys are running
their clients on Linux or Mac. So it would be good to know if anybody
else has been able to successfully test this scenario.

Br,

Ralph



Am 24.03.2020 um 02:22 schrieb Dale Henrichs via Glass:

> Ralph,
>
> So then setting the gemHost to point to `myFullQualifiedDomainName`
> was the missing ingredient?
>
> If so, I'm glad that we've got it figured out ... the remote netldi
> configuration can indeed be complicated:)
>
> Dale
>
> On 3/23/20 2:22 PM, Ralph Mauersberger via Glass wrote:
>>
>> If I substitute...
>>         #gemHost : 'localhost',
>> with...
>>         #gemHost : 'myFullQualifiedDomainName',
>> ...the connect will work.
>>
>>
> _______________________________________________
> Glass mailing list
> [hidden email]
> https://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass