Bug 58334 - infinite loop when connecting to local display
Summary: infinite loop when connecting to local display
Status: RESOLVED WORKSFORME
Alias: None
Product: krfb
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Mandrake RPMs Linux
: NOR minor
Target Milestone: ---
Assignee: Alessandro Praduroux
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-11 03:33 UTC by Richard Neill
Modified: 2022-11-12 05:14 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Neill 2003-05-11 03:33:49 UTC
Version:            (using KDE KDE 3.1)
Installed from:    Mandrake RPMs
OS:          Linux

I just did something silly - I tried to test out desktop sharing on my own pc, opening VNCviewer on the desktop being shared. Of course, I got an infinite loop!
Yes, I know this is stupid, but it is also an extremely common stupid mistake - it's almost instinctive to try out the tool yourself before letting someone else use it :-)

So, I suggest that:

1)KDE should test for this in some way and trap the error (perhaps match IP addresses, or test for both a vncviewer and a vnc client on the same computer)

2) Document it in the "Welcome to KDE desktop sharing" window.

I think this is worth fixing - because especially newbies will quickly get their Xsession locked up, without thinking to do "Ctrl-Alt-F1; [login]; killall vncviewer"


Richard
Comment 1 tim 2003-05-11 13:08:20 UTC
Actually it prevents the loop when you connect to localhost, but not when you connect using a different IP. It turned out to be quite complicated to find out when a viewer and the server are on the same display without making other valid uses cases impossible (e.g. two people working on the same system but different displays). I recently found a good way to do it, but it will require the new protocol negotiation extension from TightVNC which is not ready yet...   
Comment 2 Richard Neill 2003-05-11 18:40:28 UTC
Just checked - it doesn't do this for me in KDE 3.1.0
I'd expect it to prevent the loop whether I connect as:

vncviewer localhost:0
 or
vncviewer 131.193.xxx.yyy:0

Neither of these detects the problem.

Richard




Comment 3 tim 2003-05-11 23:24:05 UTC
Oh, you are talking about vncviewer. There is no reliable way to detect this using 
vncviewer, only krdc can. 
Comment 4 Richard Neill 2003-05-12 00:56:39 UTC
That's why I suggest that you check if the krfb server and the viewer are on the
same computer, run by the same user. "ps ux" will help - given that the viewer
program start time is within < 1 second of the invitation being accepted and KDE
preparing to allow the viewer to connect.

Certainly, I think that you should mention this problem in the desktop sharing
window, since almost every user will try this at least once!

Richard
Comment 5 tim 2003-05-12 01:08:25 UTC
Sorry, I am not going to do such a hack.  
1. parsing "ps" does not work reliably on all systems (and there is no other portable way 
to get a process list) 
2. I would have to hardcode the binary names of various vnc viewers 
3. the <1 second interval does not work, the user could specify the host name on the 
command line or the app could start slower 
4. it would break the use case of a user who connects over a ssh tunnel 
5. I suppose that most users use KDE's client, krdc, when working in a KDE session. 
That's why I am going to add detection to krdc.  
 
 
 
Comment 6 tim 2003-05-12 01:10:19 UTC
sorry, typo: 
3. the <1 second interval does not work unless the user specifies the host name on the 
command line. All VNC viewers that I know let the user enter the name in a GUI. 
 
Comment 7 Richard Neill 2003-05-12 02:05:01 UTC
OK - fair point. But please do consider changing the text on the window which
appears - something like:
-----------

ATTENTION
Somebody is requesting a RFB (VNC) connection to your computer...

[Please note, if you are testing this by connecting to your *own* computer, you
should not continue, as you will create an infinite loop. (This is like pointing
a video camera at a television.) ]
Comment 8 Richard Neill 2004-05-11 19:16:29 UTC
As requested by email, I'm re-checking this on KDE 3.2 (Mandrake 10). Now, all that happens is:

Command line: vncviewer 131.111.xxx.yyy:0
    vncviewer: VNC server closed connection

krdc:
   Connection failed. The server does not accept new connections

however, there is no other warning or explanation given.

Richard
Comment 9 George Goldberg 2008-02-18 04:02:50 UTC
Is this bug still present in a recent KDE version, such as 3.5.9 or 4.0.1?
Comment 10 George Goldberg 2009-09-12 12:14:50 UTC
Answering my own question some time later, this can still happen. However, I am really unsure about the best thing to do with it.
Comment 11 Justin Zobel 2022-10-13 04:47:28 UTC
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported and confirmed, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Comment 12 Bug Janitor Service 2022-10-28 05:02:04 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 13 Bug Janitor Service 2022-11-12 05:14:50 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!