Hello Scott, The URL is http://www.winton.org.uk/zebedee (version 2.4.1). I have set the paths for Zebedee and TightVnc to the installation directory of kaboodle.exe. Please copy the zebedee and tightvnc viewer executables to the kaboodle executable folder.
Regards, Varsha ----- Original Message ----- From: "Scott C. Best" <[EMAIL PROTECTED]> To: "mailbox" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, September 10, 2002 9:46 AM Subject: Re: Kaboodle + zebedee Status > VK: > It would help a lot with eval if the zebedee and tightvnc paths > were setup to be the installation directory of Kaboodle.exe (which is > a registry setting), and not the paths you indicate. > > Also, exactly which Zebedee binary are you using? URL? > > thanks, > Scott > > On Sun, 8 Sep 2002, mailbox wrote: > > > Hello Scott, > > > > I have added the code for Zebedee (points 3 and 4 of the specifications for > > zebedee integration) in the Wincvs. At present the zebedee path and tightvnc > > paths are hardcode in the code. I will change once you finish your > > preliminary testing. > > > > Please install the tightvnc in C:\program files\tightVNC and zebedee in > > c:\program files\zebedee. Please enable the "Allow loopback connections" for > > tightvnc servers in order to make VNC servers visible in some of cases > > listed below. > > > > > > > > The zebedee works for pc1-- >pc4 , pc1-- >pc3, pc2-- >pc3, pc2-- >pc4, > > pc3-- >pc2, pc3-- >pc1 > > > > > > > > Regrads, > > > > Varsha > > > > ----- Original Message ----- > > > > From: "Scott C. Best" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, July 04, 2002 11:47 PM > > Subject: [Kaboodle-devel] Kaboodle VPN design review > > > > > > > > > > Heyaz. This email is meant for all of the people on > > > the development list. It's an overview of how I see the "VPN" > > > capability of Kaboodle working, and I need to know if any > > > of you see a problem. > > > > > > After sleeping on the idea, I've come to the decision > > > that utilizing the ZeBeDee utility is the best idea for version > > > 1.0. It may make sense to revisit this decision later on when > > > more resources are available. But given the requirements, the > > > budget, and our existing capabilities, it'd be crazy *not* > > > to use a utility as stable and well supported as ZeBeDee. Put > > > another way, it's ready now and better than what we could come > > > up with in any reasonable timeframe (sorry for any hurt feelings > > > here...no offense intended). > > > > > > Unfortunately...I am not sure how to best implement > > > the capability I need using ZeBeDee. Let me describe my target > > > need first, and then offer some ideas. What I need is this: > > > > > > PC1 PC2 PC3 PC4 > > > ------------- FW1 <=> Internet <=> FW2 -------------- > > > LAN1 LAN2 > > > > > > In this model, PC1, PC2 and PC3 are all running Kaboodle. > > > LAN1 and LAN2 are behind firewalls, and only a small handful (I > > > think it's doable with 1, but it's easier with 2) of TCP ports are > > > opened to PC2 and PC3 (PC1 and PC4 are not externally accessible > > > at all -- two firewalls direct all incoming Kaboodle-related data > > > for LAN1 to PC2 and for LAN2 to PC3). Presume that PC2 and PC3 are > > > connected using the VPN capability that we're now talking about (so > > > both ZeBeDee client and server binaries are available to all of the > > > Kaboodle instances). PC4 is not running Kaboodle, nor ZeBeDee, but > > > it is running a VNC server. Given all that as background, I need the > > > following to work: > > > > > > 1. Two users on PC2 and PC3 can discover each other using the > > > existing capabilities of Kaboodle (which now work). > > > > > > 2. Once IP addresses are discovered, PC2 and PC3 connect with > > > each other in some manner. Let's call this piece the > > > "Control Channel". Right now, it with some legacy code > > > that we custom-developed. Going forward, we may find it > > > better to use ZeBeDee for this as well. We support one > > > authentication means today; we can add others as we see > > > fit (or as the users insist). > > > > > > 3. Once the control channel is established, PC2 and PC3 exchange > > > their NID with each other. Because of this exchange, two > > > things need to happen: first, the GUI in both LAN1 and LAN2 > > > display the VPN connection state. This works. Second, the > > > Kaboodle services (ie, VNC and File Transfer today, other > > > things tomorrow) must recognize the remote machines as valid > > > "targets". For example, if PC4 is a VNC server on LAN2, > > > then Kaboodle on PC3 can administer a VNC session from PC3 > > > to PC4. We need to extend this "target awareness" so that > > > the Kaboodle instances on LAN1 also recognize PC4 as a valid > > > target for a VNC connection. The information needed to create > > > this awareness is definitely in the NID. > > > > > > 4. Once the NIDs are exchanged and the target awareness is made > > > available to all of the services, I should now be able to VNC > > > from PC1 to PC4 using a combination of Kaboodle tunnels and > > > the ZeBeDee connection (see below). > > > > > > 5. Importantly, if I am VNC'ing from PC1 to PC4 using this > > > capability, I should be able to start a Kaboodle file transfer > > > from PC2 to PC3 without interrupting the VNC connection. > > > This, I think, will be the trickiest part. > > > > > > Ideally, this "VPN connection" is secure as possible, so > > > it is secured between PC1 and PC2 using Kaboodle and between PC2 > > > and PC3 using ZeBeDee (I don't think we can go from PC2 to PC4 > > > using all ZeBeDee...but if anyone sees a way please suggest). > > > > > > The VNC data flow would look like this: A VNC client on PC1 > > > connects to localhost port 100 where Kaboodle on PC1 is listening. > > > Kaboodle on PC1 sends this data to port 200 on PC2. On PC2, Kaboodle > > > is listening to port 200. Kaboodle on PC2 also instructs a ZeBeDee > > > client on PC2 to listen to port 201 on the loopback interface. > > > Kaboodle takes the data from port 200, decrypts it using the > > > existing VNC tunneling capabilities, and pushes that data into > > > port 201 on the loopback interface. The ZeBeDee client collects > > > this data from TCP port 201 on the loopback interface of PC2 and > > > sends it to the ZeBeeDee server on PC3 which is listening to port > > > 300 (it knows to listen to port 300 because Kaboodle on PC3 told > > > it to). The ZeBeDee server forwards the data it receives on TCP port > > > 300 on PC3 to TCP port 5902 on PC4. The ZeBeDee server knows to > > > forward the data like this, because the ZeBeDee client on PC2 told > > > it to do so when it connected (eg, the ZeBeDee client had a kickoff > > > which looks like "zebedee -b 127.0.0.1 PC3 201:PC4:5902"). The > > > ZeBeDee client pn PC2 knew to use port 5902 because Kaboodle on > > > PC3 had this information in its NID after running VNC server > > > discovery on LAN2. The VNC server receives the data, and the > > > return path is symmetric. > > > > > > I think that covers it. Feedback welcome! > > > > > > cheers, > > > Scott > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Caffeinated soap. No kidding. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Kaboodle-devel mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/kaboodle-devel > > > > > > > > > ------------------------------------------------------- In remembrance www.osdn.com/911/ _______________________________________________ Kaboodle-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
