Re: VNC via dial-up networking ?
Mark, It sounds like the PC you are trying to connect from does not have an appropriate IP route to the dialed-in machine. Try one of the following: 1) On the PC where you want to run the viewer, set the RAS server as the default gateway in "Network Nbrhood->Properties->Protocols-> TCP/IP->Properties" (That's NT4, may be a bit different for Win9x or 2K). Of course, this may interfere with your PC's ability to access other network resources. 2) At the command line of the machine where you want to run the viewer: route add MASK The netmask should be the same as that of the dialed-in PC, which you should be able to find out by doing a "netstat -r" at the RAS server (I think). This should fix your problem without causing any undesirable side effects. Windows' "route" command is a little odd, so I may not have the syntax exactly right; you may need to experiment a bit. HTH, -- Joe Mark Graves wrote: > > I think I'm getting warmer ... If I run VNC Viewer on the RAS server, it > works fine and I can control the dialled-in PC, but if I run VNC Viewer > on my PC on the same network (logged-in to the same domain), I cannot > connect. Is there some way to do this from my PC ? Help appreciated. > > In message <000301c0594c$17210380$[EMAIL PROTECTED]>, > Richard Spaven <[EMAIL PROTECTED]> writes > >you could run 'netstat' on the RAS servers DOS prompt to determine the > >machine names connected to the server. > > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED]]On Behalf Of Mark Graves > >Sent: 28 November 2000 13:25 PM > >To: [EMAIL PROTECTED] > >Subject: VNC via dial-up networking ? > > > > > >Hi, > >Apologies if this has come up before (I did search the mailing list DB). > >I have VNC running in app. mode at work on our NT server, which allows > >me to run the viewer on my PC at home after logging on to the server via > >modem and dial-up networking. I can therefore remotely administer the > >server. > > > >This all works fine but now I would like to do kind of the reverse. I am > >at work sitting in front of my PC, and a user dials-in & logs-on to the > >network. I would like to run a viewer on my PC which will allow me to > >control his PC (assuming it has VNC running in app. mode). When I try > >this, I am unable to connect. Network neighbourhood does not show the > >user in the list, presumably because they are not local to the network. > >Is it possible to do what I'm trying to do ? Help appreciated. > > > >Regards, > >-- > >Mark Graves > >Penborn Technical Services > > > >Tel: +44 (0)20 8569 7979 > >Fax: +44 (0)20 8568 1621 > >Web: www.penborn.com > >- > >To unsubscribe, send a message with the line: unsubscribe vnc-list > >to [EMAIL PROTECTED] > >See also: http://www.uk.research.att.com/vnc/intouch.html > >- > > > > > >This message has been checked for all known viruses, by Star Internet, > >delivered through the MessageLabs Virus Control Centre. > >For further information visit: > >http://www.star.net.uk/stats.asp > > > > > > > > > >This message has been checked for all known viruses, by Star Internet, > >delivered through the MessageLabs Virus Control Centre. > >For further information visit: > >http://www.star.net.uk/stats.asp > >- > >To unsubscribe, send a message with the line: unsubscribe vnc-list > >to [EMAIL PROTECTED] > >See also: http://www.uk.research.att.com/vnc/intouch.html > >- > > -- > Mark Graves > Penborn Technical Services > > Tel: +44 (0)20 8569 7979 > Fax: +44 (0)20 8568 1621 > Web: www.penborn.com > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Reply-To: (was Re: VNC via dial-up networking ?)
My apologies for spamming the list with my previous reply to Mark's message. Apparently all vnc-list messages come with a "Reply-To" setting of "vnc-list", which I did not notice at the time. Why is this the case? Personally I expect my MUA's "Reply" function to reply to the author and "Reply All" to reply to the list, and the "Reply-To:" header does great violence to my expectations. Of course I will keep this characteristic of vnc-list in mind in the future, but I wonder if others are surprised by this behavior? $.02 -- Joe Mark Graves wrote: > > I think I'm getting warmer ... If I run VNC Viewer on the RAS server, it > works fine and I can control the dialled-in PC, but if I run VNC Viewer > on my PC on the same network (logged-in to the same domain), I cannot > connect. Is there some way to do this from my PC ? Help appreciated. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: SSH and VNC
Serge Dutremble wrote: > > I have tried to use SSH as specified in the documentation for encrypting my VNC > session. > > I have succesfully installed OpenSSH on two Linux PCs and I can SSH between the > two just fine. > > (PC1 is client and PC2 is server) > On establishing the redirection from PC1 using: > > ssh -L 5802:home.dns.entry:5801 home.dns.entry > > I get prompted for the VNC password and allowed in OK. I now have a SSH > terminal session on PC2. > > I then try to open a VNC connection from PC1 using the netscape browser at the > following URL: > > http://localhost:5802 > > I get an error message on PC1 stating that "a network error occured while > Netscape was receiving data.(Network error: broken pipe) Try connecting again. > > On my PC2 ssh terminal session, I get the following error: > > "channel_open_failure:2 reason 1: bla bla" > > The connection works fine without the encryption. I.E: > > http://home.dns.entry:5801 > > Any ideas on what I may be doing wrong? Use: ssh -L 5902:home.dns.entry:5901 -L 5802:home.dns.entry:5801 home.dns.entry You must forward the rfb port as well as the http port. HTH, - Joe > Serge. > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Jon Smith wrote: > > First of all thank you to everyone that helped me solve the problem of getting vnc >to work with windows ME ICS. > > I now have another problem. I want to be able to access VNC running on my home >computer from school. They have a proxy running and probably only on port 80 and >port 21. I have tried changing the port used by VNC to port 80 and port 21 and when >trying to connect on the web (using the java applet) I get a page with the characters >"RFB 003.003" and thats it. Does anyone know why this isn't working? Why isn't it >advisable to use ports like port 80 with vnc? How does the proxy handle the data >used on this port? If the java applet connects on this port will the proxy think its >loading up a web site a million times?! If you use the native VNC viewer for your platform and tell it to connect to port 80, it should work. Your problem occurs because the Java viewer is downloaded on one port (typically 5800+display), but the RFB protocol uses a different one (typically 5900+display). You've probably got the server listening for RFB connections on port 80, and HTTP connections on 5800. It would be nice if the server could serve the Java applet via HTTP on the RFB port, but unfortunately the RFB handshake begins with the server writing the RFB protocol version, whereas the HTTP handshake begins with the client sending an HTTP request -- which means the server can't decide what to do based on the client's request. Darn. -- Joe > Thanks in advance, > > Jon Smith. > > Like my email address? Get your own for FREE at http://firstname.com > Get [EMAIL PROTECTED] or [EMAIL PROTECTED] or pick from 500 more! > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Jens Wagner wrote: > > "Joseph A. Knapka" schrieb: > > > ... > > It would be nice if the server could serve the Java applet via > > HTTP on the RFB port, but unfortunately the RFB handshake > > begins with the server writing the RFB protocol version, > > whereas the HTTP handshake begins with the client sending an > > HTTP request -- which means the server can't decide what > > to do based on the client's request. Darn. > > > > -- Joe > > Nice idea. Maybe the server could wait one or two seconds for a client request. If >there's an http request within time the server will handle it as an http server, else >it will start the rfb hanshake. Good point. I'm in the process of cobbling together a patch for Xvnc :-) -- Joe > - jens > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Jens Wagner wrote:
>
> "Joseph A. Knapka" schrieb:
>
> > ...
> > It would be nice if the server could serve the Java applet via
> > HTTP on the RFB port, but unfortunately the RFB handshake
> > begins with the server writing the RFB protocol version,
> > whereas the HTTP handshake begins with the client sending an
> > HTTP request -- which means the server can't decide what
> > to do based on the client's request. Darn.
> >
> > -- Joe
>
> Nice idea. Maybe the server could wait one or two seconds for a client request. If
>there's an http request within time the server will handle it as an http server, else
>it will start the rfb hanshake.
>
> - jens
The attached small patch seems to work fine for Xvnc. It works
exactly as Jens suggests. Of course HTTP connections to 58xx
work as usual. I've tested with Netscape 4.76 and IE4. I'll
tackle the WinVNC server in a day or two unless someone
beats me to it.
-- Joe Knapka
diff -C 3 -r vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/httpd.c
vnc_patched/Xvnc/programs/Xserver/hw/vnc/httpd.c
*** vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/httpd.cThu Apr 29 05:10:54 1999
--- vnc_patched/Xvnc/programs/Xserver/hw/vnc/httpd.cTue Dec 5 22:51:56 2000
***
*** 158,163
--- 158,201
/*
+ * maybeHandleHTTPRequest is called when a client connects to the RFB
+ * port. If the client sends a get request within 2 seconds, we handle
+ * it here. Otherwise we go ahead and start the RFB handshake.
+ */
+ int maybeHandleHTTPRequest(int rfbSock)
+ {
+ fd_set fds;
+ int nfds;
+ struct timeval tv;
+ httpSock = rfbSock; /* For httpProcessInput's benefit */
+
+ if ((httpFP = fdopen(rfbSock, "r+")) == NULL) {
+ rfbLogPerror("maybeHandleHTTPRequest: fdopen");
+ close(rfbSock);
+ httpSock = -1;
+ return;
+ }
+
+ /* Now we must select() on rfbSock for 2 seconds. If
+ we get no data, we assume this is a regular RFB client. */
+ FD_ZERO(&fds);
+ FD_SET(rfbSock,&fds);
+ tv.tv_sec = 2;
+ tv.tv_usec = 0;
+ nfds = select(rfbSock + 1, &fds, NULL, NULL, &tv);
+ if (nfds == 0) {
+ httpSock = -1;
+ return 0;
+ }
+
+ /* Client is sending a GET request. */
+ httpProcessInput();
+
+ /* Tell caller we processed an HTTP request. */
+ return 1;
+ }
+
+ /*
* httpProcessInput is called when input is received on the HTTP socket.
*/
diff -C 3 -r vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/sockets.c
vnc_patched/Xvnc/programs/Xserver/hw/vnc/sockets.c
*** vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/sockets.c Wed Oct 25 09:42:22 2000
--- vnc_patched/Xvnc/programs/Xserver/hw/vnc/sockets.c Tue Dec 5 21:41:54 2000
***
*** 49,54
--- 49,58
#include "rfb.h"
+ /* Allow server to serve Java applet over RFB socket. This
+function is defined in httpd.c.
+ */
+ int maybeHandleHTTPRequest(int sock);
int rfbMaxClientWait = 2; /* time (ms) after which we decide client has
gone away - needed to stop us hanging */
***
*** 194,199
--- 198,215
fprintf(stderr,"\n");
rfbLog("Got connection from client %s\n", inet_ntoa(addr.sin_addr));
+ /* If the client wants us to serve the Java applet, do that.
+ Otherwise start the RFB handshake.
+ */
+ if (maybeHandleHTTPRequest(sock)) {
+ rfbLog("Woo hoo! Served Java applet via RFB!");
+ /* The http server has served the Java applet and disconnected
+the client. The client will reconnect to the RFB port and
+we will carry on.
+ */
+ return;
+ }
+
AddEnabledDevice(sock);
FD_SET(sock, &allFds);
maxFd = max(sock,maxFd);
***
*** 202,208
FD_CLR(rfbListenSock, &fds);
if (--nfds == 0)
! return;
}
if ((udpSock != -1) && FD_ISSET(udpSock, &fds)) {
--- 218,224
FD_CLR(rfbListenSock, &fds);
if (--nfds == 0)
! return;
}
if ((udpSock != -1) && FD_ISSET(udpSock, &fds)) {
-
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
-
Re: VNC on port 80
Oops. Better make sure that FP only gets allocated
if we really need it... Here's a corrected patch.
Sorry...
-- Joe
"Joseph A. Knapka" wrote:
>
> Jens Wagner wrote:
> >
> > "Joseph A. Knapka" schrieb:
> >
> > > ...
> > > It would be nice if the server could serve the Java applet via
> > > HTTP on the RFB port, but unfortunately the RFB handshake
> > > begins with the server writing the RFB protocol version,
> > > whereas the HTTP handshake begins with the client sending an
> > > HTTP request -- which means the server can't decide what
> > > to do based on the client's request. Darn.
> > >
> > > -- Joe
> >
> > Nice idea. Maybe the server could wait one or two seconds for a client request. If
>there's an http request within time the server will handle it as an http server, else
>it will start the rfb hanshake.
> >
> > - jens
>
> The attached small patch seems to work fine for Xvnc. It works
> exactly as Jens suggests. Of course HTTP connections to 58xx
> work as usual. I've tested with Netscape 4.76 and IE4. I'll
> tackle the WinVNC server in a day or two unless someone
> beats me to it.
-- Joe Knapka
diff -C 3 -r vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/httpd.c
vnc_patched/Xvnc/programs/Xserver/hw/vnc/httpd.c
*** vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/httpd.cThu Apr 29 05:10:54 1999
--- vnc_patched/Xvnc/programs/Xserver/hw/vnc/httpd.cTue Dec 5 23:26:48 2000
***
*** 158,163
--- 158,199
/*
+ * maybeHandleHTTPRequest is called when a client connects to the RFB
+ * port. If the client sends a get request within 2 seconds, we handle
+ * it here. Otherwise we go ahead and start the RFB handshake.
+ */
+ int maybeHandleHTTPRequest(int rfbSock)
+ {
+ fd_set fds;
+ int nfds;
+ struct timeval tv;
+ httpSock = rfbSock; /* For httpProcessInput's benefit */
+
+ FD_ZERO(&fds);
+ FD_SET(rfbSock,&fds);
+ tv.tv_sec = 2;
+ tv.tv_usec = 0;
+ nfds = select(rfbSock + 1, &fds, NULL, NULL, &tv);
+ if (nfds == 0) {
+ httpSock = -1;
+ return 0;
+ }
+
+ /* Client is sending a GET request. */
+ if ((httpFP = fdopen(rfbSock, "r+")) == NULL) {
+ rfbLogPerror("maybeHandleHTTPRequest: fdopen");
+ close(rfbSock);
+ httpSock = -1;
+ return 0;
+ }
+
+ httpProcessInput();
+
+ /* Tell caller we processed an HTTP request. */
+ return 1;
+ }
+
+ /*
* httpProcessInput is called when input is received on the HTTP socket.
*/
diff -C 3 -r vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/sockets.c
vnc_patched/Xvnc/programs/Xserver/hw/vnc/sockets.c
*** vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/sockets.c Wed Oct 25 09:42:22 2000
--- vnc_patched/Xvnc/programs/Xserver/hw/vnc/sockets.c Tue Dec 5 21:41:54 2000
***
*** 49,54
--- 49,58
#include "rfb.h"
+ /* Allow server to serve Java applet over RFB socket. This
+function is defined in httpd.c.
+ */
+ int maybeHandleHTTPRequest(int sock);
int rfbMaxClientWait = 2; /* time (ms) after which we decide client has
gone away - needed to stop us hanging */
***
*** 194,199
--- 198,215
fprintf(stderr,"\n");
rfbLog("Got connection from client %s\n", inet_ntoa(addr.sin_addr));
+ /* If the client wants us to serve the Java applet, do that.
+ Otherwise start the RFB handshake.
+ */
+ if (maybeHandleHTTPRequest(sock)) {
+ rfbLog("Woo hoo! Served Java applet via RFB!");
+ /* The http server has served the Java applet and disconnected
+the client. The client will reconnect to the RFB port and
+we will carry on.
+ */
+ return;
+ }
+
AddEnabledDevice(sock);
FD_SET(sock, &allFds);
maxFd = max(sock,maxFd);
***
*** 202,208
FD_CLR(rfbListenSock, &fds);
if (--nfds == 0)
! return;
}
if ((udpSock != -1) && FD_ISSET(udpSock, &fds)) {
--- 218,224
FD_CLR(rfbListenSock, &fds);
if (--nfds == 0)
! return;
}
if ((udpSock != -1) && FD_ISSET(udpSock, &fds)) {
-
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
-
Re: port80 WinVNC patch?
Jon Smith wrote: > > Is that version for linux? Can anyone make a version for windows? I'm going to look at patching WinVNC tonight. -- Joe > Thanks, > Jon > > --- > > Oops. Better make sure that FP only gets allocated > if we really need it... Here's a corrected patch. > Sorry... > > -- Joe > > "Joseph A. Knapka" wrote: > > > > Jens Wagner wrote: > > > > > > "Joseph A. Knapka" schrieb: > > > > > > > ... > > > > It would be nice if the server could serve the Java applet via > > > > HTTP on the RFB port, but unfortunately the RFB handshake > > > > begins with the server writing the RFB protocol version, > > > > whereas the HTTP handshake begins with the client sending an > > > > HTTP request -- which means the server can't decide what > > > > to do based on the client's request. Darn. > > > > > > > > -- Joe > > > > > > Nice idea. Maybe the server could wait one or two seconds for a client request. >If there's an http request within time the server will handle it as an http server, >else it will start the rfb hanshake. > > > > > > - jens > > > > The attached small patch seems to work fine for Xvnc. It works > > exactly as Jens suggests. Of course HTTP connections to 58xx > > work as usual. I've tested with Netscape 4.76 and IE4. I'll > > tackle the WinVNC server in a day or two unless someone > > beats me to it. > > -- Joe Knapka > > Like my email address? Get your own for FREE at http://firstname.com > Get [EMAIL PROTECTED] or [EMAIL PROTECTED] or pick from 500 more! > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
"Joseph A. Knapka" wrote:
> > > > It would be nice if the server could serve the Java applet via
> > > > HTTP on the RFB port, but unfortunately the RFB handshake
One more fix (last one, I promise): in the unlikely event that
the fdopen() call fails, we should not then attempt to use the
closed socket for RFB...
-- Joe
diff -C 3 -r vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/httpd.c
vnc_patched/Xvnc/programs/Xserver/hw/vnc/httpd.c
*** vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/httpd.cThu Apr 29
05:10:54 1999
--- vnc_patched/Xvnc/programs/Xserver/hw/vnc/httpd.cTue Dec 5
23:26:48 2000
***
*** 158,163
--- 158,199
/*
+ * maybeHandleHTTPRequest is called when a client connects to the RFB
+ * port. If the client sends a get request within 2 seconds, we handle
+ * it here. Otherwise we go ahead and start the RFB handshake.
+ */
+ int maybeHandleHTTPRequest(int rfbSock)
+ {
+ fd_set fds;
+ int nfds;
+ struct timeval tv;
+ httpSock = rfbSock; /* For httpProcessInput's benefit */
+
+ FD_ZERO(&fds);
+ FD_SET(rfbSock,&fds);
+ tv.tv_sec = 2;
+ tv.tv_usec = 0;
+ nfds = select(rfbSock + 1, &fds, NULL, NULL, &tv);
+ if (nfds == 0) {
+ httpSock = -1;
+ return 0;
+ }
+
+ /* Client is sending a GET request. */
+ if ((httpFP = fdopen(rfbSock, "r+")) == NULL) {
+ rfbLogPerror("maybeHandleHTTPRequest: fdopen");
+ close(rfbSock);
+ httpSock = -1;
+ return 1; /* OK, we tried. Caller should give up now. */
+ }
+
+ httpProcessInput();
+
+ /* Tell caller we processed an HTTP request. */
+ return 1;
+ }
+
+ /*
* httpProcessInput is called when input is received on the HTTP
socket.
*/
diff -C 3 -r vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/sockets.c
vnc_patched/Xvnc/programs/Xserver/hw/vnc/sockets.c
*** vnc_unixsrc/Xvnc/programs/Xserver/hw/vnc/sockets.c Wed Oct 25
09:42:22 2000
--- vnc_patched/Xvnc/programs/Xserver/hw/vnc/sockets.c Tue Dec 5
21:41:54 2000
***
*** 49,54
--- 49,58
#include "rfb.h"
+ /* Allow server to serve Java applet over RFB socket. This
+function is defined in httpd.c.
+ */
+ int maybeHandleHTTPRequest(int sock);
int rfbMaxClientWait = 2; /* time (ms) after which we decide
client has
gone away - needed to stop us hanging
*/
***
*** 194,199
--- 198,215
fprintf(stderr,"\n");
rfbLog("Got connection from client %s\n",
inet_ntoa(addr.sin_addr));
+ /* If the client wants us to serve the Java applet, do that.
+ Otherwise start the RFB handshake.
+ */
+ if (maybeHandleHTTPRequest(sock)) {
+ rfbLog("Woo hoo! Served Java applet via RFB!");
+ /* The http server has served the Java applet and disconnected
+the client. The client will reconnect to the RFB port and
+we will carry on.
+ */
+ return;
+ }
+
AddEnabledDevice(sock);
FD_SET(sock, &allFds);
maxFd = max(sock,maxFd);
***
*** 202,208
FD_CLR(rfbListenSock, &fds);
if (--nfds == 0)
! return;
}
if ((udpSock != -1) && FD_ISSET(udpSock, &fds)) {
--- 218,224
FD_CLR(rfbListenSock, &fds);
if (--nfds == 0)
! return;
}
if ((udpSock != -1) && FD_ISSET(udpSock, &fds)) {
-- Joe Knapka
-
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
-
Re: VNC on port 80
"Joseph A. Knapka" wrote:
>
> > > > > It would be nice if the server could serve the Java applet via
> > > > > HTTP on the RFB port, but unfortunately the RFB handshake
Here's a patch for WinVNC. I've also made a WinVNC 3.3.3r7 executable
containing this patch available at
http://home.earthlink.net/~jknapka/WinVNC.exe
Now you can point your browser at host:5900 and get connected.
-- Joe Knapka
diff -r vncsrc_orig/vnc_winsrc/winvnc/VSocket.cpp vncsrc/vnc_winsrc/winvnc/VSocket.cpp
448a449,464
> VSocket::ReadSelect(VCard to)
> {
> fd_set fds;
> FD_ZERO(&fds);
> FD_SET((unsigned long)sock,&fds);
> struct timeval tv;
> tv.tv_sec = to/1000;
> tv.tv_usec = to % 1000;
> int rc = select(sock+1,&fds,0,0,&tv);
> if (rc>0) return true;
> return false;
> }
>
>
>
> VBool
diff -r vncsrc_orig/vnc_winsrc/winvnc/VSocket.h vncsrc/vnc_winsrc/winvnc/VSocket.h
119a120,123
> // Check to see if the socket becomes readable within msec.
> // Added to support HTTP-via-RFB.
> VBool ReadSelect(VCard to);
>
diff -r vncsrc_orig/vnc_winsrc/winvnc/vncHTTPConnect.cpp
vncsrc/vnc_winsrc/winvnc/vncHTTPConnect.cpp
67a68,79
> // Added for HTTP-via-RFB. Allows us to handle an HTTP transaction
> // without starting a separate thread.
> class vncHTTPConnectThreadHelper {
> public:
> // Routines to handle HTTP requests
> void Init(vncServer* svr) { m_server = svr; }
> void DoHTTP(VSocket *socket);
> char *ReadLine(VSocket *socket, char delimiter, int max);
> protected:
> vncServer *m_server;
> };
>
69c81
< class vncHTTPConnectThread : public omni_thread
---
> class vncHTTPConnectThread : public omni_thread, public vncHTTPConnectThreadHelper
79,80c91,92
< virtual void DoHTTP(VSocket *socket);
< virtual char *ReadLine(VSocket *socket, char delimiter, int max);
---
> //virtual void DoHTTP(VSocket *socket);
> //virtual char *ReadLine(VSocket *socket, char delimiter, int max);
85d96
< vncServer *m_server;
88a100,118
> // Added for HTTP-via-RFB. This function is called when a connection is
> // accepted on the RFB port. If the client sends an HTTP request we
> // (attempt to) handle it here and return TRUE. Otherwise we return
> // FALSE and the caller continues with the RFB handshake.
> VBool maybeHandleHTTPRequest(VSocket* sock,vncServer* svr)
> {
> if (!sock->ReadSelect(2000)) return false;
>
> // Client is sending data. Create a vncHTTPConnectThread to
> // handle it.
> vncHTTPConnectThreadHelper http;
> http.Init(svr);
> http.DoHTTP(sock);
> sock->Shutdown();
> sock->Close();
> delete sock;
> return true;
> }
>
98c128,129
< // Start the thread
---
> // Start the thread [unless we were created to handle an HTTP
> // transaction on the RFB port, in which case socket==0]
100c131
< start_undetached();
---
> if (socket) start_undetached();
134c165
< void vncHTTPConnectThread::DoHTTP(VSocket *socket)
---
> void vncHTTPConnectThreadHelper::DoHTTP(VSocket *socket)
293c324
< char *vncHTTPConnectThread::ReadLine(VSocket *socket, char delimiter, int max)
---
> char *vncHTTPConnectThreadHelper::ReadLine(VSocket *socket, char delimiter, int max)
diff -r vncsrc_orig/vnc_winsrc/winvnc/vncSockConnect.cpp
vncsrc/vnc_winsrc/winvnc/vncSockConnect.cpp
34a35,37
> // Added for HTTP-via-RFB
> VBool maybeHandleHTTPRequest(VSocket* sock,vncServer* svr);
>
81a85,93
>
> // If the client wants us to serve it the Java applet, do that;
> // otherwise, start the RFB handshake.
> if (maybeHandleHTTPRequest(new_socket,m_server)) {
> // HTTP request has been handled and new_socket closed. The
>client will
> // now reconnect to the RFB port and we will carry on.
> log.Print(LL_CLIENTS,VNCLOG("Woo hoo! Served Java applet via
>RFB!"));
> continue;
> }
-
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
-
Re: Vnc Java Compile is a no-go!
Hi Frank, You need to point your browser at http://hostname:58xx where xx is the display number (almost certainly zero if you are using WinVNC). The browser downloads the Java viewer from that port using HTTP, then connects to the VNC server at port 59xx and initiates the VNC session using RFB. If this really bugs you, or if you would prefer to have to deal with only one port (eg because of a proxy server or firewall), then try my hacked version of WinVNC that serves the Java viewer via port 59xx: http://home.earthlink.net/~jknapka/WinVNC.exe Using that server, you can aim your browser at hostname:5900 and get connected. HTH, -- Joe Frank Griffith wrote: > > Okay, another piece put away but I still cannot get the > Web Browser feature working. > > I have FreeBSD 4.2 and Xvnc is running great. I had to add > the jdk1.1.8 port in order to compile the vnc_javasrc files > and now that is done. > > I start the server with vncserver command and I can access the > system through the vncviewer from Win9x just fine. But then I > enter IE5.5 and put in http://myurl.com:5801/ and get Page Can > Not Be Found error! > > The docs are scattered all over the place on this. There is no one > place to look. Some places say use 5801 others say 5900. When > I tried 5901 I got a page that says "RFB 003.003". At least there > was no error here but it's still no-cigar! > > - Original Message - > From: "Frank Griffith" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, December 07, 2000 11:53 AM > Subject: Re: Vnc Java Compile is a no-go! > > > FreeBSD 4.2 server running Xvnc... > > > > Okay, one more piece of the puzzle done but it's still a > > no go. I was able install the jdk-1.1.8 port that comes > > with FreeBSD but I still get the exact same error > > message when I "make all". > > > > I tried reobooting but it's still no dice! Is there something > > missing? Someone recommended setting the path to > > the java directory, but in all honesty I cannot tell where > > that is. The file javamc has been added to the drive > > after I installed the port. This file is in /usr/local/bin > > directory and this is in the path. But there is no info > > on where the port installed. > > > > I will try to manually install the JDK next. > > > > > > - Original Message - > > From: "Jonathan Morton" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, December 07, 2000 9:58 AM > > Subject: Re: Vnc Java Compile is a no-go! > > > > > > > >Thanks for your reply. Being a newbie at some of > > > >this I assume you mean a Java Development Kit (JDK). > > > >And if so, how and where do I obtain one? > > > > > > http://java.sun.com/ > > > > > > http://www.blackdown.org/ > > > > > > http://www.ibm.com/ > > > > > > ...for various versions of *IX-compatible JDK's. > > > > > > -- > > > from: Jonathan "Chromatix" Morton > > > mail: [EMAIL PROTECTED] (not for attachments) > > > big-mail: [EMAIL PROTECTED] > > > uni-mail: [EMAIL PROTECTED] > > > > > > The key to knowledge is not to rely on people to teach you it. > > > > > > Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ > > > > > > -BEGIN GEEK CODE BLOCK- > > > Version 3.12 > > > GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? > PS > > > PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ > > > -END GEEK CODE BLOCK- > > > - > > > To unsubscribe, send a message with the line: unsubscribe vnc-list > > > to [EMAIL PROTECTED] > > > See also: http://www.uk.research.att.com/vnc/intouch.html > > > - > > - > > To unsubscribe, send a message with the line: unsubscribe vnc-list > > to [EMAIL PROTECTED] > > See also: http://www.uk.research.att.com/vnc/intouch.html > > - > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
HTTP-via-RFB patches
The patches for serving the Java viewer via the RFB port are now available at http://home.earthlink.net/~jknapka/vncpatch.html The patched WinVNC is there as well. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Jon Smith wrote: > > I downloaded your patch for win VNC so that i would be able to use VNC at school > (which has a proxy only allowing some ports like port 80) I changed the port > setting in the registry to port 80 and i have just tried to access my home computer > from school using the java applet through the web page. The java applet loads up > fine but when i enter a password it comes back with an error message a couple of > minutes later saying somthing like "operation timed out, no connection to host" what > could be cauusing this? Does the java applet know to use the proxy server of the > school? The Java applet -- aah. Probably doesn't know it has to go through port 80 to get to the VNC server. It is probably trying to use 5900 or similar. I will investigate this. It will probably mean adding an option to the Java viewer to select which port to connect on. -- Joe > Thanks, > > Jon > > > Get you FREE Firstname email address at http://www.Firstname.com > > Get a FREE Cell Phone at http://www.freecellphonedeal.com -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Harmen van der Wal wrote: > > "Joseph A. Knapka" wrote: > > > > Jon Smith wrote: > > > > > > I downloaded your patch for win VNC so that i would be able to use VNC at school > > > (which has a proxy only allowing some ports like port 80) I changed the port > > > setting in the registry to port 80 and i have just tried to access my home >computer > > > from school using the java applet through the web page. The java applet loads up > > > fine but when i enter a password it comes back with an error message a couple of > > > minutes later saying somthing like "operation timed out, no connection to host" >what > > > could be cauusing this? Does the java applet know to use the proxy server of the > > > school? > > > > The Java applet -- aah. Probably doesn't know it has to go through port > > 80 to get to the VNC server. It is probably trying to use 5900 or > > similar. > > > > I will investigate this. It will probably mean adding an option to the > > Java viewer to select which port to connect on. > > > > -- Joe > > > > Keep in mind that the Java applet loaded through a HTTP proxy, doesn't > use that proxy with the rfb protocol. So having both http & rfb on port > 80 alone doesn't help those who can't use direct TCP/IP connections (or > some kind of transparent proxy), but must use their LAN's HTTP proxy. > (Anyone can test this by telnetting to the rfb host+port) I had not thought about that. This seems to make my patch useless, since the only situation in which it would really be necessary is the one where there is an HTTP proxy involved. Oh well. > I have modified the Java viewer to use HTTP proxies (that allow HTTP > CONNECT /SSL) for rfb. The problem for use with LAN HTTP proxies though, > is that the applet must connect to the local HTTP proxy, but Java applet > security prohibits this, because the applet is hosted elsewhere. So the > viewer must be run as an app, or with an appletviewer with adjusted > security settings. > > If on the other hand someone is able to make direct connections, but > only on port 80, it's possible to use an outside-the-LAN-HTTP-proxy to > both load the applet and make the rfb connection on port 80. The Java > security problem can be fixed by loading the applet explicitely through > the HTTP proxy (beware: most HTTP proxies don't allow for this though). > > Note that this method doesn't need a modified server. Just common > 5800/5901 vnc will do. The modified Java client is available on my site. > Anyone with a client-side packet filtering problem can use it with HTML > like this: > > APPLET > codebase=http://proxy.spaceproxy.com:80/-_-http://www.workspot.net/~harmen/vnc > code=vncviewer.class archive=vncviewer.jar width=800 height=600 > PARAM name=HOST value=[your vnc/rfb server host] > PARAM name=PORT value=5901 > PARAM name=PROXYHOST1 value=proxy.spaceproxy.com > PARAM name=PROXYPORT1 value=80 > /APPLET > (brackets left out of code not to confuse some mail readers) > > For those who must go through their LAN's HTTP proxy there's a bunch of > http-tunnel-tools out there, but it would be ideal in my mind to have a > Java applet do it, becuase you can use it wherever you might happen to > be. Off course this would also require adjustment on the server-side. I am not sure I understand this point. You seem to be saying, (1) It is possible, with no client or server changes, to tunnel both HTTP and RFB connections through a third-party HTTP tunnel host, and achieve a connection; (2) the applet and server should just wrap the RFB protocol inside HTTP, and thus eliminate the http-tunnel host. Is that correct? Thanks, -- Joe > Anyway: I will be following your progress with interest: Good Luck! > > -- > Harmen > Firewall VNC Client: http://www.workspot.net/~harmen/vnc/readme.html -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Harmen van der Wal wrote: > > "Joseph A. Knapka" wrote: > > > > Harmen van der Wal wrote: > > > > > > For those who must go through their LAN's HTTP proxy there's a bunch of > > > http-tunnel-tools out there, but it would be ideal in my mind to have a > > > Java applet do it, becuase you can use it wherever you might happen to > > > be. Off course this would also require adjustment on the server-side. > > > > I am not sure I understand this point. You seem to be saying, > > > > (1) It is possible, with no client or server changes, to tunnel > > both HTTP and RFB connections through a third-party HTTP tunnel > > host, and achieve a connection; > > Well, the client connects to the client-side tunnel software instead of > to the actual vnc-server; the actual vnc-server gets a connection from > the server-side tunnel software. Both vnc client and server need not > know whats actually going on. > > > > (2) the applet and server should just wrap the RFB protocol inside > > HTTP, and thus eliminate the http-tunnel host. > > I would like to have at least incorporated the client-side http-tunnel > software in the Java viewer. The whole purpose of the Java viewer is > that you will always have a viewer available wherever you are. You > shouldn't have to bring your own tunnel software along in order to be > able to use it. I understand now. Is there any standard for tunnelling other protocols over HTTP, or do all of those services use their own ad-hoc methods? > But if I'm not mistaken, an applet talking HTTP (besides HTTP CONNECT > off course) will automatically use the browsers proxy configuration, > without raising security objections as far as the HTTP-proxy-host is > concerned. This would allow for an applet encapsulating rfb in HTTP, > transparently using any LAN HTTP proxy. This seems to be the ideal solution. Though I'm not sure "ideal" is the ideal word to describe it... > Now that would render both your and my patch useless;-) Well at least in > most cases:-(( Woo hoo! > <...> > > -- > Harmen > Firewall VNC Client: http://www.workspot.net/~harmen/vnc/readme.html -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC on port 80
Harmen van der Wal wrote: > > "Joseph A. Knapka" wrote: > > > > Harmen van der Wal wrote: > <...> > > I understand now. Is there any standard for tunnelling other > > protocols over HTTP, or do all of those services use their > > own ad-hoc methods? > > Well, I'm no expert on this, but I've been planning to look into this > for a while now, and maybe build the ideal firewall Java viewer;-) I > guess the techiniques are pretty standard. > > This discusses them in some detail, and has the Java-utils ready made: > http://www.mokabyte.it/2000/06/firewallutil.htm This looks very easy. It seems to imply that once the client and the server have exchanged a POST and response with no content-length specified, they can carry on their RFB conversation without interference from the proxy, provided the same connection is used. I will look at adding support for this to my server patches, once I'm sure I understand it. > I remember there's also some coding examples on Suns Java site, on the > subject of thread pools, if I'm not mistaken. I'd have to look it up. > I don't think we want Java on the server-side though. Possibly the author of the Java VNC server package would like to comment (jVNC? VNCj?). > Also check out: > http://www.nocrew.org/software/httptunnel.html > > Maybe we, and Jonathan? can collaborate on this... > That sounds like a good idea. I think I can handle the Win and X servers :-) It may also make sense to add HTTP tunneling to the native viewers, since the Java viewer is very noticably slower. Regards, -- Joe > CU, > Harmen. > > > > > > But if I'm not mistaken, an applet talking HTTP (besides HTTP CONNECT > > > off course) will automatically use the browsers proxy configuration, > > > without raising security objections as far as the HTTP-proxy-host is > > > concerned. This would allow for an applet encapsulating rfb in HTTP, > > > transparently using any LAN HTTP proxy. > > > > This seems to be the ideal solution. Though I'm not sure "ideal" > > is the ideal word to describe it... > > > > > Now that would render both your and my patch useless;-) Well at least in > > > most cases:-(( > > > > Woo hoo! > > > <...> > -- > Harmen > Firewall VNC Client: http://www.workspot.net/~harmen/vnc/readme.html > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Java Xvnc quit working!
Frank Griffith wrote: > > I installed Xvnc on my FreeBSD 4.2 server. Everything > looked great. The VNCViewer sessions went smooth > and I was truly impressed with the Java scripts which > allowed seeing the KDE desktop of the Unix server in > an IE5 browser window. > > But this morning I tried to access the Java session again > through IE5.5 and I got this error message when I logged > in to the session: > > java.lang.ArrayIndexOutOfBoundsException I get this error about 10% of the time when I try to run the Java viewer in IE. Try connecting again and see what happens. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
HTTP tunneling
Hi, Harmen, http://home.earthlink.net/~jknapka/vncpatch.html Toward the bottom are patches for Xvnc and WinVNC that attempt to implement HTTP tunnelling. They just look for a POST request on the RFB port, reply with an HTTP "OK", and then start the RFB handshake. These patches should not interfere with the operation of normal non-tunnelling clients. It is not tested because I don't have a tunnelling viewer or an HTTP proxy to test with. I'm investigating setting up a proxy, but maybe you can try this out, or else tell me why it isn't going to work :-) I think it will, but I haven't finished understanding RFC2616 yet, so I may be wrong. -- Joe -- Joe Knapka ... etc ... - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Problems compiling Xvnc on Solaris 7 x86
Andreas Schmidt wrote: > > Hello, > > yes - you must change vnc_unixsrc/Xvnc/config/cf/site.def. > Uncomment the lines > > /* > #ifndef HasGcc2 > #define HasGcc2 YES > #endif > */ > > by removing "#". That should do the job. ...although it is possible that removing /* */ might work better :-) -- Joe -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Problems with Compiling Xvnc
It looks as if Phillip ran "xmkmf" before running "make World". On my Linux box that results in exactly the problem described. You need to just unpack the tarball and do "cd vnc_unixsrc/Xvnc ; make World" -- Joe Carlyle Sutphen wrote: > > It should be made during the make World run. > > Did you abbreviate your output from make? I get: > > snip- > > Building Release 6.3 of the X Window System. > > I hope you checked the configuration parameters in ./config/cf > to see if you need to pass BOOTSTRAPCFLAGS. > > Wed Nov 1 13:17:26 MEZ 2000 > > cd ./config/imake && make -f Makefile.ini BOOTSTRAPCFLAGS="" clean > snip- > > > Looking at the Makefile, it seems it is created in the target section > imake.bootstrap: > > My guess is that you need to set BOOTSTRAPCFLAGS. > > Date: 19.12.2000 23:09 > To:[EMAIL PROTECTED] > > Reply to: [EMAIL PROTECTED] > > Subject: RE: Problems with Compiling Xvnc > Message text: > > Jeff, > >Thanks but that still didn't work: Look below: > > make World MAKE=/opt/app/pkg/gnu/bin/make > /opt/app/pkg/gnu/bin/make -f xmakefile all > make: xmakefile: No such file or directory > make: *** No rule to make target `xmakefile'. Stop. > *** Error code 2 > make: Fatal error: Command failed for target `World' > # /opt/app/pkg/gnu/bin/make -v > GNU Make version 3.78.1, by Richard Stallman and Roland McGrath. > Built for sparc-sun-solaris2.6 > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 > Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > Report bugs to <[EMAIL PROTECTED]>. > > The problem is that is can't find xmakefile. So where the heck is it? > > Phillip > > -Original Message- > From: jeff whitaker [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 19, 2000 12:11 PM > To: [EMAIL PROTECTED] > Subject: Re: Problems with Compiling Xvnc > > --- In [EMAIL PROTECTED], "Bruce, Phillip" <[EMAIL PROTECTED]> wrote: > > Hi, > > > >I'm trying to compile the Xvnc and get the following: > > > > # make World > > /usr/ccs/bin/make -f xmakefile all > > make: Fatal error: Can't find `xmakefile': No such file or directory > > Current working directory /usr/local/software/VNC/vnc_unixsrc/Xvnc > > *** Error code 1 > > make: Fatal error: Command failed for target `World' > > > > It seems that it can't fine xmakefile in this script. Where is this > > xmakefile at? > > > > This is on Solaris 2.65/98 release. > > > > > > > > You must gnu make on Solaris. On my system, > > make World MAKE=/usr/local/bin/make > > does the trick. > > -Jeff > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - > * > The information in this email is confidential and may be legally privileged. > It is intended solely for the addressee. Access to this email by anyone else > is unauthorized. > > If you are not the intended recipient, any disclosure, copying, distribution > or any action taken or omitted to be taken in reliance on it, is prohibited > and may be unlawful. When addressed to our clients any opinions or advice > contained in this email are subject to the terms and conditions expressed in > the governing KPMG client engagement letter. > * > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - > > -- > > Diese E-Mail enthdlt vertrauliche und/oder rechtlich gesch|tzte Informationen. > Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt|mlich > erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie > diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. If you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorised > copying, disclosure or distribution of the material in this e-mail is strictly > forbidden. > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EM
Re: VNC and SSH
"Erdely, Michael" wrote: > > Is your goal to use the java client from a web browser? If not, let's > abandon that line of thinking now. > > First of all, find out what port VNC Server is running on. Make sure that > "Allow Loopback" is enabled. > >From the client, run "ssh -L 5920:localhost:5902 remotehost" This assumes > that VNC Server is running on port 5902 on the remote host. Also, > localhost, in this context, is referring to "localhost" from the SSH > Server's point of view... meaning: itself. Now, connect, from the client, > to localhost:20 using the vncviewer. > > Now, if your goal _IS_ to use the java client from a web browser, make sure > that 1. VNC Server _IS_ running on 5902. Also make sure that nothing is > running on the client machine on ports 5902 or 5802. Now, make your ssh > connection like this: ssh -L 5902:localhost:5902 -L 5802:localhost:5802 > remotehost. Next, use your web browser and connect to > http://remotehost:5802/. Bingo. Just to avoid further confusion: you surely meant to say "connect to http://localhost:5802/." -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and SSH
"Joseph A. Knapka" wrote: > > "Erdely, Michael" wrote: > > > > Is your goal to use the java client from a web browser? If not, let's > > abandon that line of thinking now. > > > > First of all, find out what port VNC Server is running on. Make sure that > > "Allow Loopback" is enabled. > > >From the client, run "ssh -L 5920:localhost:5902 remotehost" This assumes This makes no sense. You are just forwarding port 5920 from localhost to itself, via the SSH server, with encryption for the first half of the journey only. "ssh -L 5920:remotehost:5902 remotehost" will do what you (seem to) want. The "-L ::" option means "forward all data arriving at localhost: to :, using an encrypted tunnel for the part of the journey between localhost an sshd-host". > > that VNC Server is running on port 5902 on the remote host. Also, > > localhost, in this context, is referring to "localhost" from the SSH > > Server's point of view... meaning: itself. Now, connect, from the client, > > to localhost:20 using the vncviewer. > > Now, if your goal _IS_ to use the java client from a web browser, make sure > > that 1. VNC Server _IS_ running on 5902. Also make sure that nothing is > > running on the client machine on ports 5902 or 5802. Now, make your ssh > > connection like this: ssh -L 5902:localhost:5902 -L 5802:localhost:5802 > > remotehost. Next, use your web browser and connect to > > http://remotehost:5802/. Bingo. > > Just to avoid further confusion: you surely meant to say "connect to > http://localhost:5802/." Now that I read more carefully I see that my suggestion immediately above would not work. Perhaps I completely misunderstand what you are trying to do here. If the VNC server is on remotehost at display :2, along with the SSH daemon, and you want the viewer to run on localhost with an encrypted tunnel to remotehost, and you want to use the Java viewer, you need local ports 5802 and 5902 forwarded to the corresponding remote ports. So you would do: ssh -L 5902:remotehost:5902 -L 5802:remotehost:5802 remotehost and connect to "http://localhost:5902/". I'm sorry if I have confused the issue further :( But the method above will certainly work for the case described. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and SSH
"Joseph A. Knapka" wrote: > > "Joseph A. Knapka" wrote: > > > > "Erdely, Michael" wrote: > > > > > > Is your goal to use the java client from a web browser? If not, let's > > > abandon that line of thinking now. > > > > > > First of all, find out what port VNC Server is running on. Make sure that > > > "Allow Loopback" is enabled. > > > >From the client, run "ssh -L 5920:localhost:5902 remotehost" This assumes > > This makes no sense. You are just forwarding port 5920 from localhost > to itself, via the SSH server, with encryption for the first half of the > journey only. "ssh -L 5920:remotehost:5902 remotehost" will do what you > (seem to) want. The "-L ::" option > means "forward all data arriving at localhost: to > :, using an encrypted tunnel for the part > of the journey between localhost an sshd-host". > > > > that VNC Server is running on port 5902 on the remote host. Also, > > > localhost, in this context, is referring to "localhost" from the SSH > > > Server's point of view... meaning: itself. Now, connect, from the client, > > > to localhost:20 using the vncviewer. > > > > Now, if your goal _IS_ to use the java client from a web browser, make sure > > > that 1. VNC Server _IS_ running on 5902. Also make sure that nothing is > > > running on the client machine on ports 5902 or 5802. Now, make your ssh > > > connection like this: ssh -L 5902:localhost:5902 -L 5802:localhost:5802 > > > remotehost. Next, use your web browser and connect to > > > http://remotehost:5802/. Bingo. > > > > Just to avoid further confusion: you surely meant to say "connect to > > http://localhost:5802/." > > Now that I read more carefully I see that my suggestion > immediately above would not work. > > Perhaps I completely misunderstand what you are trying to do here. > If the VNC server is on remotehost at display :2, along with the > SSH daemon, and you want the viewer to run on localhost with an > encrypted tunnel to remotehost, and you want to use the Java viewer, > you need local ports 5802 and 5902 forwarded to the corresponding > remote ports. So you would do: > > ssh -L 5902:remotehost:5902 -L 5802:remotehost:5802 remotehost > > and connect to "http://localhost:5902/". DUH! Make that "http://localhost:5802/". Sorry, brain is out for maintenance at the moment. -- Joe > I'm sorry if I have confused the issue further :( But the method > above will certainly work for the case described. > > -- Joe Knapka -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and SSH
"Erdely, Michael" wrote: > > When you do a port forward on an SSH server, "localhost" is from the SSH > server's point of view. In this context, localhost = remotehost. > > -ME > Ah. You're right, of course. I think it was a bit confusing to me because it was not clear whether "localhost" meant the literal string "localhost", or "insert the name of the machine" in the sense that "remotehost" clearly did. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Problems with Compiling Xvnc
So you are saying that the compile fails with v 3.78.1 of Gnu make? I am using 3.79 and it works fine. -- Joe "Bruce, Phillip" wrote: > > Joe, > > You spot on. But for those that need to know. > When compiled with this version of Make: > > # make -v > GNU Make version 3.78.1, by Richard Stallman and Roland McGrath. > Built for sparc-sun-solaris2.6 > Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 > Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > Report bugs to <[EMAIL PROTECTED]>. > > It failed. So I did the Sun standard Make and it compiled EXTREMELY Clean. > So you guys figure out why this doesn't work with GNU make. > > But I got it compiled and installed even works with the JAVA implementation. > Not Bad. > > Now, I've only got one problem left. > > The last problem is that I'm still running in CDE environment. It comes up > ok. > But it doesn't go thru the loggin screen first. It goes straight as if you > were > already logged in. This true with the JAVA implementation as well. > > Any ideas on this? > > Phillip > > > -Original Message- > From: Joseph A. Knapka [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 20, 2000 10:20 AM > To: [EMAIL PROTECTED] > Subject: Re: Problems with Compiling Xvnc > > It looks as if Phillip ran "xmkmf" before running > "make World". On my Linux box that results in > exactly the problem described. You need to just > unpack the tarball and do > "cd vnc_unixsrc/Xvnc ; make World" > > -- Joe -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and SSH
"Erdely, Michael" wrote: > > Well... I have to be honest with you, I haven't worked with the Linux > version of VNC Server for a while. And not with SSH. Maybe it is enabled > by default. Then, I'm not sure why it isn't working. > > -ME > > - Original Message - > From: "Serge Dutremble" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, December 21, 2000 8:42 AM > Subject: Re: VNC and SSH > > > I know how to do this with the Windows server but I have not found a > switch on > > the Linux server to cover that. Can you expand on how to do this? > > > > As Jay Freeman suggested to me privately, my problem is not restricted to > > VNC port forwarding. No other ports seem to work either. I agree with > him on > > this one and will pursue the issue on an SSH list. > > > > For the list: > > > > 1. I suspect it may be a conflict with my older Linux Mandrake > > configuration although I do not think so. Such conflicts would have been > > reported long ago. > > > > 2. Another possibility is that my firewall (ipchains on the > > Linux server) stops the forwarding. Does anyone have any > > ideas on which ipchain rule must be enabled (on not > > disabled) to ensure the ssh port forwarding works? I have checked the > obvious > > 58xx and 59xx series but all this work directly anyway. Anyone know if > ssh > > uses some other ports for redirection? If you get logged in via SSH using the -L blah:blah:blah argument, then the forwarding connection has been set up. Since SSH multiplexes the forwarded connections over the port-22 channel, it is not necessary for either firewall to know anything about the ports being forwarded. If you can log in to the remote host and get an SSH prompt, then forwarding should work fine. -- Joe > > > > 3. The suggestion from Michael to check for > > loopback is also possible. Once I figure out how to allow loopback on the > > linux server, I will report to the list with the results. > > > > Serge. > > -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and SSH - loopback connection
"Erdely, Michael" wrote: > > Well... I have to be honest with you, I haven't worked with the Linux > version of VNC Server for a while. And not with SSH. Maybe it is enabled > by default. Then, I'm not sure why it isn't working. > > -ME > Indeed, Xvnc allows loopback connections by default. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: WIN SERVER AND X CLIENT
[EMAIL PROTECTED] wrote: > > On Thu, Dec 21, 2000 at 08:00:58PM -0200, Vidal Augusto Zapparoli Castro Melo wrote: > > It's possible to run vncviewer from X to WinServer? > > NO you need a vncviewer (or java enabled browser) to interpret the protocol, >although it > is like X it is NOT X. > I think Vidal is asking whether you can use the X vncviewer to control a Windows desktop, which of course works fine. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Noise on the vnc-list : suggestion
Jean-Marie Theis wrote: > > Maybe I have a small simple suggestion concerning the way we handle > technical questions : > Once a question is launched , the rule could be to respond privately > to the person who has a problem until he has solved it. This is a good idea, but it is very inconvenient due to the (IMO) evil Reply-To header inserted into all vnc-list messages, that forces all replies to go to the list. If you have something to say that is not of general interest or relevance, it is a huge pain to send it only to the author of the message. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: how to hide the VNC logo ?
"David W. Chapman Jr." wrote: > > Aren't we forgetting that what people do at work is property of the > business, from email to whatever they do at their desktop during business > hours. Granted nobody likes to be spied on, its a decision that should be > made by management/hr departments whether the employees know about it or > not. I would not work for a company that deemed that sort of thing acceptable, and I would quit if I found my work was being surreptitiously spied upon. I suspect most people feel the same (though some might not have the luxury of being able to quit in protest). I can certainly see why the AT&T developers would not want to be seen as supporting this kind of activity. (Hmm, it seems software -is- political. Damn.) -- Joe > > You are right about one thing. People are curious about the icon. So save > > yourselves a lot of trouble and just explain to them what it is. In all of > > the different organizations I have worked in, I have yet to meet anyone > > who likes to be spied upon. Sure you can take away the icon, but I > wouldn't > > want to be ya the day that someone discovers you are spying on them. > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: how to hide the VNC logo ?
"David W. Chapman Jr." wrote: > > Then do you feel that system administrators are not allowed to check users > email Of course they are "allowed" to, but I certainly wouldn't work for a company that made it a policy to do so. I don't care what a company or individual does with VNC; I am simply expressing the opinion that it's evil to use it without the remote user's knowledge, and I can fully understand why the AT&T developers would not want to add functionality that makes it easy to use their software for nefarious purposes. Anyone who wants to disable the tray icon is free to do so by patching the code. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and SSH - Solution found
Tim Waugh wrote: > > On Wed, Jan 03, 2001 at 10:56:58AM -0500, Serge Dutremble wrote: > > > I must have a problem on one end with the SSH version 2. The server end > > (remoteIP) was installed separately on Mandrake 6.2 while the workstation end > > (localIP) came pre-installed with RedHat 7.0. I must have missed a step > > somewhere in installing SSH on Mandrake 6.2. > > I don't think OpenSSH (which is what ships with Red Hat Linux 7) > supports port forwarding in protocol 2 yet. Works fine for me. OpenSSH 2.1.1. -- Joe > Tim. > */ > > [demime 0.97b removed an attachment of type application/pgp-signature] > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC and Firewalls, a story.
"William L. (Bill) Barth" wrote: > Assuming I understand your suggestion, the problem with trying to do > it that way is that I'm not allowed to connect directly to or open > ports on the firewall itself. All connections to the ssh port (22) on > the work firewall are forwarded (transparently to me) to a _random_ > machine on the inside. So there are two ways I see that I can do this > > 1. Forward a local port on my home machine to the remote machine on >which the Xvnc server is running. But I don't see how since I need >to specify the machine on the _inside_ of a firewall which is (de >facto) not addressable directly. Doesn't matter. The forward host is contacted by the server, not the client, so its reachability from the client is irrelevant. So in your case where an ssh connection to "work" gets randomly forwarded to "workN" for some N, you can VNC to "work3" by: ssh -L 5910:work3:5900 work and then connect your vncviewer to localhost:0. If you get connected, say, to "work5", "work5" will happily forward the connection to "work3". -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC Newbie
Scott Thomas wrote: > > Hello, > > I've been using VNC for about six months now. We recently got a new > voicemail system that is run off of NT Workstation 4.0. It is the server for > the PHONE system, but only a workstation within our network. I want to set > up VNC on this workstation so I can do all of the phone/voicemail > changes/administration from my workstation, or from any remote location. > Since it is not a valid server within the network, is there a way to where I > can still access it by using it's IP address or do I have to promote that > workstation to a server? VNC doesn't care about Windows networking stuff at all. Just install VNC, run "WinVNC -install" to install it as a service, and away you go. (Assuming of course the machines on your network actually have the TCP/IP stack installed. It used to be possible to configure Win machines with only NETBEUI, I think, but I belive those days are long gone.) -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Rejected Connections via Web Interface
pair wrote: > > Hello, [Connection refused due to rfb port blockage. Snip.] > Any ideas out there? Yes... Open ports 5900 and 5901 as well. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC Newsgroup
$0.02: There was a lot of heated discussion a few weeks ago about the signal/noise on the VNC list. I expect a newsgroup will cause the denominator to increase far more than the numerator, since most of the "signal" is already subscribed to the list. If a newsgroup is going to be created (a topic on which I remain agnostic), it might be a good idea to create two: comp.blah.vnc and comp.blah.vnc.help, with the .vnc version possibly being moderated, and mirror only the moderated group to the list. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: getting through a fire wall
Gordon Steven-QSG001 wrote: > > We have an NT machine running vnc server (3.3.3r7) outside our corporate > firewall. When we try and connect to it, using a browser (Internet > Explorer) from inside the firewall, we get the authentication screen. When > we enter the password, we then get cut off by our firewall, like the VNC > service is switching to a new port (other than the default 5800). Is this > so, and is there any way around this? I assume you are connecting via browser. Port 5800+display is used only to serve the Java viewer applet. The VNC RFB protocol uses port 5900+display. Isn't this covered in the FAQ? -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Help with VNC
Nissim Lugasy wrote: > > Hi, > > My problem is as follow: after a couple of successful login to a specific > VNC server, a subsequent login to this VNC server does not bring up the VNC > window any longer but I do see a temporarily outline of the VNC window > when connecting. Here is the log I get at the vnc server log file: > > 23/01/01 14:36:56 Got connection from client 139.88.100.23 > 23/01/01 14:36:56 Protocol version 3.3 > 23/01/01 14:37:00 Pixel format for client 139.88.100.23: > 23/01/01 14:37:00 0 bpp, depth 24, little endian > 23/01/01 14:37:00 true colour: max r 255 g 255 b 255, shift r 0 g 8 b 16 > 23/01/01 14:37:00 rfbSetTranslateFunction: server bits per pixel not 8, 16 > or 32 > 23/01/01 14:37:00 Client 139.88.100.23 gone > 23/01/01 14:37:00 Statistics: > 23/01/01 14:37:00 framebuffer updates 0, rectangles 0, bytes 0 This seems to be the ever-popular "0bpp" problem. This is supposed to be fixed post-3.3.3R2, though; strange that you're seeing it. There's a patch somewhere in the list archives that may fix it for you. http://www.uk.research.att.com/vnc/archives/2000-03/0144.html -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Stream encryption - is it time?
"Bryan A. Pendleton" wrote: > What is it that most users of VNC use VNC for? Remote access to their > desktop? Remote administration? In any and all of the above cases, a > typical usage scenario includes accessing VNC over a path which includes a > non-secured network, where a hacker or other nefarious person might gain > information they shouldn't, just by passively listening on the line. Agreed. Having VNC be secure out-of-the-box would be really nice. Obviously not indispensible, but nice. > I want to stir up a discussion, but I think the specifics of development > might be better taken elsewhere. Any developers out there want to help me? I would be interested in working on this. There has been some discussion of a protocol plug-in architecture for VNC; if that's immanent, perhaps it will provide part of the solution. Anyhow, I imagine a good strategy would be to steal from the best and hijack some OpenSSH/SSLeay code, rather than writing some new thing that may or may not "really" be secure. I think that at least initially, wrapping the existing protocol is the way to go, rather than inventing a new encoding. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Stream encryption - is it time?
Glenn Mabbutt wrote: > > As I posted some months ago, I've had great success using Zebedee as a > secure tunnel (http://www.winton.org.uk/zebedee). I initially tried using > SSH from cygwin, but I never did get it to work - it consistently hung on my > Win95 box, no matter what version of SSH or what version of the Cygwin DLL. > So, my point is, using a form of encryption (ideally) should be as easy as > possible - don't get me wrong, I love to fiddle with settings and whatnot, > but I don't have unlimited time, either. I would be in favour of an > automated solution incorporated into VNC. This is why I say it would be "nice" to have VNC be secure "out of the box." When you know what you're doing, SSH tunnels are simple to use, but if the only thing you need is VNC, especially on Win32, you probably don't want to fool with SSH or other tunneling technology. If the security was integrated (even if it means the VNC installer automatically installs and configures SSH and SSHD, which personally I think would be a lot more trouble than just integrating the SSH authentication and encryption functionality into the VNC binary), then it would reduce the level of frustration with VNC security issues, and the related traffic on this list, by a significant degree, IMO. VNC would also, I expect, end up more secure than the commercial remote control software that's *advertised* as "secure". BTW, I think there's already an Xvnc (maybe Const's?) that can automatically set up SSH tunnels. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Stream encryption - is it time?
Jonathan Morton wrote: > > >> You can't do this. That's kind of the point about SSH tunnels. If > >> you could set them up automatically, they would be completely > >> ineffective at authentication. > > > > > > > >I might have misunderstood, I don't use SSH very much, but from an > >encryption-only standpoint (Using VNC's own authentication, which would go > >through the SSH tunnel too, so we don't have to worry about the security > >problems recently posted), SSH should be simple and easy to implement, > >right? > > > >I understand that a lot more may be involved if authentication is the name > >of the game, but at least for my uses, I only really want/need encryption. > > The security advisory posted the other day was about authentication > vulnerabilities. Hmm. I'd like to see if/how SSH gets around the type of > attack posted in that advisory... SSH does its level best never to transmit any data in the clear. Even the initial authentication exchange is encrypted. The attack against VNC hinges on the fact that the server transmits the challenge string in the clear, which gives the man in the middle some data he can change without upsetting the client or server. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: PocketPC development
Is this just the 30-day trial version, or the real package? Are there any catches like upgrade requirements? Also, can it generate binaries for any WinCE platform (specifically, I'm interested in SH (Hitachi SuperH))? Thanks, -- Joe Mac Reiter wrote: > > By the way, if anyone wants to develop for PocketPC (CE 3.0) or CE 2.12 > devices, but thought the tools were too expensive, check out: > > http://www.microsoft.com/windows/embedded/ce/tools/emvt30order.asp > > The tools are free, but they charge $7.50 for shipping. You get CE > versions of Visual C and Visual Basic. Works pretty well, and a lot better > than the old SDKs and toolkits that hacked themselves into your normal > Visual C install. > > Just thought I'd mention it, since I'm trying to do some porting and > optimization work onto PocketPCs, and wouldn't mind some help from people > who were more familiar with the VNC code... > > Mac > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Stream encryption - is it time?
Jonathan Morton wrote: > > >> >> You can't do this. That's kind of the point about SSH tunnels. If > >> >> you could set them up automatically, they would be completely > >> >> ineffective at authentication. > >> > > >> > > >> > > >> >I might have misunderstood, I don't use SSH very much, but from an > >> >encryption-only standpoint (Using VNC's own authentication, which would go > >> >through the SSH tunnel too, so we don't have to worry about the security > >> >problems recently posted), SSH should be simple and easy to implement, > >> >right? > >> > > >> >I understand that a lot more may be involved if authentication is the name > >> >of the game, but at least for my uses, I only really want/need encryption. > >> > >> The security advisory posted the other day was about authentication > >> vulnerabilities. Hmm. I'd like to see if/how SSH gets around the type of > >> attack posted in that advisory... > > > >SSH does its level best never to transmit any data in the clear. > >Even the initial authentication exchange is encrypted. The attack > >against VNC hinges on the fact that the server transmits the > >challenge string in the clear, which gives the man in the middle > >some data he can change without upsetting the client or server. > > I think I've got the picture. VNC needs two separate things if it is to > resolve security issues without (efectively) including SSH within itself: > > - Encryption, using either SSLeay, a subset thereof, or some discrete > trustable algorithm. > > - Authentication, from BOTH ends. The client needs to know it's > connecting to the right server, and the server needs to know > the client is legit. > > SSH throws up a big banner if the server's authentication key isn't kosher, > before any traditional user-authentication stuff flows over the wire. The > problem I can see is whether the same techniques could be used against any > connection, regardless of the protocol used. Consider the following > scenario: > > - C connects to S, using some future RFB with stronger authentication and > encryption. > - M intercepts C's connection, and immediately makes it's own connection > (sp00fed with C's real IP address) to S. > - S sends M the encryption key, which M makes a note of and forwards to C. This step doesn't happen. The SSH client authenticates the server by knowing the server's public key; only the server can decrypt the client's initial handshake. The client and server can exchange a session key using the server's public key without ever opening themselves to an MITM attack. (That's assuming the server key is symmetric; I don't remember for sure. If not there are secure key exchange protocols that can be used.) The server authenticates the client any number of ways, but ALL of those ways are handled using the session key negotiated in the initial exchange. So even if the client is authenticated using the plain Unix password, that password never ever travels in the clear. *For convenience only*, the very first time you connect to a particular server, the client offers to fetch the server host key for you; it caches it in a file in your .ssh directory for use in future connections. That initial connection is the *only* time any authentication data travels in the clear. Of course, if you are well-paranoid, you install the host keys on the clients by hand instead. Since changing even a single bit in any encrypted message will make the attacker's presence immediately known, the SSH authentication mechanism is not vulnerable to the attack you've outlined. -- Joe > - C sends M it's own encryption key, which M can read because it knows S's > key too. M makes another note and forwards the still-encrypted key to S. > Now M can read both halves of the conversation. > - M watches any further authentication tokens pass by. As many tokens as > are specified can be passed in this way, with server authenticating client > and vice versa. > > After the last authentication step has been passed, M can either break the > connection to C and use the existing, authenticated channel to talk to S, > or it can simply mediate the connection to conclusion and leave the > authentication tokens in a safe place for later cracking. > > If someone can give me a SINGLE example of a protocol which is NOT > susceptible to the above attack (which can be practised by any host capable > of both listening to and modifying the packet stream, eg. a rogue or > compromised router or firewall), I'd be very interested to hear how it > works. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Stream encryption - is it time?
Jonathan Morton wrote: > combination that happens to be running a browser? Does his network admin > require him to carry a floppy disk containing the server's encryption key, > or does he risk having the key sniffed by one of these MITM attacks (and > this one doesn't require modification of the stream!). > > The answer may be to have the server send the key in an encrypted form > which can only be decrypted using the VNC server password, or a separate > "key password". And then only to have that done on a "once only" basis - Now that I think about it, I don't think it's necessarily a problem for the host key to be passed in the clear. The only problem that arises is that if the first time you connect to a host its address has been hijacked by an attacker, your client will believe the attacker's host is the real one. With SSH, for example, anyone can get the host key just by attempting to open a connection, so having the host key compromised can't be that much of a problem (of course, I'm assuming the authors of SSH know what they're doing :) (This implies that the host public/private key pair is not symmetric - some other protocol must be used to negotiate the session key.) > Both of the above methods need further discussion, partly due to my > complete lack of credentials as a security expert =) Me too - I don't want to give the impression I know too much about this. I have read Bruce Schneier's book and poked about in the OpenSSH code, but that's about it. Someone with real security credentials should definitely be involved, at least in an advisory role. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Why *local* port forwarding?
"Todd A. Jacobs" wrote: > > In order to get VNC to work over SSH, I need to forward the local > connection to the remote host instead of the other way around. This seems > a little counter-intuitive to me, and I was hoping someone could explain > why it works this way. > > Since the VNC server is running on port 5901 on machine foo, why am I not > forwarding 5901 on foo to 5901 on localhost? Doing so doesn't work (I keep > making that mistake) but sending localhost:5901 to foo:5901 does the job > properly. > > Please enlighten me. > > -- > Todd A. Jacobs > Senior Network Consultant It's just like postal forwarding: "Forwarding X to Y" means "When a connection is made to X, actually connect to Y instead." The forwarder listens at address X, and delivers any data it finds there to address Y; similarly it delivers replies at Y to X. The data path is bi-directional once it is established, but the critical thing is that the forwarder is *listening for connections* at X. When you forward foo:5901 to localhost:5901, the forwarder attempts to listen for connections at foo:5901 and hook them up to some process listening at localhost:5901. This attempt is doomed, since the VNC server is already listening at foo:5901, and there's (probably) nothing running on localhost:5901. HTHTIWUIIJCTF* -- Joe Knapka * Hope This Helps, Though I Would Understand If It Just Confuses Things Further - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: problems with vnc for linux
Make sure /usr/local/bin/vncserver is executable. Also, make sure /tmp is readable and writeable by everyone. Finally, please post the exact output of "vncserver :" (eg "vncserver :1") so we can see what's really happening. -- Joe oan wrote: > > could someone pls help me with this? > > i copied the vnc-directory into the "/usr/local/bin"-directory and then > tried to start the server with vncserver. -->permission denied.Now i know > i'm doing something wring, but what is it? > > 1. do i have to start vncserver in a x11-window? > 2. (i tried both answers to 1., so) what could i possibly be doing wrong? > > thnx > predator12345 > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: owncmap and compresslevel/quality options
"Todd A. Jacobs" wrote: > > I read the X viewer docs, but couldn't find an explaination for the > -compresslevel and -quality options. In addition, I didn't understand the > implications of using owncmap; does using it reduce network traffic, or > does it have some other purpose altogether? As I understand it: -owncmap makes the viewer install its own colormap, rather than using the X server's global one. That means that the viewer will be able to allocate all the colors it needs (rather than depending on them being available in the global colormap), but there may be some strange visual effects on the rest of the screen when focusing and defocusing the vncviewer window, since the X server will switch to the vncviewer's private colormap - which most likely has no sensible colors for the other applications - when the vncviewer window is brought into focus. If you're running a TrueColor visual on the X server, this option shouldn't be necessary; only palletized visual modes use colormaps. (Note that this discussion has nothing to do with the visual in use by the VNC server; only the X server on which vncviewer is running.) I would be surprised if -owncmap has any effect on network traffic. Don't know about -compresslevel and -quality. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: 5800/5900 question
"Needham, Michael" wrote: > > I shall stand corrected... but does that then mean that the "webserver" > which is listening to VNC also on port 58xx? This would make sense if the Exactly. The web server, which does nothing but server up the Java applet, runs on port 5800. Once the applet is delivered, it reconnects to port 5900 to contact the VNC server and never ever uses 5800 again. > Java Applet loads on 58xx and then it talks on 59xx once the connection is > established to the server... -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: mapping a remote drive
Lyle wrote: > > That means opening up netbios to the world(port 138). NOT a smart idea. > You can tunnel it over SSH though. (Probably need port 139 for disk shares; I think 138 is the NetBIOS name service.) -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: About VNC Server ActiveX Control
Jonathan Morton wrote: > > >Have someone converted VNC Server to a ActiveX Control(*.ocx)?//I know > >Thong Nguyen has convert VNC Client to a ActiveX Control(VNCX.ocx). > > What practical applications are there for such a thing? Being able to automate the server could be useful. It might especially be nice to be able to securely (whatever that means in M$ land) start up the server via DCOM from a remote client. Of course that could easily be done with an external app, rather than by performing surgery on the VNC server. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: mapping a remote drive
David Rothman wrote: > > is SSH with win 2000 really a practical solution for the > 'simple' task of file xferring when ftp is an available > option, or am i missing something? > SSH is practical. It's justified if you want security; transferring files via FTP is completely insecure. I thought the desire was to share a SMB network drive across the internet when there are firewalls in the way, in which case you will absolutely need some form of port-forwarding or VPN. The secure port-forwarding solution is SSH. Forgive me if I misunderstood the original question. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: mapping a remote drive
David Rothman wrote: > > - Original Message - > From: "Joseph A. Knapka" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, February 18, 2001 2:49 PM > Subject: Re: mapping a remote drive > > > David Rothman wrote: > > > > > > is SSH with win 2000 really a practical solution for the > > > 'simple' task of file xferring when ftp is an available > > > option, or am i missing something? > > > > > > > SSH is practical. It's justified if you want security; > > transferring files via FTP is completely insecure. > > insecure how? easy to break into the system the server sits > on (regardless of whatever security the server software has > enabled)? easy to intercept files while they r being > xferred? can u be more specific? During an FTP session, the password and all data is transferred in the clear, meaning that anyone with a network sniffer can get your password or your data easily. Also, there are a number of root exploits against various FTP servers (I don't know the details, just that they exist). > > > > I thought the desire was to share a SMB network drive > > across the internet when there are firewalls in the way, > > in which case you will absolutely need some form of > > port-forwarding or VPN. The secure port-forwarding > > solution is SSH. Forgive me if I misunderstood the > > original question. > > in my situation (using win 2000 pro behind netgear rt311 > routers), it's enuf to forward ports (which is what i do for > VNC). im not quite sure how to setup SSH under windows. > actually im still confused about the differences between > VPN, IIS and SSH - but im working on it... Remember that VNC is also completely insecure. It would be fairly simple to build an application that would allow you to view anyone's VNC desktop while they are connected to it, provided your physical network segment was part of the route between VNC client and VNC server (though I don't know of anyone actually doing this). If you are accessing your desktop from the Internet, it is a very good idea to use some form of encryption. http://www.jfitz.com/tips/ssh_for_windows.html has information about free SSH clients and servers for Windows systems. VPN == Virtual Private Network. Essentially, VPN software allows you to establish a secure connection between two secure networks using the *insecure* Internet as the transport. For example, I have a private network sitting behind a firewall at home, and my employer has a private network at its development facility two timezones away. My firewall and my employer's firewall establish an encrypted link that acts as a virtual LAN, allowing data to move from my private net to my employer's and vice versa (exactly as if they were physically connected) without being vulnerable to sniffers on the public networks across which the data must pass. IIS is just a web server, like Apache. Built and marketed by our noble pals at Micro$oft. SSH is essentially just a secure version of Telnet or any other remote terminal program: it lets you log in to a remote machine and interact with a command shell. Unlike Telnet, SSH encrypts all the data it sends. It has the additional ability to securely transfer selected network traffic between the client and server machines. It is possible to build a VPN using SSH tunnels as the transport mechanism, though it is more common to use purpose-built VPN software and protocols like PPTP (point-to-point tunnelling protocol) or IPv6's security extensions. HTH, -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: mapping a remote drive
David Rothman wrote: > > first, thanks very much for the detailed response. You're welcome. > > During an FTP session, the password and all data is > transferred > > in the clear, meaning that anyone with a network sniffer > can > > get your password or your data easily. Also, there are a > > number of root exploits against various FTP servers (I > don't > > know the details, just that they exist). > > i've seen this mentioned before, but if u look around at the > various FTP programs, each boasts of its enhanced security. > isn't it possible some of the ftp's around have some > reasonable degree of security? The FTP protocol itself does not involve any kind of security other than a simple password authentication. If an FTP suite is marketed as having "enhanced security" then it probably means merely that it's had a security audit done on the code to close off possible intrusion exploits (I'm getting out of my depth here on security issues, though; be warned). > is my following summary reasonable: > > (1) if on an occasional basis u need to xfer a sensitive > document and if ftp is in fact insecure in all it's flavors, > u merely use some form of encryption (pgp or otherwise) and > send it using ftp (because of its simplicity). alternatively > one could go the SSH route, but it's a step up in > complexity. I would never transfer a "sensitive" document (eg, one that if it were intercepted could involve loss of my job, or loss of income to my employer) via plain FTP. Encryption with PGP or similar is a reasonable alternative, but remember that as soon as you tell the FTP server your password you may be opening up all the files accessible using that password to anyone who happens to be looking. FTP is fine if you don't care who can see the stuff you're copying around. The SSH suite has an FTP-like program called scp, which can be used to move files securely between hosts that support SSH. It's easier to use than FTP, IMO: C:> scp .\top_secret.txt mojo-jojo.com:/my_secret_files/top-secret.txt would copy local file "topsecret.txt" to the /my_secret_files directory on machine mojo-jojo.com. > (2) in situations where a regular connection is needed, one > would consider building a VPN. Right. > and if ok, is the win 2000 VPN stuff a reasonable place to > start playing? how hard is it to work with? I don't know anything about the w2k VPN software, sorry. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: LAN settings
Can you ping the server machine from the client? Eg C:> ping 192.168.1.101 Reply from 192.168.81.1 ICMP sequence # 1 10ms Reply from 192.168.81.1 ICMP sequence # 2 10ms ... Patrick Lim wrote: > > Hai, > > can anyone help me with this simple thing. i try for few hours now and i > am still unable to do it. > > I have two windows98 PC, both using microsoft networking. TCP/IP both > have a specified IP address. I am trying VNC to connect to the other pc, > but I never can get conection, both with de Browser > (http://192.186.1.101:5800) nor with the vnc viewer? > > What have i done wrong? Do i need to fill in a gateway, DNS, or WINS? > > PLEASE help out > > Thanks > > Patrick Lim > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: LAN settings
Patrick Lim wrote: > > Joseph, > > Thanks for the fast responce!! > > Yes i can ping the server machine and the client machine. I found out what i > have done wrong allready! i forgot to activated (Tick) the auto of incoming > connections. > Thanks for your fast reply anyway.. I am now trying to connect the other way, > but the problem now is that this client computer have a modem... so i am > wondering will it get any problems because there are now 2 ip-adresses? Should be OK, but remember that by default VNC listens for connections on all available IP addresses; you should be careful about making a VNC server available to the Internet. Look at the documentation on the VNC website for information about how to restrict connections to particular machines. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: vncpasswd & scripting
Lee Allen wrote: > > I am (still) setting up a Linux system to host a bunch of VNC sessions. > This will probably be implemented on many systems, so I very much want to > get it right: to make it smooth, robust, and maintainable. > > Today's challenge is vncpasswd. > > We have a C program that maintains users. It calls useradd, passwd, > smbpasswd, creates login scripts -- everything necessary to create a fully > functional user profile on Linux and in our application database. > > I need to incorporate vncpasswd into this program. But, unlike passwd and > smbpasswd, vncpasswd does not seem to accept input from stdin. I looked at > the source code (Notice: I am *NOT* the world's smartest C programmer) and > it seems to call getpass(). I looked at the man page for getpass() and it > seems able to accept input from stdin. But many different variations of > this (at the command line) utterly fail to work: > > echo -e "newpass\nnewpass" | vncpasswd > > It still prompts for the password, twice. > > Any suggestions? > For what it's worth, Expect ( http://expect.nist.gov ) interacts with vncpasswd quite nicely; the following expect script changes my password to "hithere" on my Linux machine: spawn vncpasswd expect Password: send hithere\r expect Verify: send hithere\r exit So maybe you could have a look at the Expect code and see how it's interacting with spawned apps. Note that I didn't have to do anything special to make this work, so whatever Expect is doing is probably the Right Way to handle this sort of thing. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC Ports
Brett Goldstein wrote: > > I understand that VNC uses two ports. However, as I am looking to do > multiple port mappings, I was hoping to limit it to one port. Does anyone > have any thoughts on how I can run WinVNC so that it would only have to > listen on a single port? > > Your help is greatly appreciated. > > -Brett If you absolutely must use the Java viewer and only one port per server (I can't offhand imagine a scenario that would require this, but whatever), there are patches at the following URL to allow Xvnc and WinVNC to deliver the Java viewer via the RFB port, which means you can just aim your browser at http://vncserver/5900+display# http://home.earthlink.net/jknapka/vncpatch.html (Ignore the part about "tunnelling RFB over HTTP"; those patches have never been tested, and there's no viewer that will work with them AFAIK.) -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC Ports
Oops. Sorry: http://home.earthlink.net/~jknapka/vncpatch.html -- Joe > "Michael F. March" wrote: > > > http://home.earthlink.net/jknapka/vncpatch.html > > 404 Error.. > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: VNC behind Proxy (port 80/21 open)
Is it a firewall or a proxy server? Those are two different problems, one of which is solved more-or-less completely and one of which is solved in a sort of half-fast way. If the machine between you and your VNC server is a packet-filter firewall that only allows connections to particular ports, but does not otherwise interfere with the data stream, then you're probably OK. If there's a way to control the RFB port setting separately from the HTTP port in the Java applet, you could do exactly as you suggest in your message (set the server to listen on port 80 for HTTP and port 21 for RFB or whatever). I don't know of a way to do that in the Java viewer, but I expect it would be easy to add such a feature. And of course if you use the native VNC viewer for your platform you only need to be able to connect to the RFB port, so you just need to make your VNC server listen for RFB connections on a port that gets through the firewall. Finally, if you *must* use the Java viewer for some reason, the patches available at http://home.earthlink.net/~jknapka/vncpatch.html might help you; they allow you to create a server that delivers the Java applet over the RFB port, so you need only one port to be accessible. In any case, the trick is figuring out what display number to tell your viewer to connect to. Typically it will be a very large value, something like 2^32-(5900-). If the machine between you and your VNC server is a proxy server, then you're in trouble. Proxy servers expect clients to interact with them using some proxy-specific protocol, so the client would need to know about that protocol. I believe there are patches available on http://www.uk.research.att.com/vnc to make some subset of the VNC viewers connect through a SOCKS proxy. But there's no general solution at present. Alternatively, you can use one of the existing HTTP tunneling services to create a TCP/IP connection encapsulated within an HTTP data stream. For example, httptunnel does this: http://www.nocrew.org/software/httptunnel.html However, this solution will be rather slow, and you will be dependent on an external tunnelling server to maintain your connection. HTH, -- Joe Nathan Shaw wrote: > > Was there ever a conclusion to whether or not you could connect to a VNC > server through a Proxy server if they only allow communication through Port 21 > and 80 (for example) ? > > I was thinking you could set the Java Viewer to listen on port 21, and then > the RFB to run on port 80. This way you could get through to your server even > though there may be a firewall/proxy setup. > > The only thing is.. how in the world do you change the port that the Java > Viewer listens/downloads on? I know the RFB port is display + 5900 but > where/how can I specify the port for the Java Viewer? > > Has anyone successfully done this? Any help is greatly appreciated! > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: how can i install vnc server as remote and giving thepassword and settings?
Michael Schwarz wrote: > > There are legitimate uses for this. I log on to a remote server and work on > payroll files for a remote plant. When I do this, I have no idea who may be > sitting in front of the computer. I do not want sensitive payroll > information to be shown on the screen. I currently use laplink and use the > screen blanking feature. I also need to be able to print from the remote > program to a local printer which I haven't figured out how to do with VNC. > > By the way, all machines involved are either Windows NT or Windows 2000. > > Michael > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Mac Reiter > Sent: Wednesday, February 28, 2001 3:53 PM > To: [EMAIL PROTECTED] > Subject: Re: how can i install vnc server as remote and giving the > password and settings? > > [EMAIL PROTECTED] wrote: > > >How can i disable or hide the remote screen for my users?. I need the > remote > >users can't see what i doing with their computers. > > and > > >how can i install vnc server as remote and giving the password and > settings? > >thanks. > > Maybe I'm paranoid, but a remote installation specifying password, > settings, and hiding the screen from the users -- Hmmm... That particular > combination of desires disturbs me. Could you describe your intended use? Actually, I think the ethical implications of this are much less worrisome than those of hiding the task-bar icon. I mean, if the screen goes blank, the user sitting at the PC is not going to be under any illusions that they are working unobserved. They might think their machine has crashed and turn it off, though :-) -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Single Port File transfer
SSH (scp) is probably the best solution. However, you can use FTP in PASSIVE mode, in which case it only will use one port. I'm not sure if all clients support passive mode, though (all servers should). -- Joe Jordan Share wrote: > > One thing that has come up for me, in my use of VNC to remotely control my > home and work PCs (running Win2kPro) is a need to transfer files between > them. > > I have not yet found a program that will use one port (which can be easily > forwarded from/permitted through a firewall) to transfer files. > > I am aware of FTP and Windows Sharing, but these both use more than one > port, and there is no easy solution if the machines involved are behind a > NAT (one-to many) box, which is my setup at home (we have one IP address > that we are sharing via IPmasquerading on linux). > > I just need a daemon that will run on Win2k, that allows an incoming > connection on one port, and then uses the same connection to transfer the > files. Does such a program exist? > > Alternately, if I could get sshd to run on Win2k (which I've tried, but > failed to do), then I could just use scp, no? > > Thanks, > Jordan > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Single Port File transfer
Jordan Share wrote: > > Well, how do use HTTP to copy files to the machine I am controlling? I have > had people tell me that this is possible, but I guess I've never really > investigated. If it involves writing ASP (or whatever) and submitting files > via the browser, this is not so much what I am looking for. > > As far as using FTP in passive mode, can you tell me how to get this to work > when both machines are behind a "one-to-many" NAT? I was pretty sure the > FTP protocol required 2 connections, one for control and one for data. Is > this not right? That is true for active mode connections only. The purpose of passive mode is to allow the control connection to also be used for data transfer. As for the one-to-many NAT problem, that is tricky, but obviously you have done something to allow VNC connections in this situation (how do you handle that, by the way?), so do the same thing for the ftp port that you do for the VNC one and you should be on your way. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: RAS and multiple remote nodes
Ian Robinson wrote: > > Hi, > > Is it possible to use VNC in the following scenario. > > I have a remote site with an NT server and five PC's. All of the > remote machines are on a local IP address scheme of 192.168.10.x. > There is no permanent WAN connection to the outside world. Would it > be possible to setup RAS on the NT server , dial in from my site, and > then use VNC to control the server and other PC's on the remote site? Sure. You just have to make sure the workstations have appropriate IP routes set up so they know how to get packets through the RAS server to your dial-up client. Setting the RAS server to be the default gateway for all the other machines would be one way to accomplish that; or else you could manually add the necessary route using the "route" command. Another possibility is to open a VNC viewer to view the RAS server desktop, and then open a VNC viewer on the RAS server to view the other machines. That will be very painfully slow over a dialup connection, but it would work in a pinch. -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Single Port File transfer
Jordan Share wrote: > > Ahh, I think there is a misconception on what passive FTP actually does. > Here is a link to (some class's notes) on ftp. Check out section 2.1 > (Passive Versus Active Mode FTP) > http://bigworm.colorado.edu/Saclass/class14.html > [Beating self about head & shoulders with inflated pig's bladder] Guilty as charged :-/ Guess it's time to read the RFCs again... -- Joe Knapka - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: using a browser with a changed port number
Jonathan Morton wrote: > > >So the connection is made on the "portnumber-100" and after the applet is > >started the connection continues on "portnumber"? > >If 3000 is an open port in the firewall and 3100 is not then I still can't > >get through? Or am I interpreting something completely false here > > Yes, the applet is loaded though the lower (HTTP) port and the VNC > connection itself always happens on the higher (VNC) port. VNC *never* > sends remote-control data through HTTP, at least in the main > implementations. I did see someone combining the two at one point, but I > think that was for Xvnc, not WinVNC. There are HTTP-via-RFB patches for both Xvnc and WinVNC at http://home.earthlink.net/~jknapka/vncpatch.html . With these patches you only need to have the RFB port open at the firewall to use the Java viewer. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone!" -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: FTP Server
Jonathan Morton wrote: > > >A built-in FTP server would be great, when using internet connection, not > >lan. > > I'm thinking that maybe FTP per se isn't a good idea, mainly because it's a > surprisingly big and complex protocol to implement. Ever noticed that > *good* FTP clients and servers are hard to come by, especially for > "desktop" systems such as Windows and Mac? > > How about a (simpler?) protocol which embeds "packets" of a file > intermingled with regular RFB messages in a single connection, which would > also make life *so* much easier for ppl who have to get through firewalls. > Some means of encoding metadata associated with a file (eg. Macintosh > filetype, UNIX file permissions) would also be highly desirable, so that > files transferred between machines of the same platform remain as intact as > possible. I implemented something like this for WinVNC a while back, but never finished it well or released it because finally the argument that RFB is and should remain a *stateless* protocol seemed compelling. I suppose it would be possible to do file transfer without state (NFS is a stateless protocol, I gather, though I've never looked at it), but it seems like a complicated thing. I did have functioning - though buggy - patches, that worked pretty much exactly as you describe. If I can find the code I'll post a pointer and maybe someone can take it further. Or not; I suspect even if I can find the code I won't be too proud of it :-/ I think it's true though that this functionality would really be useful only over Internet connections, because machines on LANs almost always have some better file transfer method available. And most people who use VNC over the 'net are probably tunnelling over either a VPN or SSH, and in either case a reasonable alternative is already available (scp/sftp or, in the VPN case, plain FTP or SMB). Well, I oversimplify, since in the VPN/SSH case it is usually possible *but often very inconvenient* to move files around. Personally, I would like to see VNC have a file transfer capability, but not at the cost of stability. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: FTP Server
Koronka Akos wrote: > > It's ok to take focus on core devel, but adding a plug-in handling will make > easier to combine several very-very good features, what is now in different > packages. > I think so many people will make plugins if this handling is available. Like > far manager, or winamp plugins. > > So what about plugins? I agree wholeheartedly. If VNC had a plugin architecture that would allow us to extend RFB and the UI without touching the server source, a lot of these threads would be reduced to "go get the [file transfer| encryption|HTTP tunnelling] plugin from http://". This does not seem like an insanely difficult thing to implement. -- Joe > RS. > Koronka Akos -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Question on Vnc
> "wtonetwork.com" wrote: > > Hi Joseph, > > I learn from Vnc news that you have encounter the problem of > the following case. > When I make connection to VNC server via browser applet ( > http://x.x.x.x:5801 ) > Error occured and here is the log file > httpd: get '' 168.70.119.31 > httpd: defaulting to 'index.vnc' > httpProcessInput : open: No such file and Directory > Is the problem related with apache? No, Apache is not involved in this interaction. Your browser is talking to the mini-HTTP server embedded in the VNC server, and it cannot find the files it needs in order to deliver the Java viewer applet to your browser. You will need to install the HTML and JAR files included with the VNC distribution in the proper directory. I don't know offhand where that is (might be /usr/local/vnc/classes), but if you carefully read the VNC installation instructions they should tell you what you need to know. HTH, -- Joe > Have your encounter similar problems and how do you solve it? > I am using Redhat 7.0(kernel 2.2.16) with apache-1.3.12-25 > > Thanks > Bryan Wu -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: FTP Server
Steve Bostedor wrote: > > I just think that installing a separate FTP program on all of the computers > that I administer is a ridiculous idea. Why not let it be part of VNC with > an option to shut it off for those of you that don't want it. I don't see > the reason for all of the venomous resistance to this if you can turn the > feature off. All of the competing products do this, why hold VNC back? I think you're on risky ground when you talk about "competing products." The guys at AT&T put VNC together for their own purposes, and it happens to be a piece of software that many of us find very useful, but I really don't think they're out to take over the remote-admin market with this product. If they were, then it would make sense for the core dev team to spend a lot of sweat to add features *that lots of folks ask for*, but as it is, it only makes sense for them to add features *that they would actually use.* Of course it is very presumptuous of me to speak for the AT&T dev team, so maybe I'm completely off track here. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Plug-ins
Hi everyone, We've discussed VNC plugins here recently, and I seem to recall that at some rather distant point in the past it was rumoured that the AT&T developers were working on a plug-in architecture for VNC. Is that work still in progress? Or is it something that could usefully be attacked by another party and possibly merged into the core distribution later? -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: FTP Server
"Bryan A. Pendleton" wrote: > > The whole discussion of the FTP server leads back to another thought I'd > had for a while, which came up during the discussion of including > encryption directly in the protocol that I started a few months ago (and > which I'll be bringing back up towards the end of the school term, when I > have programming time to throw at it). > > The problem is, there are two ways to see VNC: > 1) Stateless display access > 2) Custom user session > [snip] > That's not the only issue underlying this discussion, but it's a big one. > And, maybe it's time for those of us willing to develop VNC beyond the work > of AT&T to talk about which model to stick with. Clearly, with #2, file > transfer, security, etc., if desired, should be included in the server. > Plugins might be a nice way to go. With #1, though, all of that extra > functionality is fluff, and doesn't belong in anything but a co-packaging > arrangement. You make a good point, but unfortunately I don't think you get to choose which model to support. You have to support both to some degree, because Windows is fundamentally a single-user OS and Unix is fundamentally a multi-user OS. And furthermore, the tools you need to implement your own file transfer/ tunnelling/whatever solution are far more likely to be present on Unix boxen (at least in my experience), which seems to rather invert the sense of your argument. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: file xfer
Jonathan Morton wrote: > > Consider the scenario where a VNC user sets up a fiendishly complicated > tunnel system to get his VNC client to connect to his server, but then he > wants to do some file transfer. If the HTTP server is built into the > server (and there is usually already one present), then the client can't > see it without yet more tunnels being set up. If it's built into the > client, that's one big overhead on the client. And what if the client > itself is not visible to the Internet, eg. behind a simple NAT gateway? > OK, here's a truly bizarre thought. There's already an HTTP server embedded in the VNC server. And there's already a set of patches that allow HTTP content to be delivered via the RFB port in a limited way. Since the very first character of a GET or POST request won't conflict with any other message type byte once the authentication and negotiation phase is complete, it would be fairly easy to extend the HTTP-via-RFB patches to allow the VNC server to service HTTP requests from the client on the RFB port *even during an active connection*. Then maybe the client could open a local port and listen for requests to be tunnelled through the RFB pipe to the server, in which case HTTP-based file-xfer utils could be pointed at the local port, and away we go. Or else the viewer could be extended to do the file transfer itself. I'm not saying this is a *good* idea, just that most of the pieces are already there (on Unix and Win at least, sorry Jonathan). Having RFB and HTTP share the same pipe is icky, but I don't see any reason it can't be done. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re:
[EMAIL PROTECTED] wrote: > > Tim, > True that the data stream is unencrypted, but since we're talking > about RFB data... merely sniffing the data wouldn't tell anyone much of > anything unless they have something to decode it (like vncviewer), eh? Same > holds true of controlling a VNC server, I'd think. Wouldn't any malicious > entity on the traceroute path need a VNC server-like application to gain > control, rather than just "seeing" it, and controlling/viewing with a > command line interface? You could capture the RFB packets with Snort or similar and then play them back using one of the RFB-playback utilities. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: pcanywhere functionality
Mark wrote: > > > If you are talking about the windowing system that Solaris normally > displays, then it should just be a matter of starting the CDE in the VNC > startup scripts (I forget how...). Edit ~/.vnc/xstartup appropriately. > If you are talking about taking what is displayed on a Solaris monitor and > running that through VNC, then you have another issue entirely. The short > answer is that no, you can't do that with VNC. The long answer is that you > could, but it would probably involve hacking both VNC and X (has anyone else > already tried this?). Yes, this question comes up about twice a week. Look in the "contributed" section of http://www.uk.research.att.com/vnc for "x0rfbserver". It does not require either X or VNC to be rebuilt; it's just an app that you run which then delivers an existing X desktop to clients via RFB. -- Joe -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Setting up win32 vncserver completely from command line?
[EMAIL PROTECTED] wrote: > > Thanks very much, > > This is what I thought I knew already... but I still need to try and > configure port and password via command lines or registry entries without > using any GUI as my admin interface is just a web browser at the moment. > > >You'll either have to configure VNC to use port 25 (assuming IIS doesn't > >have a Telnet service there) or you'll have to open another port on the > >firewall. > Used for mail unfortunately... In this situation I think the best answer available at present is to install an SSH server on the firewall, and allow SSH connections from the Internet to the firewall (but not necessarily to machines behind the firewall). Then use SSH tunnels to handle VNC connections. This is fairly easy to set up (instructions are available on the VNC web site http://www.uk.research.att.com/vnc ), though it is a bit of a hassle. Of course, if you don't have access to the firewall, or the administrator perversely refuses to allow SSH connections, you are SOL. But I would argue that, since you *must* open some port, all other things being equal, the SSH port (22) is the best candidate from a security perspective (and I assume you are security conscious, given the existing firewall setup). -- Joe > Cheers, > Andy. > > ~~ > Haveland-Robinson Associates Tel. +36 30 223 2158 > Budapest 1015, Donati u.17 fszt.1, Hungary Web: www.haveland.com > - > To unsubscribe, send a message with the line: unsubscribe vnc-list > to [EMAIL PROTECTED] > See also: http://www.uk.research.att.com/vnc/intouch.html > - -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Win32 - 3.3.3r9 - password exploit?
[EMAIL PROTECTED] wrote: > > I am not sure if this has been noticed, or if VNC does not like special > characters as a password, but within the Win version I had set the password > to "QPH@#as9%" without the "". When I use the viewer to access the server I > can use ANY character as the last character and it will login successfully. > I haven't played around with it much to see if I could change more than 1 > character at a time. For all I know this may be documented somewhere. > I will play with it a little and report what happens. Are special characters > not to be used? Passwords are limited to 8 characters, due to limitations in the code used to encrypt and decrypt passwords. Yours is 9 chars, so the last is ignored. -- Joe -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Can Not Delete VNC files
[EMAIL PROTECTED] wrote: > > Yes, Winvnc is running but my uninstall procedure stops Winvnc service first > before deleting the files and folders. I don't think reboot is necessary. I > noticed if I wait about couple minutes then run the uninstall procedure > again. The file and the folder will get deleted. I need to find out where > the "hook" is so I can speed up the uninstall process. > > Gary Wong > Oregon Department of Transportation > > -Original Message- > From: Mac Reiter [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 04, 2001 3:10 PM > To: [EMAIL PROTECTED] > Subject: Re: Can Not Delete VNC files > > >is a file named VNCHooks.dll in the ORL\vnc folder that seems can not be > >deleted sometime. Any one have any idea why sometime that file is being > >locked. Thanks! > > Is WinVNC running when you try to delete it? After starting WinVNC, you > may need to reboot Windows before trying to uninstall it. VNC has to hook > into various pieces of the operating system, and sometimes those hooks > aren't unhookable... (or at least, not easily unhookable) Disclaimer: I know very little of the details of the WinVNC screen acquisition code. But my understanding is that VNCHooks.dll actually gets injected into running applications in order to allow WinVNC to intercept screen updates; maybe it takes some time for those applications to realize that WinVNC has stopped and unload the DLL? Someone please correct me if I am wrong. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Converting display numbers for different ports
[Possibly this should be in the FAQ. It doesn't come up very often on the list, but two or three people have sent me emails directly. I'll add it to my VNC page as well.] "Keyur M. Parekh" wrote: > > Hi Joseph, > > I was searching the VNC mailing list archives for help with firewall > issues and I came across your post and then I checked our your page. I > was wondering if maybe you could help me out. > > Here is the basic information: > > Server - Direct to Internet > Viewing - always will be via the HTTP interface from WITHIN a firewall > > If I install your path or use your patched exe the only port used will > be 5900 by default, is that right? > > Now the thing is I know that ports 2000 through 2010 are open over TCP. > Can you show me an example of what I can put into the display number box > in the WinVNC's server's Current User Properties dialog to get the > server > to talk to the viewer applet at any of the ports from 2000 to 2001. This > is with your patch applied. > > Thanks so much Joseph. I really appreciate your help. OK, we want to connect to port (say) 2001. Since the port number is 5900+display number, that means we need to connect to display -3899. You can't enter negative numbers, but you *can* enter a number that is large enough to overflow the 16-bit port number when 5900 is added, and thereby result in the correct port number. This works because WinVNC stores the port number as a 32-bit value, and truncates it to 16 bits when it's actually used. If you want to use the WinVNC propertied page to do it, then for port 2001, the correct number is 65536-5900+2001 = 61637, so enter 61637 in the WinVNC properties "Display Number" field. (Note, 65536 is 2 to the 16th power, which, when truncated to a 16-bit value, is 0). The WinVNC viewer seems to take display numbers outside of the expected range (which is? I'm guessing 0-99) to be port numbers, so to connect in this manner you can just use "hostname:2001". Or you can use 61637+5900 = 67537: "hostname:67537". Same result. If you want to use port 80, you need 65536-5900+80 = 59716 in the WinVNC "Display Number" field, and connect to 65536+80 = "hostname:65616". Note that in this case you *must* use the large port number, since "hostname:80" would cause the viewer to connect to port 5980. You can also use REGEDIT.EXE to directly install the desired port number in \\HKEY_CURRENT_USER\Software\ORL\WinVNC3\PortNumber - that is, you can enter decimal 2001 in that location to make WinVNC listen on port 2001; no arithmetic required. I have tested all this, confirmed that it works, and sniffed the network to be sure the correct port is used. Let me know if you have any trouble. Good luck, -- Joe -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
Re: Converting display numbers for different ports
"Joseph A. Knapka" wrote: > > [Possibly this should be in the FAQ. It doesn't come up very > often on the list, but two or three people have sent me > emails directly. I'll add it to my VNC page as well.] I feel a bit silly for not having reviewed the FAQ before posting this. The viewer-side part is already in the FAQ, but the server- side part maybe could be added. -- Joe Knapka "It was just a maddened crocodile hidden in a flower bed. It could have happened to anyone." -- Pratchett // Linux MM Documentation in progress: // http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html * Evolution is an "unproven theory" in the same sense that gravity is. * - To unsubscribe, send a message with the line: unsubscribe vnc-list to [EMAIL PROTECTED] See also: http://www.uk.research.att.com/vnc/intouch.html -
