Troubleshooting
Problem
It is a 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.
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.
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
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:
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.
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:
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): .
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:
| o | No one can connect to the server. |
| o | One 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 Name | Port Non-SSL | Port SSL | |
| Server Mapper | as-svrmap | 449 | 449 |
| License Management | as-central | 8470 | 9470 |
| Database Access | as-database | 8471 | 9471 |
| Data Queues | as-dtaq | 8472 | 9472 |
| Network Drives | as-file | 8473 | 9473 |
| Network Printers | as-netprt | 8474 | 9474 |
| Remote Command | as-rmtcmd | 8475 | 9475 |
| Signon Verification | as-signon | 8476 | 9476 |
| Telnet (PC5250 Emulation) | telnet | 23 | 992 |
| HTTP Administration | as-admi > | 2001 | 2010 |
| POP3 (MAPI) | pop3 | 5010 | --- |
| Management Central | as-mgtc > | 5555 | 5566 |
| Ultimedia Services | as-usf | 8480 | 9480 |
| DRDA | DRDA | 446 | --- |
| DDM | DDM | 447 | 448 |
| IBM AnyNet | APPCoverTCPIP | 397 (TCP and UDP) | --- |
| IBM iSeries NetServer | netbios > | 137 | --- |
| iSeries NetServer | CIFS | 445 | |
| iSeries NetServer | netbios > | 139 | --- |
| RUNRMTCMD | REXEC | 512 | --- |
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"},"ARM Category":[{"code":"a8m0z0000000CMAAA2","label":"Communications-\u003ETCP"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
437193736
Was this topic helpful?
Document Information
Modified date:
20 June 2023
UID
nas8N1018934