Oleg:
Hello and Happy New Year! Some quick comments for you in
regards to your remaining work on this contract:
> The only one thing that has been left out is item 4.3 of the Spec
> "Modification to auto-detect VNC servers on a LAN".
> We are currently working on this problem. It should not take us too
> long to complete it. But taking into account New Year holidays we would
> like to set the delivery date for this feature for January 14, 2002.
Sounds good. You may want to have a look for VNCAdmin which
already does this. It's coded in Perl, uses wxWindows. Useful.
Also, I wanted to confirm: suppose host-A and host-B are on
my LAN, and host-C and host-D are on a remote LAN. Hosts A, B and
C are all running Kaboodle, and hosts A and D have VNC installed
(both viewer and server). I now setup a Kaboodle-VPN between the two
networks using machines B and C. I then go to machine-A and want to
initiate a VNC session to machine-D. My question is...is the VNC
tunneling work you've done smart enough to allow this to work:
A (VNC client) => B (Kaboodle) => C (Kaboodle) => D (VNC server)
It should, of course, that's the whole point. :) I've
just been unable to test what you've sent yet.
Now for some longer winded thoughts...
VNC-Detection
=============
I'm thinking that this VNC auto-detection should be part of
Kaboodle's overall LAN detection. Here's how I think that old part
works: once a device (PC, printer, etc) is discovered, it joins a
"global population list". That list is further divided into an "active
list" and an "inactive list" (we'll be soon adding a third category,
the "hidden device list", but that's not ready yet). An independent
thread is responsible for managing the contents of the 3 lists
(population, active, inactive).
VNC detection is a bit tricker, though, as a device could
be running a viewer, a server, or both. Kaboodle must be able to
detect both: it needs to detect servers running on any device
including itself, and it needs to detect viewers installed only on
itself (ie, on the same machine that Kaboodle is installed upon).
For the server detection of other devices, what the VNC auto
detect should do is simply attempt to connect to TCP port 5900-5999
on a device, and grep for an RFB reply. If it fails to connect or if
there's no RFB in the reply string (try telneting to a VNC server
and you'll see what I mean), it's not running a VNC service. Of
course, if it detects something on port 5900, it can skip scanning
the other 99 TCP ports.
For viewer detection, Kaboodle can simply check the installed
programs to see if VNCviewer is around or not.
If a device *is* detected to be running a VNC viewer or client,
Kaboodle should set a property in that device's Network Information
Database entry which then allows the VNC PropertyTab to show up on
that device's PropertyPanel. Two "bits": one yes/no for VNCServer and
one yes/no for VNCViewer. These database entries are persistent, so
Kaboodle will not have to rescan every device for VNC. If it finds it
once it should stick. We'll worry about removing it later.
This auto-detection should be triggered in three manners. First,
when Kaboodle starts up, it should check the population list to see if
any devices without the VNC bits set are now running VNC and check itself
to see if a VNC viewer is now installed. Second, it should do this same
scan when the REFRESH button is hit. Third, it should do this same scan
whenever the global population list is detected to have updated.
The "VNC Setup" PropertyTab
===========================
> III. HINTS TO TEST KABOODLE+VNC
>
> 1) Kaboodle+VNC Server machine
> - Launch EF.exe;
> - Right-click _your_ computer icon;
> - Choose "VNC session" tab;
> - Press "Listen..." button. "VNC session" window will show up;
> - Press "Browse..." button and locate your WinVNC.exe file.
> Note that you do it just once;
> - Press "Listen" button to enter the Server mode.
Hmmm. I think we need to change this in a small way. If
a device is running *either* a VNC server or if it has a VNC client
installed, it should have a "VNC Setup" PropertyTab as per the whole
auto-detection discussion above. The top half of this tab should deal
with VNC server details, the bottom half should deal with VNC client
details.
Here's the tricky part, though. If I'm running Kaboodle on
the *same* machine that's running the VNC server, then I should
have some control I couldn't have otherwise. Specifically, I should
have a radio button that says "Use Kaboodle to control the startup
of the VNC service". If that button is checked, then have the field
which says "Use this server: __________" which has the "Browse..."
button next to it, so the user can go find WinVNC.exe. If checked,
Kaboodle would startup the service on an as-needed basis. If not
checked, Kaboodle could still affect the registry settings for VNC,
but it'd be running all of the time, unsupervised.
Secondly, the top-half of the window should have the "Connect
to VNC on display/port ####" where the user can specify a display
or port-number for the VNC service to bind to. It defaults of course
to display 0, aka TCP port 5900. Or, for instance, Kaboodle might
auto-detect VNC running on another machine on port 5915, and so it
should come up showing "Connect to VNC on display 15".
The spec lists some other radio buttons for the server side
controls. The most interesting ones are "Only Allow other Kaboodle
users to connect to this machine" and "Let other Kaboodle users affect
these settings".
> 2) Kaboodle+VNC Viewer machine
> - Launch EF.exe;
> - Right-click the target computer icon;
> - Choose "VNC session" tab;
> - Press "Start session..." button.
> "VNC session with xxx.xxx.xxx.xxx" window will show up;
> - Press "Browse..." button and locate your VncViewer.exe file.
> You do it just once;
> - Press "View" button to start session.
As for the bottom half of the window, the VNC Viewer part,
it's weird. The settings being adjusted will affect how the VNC
Viewer on *my* machine behaves, the one I'm working on, not the
target machine's, the one whose PropertyPanel I have open. So,
in the bottom half of the window, it should read: "When connecting
to this machine from My Machine, use these settings:", where
My Machine is the Kaboodle name for the machine I'm using.
As for what settings to adjust...similar to the server side,
there should be two mutually exclusive buttons, one which says "use
the Java viewer from this machine's server" and an alternative which
reads "Use: __________" which has the "Browse..." button next to it,
so the user can go find their local copy of VNCViewer.exe. The Java
based viewer is an option we can disable until the "steel tube" tunnel
work is complete.
There are some other radio buttons that can go in here, and
they're described in the spec. Last but not least should be a CONNECT
button, and of course a CANCEL button.
Future Steel-Tube Work
======================
A quick comment here: I *think* you meant to say SSH in all
of these cased an not SSL. SSL is certainly a component of the
SSH transport-layer, but it a low-level protocol and so has little
to do with the user-auth and connection-layer parts of SSH.
My understanding of what you wrote below is that we'll
do the connection-layer first, designing it to be a single TCP
connection with "channel management" for an arbitrary numbers of
simultaneous data tunnels, all independent of the user-auth or
transport-layer. Good. Depending on resources, I'd like to either
implement an SSL-based transport-layer next, or fix the user-auth
layer to implement the two modes ("more secure" and "more private")
as discussed in the spec.
When you can, please confirm your understanding of the
above concerns regarding the UI aspects of the VNC wrapper.
Getting close!
-Scott
> II. SSL IMPLEMENTATION
>
> We understand your idea about separate implementation
> of the three SSL layers but our final considerations
> will be given after the Christmas:
>
> 1. Connection layer - supported by what we call Variant A.
>
> OL> A. Update the implementation of Kaboodle CSocketTCPIP class so as
> OL> to (a) retain the support of Remote Connection functionality (b)
> OL> and ensure the support of intensive bilateral data streams required
> OL> by VNC tunneling (see the previous report for detail). The
> OL> encryption and key exchange solution are left unchanged.
>
> This is to be done first of all and before any SSL part is applied.
>
> 2. Transport layer - take from SSL later on.
>
> 3. User authentication - uses your mechanism of "private partnership" and
> "verified partnership":
>
> SCB> I've done some work already specifying two key-exchange
> SCB> solutions.
>
> I suppose this is also a modification of the SSL authentication layer.
> We will need the authentication protocol specification from you.
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
