www.cendio.com
Bug 2251 - Always terminate existing connections
: Always terminate existing connections
Status: CLOSED FIXED
: ThinLinc
VSM Agent
: 1.6.0
: PC Linux
: P2 Enhancement
: 4.6.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2006-11-02 09:41 by
Modified: 2016-04-18 17:01 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2006-11-02 09:41:31
When a user reconnects to an existing session, any previous connection gets
killed when vsmagent is cleaning up the tunnel ports. The visisble user
experience is that you cannot be connected with more than one client at a time.

However, if you disable all local resources, there will be no ports to free, so
existing connections will be left alone. In other words, you can have multiple
terminals controlling the same session simultaneously.

This behaviour is very inconsistent and confusing. We should be terminating
existing connections even when there are no ports to free.
------- Comment #2 From cendio 2013-12-03 13:55:21 -------
Maybe we also need to add a bug to make the sharing behaviour always work? E.g.
we could code the system to always allow a user to shadow himself. That would
also solve the issue of multiple local resource as the shadowing connections
wouldn't bring any local resources.
------- Comment #3 From cendio 2014-04-02 11:11:21 -------
*** Bug 5061 has been marked as a duplicate of this bug. ***
------- Comment #4 From cendio 2014-04-02 13:56:39 -------
Quoting from bug 5061:

> When you log in to a session, any connected native clients are disconnected
> from the session.
> 
> When you log in to a session, any connected HTML 5 clients remains connected to
> the session.
------- Comment #5 From cendio 2016-01-20 08:01:15 -------
The current behavior is a side affect for another mechanism (unbindports) which
is used  for ensuring that no-one is listening on the ports used for a session
tunnels.

We need to create a new mechanism for detecting connecting clients (not
shadowers) which works for both the native and HTML5 client.
------- Comment #11 From cendio 2016-01-27 12:40:59 -------
Reopening due to:

* Autotests not fully working

* I'd like a comment in SConnection.cxx    about why we are changing the order
of setAccessRights and queryConnection. 

* Awaiting feedback wrt code style / duplicated code.
------- Comment #13 From cendio 2016-02-03 09:13:30 -------
(In reply to comment #11)
> 
> * Autotests not fully working
> 

Fixed in commit r31139
------- Comment #15 From cendio 2016-02-03 09:42:05 -------
(In reply to comment #11)
> * I'd like a comment in SConnection.cxx    about why we are changing the order
> of setAccessRights and queryConnection. 
> 

This change is now commited upstream and brought into CTC with commit 31143.
------- Comment #17 From cendio 2016-02-03 11:11:56 -------
(In reply to comment #11)
> * Awaiting feedback wrt code style / duplicated code.
>

- Commit 31145 removes the inline if statement.

- Commit 31146 refactors handler_reqsession to reduce code duplication.
------- Comment #18 From cendio 2016-02-08 13:12:20 -------
I've found a problem:

 1. Start a new session using the HTML5 client.
 2. Shadow the session with the native client.
 3. Reconnect to the session with the HTML5 client.

Expected:

 Connection from step 1 should be disconnected.

Observed behavior:

 Connections from steps 1 and 2 are disconnected.

In other words, there are cases where shadowers are disconnected when a user
reconnects to their sessions.
------- Comment #19 From cendio 2016-02-08 16:42:54 -------
(In reply to comment #18)
> I've found a problem:
> 
>  1. Start a new session using the HTML5 client.
>  2. Shadow the session with the native client.
>  3. Reconnect to the session with the HTML5 client.
> 
> Expected:
> 
>  Connection from step 1 should be disconnected.
> 
> Observed behavior:
> 
>  Connections from steps 1 and 2 are disconnected.
> 
> In other words, there are cases where shadowers are disconnected when a user
> reconnects to their sessions.

After more investigation, we've found that this is not a new problem. It also
affects the native client. I've added bug 5795 for this problem.
------- Comment #20 From cendio 2016-02-08 16:58:41 -------
I've verified that existing connections (from both HTML5 and native clients)
are disconnected when you reconnect to a session, independent of local device
exports. Great!
------- Comment #21 From cendio 2016-04-08 13:25:49 -------
*** Bug 5835 has been marked as a duplicate of this bug. ***
------- Comment #22 From cendio 2016-04-08 13:27:14 -------
We forgot to audit other users of the vncpasswd file to make sure they only
read the first 8 bytes. Local drives are broken as a result, and there might be
more issues.
------- Comment #24 From cendio 2016-04-12 11:05:06 -------
(In reply to comment #22)
> We forgot to audit other users of the vncpasswd file to make sure they only
> read the first 8 bytes. Local drives are broken as a result, and there might be
> more issues.

Other users of vncpasswd was fixed but it seems that tl-mount-localdrives was
missed. Commit 31375 fixes the read of vncpasswd.
------- Comment #25 From cendio 2016-04-18 17:01:44 -------
(In reply to comment #24)
> Other users of vncpasswd was fixed but it seems that tl-mount-localdrives was
> missed. Commit 31375 fixes the read of vncpasswd.

Local drives work. Tested exporting/reading/writing against server build 5093.