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
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...
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
Oh, you are talking about vncviewer. There is no reliable way to detect this using vncviewer, only krdc can.
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
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.
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.
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.) ]
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
Is this bug still present in a recent KDE version, such as 3.5.9 or 4.0.1?
Answering my own question some time later, this can still happen. However, I am really unsure about the best thing to do with it.
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!
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!
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!