Yutaka Sato wrote:
> 
> On 03/18/99(18:38) you peiaqbdyi-znqnbuleqalr.ml@ml.delegate.org wrote in <_A367@delegate-en.ML_>
>  |--
>  |--  @ @  dmz2.imec.be PROXY-telnet server DeleGate/5.8.3
>  |-- ( - ) { Hit '?' or enter `help' for help. }
>  |DeleGate/5.8.3 (December 17, 1998)
>  |AIST Research Product No. 1994-ETL-8715-1
>  |Copyright (c) 1994-1998 Yutaka Sato
>  |Copyright (c) 1994-1998 Electrotechnical Laboratry (ETL), AIST, MITI
>  |WWW: http://wall.etl.go.jp/delegate/
>  |-- -- -- This (proxy) service is maintained by 'helpdesk@imec..be'
>  |>> Host name: a xproxy
>  |####[X-Proxy] accept host 'xproxy'
>  |####[started] use DISPLAY '10.1.1.12:14.0'
> 
> I don't understand why you need this "accept" command, since the
> command is necessary only when you need to use X client on a
> host which is not the same with the current Telnet server host.
> In your case, the X client is on the current Telnet server host,
> thus I think no accept command is necessary.

 Ok , I did not understand this issue previously.


> 
>  |>> Host name: x bristol:0
>  |>> Host name: duchesse.esat.kuleuven.ac.be
>  |-- Trying duchesse.esat.kuleuven.ac.be [134.58.63.135:23] ...
>  |-- Connected to duchesse.esat.kuleuven.ac.be.
>  |####[set manually] setenv DISPLAY 10.1.1.12:15.0
> 
> This message means that the X proxy invoked here started accepting
> incomming connection at the port 6015 of the host 10.1.1.12.
> I suppose this 10.x.x.x is the network interface on the private
> network side of your DeleGate's host, which can ben unreachable on
> IP level from the target Telnet server host.

 That is true ; to tell this story in short :

 The machine were delegate is on is behind a checkpoint NT 
 box with fw-1. We use address translation
 Note however that I think that this issue is not
 related to the "native problem" because your X-proxy
 part of delegate telnet works for me for standard UNIX
 workstations for instance and also for PC's with 
 reflectionX.
 It does not work for me on X-terminals...



> 
>  |imec@duchesse>setenv DISPLAY xproxy.imec.be:15.0
>  |imec@duchesse>xterm
>  |XIO:  fatal IO error 232 (Connection reset by peer) on X server "xproxy.imec.be:15.0"
>  |      after 0 requests (0 known processed) with 0 events remaining.
> 
> You tried to connect to xproxy.imec.be:6015 while the X proxy was
> waiting at 10.1.1.12:6015, thus the connection should have never
> been established, but the message seems be showing a connection is
> once established before it's disconnected.  So the situation seems
> very strange.  Is there some network address translation or so?
> 
 See my  earlier reply on previous paragraph...


> >[X11]/mit/lib/X/XlibInt.c
> >>       (void) fprintf (stderr,
> >>        "XIO:  fatal IO error %d (%s) on X server \"%s\"\r\n",
> >>                       errno, _SysErrorMsg (errno), DisplayString (dpy));
> >[HP-UX]/usr/include/sys/errno.h:
> >#  define ECONNRESET            232     /* Connection reset by peer */
> 
>  |03/18 10:10:45.04 [9308] 599+0: UDP_client_open[7] time://xproxy:37 ...
>  |03/18 10:10:45.04 [9308] 599+0: checkIF-UDP connected [7] {146.103.254.12:37 <- 10.1.1.12:2264} [0.000s]
>  |03/18 10:10:45.04 [9308] 599+0: myname = dmz2.imec.be
>  |03/18 10:10:45.04 [9308] 599+0: server_open(Xpxdisplay,dmz2.imec.be:6010,listen=1)
> ...
>  |03/18 10:10:45.04 [9308] 599+0: Xproxy -- dmz2.imec.be:6012.0 -- 10.1.1.12:12.0
>  |03/18 10:10:45.04 [9308] 599+0: #### Xproxy[9309]:  <- 10.1.1.12:12.0 <- xproxy
> 
> Here DeleGate was trying to select and bind the network interface
> which is reachable from the Telnet server (i.e. X client) hosts.
> (Though this stuff of log seems from the strange "accept" command
> for the host of DeleGate itself, I suppose similar log will be for
> the destination Telnet server host (duchesse.esat.kuleuven.ac.be))
> But the trial seems failed because of strange ? network and DNS ?
> configuration:
>  - "dmz2.imec.be" seems to have (at least) two interfaces,
>    10.1.1.12 and 146.103.254.12
>  - both of those IP addresses are given a common name "dmz2.imec.be"
>  - "xproxy.imec.be" as an alias
>  - a connection to external destination network seems to be
>    established with an address on a private (?) network as
>    a source address
>  - NAT may exist somewhere ??
>  ...

 As stated I think these issues are not part of this
 problem (so for the honest reply, only trying to be observal).
 The only thing is indeed that when you are connected
 to the remote Internet host you have to change the address
 in the setenv DISPLAY  command suggested by Delegate because
 of the address translation indeed.
 This does however work on standard workstations and NT  PC's
 with reflectionX  installed for instance.



> 
> Maybe you can get more informative information with "-vv" option to
> see what is happening in X-proxy server, like this:
> 
>   xproxy% delegated -P8023 -vv SERVER=telnet
> 
>   client% telnet xproxy 8023
>   Hostname: x bristol:0
>   Hostname: duchesse.esat.kuleuven.ac.be
>   ...login...
>   > setenv DISPLAY xproxy...
>   > xterm
> 
> [when not permitted to use the X-proxy]:
>  1+0: E-P: No permission: telserv-2:2825 => X://xserv
>  1+0: -- ident: telserv-2
>  ...
>  1+0: E-C: Can't connect: telserv-2:2825 => X://xserv (?)
>  1+0: No connection
> 
> [when failed to connect to the destination server]:
>  1+0: #### ConnectToServer: DFLT=X://xserv:6001 REAL=://:0
>  1+0: ConnectToServer connect X://xserv:6001
>  1+0: [12] ConnectToServer connect failed xx.xx.xx.xx:6001 [0.00s] 61
>  1+0: ERROR: cannot connect to X://xserv:6001 - -1
>  1+0: E-C: Can't connect: telserv:1027 => X://xserv:6001 (refused)
>  1+0: No connection
> 
> I suppose it possible that the source address of the connection
> for X protocol initiated from duchesse.esat.kuleuven.ac.be
> [134.58.63.135] is not [134.58.63.135] because of some address
> translation or multi-homed configuration of the telnet server...
> 

 No , the NAT  stuff is not affecting the address of this
machine for us.




> Then possibly you can avoid the situation with the enclosed patch,
> which makes the X-proxy bind with wild-card interface,
> and disalbes access restriction about client host of X-proxy.
> 

 Thanks !
 I  will try  this stuff. My  current workbusiness may need
 other attention area's.
 
 I  will try to give you further feedback in time.

 Thanks for your help,

                                 Marc.


> Cheers,
> Yutaka
> --
> Yutaka Sato <ysato@etl.go.jp> http://www.etl.go.jp/~ysato/   @ @
> Computer Science Division, Electrotechnical Laboratory      ( - )
> 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan            _<   >_
> 
> *** ../../delegate5.9.1/src/delegated.c Mon Mar 15 19:18:15 1999
> --- delegated.c Wed Mar 24 14:33:05 1999
> ***************
> *** 3661,3667 ****
> --- 3661,3671 ----
> 
>         pxsock = -1;
>         for( pxport = 6010; pxport < 6100; pxport++ ){
> + /*
>                 pxsock = server_open("Xpxdisplay",pxhost,pxport,1);
> + DEBUG: bind with wildcard interface
> + */
> +               pxsock = server_open("Xpxdisplay","",pxport,1);
>                 if( 0 < pxsock )
>                         break;
>         }
> ***************
> *** 3712,3718 ****
> --- 3716,3727 ----
>         unsetEnv(environ,environ,P_PERMIT);
>         unsetEnv(environ,environ,P_RELIABLE);
>         unsetEnv(environ,environ,P_REACHABLE);
> + /*
>         sprintf(permit,"%s=X:%s:%s",P_PERMIT,disphost,relhost);
> + DEBUG: don't check X-client host
> + */
> +       sprintf(permit,"%s=X:%s:*",P_PERMIT,disphost);
> +
>         av[ac++] = permit;
> 
>         if( env = getEnv(P_CONNECT) ){

-- 

 'Love is truth without any future.
 (M.E. 1997)