RE: Sockets

OK,

I tried telnet with the socket server running.  It just waits.  If I hit
enter, i get the message:

Connection to host lost.


It seems the server program is waiting/listening.   Unfortunately, I did not
write either the server or the client program.  It is a product supplied
with our ERP system.   I'll see what I can work out with them.   Looks like
the network is ok.

Thanks again for the help,

-jose a.
-----Original Message-----
From: Scott Klement [mailto:klemscot@klements.com]
Sent: Thursday, June 06, 2002 11:32 AM
To: midrange-l@midrange.com
Subject: RE: Sockets



On Thu, 6 Jun 2002, Rodriguez, Jose Amable wrote:
>
> Is there anything I have to do to the services table (under tcpadm) so
that
> I can configure the port for telnet.

You aren't trying to enable telnet on that port.   That would defeat the
purpose of the whole test.

The idea of the testing was:

     1) To see if your system is responding to basic IP function, by
            trying to ping it, and see if it responds.

                  ping x.x.x.x

     2) If it does respond, check to see if TCP works over IP by
            using a tested, known good, program like IBM's telnet
            server.

                  telnet x.x.x.x

     3) If that worked, then see if the custom-written TCP server
            is listening for connection requests.   We use a telnet
            client because we want to make sure the program we're
            testing it with is known to be working.  (It doesn't
            do us much good to test a program that may or may not
            be working by using another program that may or may not
            be working... we just end up with more questions that way)

            We use a telnet client to test it because we know that it
            worked in step 2.   But, we're not trying to create a
            telnet session -- we're trying to test the custom server
            program in question.    The way we tell the telnet client
            to connect to the custom server instead of the IBM telnet
            server is by telling it a different port number.

            So, if for example, the custom server program listens
            on port number 8026, we'd do:

                   telnet x.x.x.x 8026

>
> The reason I as is that I tried telnet x.x.x.x portno and I get the
message:
>
>       Connecting To <HOST>...Could not open a connection to host on port
> <portno> :
>       Connect failed


You do NOT want to change the services table.   Changing the services
table would make IBM's telnet server run on the new port (after it has
been restarted)

That's not the goal here.   The goal is to test the custom server program
to see if it's working.

Consequently, we leave the services table alone, and type:

          telnet x.x.x.x 8026

(or what ever the port number is supposed to be!)

Now, if we get a "Connect failed" it can mean one of two things:

        1) A firewall is blocking that port, so we can't get to it.

        2) The custom server is not listening for requests.
            (This could be because it's not running, or it could be
            that it doesn't work)

>
> I also tried adding a telnet entry in the services table and removing the
> other one. That is:
>
> telnet <portno> tcp
> telnet <portno> udp
>
> What do I do next???

Unless you intend to change which port your AS/400 uses for normal telnet
operations, I'd change that services table back to port 23.
Otherwise, it's going to cause major problems.

Hopefully, you understand now what you're trying to accomplish.

Are you the person who wrote the custom server that you're trying to test?
If so, maybe you should take a look at the bind() and listen() statements
in your code.   Make sure that they are working correctly...

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.