RE: Remote Console control of KDE

The KDE docs suggest a method for killing the krfb
process and although it did not work I took a chance
the problem was new to NetBSD, went looking for the
process and found this on the "server" (for example):

user1 5782  ...etc... 1:09PM  0:15.53 krfb --kinetd 16

It turns out this process is not exiting cleanly after
Remote Desktop is closed on the controlling "client." 
Once in awhile it behaves, but mostly it hangs.  To
get  back in using Remote Desktop, all I had to do was
kill its PID.  This leaves an unsightly popup on the
user's desktop, but if I do it only when I am going to
reconnect, I can clean it up.

BZAG
====================================================

I wrote previously:

I am running NetBSD V2.0.2 and KDE 3.4.0.  I am trying
to setup and test console control of a NetBSD PC
(i386) from initial boot into KDE and back out for
remote reboot control.

I've figured out how to get into KDE without user
intervention and logon, and how to configure Desktop
Sharing to permit this kind of control.  The idea is
to get onto the user's desktop to cleanly shutdown his
session and to execute a reboot from an SSH session
when necessary.

The problem is that once I use Remote Desktop to
connect, if I close Remote Desktop on the remote
computer, I cannot get into the client's KDE Desktop
again because Desktop Sharing says the server is not
accepting any more connections.  I believe what is
happening is that Desktop Sharing has the connection
running and I have not (nor know how to) terminate
this connection properly without forcing a KDE logout
and a reboot (without terminating Remote Desktop),
which is what I want to avoid.

Is there a way around this?  For example, a process
PID termination?

There is one other possibility.  The client's KDE sits
behind a NAT router and I have the port forwarded, but
only the one port.  Are additional connections
possible with incremented ports, i.e., if 5900 is
tied-up and I try to connect does Desktop Sharing
expect 5901 to be used ? (because 5901 is not enabled
on the port forwarder...  admittedly I haven't tried
this yet..)

BZAG
==================================