× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Connection through a telnet-gateway
  • From: "Hilbig, Andreas" <AH4@xxxxxxxxxxxxxxxx>
  • Date: Wed, 19 Jul 2000 14:26:10 +0200

Hi,

first I want to thank you all for your comments. I think I'll try to
implement
it the way Scott dreamt because indeed I think it's not such a not-normal
situation to have security-mechanisms like tn-gw between client and AS400.

My first attempt wasn't successfull, because I didn't read the whole source
-
and so I don't now how to send a string to the tn-gw and when to query the
stream for the tn-gw-prompt. 
However... I made a guess and modified telnet_stream_connect by adding the
following lines befor the 'return 0':

   if (proxyPrompt) {
           telnet_stream_wait_string(This, proxyPrompt);
   }

   if (proxyCmd) {
           telnet_stream_write(This, proxyCmd, strlen(proxyCmd));
   }

Therefore I wrote the following telnet_stream_wait_string - function:

/****i* lib5250/telnet_stream_wait_string
 * NAME
 *    telnet_stream_wait_string
 * SYNOPSIS
 *    ret = telnet_stream_wait_string (This);
 * INPUTS
 *    Tn5250Stream *       This       - 
 *    char *               searchstr  -
 * DESCRIPTION
 *    Reads data from the stream until specified string appears;
 *    Returns 0 if successfull or -1 if no data is
 *    currently available on the socket or -2 if we have been disconnected.
 *****/
static int telnet_stream_wait_string(Tn5250Stream * This, char * searchstr)
{
   int rc = 0;
   int bnfound = 1;
   int len = strlen(searchstr);
   int nbuf=0;

   char *buf = (char *) malloc(len+1);

   buf[0]=0;
   buf[len] = 0;
   while (rc >=0 && bnfound) {
      rc = telnet_stream_get_next(This);
          printf((char) rc);
      if (rc>=0) {
         buf[nbuf]= (char) rc;
         
         if (nbuf < len-1)
            nbuf++;
         else {
            bnfound=strcmp(buf, searchstr);
            strcpy(buf, buf+1);
         }
      }
   }

  if (!bnfound)
     rc = 0;
  free(buf);
  return rc;
}


The result was endless waiting... I guess it wasn't enough negotiation
before querying the
stream.

Who can give me a hint ?


> -----Ursprüngliche Nachricht-----
> Von: Jason M. Felice [mailto:jfelice@cronosys.com]
> Gesendet: Mittwoch, 12. Juli 2000 22:17
> An: LINUX5250@midrange.com
> Betreff: Re: Connection through a telnet-gateway
> 
> 
> Scott Klement wrote:
> > 
> > On Tue, 11 Jul 2000, Michael Madore wrote:
> > 
> > > Hi,
> > >
> > > >
> > > > Hmm, I'm not sure about the kind of thing your talking 
> about, but I can
> > > > imagine three possibilities:
> > > >
> > > > 1) A plain old telnet gateway (e.g. not a tn5250 
> gateway) that requires
> > > >    you to type in the name of the remote host at a 
> prompt once you
> > > >    sign on.  This would
> > >
> > > This is what tn-gw is.
> > >
> > > Mike
> > >
> > 
> > I'm dreaming up a quick hack to telnetstr.c to solve this problem...
> > 
> > I don't know if this is a good idea, or not... but I 
> thought I'd drop it
> > into E-mail while I'm dreaming it... :)
> > 
> > 1)  Have 2 new options for tn5250rc,  proxy_name, and proxy_prompt
> >         (or maybe gateway_xxx instead of proxy_xxx)
> > 
> > 2)  in telnetstr.c, in the telnet_stream_connect() function, have it
> >        check these options, and if they were specified, have it wait
> >        for the string given in "proxy_prompt", and when thats found,
> >        send the string in "proxy_name".
> > 
> > 3)  then end the telnet_stream_connect function, and let it do the
>         remainder of the work the way that it always does...
> 
> Assuming that tn-gw didn't gobble up any telnet option negotiation. 
> Actually, come to
> think of it, we're pretty passive with the option negotiation and wait
> for the server to
> query us.
> 
> > 
> > Perhaps that would solve Andreas' problem, and also add a 
> nice feature
> > to tn5250?
> 
> It's a weird situation, in other words (I think) a not-normal 
> situation
> that should be
> handled a different way.  I think the way to handle that is to write a
> preload object that
> implements the 'connect' function and negotiates with the 
> telnet proxy. 
> I've done similar
> for other functions.  See the sslwrap package for something similar:
> they re-implement the
> getpeername() function to return the forwarded address instead of the
> forwarding address
> for the spawned application.
> 
> Something like this would do the trick (not even tested, 
> folks, might be
> crashware):
> 
> struct sockaddr_in proxy_host = { AF_INET, htons(23),
> inet_addr("my.proxy.host") };
> 
> int connect (int fd, struct sockaddr *name, int namelen)
> {
>       static void *dlh = NULL;
>       static int (* real_connect) (int, struct sockaddr *, int);
>       int rc;
>       if (dlh == NULL) {
>               dlh = dlopen("/lib/libc.so.6", RTLD_LAZY);
>               if (dlh == NULL)
>                       return -1;
>               real_connect = dlsym (dlh, "connect");
>               if (real_connect == NULL)
>                       return -1;
>       }
> 
>       if (name->sa_family == AF_INET && ((struct 
> sockaddr_in*)name)->sin_port
> ==
>               htons(23)) {
>               rc = (*real_connect) (fd, &proxy_host, 
> sizeof(proxy_host));
>               if (rc == -1)
>                       return -1;
> 
>               /* Insert code to negotiate with telnet gateway 
> here... */
> 
>       } else {
>               return (* real_connect) (fd, name, namelen);
>       }
> 
>       return 0;
> }
> 
> Then:
> 
> export LD_PRELOAD=/path/to/myconnect.so
> tn5250 my.as400.com
> 
> or just:
> 
> LD_PRELOAD=/path/to/myconnect.so
> 
> It's a dirty trick and I've used it a few times to add the 
> logic to deal
> with strange
> proxies and other network situations where the application would
> otherwise need to be
> hacked.
> 
> > 
> > -Scott
> > 
> 
> -Jason M. Felice
> (jfelice@cronosys.com)
> +---
> | This is the LINUX5250 Mailing List!
> | To submit a new message, send your mail to LINUX5250@midrange.com.
> | To subscribe to this list send email to LINUX5250-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> LINUX5250-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: 
> david@midrange.com
> +---
> 
+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.