| Summary: | krdc: The connection to the host has been interrupted. | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdenetwork | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | bugwatch, darrella, kb9vqf, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: |
kcrash when using krdc
kcrash when using krfb kcrash when using krfb |
||
Update: I receive this error dialog using krdc without ssh as well. Just plain VNC and nothing special. This dialog appears immediately, almost as though there is no attempt at all to connect. Perhaps of note, the remote desktop is running MATE and vino and not TDE. Yet remmina connects just fine to the remote desktop, even when run on TDE. Thus vino probably is not the culprit. I can connect to a remote TDE, but then I have the reverse mouse button problem of bug 1583. This bug and 1583 have pretty much become show stoppers for me as I use remote desktop a lot. This should be looked at for the next SRU; hopefully the fix is something simple. I use krdc for connections mapped via SSH every day. Targets are Windows (usually TightVNC), virtual machines in KVM or desktop accessed via x11vnc. And I never observed that mapped SSH was a problem. Along with the referenced dialog, I see the following in xsession-errors: VNC server supports protocol version 3.7 (viewer 3.3) VNC connection failed: No security type suitable for RFB 3.3 supported That led me to look at whether encryption was being required. That was the case. I disabled the requirement for encryption and tried again. Same dialog and same stderr. Same observation as before: remmina has no problem when I had encryption required at the remote system. And without ssh, I need some kind of encryption. Part of the final resolution should be more verbose stderr and improved human readable dialogs when the connection fails. The remote machine is running LMDE and vino-server. The desktop is MATE but that is irrelevant. >And I never observed that mapped SSH was a problem. I shared in comment 1 that I experience the bug with or without ssh. More testing: As mentioned in comment 4, encryption is not the cause. I disabled both the local and remote firewalls as well and still see the same dialog failure. Today I saw the following stderr: VNC server supports protocol version 3.7 (viewer 3.3) VNC connection failed: No security type suitable for RFB 3.3 supported /opt/trinity/bin/krfb_httpd: line 8: read: read error: 0: Connection reset by peer krfb_httpd is shell script. Line 8: read request url httptype || exit 0 The remote system normally runs inetd. I stopped the remote inetd and saw the same dialog failure. Remmina running in TDE always connects to the same remote systems, with or without ssh. On a whim, based upon my comment number 9 in bug 1532, and that I had been using port 5900, I changed my ssh command: ssh -L 3702:localhost:5800 ${remote_box} -l ${remote_user} I again attempted to connect krdc to localhost:3702. I did not get the 'interrupted' dialog but the authentication dialog never completed. I again saw the krfb_httpd stderr message, but multiple times. Firewalls and inetd were disabled. I could not connect with remmina using port 5800. Back to port 5900 and remmina connected through ssh and directly. I'm not sure how much work it would be or whether it is even possible, but I would like to see if krdc can be ported to use the new libtdevnc library (a slightly modified libvnc). If it can, we would at minimum gain support for the latest vnc protocol and also the latest security options. I have a rough prototype of the libvncviewer port working here (still missing some features but mostly functional) so assigning this bug to myself. I have rewritten the VNC part of krdc to use libvncclient in multiple commits ending with GIT hash 2cc3446 (tdenetwork). Can you please test and see if this bug and Bug 2023 are still valid? As this is a rewrite, and has not yet undergone extensive testing, I expect that there will be bugs present that will be fixed before our next release. If you can, please let me know if you experience any additional issues from the rewrite and I will resolve them ASAP. I am also interested if you see either improved or decreased performance from the krdc client. Thanks! First test: The latest TDE GIT on local and remote Slackware 14.1 systems. Colors look true. First connection attempt takes a couple of seconds, but subsequent attempts to the same remote system are immediate. Overall session response seems snappy. For a while now I have been seeing the following stderr messages noted in comment 5: /opt/trinity/bin/krfb_httpd: line 8: read: read error: 0: Connection reset by peer Those stderr messages continue with the latest GIT. The messages appear frequently and cause a lot of noise spew/clutter in the ~/.xsession-errors log. Regarding "The connection to the host has been interrupted": I never experienced this bug between two TDE systems. No change with the latest GIT. Second test: The latest TDE GIT on a local Slackware 14.1 system and MATE desktop on a Fedora 21 remote system. Connects okay, but one time I received a kcrash. Backtrace attached. Colors are not true, despite using highest resolution and 24-bit preferences. The remote system has a blue desktop background but in the VNC window the color is almost purple. Regarding "The connection to the host has been interrupted": No error dialog. Same mouse button reversal, which again points to krfb as the culprit rather than krdc. Third test: MATE Desktop and Remmina on a local Fedora 21 system. The latest TDE GIT on a remote Slackware 14.1 system. Colors look true. First connection attempt takes about two seconds. Subsequent attempts seem a tad faster although not immediate. Several times after connecting I saw only a black screen. When disconnecting with remmina, often the krfb process did not terminate, which resulted in subsequent connection attempts all failing with a "VNC server closed connection" error dialog. Each time I had to manually kill the krfb process at the remote system and then attempt the connection. After several attempts, I finally realized that the actual problem was krfb not terminating quickly. When I waited a _long_ several seconds, the krfb process finally terminated and I again could connect with remmina. I don't recall krfb waiting so long to terminate between two TDE systems, or perhaps using two TDE systems tends to ignore or mask the problem. Regarding "The connection to the host has been interrupted": No error dialog. Same mouse button reversal, which again points to krfb as the culprit rather than krdc. Created attachment 2426 [details]
kcrash when using krdc
Summary: Refer to bug 1583 regarding mouse button reversal. The recent changes did not help. Refer to bug 2023 regarding the screen saver. The recent changes did not help. Regarding this bug report, the changes seem to resolve the originally reported error dialog. I now can connect to a non TDE desktop with krdc. However, the stderr spew seen in the xsession-errors (comment 5) needs resolution. Side note, not a bug but a nuisance, remmina remembers the previous connection session, which is real nice when using a laptop to connect to a larger remote desktop monitor. Every time I use TDE/krdc I always have to manually readjust the scaling to fit the smaller laptop screen. Created attachment 2428 [details]
kcrash when using krfb
I was using a Fedora 21 MATE desktop and remmina to connect to remote a Slackware 14.1 TDE. The kcrash occurred on the remote system.
I don't know whether this matters, but I had the krdc dialog open on the remote Slackware system when I connected from the MATE desktop. I had not connected to anything with the krdc dialog. When connecting to a remote krfb and DPMS off is engaged, should a VNC connection cause the remote monitor to power on? I have not tested conclusively, but when I use TDE krdc to connect to a remote vino server, and the monitor is in DPMS off, connecting results in an expected black screen. Yet moving the mouse causes the VNC connection to show the remote desktop and the remote monitor powers on. This never happens with TDE krfb. Since the new changes, several times I have experienced a complete desktop freeze after the session enters DPMS off. The moment I attempt to connect from another machine, I lose all keyboard and mouse access. I have to visit the remote system and use Ctrl+Alt+Backspace to recover. Created attachment 2441 [details]
kcrash when using krfb
Tim, whenever you get back to this, the kcrashes need attention. They occur quite regularly on remote systems after DPMS off kicks in and I try to connect to the remote system. >the kcrashes need attention Please refer to bug 2349. I believe the root cause is one and the same. |
I receive this error dialog when attempting to connect to a remote system using krdc through ssh. The message is from tdenetwork/krdc/vnc/kvncview.cpp:477. After copying the public key to the remote user's authorized_keys, I ssh into the remote system as follows: ssh -L 3702:localhost:5900 ${remote_hostname} -l ${remote_username} This opens local port 3702 to connect to the remote system port 5900. With krdc I then try both localhost:3702 and 127.0.0.1:3702. I receive the error dialog. Remmina connects just fine through the same ssh tunnel.