IBM Support

Unable to Start or Connect to TCP/IP Server

Troubleshooting


Problem

It is a very rare scenario to be unable to connect to a specific TCP/IP server such as Telnet or FTP; however, it can occur. It is important to verify if the server is actually "listening" or running on the system when performing proper problem determination.

Resolving The Problem

It is a common scenario to be unable to connect to a specific TCP/IP server such as Telnet or FTP. It is important to verify if the server is actually "listening" or running on the system when performing proper problem determination. As an administrator, you may hear the following:

I can't get any Telnet sessions.
I can't FTP.

Server Not Listening

I will assume that TCP/IP on the IBM Power Systems is up and running and that users can PING the Power Systems. I will also assume the TCP/IP interface on the Power Systems is active. The first thing we want to determine is if the server is running.

Step 1: On the operating system command line, type the following:

NETSTAT

Press the Enter key, and select Option 3 from the menu.

                                                     Work with TCP/IP Connection Status          
                                                             System:
 Type options, press Enter.                                        
   3=Enable debug   4=End   5=Display details   6=Disable debug    
   8=Display jobs                                                  
                                                                   
      Remote           Remote     Local                            
 Opt  Address          Port       Port       Idle Time  State      
      *                *          12         169:06:16  Listen      
      *                *          daytime    194:49:43  Listen      
      *                *          daytime    194:49:44  *UDP        
      *                *          ftp-con >  000:03:21  Listen      
      *                *          telnet     000:04:39  Listen    

This shows us that both FTP and Telnet are in a listen state.

Step 2: Press F14. It shows the same screen; however, it displays the port numbers rather than the names.

                                                          Work with TCP/IP Connection Status  
                                                           
 Type options, press Enter.                                
   3=Enable debug   4=End   5=Display details   6=Disable d
   8=Display jobs                                          
                                                           
      Remote           Remote  Local                      
 Opt  Address           Port    Port  Idle Time  State    
      *                     *     12  169:06:16  Listen    
      *                     *     13  194:49:43  Listen    
      *                     *     13  194:49:44  *UDP      
      *                     *     21  000:03:21  Listen    
      *                     *     23  000:04:39  Listen    


FTP is on Port 21, and it is up and listening. Telnet is on port 23, and it is up and listening. In this scenario, both servers are listening. If the server you are trying to connect to is not listening, that is a possible reason for failure.

Step 3: The server can be ended by running the ENDTCPSVR command. This clears any problems there might be with the server jobs.

ENDTCPSVR *TELNET or ENDTCPSVR *FTP

STRTCPSVR *TELNET or STRTCPSVR *FTP

Step 4: Verify NETSTAT again using Step 1 to determine if the servers are now listening. If the server is still not starting, verify the attributes of the server. On the operating system command line, type each of the following commands, and press F4 to prompt the command:

CHGFTPA

CHGTELNA

Step 5: Both of these servers have a parameter called Allow SSL. If you are not using Secure Socket Layer (SSL) for encrypting data, you might want to set this value to *NO.

Allow secure sockets layer . . .   *NO  

Step 6: Attempt to start the server again. Is it now listening?

Step 7: Exit programs are often a reason for a server not starting. Exit points are programming points in IBM code where users can insert their own program to provide some function or security. If an exit program is registered for a exit point but it does not exist, the server will not start. To display all of the exit points on your system, on the operating system command line type the following:

WRKREGINF

Press the Enter key.

Step 9: Following are the exit points for Telnet:

QIBM_QTG_DEVINIT Telnet Device Initialization
QIBM_QTG_DEVTERM Telnet Device Termination

Following are the exit points for FTP:

QIBM_QTMF_CLIENT_REQ FTP Client Request Validation
QIBM_QTMF_SERVER_REQ FTP Server Request Validation
QIBM_QTMF_SVR_LOGON FTP Server Logon
QIBM_QTMF_SVR_LOGON FTP Server Logon
QIBM_QTMF_SVR_LOGON FTP Server Logon

Step 10: Select Option 8 next to each entry. If an exit program is displayed, determine if the object exists. On the operating system command line, type the following and press F4 to prompt the command:

WRKOBJ

                           Work with Objects (WRKOBJ)                    
                                                                         
 Type choices, press Enter.                                              
                                                                         
 Object . . . . . . . . . . . . .   programname       Name, generic*, *ALL  
   Library  . . . . . . . . . . .     libraryname     Name, *LIBL, *CURLIB...
 Object type  . . . . . . . . . .   *ALL          *ALL, *ALRTBL, *AUTL...


If the program specified in the exit point does not exist, typically the server will not start. Often a user tests OEM security software that registers programs in these exit points. Then, when the user completes testing, the library that these programs reside in is removed. These programs are still registered in the exit points, and the programs no longer exist, which results in the server failing to start.

Step 11: If the server you are trying to connect to is still not listening, there are other options. Display your job log to view any messages regarding the attempted start of the server. On the operating system command line, type the following:

WRKJOB

Press the Enter key, and select Option 10 from the menu. Press F10 for detailed messages, and page up or page down.

Step 12: Attempt to run the ENDTCP command followed by the STRTCP command. Ensure you are at the console and realize that any and all TCP/IP communications are going to end during the time TCP is down.

If you are still not able to start the TCP server and get it into a listen state, contact Software Support for advanced problem determination.


Server Listening, However Cannot Connect

We have verified that the server you are trying to connect to is listening and that the user can PING the Power Systems. This tells us the user has TCP/IP connectivity to the Power Systems and that the server is listening and ready to service any incoming requests. This issue can involve the following issues:
oNo one can connect to the server.
oOne user or one location cannot connect to the server.

No One Can Connect to Server X

No one can FTP or no one can Telnet. If the server is up and listening in NETSTAT but no one can connect, there are only a few things to verify on the Power Systems. First, determine that it is not only one location or one person with the problem. Test the function from a PC local to the Power Systems. This verifies that the issue is on the Power Systems and not an external issue. If a local user (same TCP/IP subnet as the Power Systems) can FTP or Telnet or use the specific TCP server, refer to the next section regarding one location.


Telnet

No one can Telnet, and the server is in a listen state.

Step 1: On the operating system command line, type the following:

WRKSBS

Press the Enter key, and press F11.

QINTER               1.60   516337      125   ACTIVE

Step 2: Is QINTER subsystem up and active? If not, try starting it using the STRSBS QINTER command. On the operating system command line, type the following:

WRKSYSVAL QAUTOVRT

Press the Enter key. Type 5 to display.

What is this system value set to? Each Telnet connection is going to use a virtual device. Having this value set to 0 or too low will prevent new connections.

If there are any exit programs associated with the Telnet exit points, this could prevent users from connecting.

Step 3: On the operating system command line, type the following:

WRKREGINF

Press the Enter key.

The following are the exit points for Telnet:

QIBM_QTG_DEVINIT Telnet Device Initialization
QIBM_QTG_DEVTERM Telnet Device Termination

Select Option 8 next to each exit point. Is there a program listed? If so, you have customized your Power Systems. Software Support does not know what your program is doing and cannot diagnose it. However, it is suggested that the exit program be removed and that the server be ended and started again. If this resolves the issue, contact the provider of the exit program to determine why the application is blocking connections.

                                               Work with Exit Programs        
                                                           
 Exit point:   QIBM_QTG_DEVINIT         Format:   INIT0100  
                                                           
 Type options, press Enter.                                
   1=Add   4=Remove   5=Display   10=Replace                
                                                           
               Exit                                        
             Program     Exit                              
 Opt          Number     Program        Library            
 
 4                       security       mylibrary  

If you have determined that Telnet is listening in NETSTAT, QINTER is active, QAUTOVRT system value is set to *NOMAX or a sufficient level, and there are no Telnet exit programs, contacting Software Support is suggested to obtain a more in-depth analysis.


FTP

If no one, including local users, is able to FTP to the Power Systems, on the operating system command line type the following:

WRKREGINF

Press the Enter key. Any exit programs associated with the FTP exit points could be restricting users from connecting.

The following are the exit points for FTP:

QIBM_QTMF_CLIENT_REQ FTP Client Request Validation
QIBM_QTMF_SERVER_REQ FTP Server Request Validation
QIBM_QTMF_SVR_LOGON FTP Server Logon
QIBM_QTMF_SVR_LOGON FTP Server Logon
QIBM_QTMF_SVR_LOGON FTP Server Logon

Select Option 8 on each. If there are any exit programs associated with any of these exit points, the system is customized. Software Support is not able to do any problem determination on these programs. One option is to remove this association by selecting Option 4 to remove and end and start the server again. If this resolves the issue, contact the provider of the exit programs to determine the failure.

If the FTP server is in a listen state in NETSTAT and there are no exit programs associated with the FTP exit point, it is recommended that you contact Software Support for further problem determination.


One Location or One User Cannot Connect

An important concept regarding TCP/IP connectivity and connections to specific TCP servers is ports. Each TCP/IP server "listens" on a specific port. Common servers (servers that are not specific to IBM or Power Systems but are specific to TCP in general) have an assigned port that they listen on. Telnet typically listens on port 23. FTP typically listens on port 21. Custom applications or servers will listen on their own ports. To make a connection to these servers (and ports), a clear communications path on that port must be available. A firewall is a piece of network hardware that provides security by restricting usage on the network. It might restrict or allow only certain TCP/IP addresses through, or it might allow or have open only specific ports. Understanding what port your application or function is trying to use is essential in a TCP/IP network. Firewall restrictions are the cause of a great deal of connectivity issues, especially with remote sites.

Is the user who is trying to Telnet or FTP to the Power Systems local or remote? To clarify, is the user on the same network or network subnet as the Power Systems? On the operating system command line, type the following:

CFGTCP

Press the Enter key, and select Option 1 from the menu

This will show you the TCP/IP interfaces on the Power Systems. One of these addresses should be the address you are trying to connect to. Is the PC on the same network?

Example

Power Systems address: 192.168.10.100 subnet mask: 255.255.255.0

This tells me that the Power Systems is on a 192.168.10 network and that any user with a 192.168.10.x address is on the same network. Any user trying to connect to the Power Systems with any other address is remote. This is key because often remote users will fail when local users can connect. The reason for this is often the use of firewalls.

If a local user can FTP to the Power Systems but a remote user cannot, firewall restrictions should be verified. If a local user can use any TCP/IP server or application but a remote user cannot, firewall restrictions should be verified.

FTP control connection uses port 21. Telnet uses port 23. Other TCP/IP applications use other ports. Some common ports used in conjunction with IBM iSeries Access for Windows are as follows:


Server NamePort Non-SSLPort SSL
Server Mapperas-svrmap449449
License Managementas-central84709470
Database Accessas-database84719471
Data Queuesas-dtaq84729472
Network Drivesas-file84739473
Network Printersas-netprt84749474
Remote Commandas-rmtcmd84759475
Signon Verificationas-signon84769476
Telnet (PC5250 Emulation)telnet23992
HTTP Administrationas-admi > 20012010
POP3 (MAPI) pop35010---
Management Centralas-mgtc > 55555566
Ultimedia Servicesas-usf84809480
DRDADRDA446---
DDMDDM447448
IBM AnyNetAPPCoverTCPIP397 (TCP and UDP)---
IBM iSeries NetServernetbios >137---
iSeries NetServerCIFS 445
iSeries NetServernetbios >139---
RUNRMTCMDREXEC512---

From the chart it should be noted that for full functionality of iSeries Access for Windows, ports 23, 449, and 8470-8476 should be open on any firewall that the communications is going through.

The following scenario is fairly common. A company has local users and three remote sites. Local users are able to FTP or use TCP application X. Remote site 1 and remote site 2 are able to FTP, or use TCP application X. Remote site 3 is not able to FTP or use TCP application X. If all users are connecting to the same TCP/IP address on the Power Systems, the problem is not typically on the Power Systems. All users are coming into the same TCP/IP interface on the Power Systems, using the same ports and same jobs. Therefore, focus attention on a firewall at the remote site 3.

For a common telnet startup issue, you should refer to Rochester Support Center Knowledgebase document N1014641,Telnet Fails after System Save (GO SAVE 21): .

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0"}]

Historical Number

437193736

Document Information

Modified date:
18 December 2019

UID

nas8N1018934